Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.3. Současně oznámila, že nadcházející větší vydání 24.04-2.0 bude mít modernější webový prohlížeč.
Ploopy po DIY trackballech či sluchátkách představuje nový externí DIY trackpoint se čtyřmi tlačítky Bean. Obsahuje snímač Texas Instruments TMAG5273, spínače Omron D2LS-21 a řadič RP2040, používá firmware QMK. Schémata jsou na GitHubu; sadu lze předobjednat za 69 kanadských dolarů (bez dopravy a DPH).
Mozilla před dvěma týdny na svém blogu oznámila, že díky Claude Mythos Preview bylo ve Firefoxu nalezeno a opraveno 271 bezpečnostních chyb. Včera vyšel na Mozilla Hacks článek s podrobnějšími informacemi. Z 271 bezpečnostních chyb mělo 180 chyb vysokou závažnost, 80 chyb střední závažnost a 11 chyb nízkou závažnost. Celkově bylo v dubnu ve Firefoxu opraveno 423 bezpečnostních chyb. Čísla CVE nemusí být přiřazována jednotlivým chybám. CVE-2026-6784 například představuje 154 bezpečnostních chyb.
Před týdnem zranitelnost Copy Fail. Dnes zranitelnost Dirty Frag. Běžný uživatel může na Linuxu získat práva roota (lokální eskalaci práv). Na většině linuxových distribucí vydaných od roku 2017. Aktuálně bez oficiální záplaty a CVE čísla [oss-security mailing list].
Ačkoli je papež Lev XIV. hlavou katolické církve a stojí v čele více než miliardy věřících po celém světě, také on někdy řeší všední potíže. A kdo v životě neměl problémy se zákaznickou linkou? Krátce poté, co nastoupil do úřadu, musel papež se svou bankou řešit změnu údajů. Operátorka ale nechtěla uvěřit, s kým mluví, a Svatému otci zavěsila.
Incus, komunitní fork nástroje pro správu kontejnerů LXD, byl vydán ve verzi 7.0 LTS (YouTube). Stejně tak související LXC a LXCFS.
Google Chrome 148 byl prohlášen za stabilní. Nejnovější stabilní verze 148.0.7778.96 přináší řadu novinek z hlediska uživatelů i vývojářů. Vypíchnout lze Prompt API (demo) pro přímý přístup k AI v zařízení. Podrobný přehled v poznámkách k vydání. Opraveno bylo 127 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Richard Hughes oznámil, že po společnostech Red Hat a Framework a organizacích OSFF a Linux Foundation, službu Linux Vendor Firmware Service (LVFS) umožňující aktualizovat firmware zařízení na počítačích s Linuxem, nově sponzorují také společnosti Dell a Lenovo. Do dnešního dne bylo díky LVFS provedeno více než 145 milionů aktualizací firmwarů od více než 100 různých výrobců na milionech linuxových zařízení.
Americké technologické společnosti Microsoft, Google a xAI souhlasily, že vládě Spojených států poskytnou přístup k novým modelům umělé inteligence (AI) před jejich uvedením na trh. Oznámila to americká vláda, která tak bude moci prověřit, zda modely nepředstavují hrozbu pro národní bezpečnost. Oznámení podtrhuje rostoucí obavy Washingtonu z rizik spojených s výkonnými AI systémy. Americké úřady chtějí v rámci předběžného přístupu
… více »Koncepční návrhy pro možnou podporu microformatu pro Firefox 3 si můžete prohlídnout na blogu Alexe Faaborga. Mezi zajímavé nápady patří využití sidebaru a ukládání historie. Sidebar by pro aktuální stránku mohl zobrazovat detekované kontakty, události a další informace a přímo k nim nabízet akce podle možností systému. Historie by mohla umožňovat vyhledávat v již navštívených stránkách např. lokality.
Tiskni
Sdílej:
XHTML zklamalo, je pro web nepoužitelné a nevhodné (hint: uživatel je tvrdě trestán i za drobné chyby v generátorech výstupního XHTMLTo bych mohl prijit a rict: Java zklamala a je nepouzitelna a nevhodna. I kdyz zapomenu jen pitomou zavorkou uzavrit blok, vyhodi mi to chybu!........
Mozna prave proto mam ted rad jazyky, ktere striktni jsou
JJ, pokud se mi na XML něco líbí, tak je to právě to, že striktně trvá na správné syntaxi.Ale to není záležitost XML. HTML taky „striktně trvá“ na správné syntaxi, pokud něco nedodržuje syntaxi HTML, není to HTML. Ale HTML parsery jsou zpravidla konstruovány tak, že přežvýkají všechno možné. Bylo by možné zkonstruovat takovým způsobem i XML parser. Jenže většina XML parserů vznikla v době, kdy byli všichni frustrovaní z toho, že drtivá většina „HTML“ dokumentů je na tom ve skutečnosti dost bídně s validitou. Takže celá debata ohledně HTML vs. XHTML vzhledem ke zpracování nevalidních dokumentů je poněkud mimo. Pro oba formáty mohou existovat parsery, které odmítnou nevalidní kód, i takové, které se pokusí jím prokousat. Jenže psát dneska do prohlížeče pro relativně nový formát nový parser, který by akceptoval i nevalidní kód, se nikomu nechce s docela logickým poukazem na to, že vytvořit validní XHTML kód není zas tak těžké, tak ať to tvůrci webových stránek laskavě dělají. A proti tomu zase jiní argumentují, že uživateli by se mělo něco zobrazit, i když je autor stránek nemehlo. Jenže nikdo ze zastánců tohohle přístupu zatím nenapsal tolerantní XML parser. A mimochodem, ono to s tou nutností validity XHTML také není tak horké, pokud vím, žádný internetový prohlížeč nevaliduje stránku proti DTD nebo XML schématu pro XHTML, všem stačí validní XML. Ono by nakonec vůbec nebylo naškodu, pokud by nějaký nikoli bezvýznamný „uživatel“ (X)HTML kódu (ať už browser nebo třeba internetový vyhledávač) začal upřednostňovat syntakticky validní (X)HTML. Proč mají pořád všichni doplácet na to, že někteří HTML kodéři nedělají svou práci pořádně?
ach taaaak :) To uz motas nekolik veci dohromady. Mime typ odeslany v HTTP hlavicce se tyka prenosu dokumentu ale nerika nic o tom jestli samotny dokument je nebo neni XML. U XHTML stranek se opravdu neposila mimetyp XML a to z pragmatickeho duvodu. Prohlizec IE s tim ma problem. Takze se posle hlavicka text/... ale samotny dokument je XHTML. Takze tady je problem pouze v tom, ze server neuvede presne mime typ jen proto, aby dokument byl dostupny.
RSS a ATOM feed nemaji s XHTML nic spolecneho.
Mime typ odeslany v HTTP hlavicce se tyka prenosu dokumentu ale nerika nic o tom jestli samotny dokument je nebo neni XML.Mime typ odesílaný v HTTP hlavičce určuje právě typ přenášeného dokumentu, má dokonce přednost před typem uvedeným v samotném dokumentu. Přenosu se týkají jiné hlavičky a ty se týkají použitého kódování – s mime typy to nemá nic společného.
U XHTML stranek se opravdu neposila mimetyp XML a to z pragmatickeho duvodu. Prohlizec IE s tim ma problem. Takze se posle hlavicka text/... ale samotny dokument je XHTML.Ten důvod je nesmyslný, nejjednodušší je poslat XHTML prohlížeči, který deklaruje, že umí XHTML, a poslat HTML prohlížeči, který deklaruje, že umí HTML (ale neumí XHTML). Hlavičku
Accept neodesílají prohlížeče jen tak pro nic za nic.
Takze tady je problem pouze v tom, ze server neuvede presne mime typ jen proto, aby dokument byl dostupny.To není „pouze“ problém, to je závažný problém – protože buď se prohlížeči pošle XHTML ale prohlížeč jej zpracovává jako HTML (a pak nemá valný smysl to jako XHTML používat), nebo se spoléhá na to, že prohlížeč bude ignorovat mime-typ, který mu oznámil server, a rozhodne se dle vlastního uvážení (jako to s oblibou dělá MSIE). Např. Gecko když dostane dokument, který je formálně XHTML, ale dostane jej s hlavičkou
text/html, zpracovává jej HTML parserem a liší se např. i DOM takové stránky od DOMu stránky poslané s application/xml+xhtml.
nevim jestli si rozumime. To co chci rict je ze, hlavicka uvedena pri prenosu dokumentu nezmeni dokument jako takovy. Muze ovlivnit jak s nim klient zachazi, ale pokud dokument je validni XHTML tak s nim lze stale pracovat jako s XML bez ohledu na mime hlavicku.
Ta stránka tam je spíš jen aby to nehlásilo chybu 404 než se konečně dostanu k tomu udělat tam něco normálního. Měl jsme v plánu to předělat při přechodu na Jetty 6, ale ukecal jste mě, už je to opravené
Na Webu se dnes žádné XML nepoužíváAle používá, jenom o tom nevíte.
je to pouze HTML se syntaktickými chybami (lomítky na konci prázdných elementů)Syntaktickou chybou není lomítko, ale > za tím lomítkem, např.
<br/ je validní zápis.
ale podle specifikací parser/user agent nemusí na každé z nich rovnou chcípnout a znepřístupnit tak celý dokumentSpecifikace popisuje pouze chování v případě neznámých elementů nebo atributů – a v takovém případě neskončí ani prohlížeč používající XHTML, protože prohlížeče XHTML nevalidují proti XML schématu ani proti DTD. Že si prohlížeč nějak vyloží i chybějící koncové uvozovky okolo atributů nebo dokonce chybějící > nemá ve specifikaci žádnou oporu. Navíc každý prohlížeč se s tím vyrovná jinak, takže ve výsledku je to stejně mínus pro autora takové stránky – jenom se takový problém hůř hledá.
Myslím, že software by se ve většině případů měl chovat podle "be liberal what you accept, be strict in what you send".Ale zase se to nesmí přehánět. Současný stav, kdy prohlížeč, který dostane data s hlavičkou
text/html vždy něco zobrazí a nikdy nezobrazí chybovou hlášku je myslím dost přehnaný.
Na Webu se dnes žádné XML nepoužívá, je to pouze HTML se syntaktickými chybami (lomítky na konci prázdných elementů), které funguje právě díky volnosti HTML parserů. Aneb rozdíl text/html vs. application/xml+xhtml.U všech svých aktuálních webu, pokud prohlížeč posílá v HTTP hlavičce ACCEPT application/xhtml+xml, pošlu mu stránku s tímto MIME typem, v opačném případě s MIME typem text/html. Je to podle vás dostatečně v duchu XHTML?
<java:class name="Foo"> <java:method name="Main" returnType="void" static="true" ...
Ale inak, samozrejme sa tým dá zapísať všetko, veď je to strom (Aiya, Alda
). Podobne sa dá všetko zapísať v LISPe.
Pravda, u MSIE se nesmí moc divočit, HTML v jiném než defaultním jmenném prostoru nebo s jiným prefixem než HTML nebude rozumět, a kvůli přepínání módu kompatibility je lepší mu stejně posílat HTML. Ale MSIE umí jmenné prostory i v HTML.
Microformat je cesta do pekel, byť dlážděna těmi nejlepšími úmysly. Proč bylo vymyšleno XHTML a jmenné prostory v XML?
Tak ho proste ignoruj :)