Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Intel potvrdil (INTEL-SA-00145) další bezpečnostní chybu ve svých procesorech. Jedná se o chybu CVE-2018-3665 s názvem LazyFP.
Tiskni Sdílej:
Ve skutečnosti to bylo mnohem horší. Plnohodnotné 486 byly trochu dražší a Intel potřeboval něco, co by konkurovalo levným 386 od AMD a Cyrixu (možná i VIA), které běhaly na vyšší frekvenci než 386 od Intelu. Takže začali u vadných 486, které měly vadnou jen FPU část, tu FPU část blokovat a prodávat je jako 486SX, což byla "486 bez koprocesoru". A protože jich nebylo dost (zejména poté, co se výrobní proces zaběhl), tak časem začali jako 486SX prodávat i zcela funkční 486DX se zablokovanou FPU (tou dobou už byla stejně výroba levnější).
Vyvrcholení frašky nastalo, když někteří zákazníci, kteří si koupili 486SX, zjistili, že by se jim FPU přeci jen hodila. Řešením bylo - modří už vědí - prodávat 486DX se zablokovanou CPU jako "487SX". Takže si člověk místo jednoho procesoru s integrovanou FPU vlastně koupil dva, každý měl zablokovanou jednu půlku a jako bonus jste měl pomalejší komunikaci mezi CPU a FPU. A to se vyplatí… (tedy aspoň Intelu)
de Raadt z OpenBSD musel bejt slavnej, tak to vykecal
AFAIK byl spíš naštvaný (právem), že nebyl mezi těmi, kdo dostali informace. Na jednu stranu ho chápu, na druhou nejsem úplně přesvědčený, že tohle je ten správný způsob, jak zařídit, aby je příště dostal.
Protože to mělo vyjít až pozděj ale de Raadt z OpenBSD musel bejt slavnej, tak to vykecal, údajně se to dozvěděl z "rumours".Vykecal to ještě dřív než patch do kernelu ještě v roce 2017? Ale dobrý no. I když bych teda čekal, že by to zveřejnil google zero za pár dní tak jako tak. Každopádně vzhledem k tomu, že je LazyFPU dneska víceméně blokovaný tím, že všichni stejně flushujou při každým task switchi (a fakt to není tak velký problém implementovat), tak na to tak 90 denní lhůta IMO stačila.
To provedení FPU (který platilo jenom u předchozích architektur, ne u současnejch) ba na tom asi nic nezměnilo. Tady jde o to, že to lazy FP restore má aktualizovat stav FPU registrů předtím, než na ně progeam po přepnutí kontextu šáhne.Právě že u bulldozeru na ty registry možná šáhne mnohem dřív druhé jádro (pokud potřebuje 256bit operaci), takže se musí udržovat konzistence už každým taktu ne až na každém task switchi. Alespoň na blokovém schéma jsou ty FPU registry označováný jako shared. Jako samozřejmě ten bug se tam asi dá udělat taky, ale tady je vyšší šance, že si toho někdo všimne při verifikaci. P.S.
RHEL-7 defaults to (safe) “eager” floating point register restore on Sandy Bridge and newer Intel processors, so is not affected. AMD processors are not affected.
Právě že u bulldozeru na ty registry možná šáhne mnohem dřív druhé jádro (pokud potřebuje 256bit operaci), takže se musí udržovat konzistence už každým taktu ne až na každém task switchi. Alespoň na blokovém schéma jsou ty FPU registry označováný jako shared. Jako samozřejmě ten bug se tam asi dá udělat taky, ale tady je vyšší šance, že si toho někdo všimne při verifikaci.V blokovém schématu to může vypadat jak chce, ale ty registry samozřejmě s druhým vláknem sdílené nejsou, to by bylo absurdní. Je to jako v případě SMT/HT, tyhle struktury musí být zdvojené. Respektive fyzický registrový soubor (který je mnohem větší) může být sdílený, to není problém, ale nikdy ne na něj odkazující architektonické registry, které jádra (vlákna) vidí. A mapování mezi arch. registry a tím fyzickým souborem zajistí, aby druhé vlákno nikdy nevidělo obsah mapovaný z druhého vlákna.
Každopádně vzhledem k tomu, že je LazyFPU dneska víceméně blokovaný tím, že všichni stejně flushujou při každým task switchi (a fakt to není tak velký problém implementovat), tak na to tak 90 denní lhůta IMO stačila.P.S. Právě že to vypadá, že na Windows je pořád LazyFP používané a patche zatím nejsou. Takže delší čekání bylo na místě, i když bug IMHO tak hrozný není (ale bavíme se o principu). V Linuxu je Lazy FP Restore nejspíš vypnuté z jiných důvodů - už nebylo považováno za užitečné kvůli tomu, že už neneí časté, že by aplikace nesahaly na FPU/SIMD. Zdroj: Linus.
V blokovém schématu to může vypadat jak chce, ale ty registry samozřejmě s druhým vláknem sdílené nejsou, to by bylo absurdní.OK jsem to blbě nazval no. Zase pro stav, kdy je ta jednotka prvním vláknem používaná a druhé vlákno si na ní chce udělat out of order spekulativní přístup, tak nutně narazí na to, že je busy.
Právě že to vypadá, že na Windows je pořád LazyFP používané a patche zatím nejsou. Takže delší čekání bylo na místě, i když bug IMHO tak hrozný není (ale bavíme se o principu).Neměla by oprava spočívat jen v tom, že místo v handleru té lazy FPU vyjímky se ty FPU registry uloží už při task switchi? To je tak přesunutí volání jedné funkce a rekompilace.
V Linuxu je Lazy FP Restore nejspíš vypnuté z jiných důvodů - už nebylo považováno za užitečné kvůli tomu, že už neneí časté, že by aplikace nesahaly na FPU/SIMD.To je to samý co píšu IMO . Každej task switch stejně nakonec skončil vyprázdněním registrů předchozí úlohy, tak odstranění té hw vyjímky se kód zjednodušil.