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).
Řešení dotazu:
Raději nijak. Doporučuji do vnitřní sítě / stroje dotáhnout IPv6 a vevnitř už rozvést nativně.
Uniká mi totiž, k čemu vám bude hypotetický překlad, když nebudete moci zadat cílovou adresu. Bijekce se mezi množinami s různým počtem prvků (adres) dělá blbě.
Pridavam se k dotazu a pokusim se popsat situace, kdy by to mohlo byt potreba:
Dejv
(1) není problém (pokud se omezíme na omezený počet spojení). Prostě se na NAT64 vyhradí vnitřní rozsah pro SNAT a příchozím IPv6 spojení se přiřadí zdrojová adresa z vyhrazeného rozsahu a cílová se přepíše na adresu vnitřního zařízení. Mapování z cílové adresy zvnějšího IPv6 do vnitřního IPv4 lze udělat algoritmicky například vestavěním IPv4 adresy do IPv6 adresy. Počet spojení bude samozřejmě omezen velikostí vyhrazeného vnitřního IPv4 rozsahu.
(2) je, co tazatel zřejmě chtěl. Vzhledem k tomu, že globální IPv6 adres je mnohem více než soukromých IPv4 adres, není možné zevnitř zahájit komunikaci s kýmkoliv. Buďto se vybere malý IPv6 rozsah, který dá bijektivně namapovat do vnitřního IPv4. To je ale prakticky použitelné jen pro vnitřní kontrolovaná prostředí, kde si toto omezení lze dovolit. V opačném případě musí by se musel zapojit dynamické mapování DNS záznamů do vyhrazeného IPv4 rozsahu a držet DNS a NAT mapování v synchronizaci (a s rozumnou životností). Dříve se věřilo, že to půjde, praxe ukázala, že je to natolik ošklivé, že se toto řešení a tedy i celý bod (2) označil za zhoubný a nepodporovaný (stavěl na tom článek na Lupě, který představoval NAT64).
(3) S NAT64 máte blok veřejných IPv4 adres na které staticky mapuje stejně chudý počet vnitřních IPv6 adres. Zdrojové není problém namapovat algoritmicky, protože vnější IPv4 se do vnitřního IPv6 podprostoru vleze. Daly by se zapojit i vnější transportní adresy, ale dokud se nerozšíří dohledávání serverů přes NAPTR/SRV záznamy na straně klientů, tak to bude komerčně/uživatelsky neprůchodné, protože psát k adrese i číslo portu se nenosí.
(4) není problém. Prostě se veřejný IPv4 algoritmicky namapuje do vnitřního IPv6 podprostoru. Zvenku se pouze naptuje zdrojová transportní v4 adresa. Umí TRT. Nebo jako standardní součást NAT64, kdy se vyhradí blok veřejných IPv4 adres a natuje se z něj. Počet spojení je pak ale omezen na počet vnějších IPv4 adres. TRT obslouží více spojení, protože si vypomůže transportním prostorem.
Tiskni
Sdílej: