Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Byla vydána verze 2.0.0 programovacího jazyka Kotlin (Wikipedie, GitHub). Oficiálně bude představena ve čtvrtek na konferenci KotlinConf 2024 v Kodani. Livestream bude možné sledovat na YouTube.
Byla vydána nová major verze 27.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Byla vydána nová verze 1.8.0 svobodného multiplatformního softwaru pro konverzi video formátů HandBrake (Wikipedie). Přehled novinek v poznámkách k vydání na GitHubu. Instalovat lze také z Flathubu.
Microsoft představil nové označení počítačů Copilot+. Dle oznámení se jedná se o počítače poskytující funkce umělé inteligence. Vedle CPU a GPU mají také NPU (Neural Processing Unit). Uvnitř představených Copilot+ notebooků běží ARM čipy Qualcomm Snapdragon X Elite nebo X Plus.
Příspěvek na blogu Codean Labs rozebírá zranitelnost CVE-2024-4367 v PDF.js, tj. mj. prohlížeči PDF souborů ve Firefoxu. Při otevření útočníkem připraveného pdf souboru může být spuštěn libovolný kód v JavaScriptu. Vyřešeno ve Firefoxu 126.
Lazygit byl vydán ve verzi 0.42.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
Současné vývojové jádro je 4.11-rc8; finální verze 4.11 nebyla vydána 23. dubna, jak se očekávalo. Linus se raději rozhodl vydat ještě jeden prepatch. „Původně jsem zamýšlel 4.11 vydat dnes, ale přestože minulý týden nedošlo k *mnoha* změnám, pár jich bylo dost otravných, takže místo toho tu máme ještě jedno rc vydání. Dostal jsem opravy problémů, které se objevily, takže jsem mohl 4.11 vydat v tomto stavu, ale nebylo by to v pořádku.“
Seznam regresí z 21. dubna ukazuje deset známých problémů v jádře 4.11.
Stabilní aktualizace: 4.10.12, 4.9.24 a 4.4.63 byly vydány 21. dubna. O den později následovala 3.18.50.
Stabilní verze 4.10.13, 4.9.25 a 4.4.64 byly v době psaní tohoto článku v procesu revidování, vydány byly 27. dubna.
Subsystém vícefrontové blokové vrstvy, který byl představen v roce 2013, byl nezbytným krokem k tomu, aby jádro škálovalo s nejrychlejšími paměťovými zařízeními na velkých systémech. Implementace v současných jádrech je ale neúplná, postrádá totiž plánovač I/O navržený tak, aby pracoval s vícefrontovými zařízeními. Mezera by měla být vyplněna ve vývojovém cyklu 4.12, v němž jádro dostane ne jeden, ale hned dva vícefrontové plánovače I/O.
Absence plánovače I/O může v kódu pro více front vypadat jako zásadní vada, ale pravdou je, že potřeba plánovače nebyla od počátku jasně patrná. High-end disky jsou většinou SSD, jež netrpí problémy se zpožděním kvůli rotaci, takže nejsou tak citlivé na pořadí operací. Ovšem ukazuje se, že plánování I/O má smysl i v případě těch nejrychlejších zařízení – plánovač může spojovat sousedící požadavky, a tak snížit celkový počet operací, a upřednostňovat některé operace před jinými. Takže zájem o přidání plánování I/O vícefrontových zařízení je tu už nějaký čas, ale dosud chyběl kód.
Řešení se přiblížilo se začleňovacím oknem 4.11, kdy bloková vrstva získala podporu plánování I/O vícefrontových zařízení. Plánovač I/O deadline přešel na tento mechanismus jako důkaz proveditelnosti, ale nikdo jej nevnímal jako skutečné řešení do budoucna.
Po přidání plánování I/O byl prvním zamýšleným využitím plánovač BFQ (Budget Fair Queuing), na němž se pracuje už roky. Každému procesu přiděluje rozpočet I/O, což v kombinaci s několika heuristikami vede k údajně mnohem lepší odezvě I/O, zvláště na pomalejších zařízeních. Uživatelé s rotačními úložišti mají z BFQ prospěch, existují však výhody i při použití pomalejších SSD zařízení. V důsledku je tu značný zájem o použití BFQ například v mobilních zařízeních.
Myšlenka, že BFQ je lepší než plánovač CFQ, který se nachází v hlavních jádrech, není nijak zvlášť kontroverzní, ale začlenit BFQ byl i tak dlouhý proces. Jednou z posledních překážek bylo, že šlo o tradiční plánovač I/O spíše než vícefrontový plánovač. Vývojáři subsystému blokové vrstvy mají dlouhodobý cíl přejít u všech ovladačů na vícefrontový model a začlenění obyčejného (tedy ne vícefrontového) plánovače I/O se nejevilo jako krok tímto směrem.
Vývojář BFQ Paolo Valente v posledních několika měsících pracoval na převedení kódu do vícefrontového rozhraní. Známé problémy s jeho prací byly vyřešeny a správce blokového subsystému, Jens Axboe, souhlasil se začleněním do vydání 4.12. Pokud všechno půjde podle plánu, bude dlouhé čekání na plánovač BFQ u konce.
Zajímavé je, že BFQ nebude jediným plánovačem vícefrontového I/O, který se v cyklu 4.12 dostane do upstreamu. Ten druhý, vyvinutý v mnohem kratším čase, by totiž měl být také začleněn. Člověk by se mohl divit, k čemu je potřeba druhý plánovač, obzvláště když vývojáři kladou důraz na obecná řešení, která mohou pokrýt širokou škálu použití. Ovšem zdá se, že vskutku existuje rozumný důvod pro začlenění druhého vícefrontového plánovače.
BFQ je složitý plánovač navržený tak, aby poskytoval dobrou interaktivní odezvu, zvláště na pomalejších systémech. Má relativně vysokou režii pro dílčí operace, což je opodstatněné, když I/O operace samotné jsou pomalé a drahé. Tato složitost ale nemusí dávat smysl v situacích, kdy jsou I/O operace levné a hlavním problémem je propustnost. Při pracovní zátěži serveru používajícího SSD může být lepší používat jednodušší plánovač, který umožňuje slučování požadavků a možná i jednoduchá pravidla, většinu času se však neplete do cesty.
Plánovač I/O Kyber, kterým přispěl Omar Sandoval, by mohl být přesně tím potřebným plánovačem. Je určen pro rychlá vícefrontová zařízení a postrádá většinu složitosti plánovače BFQ. Nemá ani tisíc řádek kódu. Jeho pravidla, i když jednoduchá, se jeví jako zajímavá ozvěna práce na bufferbloatu, kterou se povedlo udělat v části jádra, která má na starosti síťování.
I/O požadavky procházející skrze Kyber jsou rozděleny do dvou primárních front, jedné pro synchronní a druhé pro asynchronní požadavky – jinými slovy, jedné pro čtení a druhé pro zápisy. Proces, který žádá o čtení, obvykle není schopen pokračovat, dokud není příslušnému požadavku vyhověno a data nejsou k dispozici, tudíž tyto požadavky jsou vnímány jako synchronní. Naopak operace zápisu může být dokončena někdy později, přičemž žádající proces většinou nezajímá, kdy k zápisu skutečně dojde. Takže je běžné upřednostňovat čtení před zápisy, nikoliv však do té míry, že by došlo k vyhladovění zápisů.
Klíčem k algoritmu Kyber je to, že počet operací (čtení i zápisu) odeslaných do odbavovacích front (které směřují operace přímo zařízení) je striktně omezen tak, že udržuje tyto fronty relativně krátké. Pokud jsou odbavovací fronty krátké, pak je množství času, který uplyne během čekání požadavku ve frontě (latence dílčího požadavku), poměrně malé. To zajišťuje rychlé dokončení požadavků s vyšší prioritou.
Plánovač reguluje skutečný počet požadavků vpuštěných do odbavovacích front podle měření doby nutné ke splnění jednotlivých požadavků a úpravou limitů k dosažení požadovaných latencí. K dosažení cílových latencí slouží správci systému dva atributy s výchozími hodnotami 2 ms pro čtení a 10 ms pro zápis. Jako vždy bude při nastavování těchto hodnot docházet ke kompromisům. Příliš nízké hodnoty zajistí nízké latence, ovšem za cenu méně příležitostí ke sloučení požadavků, což zhorší propustnost.
Také Kyber byl přijat do začleňovacího okna 4.12. Takže pokud půjde vše podle plánu, bude mít jádro 4.12 dvě nové možnosti plánování I/O ve vícefrontových zařízeních. Uživatelé, kteří se zabývají interaktivní odezvou a možná pracují s pomalejšími zařízeními, se pravděpodobně přikloní k BFQ, zatímco servery, na kterých poběží úlohy citlivé na propustnost, budou pravděpodobněji používat Kyber. Každopádně se podařilo zaplnit významnou mezeru v subsystému vícefrontového blokového I/O, čímž se otevírá cesta k případnému přechodu všech jaderných blokových ovladačů na vícefrontové API.
Nástroje: Tisk bez diskuse
Tiskni Sdílej: