Byla vydána nová verze 3.2.8 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Projekt openSUSE dnes, 3. listopadu 2026, oficiálně vydal openSUSE Leap 16.1, novou verzi své stabilní linuxové distribuce. Novinkou je také Immutable Mode, který nahrazuje dosavadní samostatnou distribuci openSUSE Leap Micro. Podrobnosti o novém vydání najdete v oficiálním oznámení nebo v českém překladu oznámení. Instalační obrazy jsou již dostupné na get.opensuse.org. Vydání společně oslavíme v pátek ve virtuálním baru a na … více »
Bylo oznámeno vydání Fedora Linuxu 45. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora Cloud pro cloudové nasazení, Fedora CoreOS pro ty, kteří preferují neměnné systémy a Fedora IoT pro internet věcí. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách
… více »Vědci z MIT CSAIL představili koncept 'weight-space programming' a názorně předvedli, že pokročilé jazykové modely SI dokážou přímo číst a upravovat váhy neuronových sítí. Studie ukazuje, že modely nejen dokážou identifikovat účel sítí z pouhého nahlédnutí do jejich číselných vah, ale mohou i cíleně opravovat chyby a nedostatky, například GPT-6 Astra se změnou pouhých 0,016% vah open-weight modelu Qwen3.5-0.8B podařilo odstranit
… více »Organizátoři komunitního setkání nejen českých a slovenských správců sítí CSNOG 2027, které se uskuteční 20. a 21. ledna na půdě zlínské univerzity Tomáše Bati, oznámili prodloužení termínu pro zasílání abstraktů do programu akce. Zájemci se mohou hlásit prostřednictvím webu setkání do úterý 10. listopadu. Programová komise uvítá příspěvky věnované nejen správě sítí, ale také legislativě a regulaci nebo síťařským aktivitám studentů a pedagogů.
Bylo spuštěno předobjednávání zařízení Flipper One s Linuxem. Za 20 dolarů si lze koupit kupón a zajistit si tím speciální cenu 379 dolarů po spuštění kampaně na Kickstarteru.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 16.0. Postaven je na Firefoxu ESR 153. Vydána byla také nová verze 7.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. S Tor Browserem 16.0.
FreeTube, desktopový klient pro YouTube využívající lokální API, byl vydán ve verzi 0.26.0. Toto velké opravné vydání mj. vrací částečnou podporu živých přenosů nebo přepracovává zobrazování titulků a obecně nastavení videa v přehrávači – FreeTube umožňuje např. přehrávat video s větším zrychlením.
Další vlna kyberútoků zasáhla chladicí zařízení supermarketů v sedmi evropských zemích, Belgii, Lucembursku, Švédsku, Nizozemsku, Irsku, Estonsku a Finsku. Mrazáky se v některých prodejnách opět 'proměnily v trouby' a zahřály až na 50°C, což pochopitelně vedlo ke znehodnocení uskladněných potravin. Útoky navazují na podobný incident ve Francii z první poloviny října letošního roku, pachatel stále není znám.
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:
