Singularity je rootkit ve formě jaderného modulu (Linux Kernel Module), s otevřeným zdrojovým kódem dostupným pod licencí MIT. Tento rootkit je určený pro moderní linuxová jádra 6.x a poskytuje své 'komplexní skryté funkce' prostřednictvím hookingu systémových volání pomocí ftrace. Pro nadšence je k dispozici podrobnější popis rootkitu na blogu autora, případně v článku na LWN.net. Projekt je zamýšlen jako pomůcka pro bezpečnostní experty a výzkumníky, takže instalujte pouze na vlastní nebezpečí a raději pouze do vlastních strojů 😉.
Iconify je seznam a galerie kolekcí vektorových open-source ikon, ke stažení je přes 275000 ikon z více jak dvou set sad. Tento rovněž open-source projekt dává vývojářům k dispozici i API pro snadnou integraci svobodných ikon do jejich projektů.
Dle plánu certifikační autorita Let's Encrypt nově vydává také certifikáty s šestidenní platností (160 hodin) s možností vystavit je na IP adresu.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 14.0 (Mastodon). Forgejo je fork Gitei.
Just the Browser je projekt, 'který vám pomůže v internetovém prohlížeči deaktivovat funkce umělé inteligence, telemetrii, sponzorovaný obsah, integraci produktů a další nepříjemnosti' (repozitář na GitHubu). Využívá k tomu skrytá nastavení ve webových prohlížečích, určená původně pro firmy a organizace ('enterprise policies'). Pod linuxem je skriptem pro automatickou úpravu nastavení prozatím podporován pouze prohlížeč Firefox.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.
Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.
Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny
… více »D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
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