Lazygit byl vydán ve verzi 0.42.0. Jedná se o TUI (Text User Interface) nadstavbu nad gitem.
K open source herní konzole Picopad přibyla (𝕏) vylepšená verze Picopad Pro s větším displejem, lepšími tlačítky a větší baterii. Na YouTube lze zhlédnout přednášku Picopad - open source herní konzole z LinuxDays 2023.
Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Aktuální vývojová verze jádra je 3.14-rc8 vydaná 24. března. Linus k ní řekl: Oproti mému běžnému plánu mám den zpoždění, doufal jsem, že to nakonec bude vypadat na verzi 3.14, ale nevyšlo to. Proto tu máme rc8 a vidím to na konečné 3.14 přiští víkend.
Stabilní aktualizace: verze 3.13.7, 3.10.34 a 3.4.84 vyšly 23. března; verze 3.12.15 vyšla 26. března.
Cache stránek je na Linuxu pověřena správou cachí bloků dat z persistentních úložných zařízení; jde o zásadní součást jak virtuálního systému souborů, tak subsystémů správy paměti. Cache stránek je klíčem k výkonu systému jako celku. Bohužel už v řadě směrů začíná vykazovat své stáří. První technická debata na Linuxovém sumitu pro úložiště, systémy souborů a správu paměti 2014 se zaměřila na řadu problémů s cachí stránek a ukázala přibližnou cestu k jejich řešení.
Jedním z hrozících problémů, který představil James Bottomley, je, že na 32bitových systémech nemůže cache stránek pracovat s disky většími než 16 TB. Cache stránek používá nativní velikost stránky (4 KB) k adresaci bloků na zařízení; s 32bitovými indexy bloků končí schopnost adresace na 16 TB. James kladl tyto otázky: je třeba tento problém na 32 bitech řešit a pokud ano, tak jak to udělat?
Řada vývojářů to jednoznačně vnímala tak, že tento problém není nutné řešit. Vnímají 32bitové systémy jako systémy, co jsou už na odchodu; kdokoliv, kdo chce používat velká úložná zařízení, by si měl pořídit 64bitový systém. Ve skutečném světě to ale nemusí být tak snadné. 32bitová zařízení tu s námi ještě nějakou dobu budou, hlavně v říši embedded zařízení. Lidé si pořídí 16TB USB disky a budou očekávat, že poběží. Jiní umístí 32bitový procesor do laciného NAS a budou tam chtít dát velké disky. Navíc tu máme výrobce, kteří dávají 32bitové procesory přímo do disků, aby tak doplnili protokoly jako iSCSI.
Dave Chinner poukázal na to, že jádro problému se skrývá v samotné cache stránek. Pokud dělá aplikace přímé I/O (čímž je obcházena cache stránek), pak žádné problémy nejsou. Pokazí se to až jakmile se uživatelský prostor pokusí o bufferované I/O na velkém disku. K tomu dojde při používání systémů souborů, ale i před tím: udev například používá bufferované I/O při mapování disků. A je tu ještě jeden drobný problém: i kdyby bylo možné 16TB systém souborů připojit a používat na 32bitovém systému, tak stále nebude dostatek adresního prostoru pro běh kontroly systému souborů. Tento problém se zdá na těchto systémech být neřešitelným. Jinými slovy, i když opravíme jádro, tak zbytek ekosystému bude zkrátka rozbitý.
Tyto informace více méně vedly ke shodě. Nikdo se nebude snažit o podporu větších systémů souborů na 32bitových systémech. Ale přímé I/O bude na velkých discích fungovat a bude nadále podporováno. Takže situace, které závisí jen na přímém I/O – například v případě iSCSI – budou na 32bitových systémech fungovat. V ostatních případech bude nutné si pořídit 64bitové CPU.
Dave spolus s Christophem Lameterem pak přešli na další téma: ukládání větších bloků dat v cache stránek. Ukázalo se, že o to usilují z odlišných důvodů, což je vede k odlišným řešením. Může být možné vyřešit oba problémy, ale jedno z řešení bude pravděpodobně hotové dříve než to druhé.
Christoph má obavy z režie operačního systému na všech úrovních; součástí jeho řešení je podpora větších fyzických disků v cache stránek. Větší fyzické stránky by snížily režii správy v jádře a objem práce spojený se sestavováním a úklidem [setup and teardown] při I/O operacích nad těmito stránkami. K velikostem v cachi stránek je možné přiřazovat atribut „řazení“, což umožní uložení odlišně velkých stránek, ale skrývá se tu obvyklý problém: udržení schopnosti doopravdy alokovat větší fyzické stránky poté, co systém už nějakou dobu běží.
Podle Christopha je řešením udržovat si rezervu v podobě velkých stránek jen pro tento účel, ale to je „divné“ a obtížné správně vyladit. Jiným řešením je pak umožnit jádru přesouvat stránky, defragmentovat tedy za běhu. Většina nutné podpory už existuje; subsystém správy paměti má schopnost migrovat stránky a tato schopnost se používá v kódu pro kompakci stránek z účelem defragmentace paměti. Problém je v tom, že ne všechny stránky se dají přesouvat; jde o velkou překážku, jelikož na rozbití jedné velké fyzické stránky stačí jediná nepřesunutelná stránka.
Existuje řada důvodů, proč nemusí být možné přesunout konkrétní stránku, ale jedním z nejzávažnějších příčin je alokace objektů v jádře. Kdyby objekty získané ze slab alokátoru byly přesunutelné, tak by problém zmizel. Christoph má patche, které tuto funkčnost přidají do některých intenzivně používaných cachí (kupříkladu do inode cache), ale ještě nebyly začleněny. Proti tomuto nápadu se objevil odpor; jádro je plné ukazatelů na objekty; žádný objekt nelze přesunout, leda by bylo možné všechny tyto ukazatele změnit bez zanesení race condition. Christoph trval na tom, že většinu obtíží lze zažehnat změnmi v několika důležitých datových strukturách.
I tak to ale nemusí vše zafungovat tak, jak by se Christophovi líbilo. Mel Groman řekl, že i na současných systémech, kde probíhá snaha o oddělení přesunutelných a nepřesunutelných stránek, se ukazuje, že překvapivě hodně „přesunutelné“ paměti zkrátka neexistuje. Stránky tabulky stránek mohou představovat velkou část paměti a nejde je přesunout; patch, který to napravoval, přidával 5-6% režii, a proto nebyl začleněn. Jiné stránky jsou údajně přesunutelné, ale jsou zablokovány pro přímé I/O nebo jinak drženy na místě v paměti; i kdyby tomu bylo věnováno velké úsilí, tak by mohla být migrace stránek obtížná. Prozatím je pro většinu uživatelů hlavním symptomem to, že alokace transparentních velkých stránek selže; to není velký problém. Pokud bychom ale podle Mela došli do fáze, že opravdu závisíme na schopnosti přesouvat stránky, „tak se nám to šeredně vymstí“.
Dave se zeptal na odlišnou, ale příbuznou otázku. Zajímala ho lepší podpora systémů souborů s bloky většími než je velikost stránky v systému. Podpora větších fyzicky souvislých stránek v cache stránek by v tomto ohledu mohla pomoci a tento přístup nabízí jisté výhody, hlavně díky tomu, že pro jeho podporu nejsou v kódu systémů souborů nutné téměř žádné změny. To samé se ale nedá říct o subsystému pro správu paměti, kde by to s rozsahem změn bylo závažnější. Než abychom na to hned skočili, bychom podle něj měli zvážit, zda musíme problém opravdu řešit takto.
Jedním z popudů pro větší fyzické stránky byla omezení v zásobníku blokového I/O; maximální velikost jediného I/O požadavku byla po dlouhou dobu příliš nízká na to, abychom z vysokorychlostních úložišť získali maximální výkon. Zvýšení velikosti stránek by tento limit posunulo dále, což by umožnilo přenést více dat se stejným počtem stránek a problém by byl vyřešen. Ale omezení velikosti požadavků už bylo vyřešeno, takže není takový tlak na řešení problému s velikostí stránek. Skutečným problémem je tedy podle něj to, že cache stránek ví o velikosti bloků používaném na každém systému souborů. Končí to tak, že sleduje hodně údajů z úrovně systému souborů, čímž se duplikují údaje uložené na systémech souborů. Tato duplikace vede k problémům s koherencí a občasným ošklivým chybám; je to také zdroj toho omezení, že bloky systému souborů nemohou být větší než systémová velikost stránky.
Nick Piggin se pokusil tento problém vyřešit už před lety svou prací na fsblock. Problém s tímto patchem je ten, že vyžaduje rozsáhlé změny ve všech systémech souborů. I ext2, který byl Nickem upraven na ukázku, potřeboval změn opravdu hodně. Proto Dave hledal jiné řešení. Ve zkratce by byl rád, kdyby cache stránek přestala udržovat mapování mezi stránkami a bloky systému souborů. Vše ostatní je už v systému souborů známo; odstranění tohoto sledování z cache stránek by mohlo umožnit odstranit omezení velikosti bloků.
Tato práce by rovněž umožnila eliminovat používání hlaviček bufferů [buffer heads] pro sledování bloků. Vývojářům systémů souborů se s nimi těžko pracuje; navíc jen s malým užitkem přidávají hodně režie. Mapování stránek na bloky se mnohem lépe řeší na základě informací pro sledování extentů, které už v kódu systému souborů jsou. Cache stránek by se musela starat jen o to, jestli je daná stránka aktuální s ohledem na zapsaný permanentní stav; vše ostatní se může snáze a spolehlivěji řešit jinde.
Christoph se ozval s tím, že chce, aby cache stránek vyšší úrovně snížila režii aplikací, hlavně okolo I/O požadavků; řešení na úrovni systémů souborů popisované Davem podle něj tento problém neřeší. Martin Peterson poukázal na to, že menší granularita I/O může být stejně vynucena hostitelskými adaptéry, ale Christoph řekl, že používá high-end hardware a tímto tedy netrpí. Dave za souhlasu ostatních prohlásil, že tu popisujeme dva odlišné problémy a že ve každém případě je nejprve potřeba vyřešit velké bloky systémů souborů.
Vyskytly se také obavy z interakce mezi formátem binárek ELF, který má v sobě jisté předpoklady o zarovnání, a velkými bloky systému souborů. Vypadá to ale, že v této oblasti žádné problémy nejsou, hlavně jakmile se člověk zbaví 32bitových systémů.
Na konci debaty se zdálo, že panuje shoda, že by Dave měl dále dělat na přesunu povědomí o systému souborů pryč z cache stránek. Podle něj jde o překvapivě malou změnu, ale stále o opravdu hodně práce. Změny budou volitelné; nikdo neočekává, že celá ta spousta starých systémů souborů na Linuxu bude aktualizována, a současně je nutné, aby dál fungovaly. Vyskytly se obavy o to, kolik práce by se dotklo obecného kódu pro systémy souborů; nikdo nechce vidět duplicitní implementace nakopírované do jednotlivých systémů souborů.
Mezitím byl Christoph přizván k tomu, aby pracoval na podpoře větších fyzicky souvislých stránek v cache stránek. Bylo ale rozhodnuto, že se musí jednat o příznak pro alokátor; funkčnost systému nemůže záviset na úspěšnosti alokace. V obou případech bude prvním krokem zaslání kódu k revizi.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
14.4.2014 15:41
pavlix | skóre: 54
| blog: pavlix
14.4.2014 13:02
Saljack | skóre: 28
| blog: Saljack
| Praha
14.4.2014 22:04
Jendа | skóre: 78
| blog: Jenda
| JO70FB
15.4.2014 14:41
Gilhad | skóre: 20
| blog: gilhadoviny
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz