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.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
Aktuální vývojová verze jádra je 3.1-rc4 vydaná 28. srpna. Nuže, rozjeďte to a začněte prosím testovat. Připojený seznam změn vám dá rozumnou představu o změnách, ale nejde o nic velkého. Tudíž rozhodně *doufám*, že -rc5 bude menší. Zároveň mám ale z dosavadního stavu verze 3.1 radost. Ale možná jen začaly fungovat moje prášky. Pro všechny podrobnosti si přečtěte kompletní seznam změn.
Stabilní aktualizace: aktualizace 2.6.32.46, 2.6.33.19 a 3.0.4 vyšly 29. srpna a obsahují obvyklou dávku oprav.
Nebylo by to poprvé, že by v POSIXu byla chyba. Někdy je doopravdy řešením říct „sorry, napsali jste to před 20 lety a věci se od té doby změnily“.
Na to, abyste měli zkažený celý den, stačí jen trocha multicastu.
-- Dave Täht
Posledních ~6 měsíců pracoval tým Broadcomu na tom, aby svůj ovladač dostali ze staging. Nezbývá mi než věřit, že během té doby spíše pracovali na aktualizaci podpory zařízení. Mohu jen předpokládat, že toto by se mohlo stát v dlouhodobém měřítku jejich prioritou.
Kolikrát se už stalo, že b43 bylo v podpoře hardwaru > ~6 měsíců pozadu? Navzdory nedávné heroické snaze Rafała toto zlepšit mi nezbývá než dumat, jak dlouho asi potrvá, než bude b43 opět brutálně pozadu?
Špatná angličtina a adresa na githubu ve mně vyvolává neradostné pocity.
Úvodní stránka kernel.org nyní nese zprávu, že server byl napaden. Tento měsíc byla kompromitována řada serverů v infrastruktuře kernel.org. Tuto skutečnost jsme odhalili 28. srpna. Ačkoliv v současnosti věříme, že repozitáře se zdrojovým kódem zasaženy nebyly, tuto domněnku ověřujeme a podnikáme kroky k rozšíření bezpečnosti napříč infrastrukturou kernel.org. Jak aktualizace této informace zmiňuje, pohráváním si s git repozitáři by toho stejně nikdo mnoho nezískal.
32bitová architektura x86 má řadu známých nedostatků. Mnoho z nich bylo vyřešeno, když ji AMD rozšiřovalo na 64 bitů, ale běh v 64bitovém režimu také není bez problémů. Z tohoto důvodu pracuje skupina vývojářů GCC, jádra a knihoven na novém strojovém modelu známém jako „x32 ABI“. ABI se blíží dokončení, avšak, jak ukázala nedávná diskuze, širší nasazení x32 přináší nové obtíže.
Klasické 32bitové x86 má problémy, kterým není těžké porozumět: může adresovat jen 4 GB paměti a jeho drobná sada registrů věci značně zpomaluje. Spuštění současných procesorů v 64bitovém režimu oba problémy hezky řeší, má to ale háček: rozšíření proměnných a ukazatelů na 64 bitů vede k většímu využívání paměti a rozsáhlejšímu záběru cache. Navíc není (stále) neobvyklé narazit na program, který jednoduše nefunguje na 64bitovém systému správně. Většina programů ve skutečnosti nepotřebuje 64bitové proměnné a schopnost adresovat masivní objemy paměti; pro takový kód jsou větší datové typy břemenem bez přínosů. Bylo by opravdu hezké, kdyby tyto programy mohly zužitkovat přídavné registry a instrukce 64bitové architektury, aniž by zároveň musely pykat za zvýšenou spotřebu paměti.
x32 ABI se snaží nabídnout právě to nejlepší z obou světů. Program zkompilovaný vůči tomuto ABI poběží v nativním 64bitovém režimu, avšak s 32bitovými ukazateli a proměnnými. Plná sada registrů bude k dispozici, stejně tak jako další přednosti 64bitové architektury jako rychlejší instrukce SYSCALL64. Pokud vše půjde podle plánů, toto ABI by mělo být pro širokou paletu programů nejrychlejším režimem na 64bitových strojích; snadno si pak lze představit, že by x32 na mnoha místech nahradilo režim kompatibility s 32bitovými aplikacemi.
Je nutné poznamenat, že slovo „Pokud“ v předchozí větě je zatím poněkud neprokázané: je problém najít testy, které by dokázaly skutečné rozdíly mezi x32 a existujícími čistokrevnými režimy.
Jeden zbývající problém – a jiskra, která zažehla aktuální debatu – má co dočinění s ABI systémových volání. Většina tohoto ABI je podobná tomu, co používá starý 32bitový režim: jsou použita systémová volání a datové struktury kompatibilní s 32 bity. Ale je zde jeden rozdíl: vývojáři x32 chtějí používat SYSCALL64 stejně jako nativní 64bitové aplikace, a to kvůli výkonnostním přednostem. To věci trochu komplikuje, protože aby jádro vědělo, jakou velikost dat očekávat, musí odlišit systémová volání od 64bitových aplikací od aplikací v režimu x32, bez ohledu na skutečnost, že v obou případech běží procesor ve stejném režimu. Navíc je zde další překážka, a to, že toto odlišení musí proběhnout, aniž by byly nativní 64bitové aplikace zpomaleny.
Řešení zahrnuje používání rozšířené verze 64bitové tabulky systémových volání. Mnoho systémových volání je možné volat napřímo bez jakýchkoliv problémů s kompatibilitou – volání fork() moc překládání datových struktur nepotřebuje. Jiné však vrstvu kompatibility potřebují. Každé z těchto systémových volání (je jich 92) dostane nové číslo začínající od 512. Toto ponechává mezeru mezi nativními systémovými volání pro další rozšiřování v budoucnosti. Kdykoliv x32 binárka volá jádro, je také v číslu volání nastaven 30. bit; to umožňuje kódu jádra implementovat chování „režimu kompatibility“.
Linusovi asi obecně ani nevadilo používání mechanismu pro odlišení systémových volání x32, ale zavrhoval používání režimu kompatibility pro x32 ABI. Zeptal se:
Řekl bych, že tou opravdovou otázkou je „proč?“. Myslím si, že nám schází důvody pro to, abychom museli mít další sadu systémových volání a další stavový příznak. Proč nemůže x32 kód prostě používat nativní 64bitová volání?
Existují legitimní důvody, proč nemohou některá systémová volání být sdílena mezi režimy x32 a 64 bit. Situace, kdy uživatelský prostor předává jádru struktury obsahující ukazatele (jako jednoduché příklady poslouží ioctl() a readv()), budou vyžadovat speciální ošetření, protože tyto ukazatele budou 32bitové. Obsluha signálů bude také vždy jiná. Řada jiných systémových volání připravených speciálně pro x32 existuje především ke zmenšení odlišností mezi režimem x32 a zastaralým 32bitovým. A to jsou právě ty, ke kterým má Linus největší námitky.
Ve výsledku jde povětšinou o formát hodnot celých čísel [integerů] předávaných v jaderných strukturách. Zastaralý 32bitový režim pochopitelně používá ve většině případů 32bitové hodnoty; x32 si z toho bere příklad. Linus ale říká, že by namísto toho měly být použity 64bitové verze těchto struktur se 64bitovými hodnotami celých čísel [integerů]. Přinejmenším by tento přístup minimalizoval rozdíly mezi x32 a nativním 64bitovým režimem. Ale jsou zde i problémy s korektností.
Jedním místem, kde se 32 a 64bitové režimy liší, je jejich zachycení hodnot času; ve 32bitovém světě jsou typy jako time_t, struct timespec a struct timeval 32bitové. A 32bitové hodnoty přetečou v roce 2038. Pokud nám problém Y2K něco ukázal, tak určitě to, že takové konce světa přicházejí dříve, než se člověk naděje. Proto není překvapivé, že Linus není ochoten přidat nové ABI, které by trpělo problémem roku 2038:
Rok 2038 je pro zastaralé binárky daleko. Ale *není* to tak daleko, jakmile zavádíte nový 32bitový režim z výkonnostních důvodů.
Pro 32bitové binárky nelze šířku time_t měnit. Ale x32 je kompletně nové ABI bez historických uživatelů; v této situaci není nutné udržovat jakoukoliv zpětnou kompatibilitu. Teď je jediná příležitost pro napravení podobných problémů. Takže asi není přehnané říct, že se x32 ABI nedostane do hlavní řady jádra, dokud v něm bude problém roku 2038.
Nyní musí vývojáři x32 přehodnotit svůj návrh ABI systémových volání a najít způsob, jak to předělat, aby to mělo blíže k Linusovu gustu; tento proces už probíhá. Pak se vývojáři budou moci naplno vrhnout do stavby systémů pod tímto ABI a spustit výkonnostní testy, aby viděli, jestli to vlastně za tu námahu stojí. K přesvědčení distributorů (samozřejmě vyjma Gentoo), aby podporovali toto ABI, bude potřeba mít obstojně pádné argumenty, ale pokud tento režim naplní svůj potenciál, hned tu argumenty budou.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
. Jinak doufám, že si Linus vydupe co nejvíc změn, aby se to nemuselo zase zachvíli předělávat.
Mohli to pojmenovat třeba "32x", současné "x32" se ve světě bude plést s microsoftím starým 32bit režimem pro windows.
"Geniální" je spíše pojmenování x64 pro 64bitový systém založený na x86, nikdo kromě MS snad takhle blbý název nepoužívá.
12.9.2011 19:28
belisarivs | skóre: 22
| blog: Psychobláboly
12.9.2011 22:23
poky74 | skóre: 36
| blog: Zápisník
| Vrchlabí
x64???
32bit=x86=x86_32
64bit=x86_64
Imho je x64 blbost
Stejně jako uživatelé, kteří ví o "32-bit" a "64-bit", znají "x64" a domyslí si "x32".
x86 je správně 16bitová architekturaTo samozřejmě není pravda, ta zkratka objevila až někdy v době Intelu 80386 a v následujících letech se používala převážně pro označení kompatibility s intelovskou 32b instrukční sadou. To bylo samozřejmě dáno tím, že 32b architektura se u Intelů rychle prosadila a velmi dlouho udržela jako majoritní. V širším pojetí se ta zkratka ovšem používá pro jakoukoli instrukční sadu od 8086 až po její dnešní odvozeniny.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
12.9.2011 21:18