Byla vydána nová verze 10.2 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Vypíchnout lze nové balíčky Immich, Immich Machine Learning, uv a RustDesk Client.
TypeScript (Wikipedie), tj. JavaScript rozšířený o statické typování a další atributy, byl vydán v nové verzi 6.0. Příští verze 7.0 je kvůli výkonu přepisována do programovacího jazyka Go.
Christian Schaller z Red Hatu na svém blogu popsal své zkušenosti s používáním AI při vývoji open source aplikací pro Linux. Pomocí různých AI aktualizoval nebo vytvořil aplikace Elgato Light GNOME Shell extension, Dell Ultrasharp Webcam 4K, Red Hat Planet, WMDock, XMMS resuscitated (aktualizace z GTK 2 a Esound na GTK 4, GStreamer a PipeWire) a Monkey Bubble. SANE ovladač pro skener Plustek OpticFilm 8200i se mu zatím nepovedl.
Americké firmy Tesla a SpaceX postaví v texaském Austinu moderní komplex na výrobu čipů pro umělou inteligenci (AI). Součástí projektu s názvem Terafab budou dvě moderní továrny na výrobu čipů – jedna se zaměří na automobily a humanoidní roboty, druhá na datová centra ve vesmíru. Uvedl to generální ředitel těchto firem Elon Musk. Projekt by podle odhadů měl stát 20 miliard USD (zhruba 425 miliard Kč).
Byla vydána nová stabilní verze 6.11 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Ubuntu 26.04 patrně bude ve výchozím nastavení zobrazovat hvězdičky při zadávání hesla příkazu sudo, změna vychází z nové verze sudo-rs. Ta sice zlepší použitelnost systému pro nové uživatele, na které mohlo 'tiché sudo' působit dojmem, že systém 'zamrzl' a nijak nereaguje na stisky kláves, na druhou stranu se jedná o možnou bezpečnostní slabinu, neboť zobrazování hvězdiček v terminálu odhaluje délku hesla. Původní chování příkazu sudo
… více »Projekt systemd schválil kontroverzní pull request, který do JSON záznamů uživatelů přidává nové pole 'birthDate', datum narození, tedy údaj vyžadovaný zákony o ověřování věku v Kalifornii, Coloradu a Brazílii. Jiný pull request, který tuto změnu napravoval, byl správcem projektu Lennartem Poetteringem zamítnut s následujícím zdůvodněním:
… více »Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 163 (pdf).
Eric Lengyel dobrovolně uvolnil jako volné dílo svůj patentovaný algoritmus Slug. Algoritmus vykresluje text a vektorovou grafiku na GPU přímo z dat Bézierových křivek, aniž by využíval texturové mapy obsahující jakékoli předem vypočítané nebo uložené obrázky a počítá přesné pokrytí pro ostré a škálovatelné zobrazení písma, referenční ukázka implementace v HLSL shaderech je na GitHubu. Slug je volným dílem od 17. března letošního
… více »Sashiko (GitHub) je open source automatizovaný systém pro revizi kódu linuxového jádra. Monitoruje veřejné mailing listy a hodnotí navrhované změny pomocí umělé inteligence. Výpočetní zdroje a LLM tokeny poskytuje Google.
Aktuální vývojová verze jádra je nadále 3.6-rc3, od minulého týdne žádné další -rc verze nevyšly.
Stabilní aktualizace: verze 3.0.42, 3.4.10 a 3.5.3 vyšly 26. srpna s obvyklou hromadou oprav. Ve verzích 3.0.42 a 3.4.10 se vyskytly potíže s grafikami Intel, takže pozor na ně.
Někdo se snaží pozabíjet vývojáře jádra.
Nejprve jsme tu měli dvě zemětřesení – Bůh asi tento týden nenávidí nejen republikány, ale i nás jaderné vývojáře. Jenže my se zastrašit nenecháme a kvůli zemětřesení o síle 5,5 jen trochu zafňukáme a na chvilku se schováme do skříně.
Ale po chvíli krčení ve skříni zaklepali na dveře pořadatelé a začali rozdávat skateboardy s nevinným vysvětlením "Jsme přece v San Diegu."
Pokud to není znamení, že se nás někdo snaží zabít, pak teda nevím.
Co se Linuxu týče, tak Linus Torvalds evidentně nevynucuje svá vlastní autorská práva přes [Software Freedom] Conservancy, ale nedávno jsem se ho na jedné akci zeptal: „Nevadí ti, že vynucuji GPL u Linuxu?“ Linus odpověděl: „Ne. Pravdou je, že jedním z důvodů, proč u Linuxu nevyžaduji přiřazení autorských práv, je to, že jsem chtěl, aby o osudu svých práv rozhodovali vývojáři sami“. Mnoho držitelů práv u Linuxu v této věci s Conservancy spolupracuje v souladu s Linusovým postojem, že o svých právech mají rozhodovat sami.
-- Bradley Kuhn
Většina lidí soubor feature-removal-schedule.txt ignoruje, vyjma těch, co do něj něco přidávají. Je to spíš něco jako globální TODO pro vývojáře než cosi užitečného pro každého.
Zařaďte pořadavek na odstranění souboru feature-removal-schedule.txt.
Ben Hutchings oznamuje: Mám v plánu Linux 3.2.y udržovat alespoň tak dlouho, jako bude podporován Debian 7.0. End-of-life pro každé vydání Debianu je 1 rok po následujícím vydání, takže to bude asi tak do konce roku 2015.
Jaderný summit 2012 trval tři dny (od 27. do 29. srpna) a konal se v San Diegu. Podíváme se na vybraná témata.
Už několik let Rafael Wysocki sleduje regrese v jádře a vytváří seznamy a statistickou analýzu. Tato práce, která má za výsledek (nepřesné) údaje o zvyšování nebo snížování kvality následujících vydání jádra, byla něčím, co ostatní vývojáři jádra na Jaderném summitu vždy ocenili. Jeho přednáška v první den Jaderného sumitu ale byla letos poněkud odlišná. Zajímal se o to, jak by budoucnost sledování regresí měla vypadat.
Postupem času se totiž Rafael postupně přesunul k jiným pracem v jádře a zbývalo mu tak méně času na sledování regresí. Tou dobou se pár dalších lidí naštěstí přihlásilo, že budou vytvářet a spravovat souhrnná hlášení z Bugzilly, která jsou používána ke sledování regresí. Bohužel to ale nešlo moc dobře. Rafael už dříve poznamenal, že jaderná Bugzilla není pro toto moc vhodná. Po odchodu Rafaela se navíc ukázalo, že ne všichni mají stejný názor na to, jak by k tomuto měla Bugzilla být používána. Tyto neshody nakonec byly jedním z důvodů, proč Rafaelovi následníci přestali na sledování regresí pracovat.
Tím se dostáváme k současné situaci: už skoro půl roku nikdo regrese nesleduje. Navíc Rafael poznamenal, že vzhledem ke svým ostatním závazkům se nebude moci k této práci v budoucnu vrátit. To jej vedlo k jednoduché otázce: chceme regrese dále sledovat?
Právě v tento moment se ozvalo mnoho vývjářů, kteří vyjádřili, jak důležitá jim Rafaelova práce přišla. H. Peter Anvin například řekl, že sice není fanouškem Bugzilly ale přehled regresí mi přišel užitečný. Přinutilo mě to pracovat na věcech, na kterých se mi dělat nechtělo. Linus Torvalds navíc rovněž řekl, že si cenil přehledu, který mu Rafaelova práce poskytovala.
Diskuze se odklonila k jiným tématům. Rafael přemýšlel o tom, jestli je Bugzilla vůbec ke sledování a řešení chyb v jádře užitečná. Odpovědi vývojářů se lišily podle konkrétního subsystému, některé na ni dosti závisí, jinde se zase preferuje e-mail. James Bottomley upozornil, že Bugzila umožňuje lidem, kterým mailing list nic neříká, zadat bug do Bugzilly a ten se pak automaticky objeví v mailing listu. Bugzilla tak těmto uživatelům umožňuje komunikovat s vývjáři v souladu s jejich pracovními postupy. Později toto vedlo Rafaela k jinému problému: když některé subsystémy používají Bugzillu, zatímco jiné zase mailing listy nebo jiné mechanismy, co by lidem, co nahlašují chyby, měli vývojáři říci o správném způsobu? Tato otázka je pro lidi, co hlásí chyby poprvé, docela překážkou. Bohužel nebylo moc času se tímto zabývat hlouběji.
Dále pak proběhly další diskuze o tom, jak by se Bugzilla měla ke sledování regresí používat a zda na to nejsou lepší nástroje, žádné konkrétní alternativy ale navrženy nebyly. Nakonec se přítomní shodli, že na nástroji až tak nesejde a volba nástroje by měla zůstat na tom, kdo se od sledování bude starat.
Stále tu tedy je volné místo pro jednoho nebo více lidí, kteří se o sledování regresí postarají. Práce je to sice ceněná, nicméně neplacená.
H. Peter Anvin zahájil svou přednášku slovy, že Linux podporuje neuvěřitelné množství hardwaru. Zejména nabízí dlouhou podporu pro starší hardware a právě díky tomu je u některých uživatelů tak populární. Většinou je podpora starého a neobvyklého hardwaru a toolchainů záslužná. Petrova otázka nehledě na toto zněla: jaká omezení na úsilí věnované podpoře starých či neobvyklých hardwarových architektur, toolchainů a zařízení chce vývojářská komunita určit?
Peterovi jde o to, že podporování starých a podivných systémů s sebou nese značné úsilí a obtíže. Když jde o podporu takových systémů, je nutné zvážit toto: na těchto systémech záleží jen malému množství uživatelů, jenže jejich podpora ztěžuje práci napříč celou komunitou.
Peter uvedl několik příkladů. Jádro stále obsahuje kód pro podporu starých procesorů Intel 386 (předchůdce 486 z roku 1989). Spouští ještě někdo Linux na tak starém hardwaru? Peter prohlásil, že jako správce x86 nedavno přijal hlášení chyby od uživatele, který se na takovém systému pokoušel Linux spustit. Zrod tohoto hlášení je ale zajímavý. Pocházelo totiž od někodo, kdo se sám sebe ptal, jestli půjde moderní linuxové jádro vůbec ještě nastartovat na obdobně starém stroji. Peterova otázkou tedy je: má se komunita ještě snažit toto podporovat?
S podporou starých systémů se pojí různé komplikace. Správce například může chtít udělat změny, které mohou mít vliv na staré systémy, ale může být nesnadné zhodnotit, jaký dopad mohou mít. Navíc je nepravděpodobné, že tento správce bude mít po ruce hardware, aby to otestoval. Legacy kód je tedy jen málokdy spouštěn a v takovém kódu se mohou ukrývat chyby a bezpečnostní díry. (Peter upozornil, že „háčky“ specifické pro architektury jsou „běžným“ řešením, jak podporovat podivné architektury. Tyto háčky jsou pak kódem ve stylu COMEFROM, o kterém je obtížné se pak rozumně bavit. Jediným řešením je důsledné dokumentování prekondicí, postkondicí a invariantů takového háčku. Asi nepřekvapí, že pravděpodobnost výskytu takové dokumentace je někde mezi výjimečně a nikdy.
Je tu několik otázek, které by měl člověk zvážit, když jde o to pokračovat v podpoře starého systému. Kupříkladu jestli nějací uživatelé tohoto systému vůbec ještě jsou, kolik jich je a hlavně, jestli má smysl je podporovat v nových jádrech? Průšvih je, že u obskurních systémů je těžké odpovědi na tyto otázky získat. Peter hlavně zpochybnil domněnku, že bug reporty znamenají, že tu jsou aktivní uživatelé.
Staré nástroje pro sestavování představují obdobný problém. Peter řekl, že Lidé si stěžují, když uděláme něco, co vyvolá chybu v 7 let starém toolchainu. Jednoho dne prostě musíme říct: pokud chcete používat nové jádro, musíte být připraveni nainstalovat si náležitý toolchain..
Peter rozšířil debatu o starých systémech na rozhraní pro uživatelský prostor. Jako příklad posloužil kód pro kompatibilitu, který už dlouho není používán. Jde například o podporu a.out na x86-64, což bylo zdrojem několika závažných bezpečnostních chyb; jenže formát a.out byl v době příchodu architektury x86-64 zastaralý a pravděpodobně se mu nedostalo ani žádného použití. Má nějaký smysl takto stará rozhraní podporovat a existuje vhodný způsob, jak je označit za zastaralá a odstranit je?
V tento moment se o slovo přihlásil Linus: Nikdy jsem netvrdil, že nemáme měnit ABI. Už jsme to kvůli opravě chyb udělali. Hlavně jen neporouchejte uživatelský prostor. Pokud můžeme změnit ABI a nikdo si na to nestěžuje, tak směle do toho. Jako mezikrok v procesu odstraňování Rusty Russel navrhl přidání volby CONFIG_MODERN, která by byla standardně zapnutá a mohla by být vypnuta, pokud někdo potřebuje zastaralé funkce. Len Brown odpověděl, že by se tomu asi dostalo podobného osudu jako CONFIG_EXPERIMENTAL, které je vždy zapnuté (CONFIG_MODERN by tedy ve výsledku asi bylo distributory vždy vypnuto). Thomas Gleixner místo toho navrhl, aby staré funkce byly skryty pod volbami označenými jako „bool n“, což by bránilo jejich vybrání, a pak by po rozumné prodlevě mohlo dojít k odstranění, když si nikdo nebude stěžovat.
Debata skončila bez jasných závěrů, ale pár lidí se vyslovilo pro odstranění podpory zastaralých systémů, aniž by proti tomu někdo zásadně protestoval. Proto se tedy může stát, že brzy budeme svědky aktivit s cílem vyčistit jaderný kód od systémů, které už nemají žádné využití.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
H. Peter Anvin[joke] Osobně bych odstranil všechen x86 kód
[/joke]
Kdyby existovala udržovaná větev pro tyto systémy, tak bych řekl skoro bez zaváhání Ano, ale i386 systémy pořád mohou existovat. Například jako opencore projekty a tam není jistota, že někdo implementuje pentium like core. Jinak 386 se od 486 liší minimálně (jen podpora writeback cache a CPUID u některých modelů a asi dvou až tří užitečných instrukcí), takže vyhození i386 by se mohlo dotknout i 486 strojů, což bych nerad, protože 486 je z x86 můj nejoblíbenější model (relativně. Absolutně je to fušeřina ). Hlavně tu taky pár 486 strojů mám a nejsou zrovna zakonzervovaný ve vitrínce.
podpora … a asi dvou až tří užitečných instrukcí
Jednou z nich je ale cmpxchg, která je zrovna dost důležitá.
.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
xchgadd.
Nojo fakt:
flags : fpu tsc cx8
Myslíte, že by dovolil vmware Xpečkům ošahat si procesor nebo dokáže tyto rozšíření nějakým způsobem emulovat a instalace by pokračovala dál jako by se nechumelilo? :) Já myslím, že by též zkiksovala :)
20.9.2012 17:13
stativ | skóre: 54
| blog: SlaNé roury
21.9.2012 12:32
stativ | skóre: 54
| blog: SlaNé roury
17.9.2012 12:06
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Například jako opencore projekty a tam není jistota, že někdo implementuje pentium like core.Proč by open-source procesor implementoval zrovna x86?
. (+ spousta 8080 implementací)
Nicméně (viz zet86) je otázka zda se někdo odhodlá k plnému 386 (32b, stránkování, chráněný mód). Protipříklad, takovej Vortex prej dělal i586 kompatibilní procesory, ale bez FPU, což je stav stejný jako u 386 nebo u hodně prvních 486.
My jsme tehdy napoprvé od toho chtěli základní běh a laditelnost Cčkových programů, bez potřeby složitého portování(na ARM)/cross-kompilace/cross-ladění, plus podporou WiFi v MiniPCI slotu (nové jádro bylo hlavně kvůli tomu).
Taky už jsem zkoušel provozovat na Vortexu nějaký softwarek v Perlu, nepříliš složitý - a jenom start Perlu 5 na Vortexu z CF karty je docela tragédie. Trvalo mi asi 20 vteřin, než se program rozběhl (= load z disku + překlad zdrojáku do interního syntaktického stromu). Možná to souvisí spíš s IOPS té CF karty, než s výkonem procesoru při kompilaci zdrojáku. On ten softwarek používal docela velké knihovny jako Expect, Switch a POSIX(termios) - spoustu malých souborků v /usr/lib/perl5/*
Pokud se týče práce v kernelu, považuju se taky za učedníka/začátečníka - a přesně proto se ARMu vyhýbám obloukem. Už jsem potkal pár lidí, kteří se o Linux na ARMu pokusili, byli o ligu výš než já, a většinou dost naříkali.
Taky mi prijde, ze pokud uz nekdo nakoduje cely virtualni rezim u 386, tak uz tam tech par instrukci, co ma navic 486, muze snadno dodelat...Pokud by podpora 486 zůstala, tak by se mě to asi nedotklo. Ale bál bych se, že by po krátkém čase chtěli zaříznout třeba i 486 a toby už byl problém.
Mimochodem, 486 se vyrabely v SMP konfiguraci, ze je ta cmpxchg() tak dulezita?Jj přesně tohle mě napadlo taky
. Samotná 486 to nepodporuje, myslím, že by byl nutnej hodně speciální čipset. Jediný o čem vím je NCR Voyager, kde je prý stále podpora v kernelu pro cca 3 lidi na světě . Doufám, že jim to podporu neukončí, pokud by se v kernelu dohodli na odstranění podpory.
Jinak je otázka do jaké míry se cmpxchg používá i pro atomické operace na jednom CPU, třeba chtějí v linuxu všude použít cmpxchg. Jako cmpxchg se totiž přímo jmenujou linuxové lowlevel funkce pro atomickou operaci na sběrnici třeba i u MIPSu .
Atomicita operace na sběrnici je u x86 dost jednoduchá, pokud se použije prefix LOCK (i386 má prý u XCHG LOCK implicitní), tak má sběrnici jen jeden procesor a to na celou dobu CISC operace (načtení a uložení).
. Jinak u 486 je L2 cache mimo procesor, takže tam snad není problém (nebo jí CPU před pasivní čipset ovládá? :-O).
ocfs2_fast_symlink_readpage. Patch, který to opravuje, je již k dispozici, pouze není zařazen do stable větve.
17.9.2012 15:25
Petr Tomášek | skóre: 39
| blog: Vejšplechty