Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Microsoft vydal novou velkou aktualizaci 2404.23 v září 2019 pod licencí SIL Open Font License (OFL) zveřejněné rodiny písma Cascadia Code pro zobrazování textu v emulátorech terminálu a vývojových prostředích.
OpenTofu, tj. svobodný a otevřený fork Terraformu vzniknuvší jako reakce na přelicencování Terraformu z MPL na BSL (Business Source License) společností HashiCorp, bylo vydáno ve verzi 1.7.0. Přehled novinek v aktualizované dokumentaci. Vypíchnout lze State encryption.
Spouštět webový prohlížeč jenom kvůli nákupu kávy? Nestačí ssh? Stačí: ssh terminal.shop (𝕏).
Yocto Project byl vydán ve verzi 5.0. Její kódové jméno je Scarthgap. Yocto Project usnadňuje vývoj vestavěných (embedded) linuxových systémů na míru konkrétním zařízením. Cílem projektu je nabídnou vývojářům vše potřebné. Jedná se o projekt Linux Foundation.
Operační systém 9front, fork operačního systému Plan 9, byl vydán v nové verzi "do not install" (pdf). Více o 9front v FQA.
Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
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: