Evropská komise naléhavě vyzvala členské státy EU, aby kvůli ochraně nezletilých na internetu urychlily zavádění unijní aplikace pro ověřování věku a zajistily její dostupnost do konce roku. Členské státy mohou zavést aplikaci EU pro ověřování věku jako samostatnou aplikaci nebo ji integrovat do takzvané evropské peněženky digitální identity.
Richard Biener oznámil vydání verze 16.1 (16.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 16. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Zulip Server z open source komunikační platformy Zulip (Wikipedie, GitHub) byl vydán ve verzi 12.0. Přehled novinek v příspěvku na blogu.
Před 30 lety, tj. v úterý 30. dubna 1996, byl spuštěn Seznam.cz.
Byly zpracovány a zveřejněny všechny videozáznamy, které stojí za zveřejnění, z konference FOSDEM 2026.
Od úterý 28. dubna musí nově uváděné notebooky v Evropské unii podporovat nabíjení přes USB-C. Jednotná nabíječka byla schválena Evropským parlamentem v říjnu 2022.
Byly publikovány informace o kritické zranitelnosti CVE-2026-31431 pojmenované Copy Fail v Linuxu, konkrétně v kryptografii (AF_ALG). Běžný uživatel může získat práva roota (lokální eskalaci práv). Na všech distribucích Linuxu vydaných od roku 2017. Pomocí 732bajtového skriptu. V upstreamu je již opraveno. Zranitelnost byla nalezena pomocí AI Xint Code.
Textový editor Zed dospěl do verze 1.0. Představení v příspěvku na blogu.
Vývojáři svobodného 3D softwaru Blender představili (𝕏, Mastodon, Bluesky) nejnovějšího firemního sponzora Blenderu. Je ním společnost Anthropic stojící za AI Claude a úroveň sponzoringu je Patron, tj. minimálně 240 tisíc eur ročně. Anthropic oznámil sponzorství v tiskové zprávě Claude for Creative Work.
VNC server wayvnc pro Wayland kompozitory postavené nad wlroots - ne GNOME, KDE nebo Weston - byl vydán ve verzi 0.10.0. Vydána byla také verze 1.0.0 související knihovny neatvnc.
chybí mi "jak kdy",To spadá pod "ano", ne?
Já když svým partnerům odpovím v čistém textu, tak nadávají, že tohleto a támhleto nemají podtržené a zase tohle by chtělo zdůraznit a napsat velkým písmem ...majitelka firmy - největší zákazník má špatné oči ... takže jasná volba. Téměř vždy HTML
má špatné očiTak ať si zvětší písmo ve svém klientovi... Jinak když mám poslat formátovaný dokument, tak RTF nebo PDF

Výjimečně.
Ne, proti HTML e-mailům nic nemám, pokud je to vhodné (ceníky s obrázky), ale když mi někdo pošle mail s obrázkem dopisního papíru na pozadí a jako font použije nějaký Comic Sans (či podobné), tak mi to už vadí.
ti nekdo zaskrtne "
), byly tam 3 věty bez jakéhokoliv formátování. Jinak BFU běžně posílají fotky v 2MB doc (!), i když je jasné, že třeba z jejich foťáku vypadne jpg.
Snad si to paní na druhém konci drátu příště rozmyslí.
> To nic není, mně přišel o víkendu spam (od české firmy) s 4 MB docem.To nič nie je. Najväčšou perlou, ktorú som dostail mailom, je "Return Receipt" s veľkosťou 242kB. Ministerstvo zdravotníctva SR zjavne používa Lotus Notes, ktoré potrebujú takmer štvrť megabajtu, aby povedali "Vaša správa bola prečítaná".
Nebylo by asi na škodu vytvořit navazující anktetu, která mě v souvislosti s maily hned napadla: Používáte diakritiku v mailu? Já osobně jen když mi příjde mail od osoby, která ji použila nebo v případě, kdy je zcela jasné, že nebude příjemci činit problém.
Return-Path: X-Original-To: Delivered-To: Received: To: Subject: =?UTF-8?B?Tm92w6kgcMWZaWhsYcWhb3ZhY8OtIGl uZm9ybWFjZSBwcm8gRnJhbnRhIG5hIE4=?= =?UTF-8?B?ZW9maWNpw6FsbsOtIGtsdWIgcMWZw6F0ZWwgZUJhbmt5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BitDopis pak obsahuje text v UTF-8. Na tom vidíš, kde je dvakrát deklarováno kódování (dvě úrovně). A pak je tam ještě jednou - v předmětu (u jména odesílatele a příjemce se to dělá stejně). Dnes není problém posílat (a přijímat) e-maily s diakritikou. A to nejen v těle zprávy, ale i v předmětu nebo ve jméně odesílatele/příjemce. Takže pišme s diakritikou, lépe se to čte.
Proto nic nezkazite mailem bez diakritiky.Zkazí - jednak obtěžuje příjemce tím, že musí číst hůře čitelný text a jednak pomáhá udržovat ten mizerný stav softwaru - když se lidem budou špatně zobrazovat maily, časem jim dojde, že by si měli pořídit lepší software (postfix, KMail, Thunderbird...) nebo si ho aspoň správně nastavit.
(nabízí se např. XML)Dalo by se použít XHTML a jeho < blockquote > a tam, kde sémantické značky nejsou (asi patička) by stačilo dohodnout nějakou CSS třídu pro označení daného blokového elementu. S tím rozbalováním a sbalováním by se mi to taky líbilo.
Dalo by se použít XHTML a jeho < blockquote > a tam, kde sémantické značky nejsou (asi patička) by stačilo dohodnout nějakou CSS třídu pro označení daného blokového elementu.Ale tady vůbec nejde o vzhled! To už si zařídí klient (tedy poštovní klient) sám. Jde o to, aby věděl, kde ty části zprávy jsou -- jejich formátování je druhá věc, na té první nezávislá. A nejde jen o citaci, jde třeba i o záhlaví vložených zpráv. Takhle vidím ta záhlaví, která mi tam pošle odesílatel, ale co když chci vidět jen některá?
S tím rozbalováním a sbalováním by se mi to taky líbilo.Jsou klienty, co to umí. Ale podle mě se to (to = jakákoli práce se zprávou formátovanou v ASCII-artu) příliš složitě implementuje (regulární výrazy, mnoho úprav řetězců atd.), a tak se do toho nikdo moc nehrne, protože z toho vždycky koukají problémy (nestandardní formátování, např. jiné značky než "> " atp.). Kdyby to bylo třeba v tom XML, tak zpracovatele XML má ve standarních knihovnách kdejaký jazyk, takže by se vývojář klienta staral jen o práci s obsahem uzlů -- a nikoli o samotné uzly (potažmo formátování ASCII-artem).
Ale tady vůbec nejde o vzhled! To už si zařídí klient (tedy poštovní klient) sám. Jde o to, aby věděl, kde ty části zprávy jsou -- jejich formátování je druhá věc, na té první nezávislá.Však v XHTML definuješ jen význam a o formátování se postará až CSS. Pokud styl není, použije se výchozí styl prohlížeče/klienta. To je jako když uděláš jednoduchou HTML stránku s H1, STRONG, UL, OL... tam si to taky prohlížeč naformátuje po svém a ty uvádíš jen význam elementů. Zavádět XML formát zpráv by bylo fajn, ale to bychom rovnou mohli přepsat protokol SMTP, aby pracoval s XML požadavky a odpověďmi místo těch zastaralých
klíč: hodnota asi by to za to stálo, ale je to spousta práce.
BTW: co máž proti přiložení celé MIME zprávy? Aspoň se k tobě dostanou všechny hlavičky.
Zavádět XML formát zpráv by bylo fajn, ale to bychom rovnou mohli přepsat protokol SMTP, aby pracoval s XML požadavky a odpověďmi místo těch zastaralých klíč: hodnota asi by to za to stálo, ale je to spousta práce.Nevím, já ty protokoly neznám, jsem jen uživatel (a jako uživatel navrhuju to, co jsem navrhl výše), ale myslím si, že by celá zpráva nemusela hned být v XML. Hlavičky by mohly zůstat, typ zprávy by se nastavil na XML a text zprávy by už byl v XML (jako se to teď dělá s HTML). Nicméně nechci spekulovat, nevidím do toho tolik.
BTW: co máž proti přiložení celé MIME zprávy? Aspoň se k tobě dostanou všechny hlavičky.Nelíbí se mi to; často někdo přiloží nějaký divný formát zprávy, plus se mi moc nelíbí, když mám víc v sobě vložených zpráv, přijde mi nepohodlné s tím pracovat.
Nevím, já ty protokoly neznám, jsem jen uživatel (a jako uživatel navrhuju to, co jsem navrhl výše), ale myslím si, že by celá zpráva nemusela hned být v XML. Hlavičky by mohly zůstat, typ zprávy by se nastavil na XML a text zprávy by už byl v XML (jako se to teď dělá s HTML). Nicméně nechci spekulovat, nevidím do toho tolik.Když už, tak by bylo přínosné do XML nacpat celou komunikaci, včetně všech hlaviček. Ale k tomu se jen tak nedohrabeme, protože současné SMTP a MIME funguje relativně dobře a bylo by to spousta práce.
Nelíbí se mi to; často někdo přiloží nějaký divný formát zprávy, plus se mi moc nelíbí, když mám víc v sobě vložených zpráv, přijde mi nepohodlné s tím pracovat.V současnosti to má pro (kompletní zpráva včetně hlaviček) i proti (vloženou zprávu si musíš rozkliknout v novém okně*). Ale ty nevýhody jsou čistě věcí klientů - šlo by to udělat tak, aby i vložené MIME zprávy zobrazovaly jako vložený text. *) Alespoň v klientech, které používám.
Když už by se to (XML) dělalo, tak by stejně umělo formátování. Takže XHTML se přímo nabízí. Dělal bys tak vlastní XML schéma, které by obsahovalo většinou značky, které už existují v XHTML. A pak bys třeba zjistil, že vyvíjíš ten nový formát jen kvůli tomu, abys přidal jednu značku pro patičky.Jenže XHTML nabízí spoustu zbytečností. Např. dělení dokumentu na HEAD a BODY -- to vůbec není třeba.
Když už, tak by bylo přínosné do XML nacpat celou komunikaci, včetně všech hlaviček. Ale k tomu se jen tak nedohrabeme, protože současné SMTP a MIME funguje relativně dobře a bylo by to spousta práce.Souhlasím, ale výměna formátu hlaviček nejde udělat ze dne na den...
Jak už jsem psal: většina diskutujících (ostatně včetně zadavatele ankety) by měla upřesnit, jestli myslí HTML only maily nebo multipart/alternative s jednou text/html a jednou text/plain alternativou. Za to první bych schvaloval použití tělesných trestů, to druhé je sice neefektivní, ale akceptovatelné.
P.S.: odkdy na odrážky potřebujete HTML?
http-equiv meta-element je jen berlička pro případ chybějící hlavičky HTTP odpovědi. V praxi to má na svědomí akorát zmatené stížnosti lidí, kteří si čertvíproč myslí, že má http-equiv mít přednost před hlavičkou HTTP odpovědi, případně o její existenci vůbec netuší.
Tak na Outlookáře mám jednoduchý, i když zdlouhavý recept: otravuji je tak dlouho dokud mi nezačnou posílat maily v prostém textu. 
Tiskni
Sdílej: