V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.
Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
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.
Odesíláte e-maily v HTML?
ano |
|
19% (297) |
ne |
|
77% (1190) |
nevím |
|
4% (61) |
Celkem 1548 hlasů
Vytvořeno: 30.3.2008 19:07
Tiskni
Sdílej:
chybí mi "jak kdy",To spadá pod "ano", ne?
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ě.
> 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á".
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.