Vyjádřeni Software Freedom Conservancy (SFC) k porušování licence AGPLv3 společností Bambu Lab v jejich softwaru Bambu Studio pro 3D tisk. Bambu Studio vychází z PrusaSliceru. Ten zase z Slic3ru. Spuštěn byl projekt baltobu, který kombinuje několik strategií pro řešení problému. SFC zastřeší vývoj svobodné náhrady proprietární knihovny libbambu_networking pomocí reverzního inženýrství a reimplementace, forku OrcaSliceru pro Bambu Lab tiskárny od Paweła Jarczaka a forku celého Bambu Studia pod názvem Viscose.
Správce souborů GNOME Commander (Wikipedie) byl přepsán do Rustu a vydán v nové verzi 2.0.0.
Sway (Wikipedie), dlaždicový (tiling) správce oken pro Wayland kompatibilní s i3, byl vydán ve verzi 1.12. Do vývoje se zapojilo 50 vývojářů. Přehled novinek na GitHubu. Sway 1.12 závisí na wlroots 0.20.0.
Papež Lev XIV. ve své první encyklice Magnifica Humanitas (Skvělé lidství), která se věnuje umělé inteligenci (AI), varoval před dezinformacemi, které AI manipulací s obsahem vytváří. Moc mají podle něj sociální sítě ovládané hrstkou soukromníků. Upozornil také roli digitálních platforem v obchodování s lidmi, které podle něj musí být uznáno jako současná forma otroctví. Papež se také poprvé omluvil za roli, kterou Vatikán sehrál při legitimizaci otroctví, a za to, že jej po staletí neodsoudil.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2025 (pdf), která shrnuje jeho hlavní aktivity v oblasti regulace elektronických komunikací, poštovních služeb, digitálních služeb a přípravy na dohled nad umělou inteligencí. Součástí zprávy jsou také data o vývoji trhu, včetně pokračujícího růstu spotřeby mobilních dat a rozšiřování sítí nové generace. Celkový objem přenesených mobilních dat dosáhl v roce 2025 přibližně
… více »Tým sdružení CZ.NIC vyvíjející routovacího daemona BIRD oznámil vydání nových verzí 3.3.0 a 2.19.0. Ty přinášejí podporu pro EVPN/VXLAN a automatizaci BGP na základě router advertisementů. Více informací je k dispozici v archivu uživatelského mailing-listu.
Open source software pro úpravu digitálních fotografií LightZone (Wikipedie) byl vydán v nové verzi 5.0.0. LightZone je dnes k dispozici pod licencí BSD. Původně se jednalo o proprietární software vyvíjený společností Light Crafts. Ta v prosinci 2012 souhlasila s uvolněním zdrojových kódů jako open source [Wayback Machine].
Byla vydána verze 0.84 telnet a ssh klienta PuTTY (Wikipedie). Podrobnosti v přehledu nových vlastností a oprav chyb a Change Logu.
Microsoft představil Azure Linux 4.0 a Azure Container Linux. Na konferenci Open Source Summit North America 2026 organizované konsorciem Linux Foundation a sponzorované také Microsoftem. Azure Linux 4.0 vychází z Fedora Linuxu. Azure Container Linux je založen na projektu Flatcar. Azure Linux (GitHub, Wikipedie) byl původně znám jako CBL-Mariner.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 165 (pdf).
ifconfig ath0 0.0.0.0 up
ifconfig ath1 0.0.0.0 up
ifconfig eth0 0.0.0.0 up
brctl addbr br0
brctl addif br0 ath0
brctl addbr br0 ath1
brctl addbr br0 eth0
ifconfig br0 1.2.3.4....
Pokud na to AP nemas pristup a potrebujes resit takovehle veci, tak se tak trochu nabizi otazka co je to za AP? Ze by nejake KFC nebo sousedovo ADSL?
Zdenek
Ale zkusil sis dat do bridge AP i Client kartu? Pokud jo, chodilo to? Protoze pokud to chodilo, tak by me zajimaly podrobnosti, nebot me to proste nechodi. Proto tady taky tak nahlas placu
A jak je to tu uz napsane, tak to bude souviset s problemem MAC adres. Tedy nezbyva mi, nez tomu verit, ja jsem se tim nikdy zabyvat nemusel.
Proste najedou vyvstala potreba udelat "prevadec" na prodlouzeni dosahu wifi a v jednom pripade ze dvou uvedenych to musi byt transparentni bridge.
Karticky jsou Atherosky a ovlada je madwifi. WDS neni nikterak realizovan, pouze jsem polozil dotaz, abych vedel, jakym smerem se dal ubirat.
Jde o to, ze je WiFI AP, na ktere se ja potrebuji jednou kartou chytit a druhou pouzit jako AP a k ni se pak pripojovat. A jak jsem psal vyse, tak potrebuji, aby to bylo transparentni a prochazely i DHCP pozadavky, atp...
Jo, taky jsem uz nekde cetl, ze MadWifi umi WDS (jako jeden z mala WiFi ovladacu ve svobodnem linuxu). Nicmene par veci se mi na WDS nelibi:
- pokud se tyce sifrovani, umi bezne jenom WEP (v nekterych implementacich udajne i WPA-PSK)
- pokud z toho vyplyne vice radiovych hopu na spolecnem kanale, tak s kazdym hopem spadne efektivni kapacita na polovinu, coz mi pro me pouziti vadi (pokud to potrebujete na jeden hop, tak je to kapacitne srovnatelne s AP/Client)
- smiseny provoz WDS+Client je opet k dispozici pouze v nekterych implementacich
Proste pro prakticke pouziti je WDS docela hnus. Oni ale ty "hnusne vlastnosti" plynou nejspis z principu - radiovy kanal je kolizni segment s Alohou, lepsi sifry jako WPA/WPA2 jsou point-to-point (takze s multihop WDS nejdou zkombinovat) apod.
Trochu s nadeji sleduju 802.11s mesh, ale spis mam strach, ze to nakonec bude stizeno obdobnym klubkem principialnich problemu, jako svazuje prave WDS. Navic je to zatim jenom draft, a linuxova implementace tohoto draftu zatim autentikaci natozpak sifrovani payloadu nijak neresi.
Pokud se tyce Vaseho pripadu, opravdu by to neslo routovat? Pokud na tom "klientskem" APcku nechcete rozjizdet plnohodnotny DHCP server, co treba jenom DHCP relay? Na treti vrstve uz by to zase bylo koser i s wifinou v obycejnem rezimu AP/Client.
PS: Jak to ted ctu, tak si rikam, jestli je to vubec srozumitelne
Takze bych rad na WRAPu udelal to same, co je na techto jednotkach. Tedy aby bridge fungoval, byt bych ozelel DHCP. Ale asi bude nejschudnejsi udelat to s NATem a DHCP na WRAPu. A v druhem pripade, kde se dostanu i k "hlavnimu" AP to udelat routovane.
Problem je v tom, ze na toto tema se clovek zas tak moc veci nedocte, protoze drtiva vetsina clanku je "Stavime AP" a nebo "Jak na WISP".
MACky klientu (treba za switchem) byly vsechny videt i na APTo bych docela chtěl vidět... jak AP (bez WDS) vidělo za klienta (bez WDS), když klient posílá rámec jenom se třema MAC adresama, z nichž jedna je MAC AP, druhá MAC cílovýho stroje za AP. Nevěřim tomu.
kurviSpíš nemá ty dvě pozice v rámcích pro svoji MAC i MAC skutečného odesilatele. Takže bude umět obsloužit jen jednoho odesilatele přes svoji vlastní jedinou MAC adresu (případně naklonovanou MAC toho jediného odesílatele).
Problemy s timhle spojene jsou straslive. Napr. neni mozne za takovou wifi krabickou mit router.Tenhle nesmysl bereš kde? Router (jeden) tam samozřejmě být může. Má jednu MAC adresu na rozhraní k wifi klientovi, stejně jako jakýkoli jiný stroj. Směšuješ dvě vrstvy.
Zkousel jsi ten WRAP nastavit s bridgem a klientum na svem AP nastavit staticke IP adresy.Problém není s klientama, ale s tím, že za klientem může být několik zařízení s různými MAC. Statická nebo dynamická IP na tohle nejspíš nebude mít tak úplně vliv (i kdyby, switch to celé rozbije filtrováním MAC).
broadcasty tam litaj jak splasenyNelítaj. Neni důvod.
Vubec to primarni AP je dost zmagoreny ze ma vetsi mnozstvi IP adres se stejnou MAC adresou.Zrovna s tím nebude mít AP nejmenší problém. Zvlášť pokud se jedná o transparentní AP, které používá IP vrstvu jen na konfiguraci a rovnání času.
Tak si nejakej sezen. Dlink se asicouje na AP nekolikrat, za kazdou MACku prichazejici z ethernetu.MACky klientu (treba za switchem) byly vsechny videt i na APTo bych docela chtěl vidět... jak AP (bez WDS) vidělo za klienta (bez WDS), když klient posílá rámec jenom se třema MAC adresama, z nichž jedna je MAC AP, druhá MAC cílovýho stroje za AP. Nevěřim tomu.
Ze zkusenosti (edimax 5409APg + edimax BR6104K). Router s NATem tam byt muze, ale jak jsem NAT vypnul a nastavil bezne staticke routovani tak jsem si ani neskrtl. Do te doby jsem to s dlinky (dlink 900 + edimax BR6104K) pouzival bezne. Pak uz prisly na trh zarizeni s wifi a routerem v jednom.Problemy s timhle spojene jsou straslive. Napr. neni mozne za takovou wifi krabickou mit router.Tenhle nesmysl bereš kde? Router (jeden) tam samozřejmě být může. Má jednu MAC adresu na rozhraní k wifi klientovi, stejně jako jakýkoli jiný stroj. Směšuješ dvě vrstvy.
Mel jsem na mysli router, proste branu toho subnetu. AP samotne to vlastne byt nemusi, i kdyz vetsinou miva. ------ Osobne tuhle zrudnost povazuju za nejvetsi prusvih na wifine.Vubec to primarni AP je dost zmagoreny ze ma vetsi mnozstvi IP adres se stejnou MAC adresou.Zrovna s tím nebude mít AP nejmenší problém. Zvlášť pokud se jedná o transparentní AP, které používá IP vrstvu jen na konfiguraci a rovnání času.
Tak si nejakej sezen. Dlink se asicouje na AP nekolikrat, za kazdou MACku prichazejici z ethernetu.Jako odpověď stačí :). Shánět si to nepotřebuju. Vícenásobná asociace by leccos vysvětlovala, i když je to totální alchymie na jinak bezstavovym ethernetu. Docela by mě zajímalo, za jakých okolností ty asociace ruší, ale to už je vrtání se v nějakém konkrétním řešení. Good point, beru jako přínos do diskuze.
Ze zkusenosti (edimax 5409APg + edimax BR6104K). Router s NATem tam byt muze, ale jak jsem NAT vypnul a nastavil bezne staticke routovani tak jsem si ani neskrtl. Do te doby jsem to s dlinky (dlink 900 + edimax BR6104K) pouzival bezne. Pak uz prisly na trh zarizeni s wifi a routerem v jednom.Hádám na špatné nastavení IP vrstvy, tzn spíš konfigurační chybu než technické omezení.
Mel jsem na mysli router, proste branu toho subnetu. AP samotne to vlastne byt nemusi, i kdyz vetsinou miva.
Osobne tuhle zrudnost povazuju za nejvetsi prusvih na wifine.Mno... osobně považuju za největší zrůdnost směšování různých vrstev tam, kde k tomu není *velmi* dobrý důvod. Jediný problém v adresování wifi rámců vidím v tom tříadresovém formátu, který prostě nepočítal s bridgováním na klientské straně. Na druhou stranu vyhybání se bridgingu mezi wired a wireless celý problém řeší (pokud člověk zvládne nakonfigurovat routing).
Tiskni
Sdílej: