V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.
Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.
Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
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
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: