Open-source trackball Ploopy Adept má novou verzi nazvanou A+. Stále jde o symetrický desktopový trackball s šasi z 3D tiskárny a firmwarem QMK. Novinkami jsou dvojice tlačítek, jimiž půjde také otáčet, a volitelná opěrka ruky. Funkcionalita firmwaru je rozšířena o gesta, vrstvy a možnost konfigurace za běhu. Schémata a kód jsou jako obvykle na GitHubu. A+ půjde předobjednat za 99 CAD (bez dopravy a cla/DPH).
Prusa Research představil nové modely svých 3D tiskáren: Prusa XL+, CORE One+ (Gen 2) a CORE One L+.
Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.64. Vyzkoušet lze online demo.
NVIDIA na konci ledna vydala v beta verzi nativního linuxového klienta své cloudové herní služby GeForce NOW. Včera oznámila ukončení beta verze a oficiální podporu Linuxu.
Byla vydána nová verze 3.5.0 nástroje pro inkrementální kopírování souborů rsync (Wikipedie). Přehled oprav a vylepšení v souboru NEWS. Řešeno je 33 zranitelností.
Organizace Apache Software Foundation (ASF) vydala verzi 31 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Firma IBM uvedla svůj první mikropočítač Personal Computer před 45 lety, v srpnu 1981. Základní konfigurace modelu 5150 za 1 565 tehdejších dolarů obsahovala desktop s Intel 8088 a 16KB RAM, Color Graphics Adapter a klávesnici. Právě klávesnice Model F/XT vybavené kapacitními spínači, vlivné a s převodníkem dodnes použitelné, připomíná sběratelský web Admiral Shark's Keyboards.
Slovensko odhalilo ruské součástky ve dvou testovaných zařízeních na zjišťování přestupků v silničním provozu a označilo je za bezpečnostní riziko. S odvoláním na vyjádření slovenského Národního bezpečnostního úřadu (NBÚ) to včera oznámil ministr vnitra Matúš Šutaj Eštok. Zároveň ohlásil ukončení spolupráce svého úřadu s dodavatelem části uvedeného systému, slovenskou společností Soitron. Opozice, která na problematické kamery upozornila už dříve, vyzvala k odvolání ministra vnitra.
Dle plánu dnes ve 13:00 proběhne veřejný test eDokladů. Jeho cílem je ověřit připravenost aplikace a související infrastruktury na vysokou souběžnou zátěž před podzimními komunálními volbami.
Byla vydána nová verze 3.47 frameworku Flutter (Wikipedie) pro vývoj mobilních, webových i desktopových aplikací a nová verze 3.13 souvisejícího programovacího jazyka Dart (Wikipedie).
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