Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
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:
