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).
Nějak mi občas nefunguje načítání doplňkových souborů k uloženým html stránkám, tak jsem se snažil zjistit, čím to je a udělal jsem pokus:
Vyrobil jsem si dva html dokumenty (dal jsem je tady do přílohy, ať na ně vidíte). Jsou v něm odkazy - jeden dokument odkazuje na druhý dokument a naopak, takže kliknutím na odkaz se dostanete z jednoho dokumentu na druhý. Odkazy jsou dělané pomoci relativní cesty, v tomto případě cesta obsahuje jenom název souboru. Názvy těchto souborů neobsahují mezery, háčky, čárky nad písmenem, ani podobné nevhodné znaky. Aby tyto odkazy fungovaly, oba html soubory musí být umístěné společně v jedné složce. Dokumenty jsem vyrobil ve znakové sadě UTF-8. Odkazy fungují, jak mají. Dokonce i když název složky, ve které jsou umístěné, nebo název kteréhokoliv nadřazeného adresáře, obsahuje háčky, čárky, mezery a pod, nevadí, nemá to na funkci vliv.
Potom jsem zkusil oba html dokumenty převést do jiné znakové sady, například na ISO 8859-2 a samozřejmě jsem nezapoměl ani opravit tag meta, aby v něm zapsaná znaková sada odpovídala te použité. Tyto dokumenty jsem zkusil otevřít v prohlížeči, zobrazují se opět čitelně a fungují i odkazy, ale odkazy fungovaly jenom do te doby, než jsem některý z nadřazených adresářů pojmenoval názvem, obsahujícím háčky, čárky nad písmeny, mezery a podobně. Potom mi přestalo fungovat klikání na odkazy v těch dokumentech a hlásilo se něco podobného, jako: Chyba při načítání /home/david/Nov??slo?ka/clanky/clanek2. Soubor /home/david/Nov??slo?ka/clanky/clanek2 neexistuje. Když jsem v prohlížeči ručně nastavil znakovou sadu UTF-8, samozřejmě se texty zobrazovaly nečitelně (což je v pořádku), ale klikání na odkazy fungovalo.
Čím to je, že to tak blbne? A zjistil jsem, že podobné problémy jsou nejen s klikacími odkazy typu a href=, ale i img src= a možná i dalších. Později jsem zjistil další věc: Pokud nastala ta situace, kdy ty odkazy nefungují (například výše popisovaný pokus), tak nefungují, jen když ty dokumenty prohlížím v Konqueroru; když jsem je otevřel v Mozille Firefoxu, tak to funguje normálně. Není to nakonec chyba Konqueroru? Verzi Konqueroru se mi nepovedlo zjistit, ale jestli to pomůže, mám KDE verze 3.5.7.
Všechny ne-ASCII znaky by v URL měly být zaescapované, potom nebudete mít problém nikde.
Jak se znaky zaescapovávají?
Jinak - v těch mých html dokumentech v URL žádné ne-ASCI znaky nemám, takže nemám co zaescapovávat a cesty v URL tam používám zásadně relativní. Ty ne-ASCI znaky mám jenom v nadřazených adresářích (které už nemám ani nemusím mít uvedené v cestách těch URL) a přesto mají někdy blbé účinky, jak jsem popisoval. Bude muset být chyba v moje verzi Konqueroru. Vám všem to v Konqueroru taky dělá v popisovaných případech ty samé problémy, jak mi?
Jak poznám, jestli můj lokální souborový systém je v UTF-8? (ikdyž nejspíš bude) A platí obecně pravidlo, že bych měl do počítače ukládat html dokumenty jenom ve stejné znakové sadě, jak můj lokální souborový systém? Pokud toto pravidlo platí, není to dobré, protože co když budu například chtít své html dokumenty vypálit a půjčit někomu, kdo má v počítači souborový systém v jiné znakové sadě? Potom se mu můžou blbě načítat doplňující soubory k těm mým html souborům a podobně, pokud by v tom počítači byl některý z nadřazených adresářů pojmenovaný názvem obsahujícím ne-ASCI znaky. Hrozí ten problém?
Jak poznám, jestli můj lokální souborový systém je v UTF-8?V linuxu bohužel názvy souborů neobsahují znaky, ale bajty. Takže neexistuje nic jako systémové nastavení kódování názvů souborů – každá aplikace si názvy souborů interpretuje sama. Normálně k tomu ale aplikace používají kódování nastavené v locale. Takže když si z příkazového řádku spustíte příkaz
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
locale a ve výpise budete mít u jednotlivých parametrů „UTF-8“, bude drtivá většina programů používat pro kódování názvů souborů UTF-8.
A platí obecně pravidlo, že bych měl do počítače ukládat html dokumenty jenom ve stejné znakové sadě, jak můj lokální souborový systém?Žádné takové pravidlo neplatí, byl by to nesmysl. To vámi popsané chování je jednoznačně chyba Konqueroru – používá pro ten samý text jinou kódovací tabulku pro dekódování a jinou pro kódování.
Jak se znaky zaescapovávají?Jednoduše podle tabulek UTF-8, resp. jiného kódování, které máte (pro UTF-8 lze vyhledat kódy např. v KCharSelect). Místo každého kódovaného bajtu se uvede %XX, které vyjadřuje hexadecimální hodnotu onoho bajtu. V UTF-8 má např. „ř“ hodnotu dvou bajtů 0xC5 0x99 a zaescapované je „%C5%99“.
Jinak - v těch mých html dokumentech v URL žádné ne-ASCI znaky nemám, takže nemám co zaescapovávat a cesty v URL tam používám zásadně relativní.V tom případě je chyba v prohlížeči. Qt (KDE) a GNOME aplikace mají obecně problémy pracovat s adresáři, jejichž názvy jsou v jiném kódování, než které uvádí locales, protože interně používají UCS-2 a při převodu tak jméno rozbijí.
Vám všem to v Konqueroru taky dělá v popisovaných případech ty samé problémy, jak mi?Ano, mám přes NFS připojený oddíl, kam nahrávají přes FTP lidé z Windows soubory a adresáře v kódové stránce CP-1250, takže můj Konqueror je potom nedokáže otevřít, protože já používám UTF-8.
A platí obecně pravidlo, že bych měl do počítače ukládat html dokumenty jenom ve stejné znakové sadě, jak můj lokální souborový systém?Pokud budete používat ne-ASCII znaky v relativních URL, tak ano, neexistuje způsob, jak je tam zapsat tak, aby správně fungovaly. URL nadřazených adresářů dodá souborový systém, takže o ně se starat nemusíte.
A platí obecně pravidlo, že bych měl do počítače ukládat html dokumenty jenom ve stejné znakové sadě, jak můj lokální souborový systém?
Pokud budete používat ne-ASCII znaky v relativních URL, tak ano, neexistuje způsob, jak je tam zapsat tak, aby správně fungovaly. URL nadřazených adresářů dodá souborový systém, takže o ně se starat nemusíte.
Žádné ne-ASCII znaky v URL nepoužívám, přesto Konqueror načítání těch URL neumí, pokud ten soubor HTML má kódování jiné, než UTF-8, a pokud přitom někde v nadřazeném adresáři někde nad tím HTML dokumentem (a to ikdyž jde o adresář, který v těch URL neuvádím, ani nepotřebuji uvádět, protože URL mám relativní) je nějaký ne-ASCII znak. Proto kvůli chybě v Konqueroru jsem nucený se stareat i o znaky názvů všech nadřazených adresářů, nebo jsem nucený používat to nesmyslné omezující pravidlo, co jsem teď znovu opsal v první větě citace.
Podle příkazů locale aplikace používají znakovou sadu UTF-8.
Tiskni
Sdílej:
