Open source softwarový stack AMD ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán v nové major verzi 10.0. S ROCm.AI. Přehled novinek v aktualizované dokumentaci.
Finanční skupina Partners se stala minulou neděli obětí kybernetického útoku, při kterém se útočníci dostali k některým osobním údajům klientů. Společnost o tom informovala ve čtvrtek. Ujišťuje, že peníze klientů nejsou v ohrožení. „Kybernetický útok zasáhl část IT infrastruktury naší společnosti. Ihned po zjištění útoku jsme s pomocí externích bezpečnostních odborníků začali intenzivně pracovat na minimalizaci škod. Útočníci se
… více »Americká technologická společnost Meta Platforms se dohodla, že zaplatí až zhruba 18 miliard dolarů (asi 373 miliard Kč) za mimosoudní urovnání sporu o závislosti dětí na sociálních sítích a provede významné změny pro jejich používání mladistvými. Téměř tři desítky států USA firmu v roce 2023 obvinily z toho, že sítě Facebook a Instagram vědomě navrhla tak, aby u dětí vyvolávaly závislost, a zatajovala tyto dopady před veřejností. Firma se
… více »Byl publikován aktuální přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Blíží se vydání podporující čipy M3. Vývojáře lze podpořit na GitHub Sponsors a Open Collective.
Kancelářský balík LibreOffice byl vydán ve verzi 26.8. Mimo jiné vylepšuje typografii a kompatibilitu s formáty MS Office, více v poznámkách k vydání.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 26.8. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 23.1.0, tj. první stabilní verze z nové řady 23.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools, Libc++, Polly a Flang.
Google Chrome 152 byl prohlášen za stabilní. Nejnovější stabilní verze 152.0.7977.64 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Opraveno bylo 327 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Před 35 lety, 25. srpna 1991, oznámil Linus Benedict Torvalds v diskusní skupině comp.os.minix, že vyvíjí (svobodný) operační systém (jako koníček, nebude tak velký a profesionální jako GNU) pro klony 386 (486), že začal v dubnu a během několika měsíců by mohl mít něco použitelného.
Apple představil čipy M6 a M5 Ultra, Mac mini s M6 nebo M5 Pro a Mac Studio s M5 Max nebo M5 Ultra. Fedora Asahi Remix zatím podporuje jenom M1 a M2.
Současný vývojový kernel nese označení 4.5-rc2. Vydán byl 31. ledna a podle Linuse se práce na vydání zrychlily: „Ještě v pátek jsem měl v plánu zmínit, jak prima je nový trend malých rc2 vydání, protože až do pátku nebylo příliš mnoho žádostí o zařazení. Jenomže se ukázalo, že všechny žádosti se objevily až o víkendu a 4.5-rc2 nakonec až tak malým vydáním nebude. Za víkend se prakticky zdvojnásobila.“
Stabilní aktualizace: 3.14.60 a 3.10.96 byly vydány 29. ledna a o dva dny později je následovaly 4.4.1, 4.3.5 a 4.1.17.
*Nejhorší* chyby jsou ty, kde kód dává smysl a na lokální úrovni funguje bez problému, ale kombinace dvou nebo tří částí kódu, které jsou jednotlivě srozumitelné, z jakýchsi podivných důvodů nefunguje – kvůli absenci tranzitivity. S tím je opravdu těžké se vypořádat.
Vskutku, paměťový model definovaný výhradně testy lakmusovými papírky by se dal kvalifikovat jako exotická forma mučení.
Bylo nebylo, blokové I/O plánovače, zodpovědné za optimalizování proudu I/O požadavků k úložným zařízením, byly oblastí intenzivního vývoje. Charakteristika rotujících disků znamenala, že výkon I/O se hodně různil podle toho, v jakém pořadí byly požadavky vyřizovány. Změny v hardwaru (hlavně přechod k SSD) způsobily úpadek motivace na práci v této oblasti. To nejlepší, čeho může u moderních disků I/O plánovač dosáhnout je, že zůstane stranou. I přesto přetrvává aspoň nějaký zájem na vylepšování I/O plánovačů a dokládá to zejména návrat plánovače BFQ (budget fair queuing).
Plánovač BFQ vyvinuli Paolo Valente a Arianna Avanzini a naposledy se o něm psalo v červnu 2014. Je odvozen od plánovače CFQ I/O, který je obsažen v současných jádrech. Na většině systémů se jedná o výchozí plánovač, ačkoliv někteří uživatelé s rychlejšími disky jej nahrazují některým z jednodušších plánovačů. Nicméně, BFQ se od svých kořenů v CFQ za tu dobu hodně odchýlil.
Pro podrobnosti o tom, jak BFQ funguje, viz zmíněný článek z roku 2014. Následuje jen velmi zkrácené shrnutí. Pro jakékoli blokové zařízení BFQ vytvoří frontu požadavků pro každý proces v systému. Každá fronta získá rozpočet, který představuje množství I/O provozu, které může vyslat k diskové jednotce v daném plánovacím cyklu. Rozpočet je stanoven plánovačem podle priority I/O a pozorováním I/O chování procesu. Odesílaný kód (pod názvem B-WF2Q+) obsluhuje každou frontu zvlášť; v jednotlivých krocích je uvolněno určité množství I/O až do výše přidruženého rozpočtu. Správným nastavením rozpočtů se BFQ snaží zajistit, aby každý z procesů dostal spravedlivé množství dostupného I/O pásma, a to v celkem malých mezích latence.
Hlavní myšlenka je jednoduchá, ale reálný svět je o něco složitější, a tak BFQ, stejně jako předtím CFQ, nashromáždil velké množství heuristik, jejichž cílem je zlepšení výkonu v konkrétních oblastech. Dochází ke sloučení front spolupracujících procesů ve stejné oblasti disku, což umožňuje větší konsolidaci požadavků. Pokud proces vykonávající požadavek na čtení vyprázdní svou frontu před vyčerpáním rozpočtu, bude zařízení na krátkou dobu označeno jako nečinné, aby tak proces získal šanci vytvořit další požadavek. Procesy, identifikované jako soft realtime (ty s mírnými požadavky na šířku pásma a pravidelně přerušovaným cyklem žádostí) získají vyšší prioritu, stejně jako právě začínající procesy atd.
Podle všeho se BFQ od června 2014 příliš nezměnilo. Popisované heuristiky jsou více méně stejné. Jistě došlo k odstranění chyb a zlepšení výkonu na základě zkušeností z využívání plánovače v ostrém provozu – plánovač se dodával v několika méně rozšířených distribucích a zřejmě byl využíván v některých telefonech. Původní patche pocházely od Paola z univerzity v Modeně a Reggio Emilia, ale ty současné chodí z adresy v Linaru, což by mohlo naznačovat nějaký komerční zájem.
Plánovači BFQ se dostalo v roce 2014 dobrého přijetí – na rozdíl od navrženého postupu zavedení do jádra. V té době byl BFQ přidán jako nový I/O plánovač spolu s ostatními do kernelu, bohužel komunita kolem jádra neměla vůbec chuť na další plánovač, natož takový, který by se tolik podobal plánovači CFQ. Vzhledem k tomu, že BFQ je hlavně vylepšením CFQ, bylo Paolovi doporučeno zapracovat na sérii patchů vyvíjejících CFQ požadovaným směrem. To se snadněji řekne než udělá, přestože BFQ původně z CFQ pochází. Tyto dva plánovače se během vývoje BFQ značně vzdálily. V důsledku tohoto požadavku zmizel BFQ plánovač z e-mailové konference na více než rok.
Jeho návrat naznačuje, jak mají BFQ vývojáři v plánu uspokojit požadavek, který jim byl zadán. Nový patchset se skládá z 22 změn, rozdělených do tří kroků:
V době psaní tohoto článku nebyl ještě nový patch nikým komentován, takže se teprve ukáže, zda komunita patch přijme či nikoli. Dá se říct, že jaderní vývojáři mají rádi kód, který se vyvíjí po menších krocích. Velký kus nového kódu v jediném patchi je složitý na kontrolu a je velké riziko problémů s výkonem či regresemi. CFQ se hojně využívá, jeho destabilizace po několik vydání není nejlepší nápad. Je tedy možné, že tento příspěvek nebude o moc úspěšnější než ten předešlý.
Na druhou stranu, možná v současné době neexistuje lepší způsob, jak BFQ do kernelu dostat. Pokud by nadšení pro BFQ bylo nízké, znamenalo by to, že bude odsouzen k životu mimo hlavní strom i nadále. Jenže BFQ se zdá být prokazatelně lepší než CFQ a jeho heuristiky jsou srozumitelnější, takže motivace pro zavedení do jádra by tu byla. Lze si představit, že vybudovat kvalitní kód bude nějaký čas trvat, takže bychom se BFQ mohli dočkat třeba ve vývojovém cyklu 4.6. Tou dobou by vývojová komunita mohla přijít na způsob, jak tento kód začlenit a jak ho učinit dostupným celé uživatelské komunitě.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: