Byla představena nová verze modelu Claude Opus 4.6 od společnosti Anthropic. Jako demonstraci možností Anthropic využil 16 agentů Claude Opus 4.6 k vytvoření kompilátoru jazyka C, napsaného v programovacím jazyce Rust. Claude pracoval téměř autonomně, projekt trval zhruba dva týdny a náklady činily přibližně 20 000 dolarů. Výsledkem je fungující kompilátor o 100 000 řádcích kódu, jehož zdrojový kód je volně dostupný na GitHubu pod licencí Creative Commons.
Kultovní britský seriál The IT Crowd (Ajťáci) oslavil dvacáté výročí svého prvního vysílání. Sitcom o dvou sociálně nemotorných pracovnících a jejich nadřízené zaujal diváky svým humorem a ikonickými hláškami. Seriál, který debutoval v roce 2006, si i po dvou dekádách udržuje silnou fanouškovskou základnu a pravidelně se objevuje v seznamech nejlepších komedií své doby. Nedávné zatčení autora seriálu Grahama Linehana za hatecrime však vyvolává otázku, jestli by tento sitcom v současné Velké Británii vůbec vznikl.
Společnost JetBrains oznámila, že počínaje verzí 2026.1 budou IDE založená na IntelliJ ve výchozím nastavení používat Wayland.
Společnost SpaceX amerického miliardáře Elona Muska podala žádost o vypuštění jednoho milionu satelitů na oběžnou dráhu kolem Země, odkud by pomohly zajistit provoz umělé inteligence (AI) a zároveň šetřily pozemské zdroje. Zatím se ale neví, kdy by se tak mělo stát. V žádosti Federální komisi pro spoje (FCC) se píše, že orbitální datová centra jsou nejúspornějším a energeticky nejúčinnějším způsobem, jak uspokojit rostoucí poptávku po
… více »Byla vydána nová verze 2.53.0 distribuovaného systému správy verzí Git. Přispělo 70 vývojářů, z toho 21 nových. Přehled novinek v poznámkách k vydání.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 216. sraz, který proběhne v pátek 20. února od 18:00 v Red Hat Labu (místnost Q304) na Fakultě informačních technologií VUT v Brně na ulici Božetěchova 1/2. Tématem srazu bude komunitní komunikační síť MeshCore. Jindřich Skácel představí, co je to MeshCore, předvede nejrůznější klientské zařízení a ukáže, jak v praxi vypadá nasazení vlastního repeateru.
Byla vydána nová major verze 9.0 multiplatformní digitální pracovní stanice pro práci s audiem (DAW) Ardour. Přehled novinek, vylepšení a oprav v poznámkách k vydání.
Hodnota Bitcoinu, decentralizované kryptoměny klesla pod 70 000 dolarů (1,44 milionu korun).
Valve z důvodu nedostatku pamětí a úložišť přehodnocuje plán na vydání zařízení Steam Controller, Steam Machine a Steam Frame: „Cílem tedy stále zůstává vydat všechna tři nová zařízení v první polovině letošního roku, ale přesná data a ceny jsou dvě věci, na kterých usilovně pracujeme a jsme si dobře vědomi toho, jak rychle se v tomto ohledu může vše změnit. Takže ač dnes žádné zveřejnitelné údaje nemáme, hned jak plány finalizujeme, budeme Vás informovat.“
Do 20. února lze hlasovat pro wallpapery pro Ubuntu 26.04 s kódovým názvem Resolute Raccoon.
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: