Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Aktuální vývojová verze jádra je 3.9-rc8 vydaná 21. dubna. Ano, skutečně jsem doufal (a měl jsem to v plánu), že během tohoto víkendu vydám konečnou verzi 3.9, ale našlo se tolik problémů, že jsem se na to necítil. Bylo to dost na hraně a žádný z problémů nebyl až tak velký a možná jsem to mohl zkrátka označit za verzi 3.9 a otevřít začleňovací okno, ale další týden nás přece nezabije.
Stabilní aktualizace: verze 3.6.11.2 vyšla 19. dubna a verze 3.5.7.11 vyšla 22. dubna.
Aktualizace 3.8.9, 3.4.42 a 3.0.75 se aktuálně revidují; jejich vydání lze očekávat 25. dubna nebo později.
Poučka pro tento den:
yes "" | make menuconfig
je špatný nápad.
Linus si nedávno hrál s nástrojem sparse pro statickou analýzu kódu, když narazil na zajímavý a snad i překvapivý zdroj chyb v jaderném kódu. Pravdou je, že to není žádné překvapení, jakmile pochopíte podstatu, ale i tak to představuje riziko pro netušící.
Představte si takovýto kód:
u32 bitmask = 0xff; u64 value; value &= ~bitmask;
Člověk by očekával, že tento kód vynuluje spodních 8 bitů ve value a to se i stane. Jenže operátor bitové negace ~ je aplikován na 32bitový typ, takže ~bitmask se vyhodnotí jako 0xffffff00 – z pohledu 64 bitů je pak horních 32 bitů nulových. Takže logická operace AND vynuluje i těchto vrchních 32 bitů, což není kýženým výsledkem.
Když se nad tím člověk zamyslí, tak toto chování dává smysl, ale i tak to vypadá jako pravděpodobný zdroj chyb v jádře. Při analýze kódu v jádře se hned našly podobné chyby v kódu pro MIPS (právě kvůli nim se tím začal Linus zabývat), v perf a v systému souborů ext4. Je možné, že se najdou i jinde. Linus dále rozšiřuje sparse, aby označoval potenciální problémy, ale i tak je vhodné, aby si vývojáři dávali na tento typ chyb pozor.
Od úpadku centrálních pamětí se u technologií datových úložišť drží dva odlišné typy úložišť: paměť je buď rychlá a krátkodobá nebo pomalá a persistentní (trvalá). Tato situace se ale mění a to pro Linux představuje zajímavé výzvy. Jak se přizpůsobíme změnám, kde jsou non-volatilní paměťová (NVM) zařízení běžná? Ric Wheeler na toto téma měl přednášku na Linux Foundation Collaboration Summitu 2013.
Ric řekl, že o NVM se mluví už pár let. Zařízení typu NVM mají několik charakteristik, které je odlišují od jiných technologií. Jsou adresovatelné po bajtech jako běžná RAM, na rozdíl od úložných zařízení, kde to bylo vždy po blocích. Jsou persistentní: jejich stav se neztratí při odpojení napájení. Svou rychlostí, ale i cenou jsou srovnatelná s obyčejnými paměťmi, takže v blízké době nebudou tak velké jako pevné disky. Zatím si s nimi většina z nás nemůže za rozumnou cenu hrát.
První SSD vypadaly hodně jako disky; používaly obvyklé protokoly a nebyly tak rychlé, že by je systém nestíhal používat. Tato situace se ale spolu s další vlnou zařízení, která jsou obvykle připojená přes PCIe, změnila. V I/O vrstvě sídlí mezi systémem a úložištěm spousta kódu; s rostoucí rychlostí úložišť představuje jeho režie čím dál větší problém. Většina tohoto kódu není v této situaci moc k užitku, protože ten byl navržen pro zařízení s vysokou latencí. Následkem toho není na Linuxu stále možné z SSD připojených přímo k řadiči získat maximální výkon.
Ric měl nakolik návrhů, jak vyladit současné linuxové systémy pro práci se stávajícími rychlými blokovými zařízeními. Relevantní parametry najdeme pod /sys/block/dev/queue, kde dev je název příslušného blokového zařízení (například sda). Parametr rotational je nejdůležitější; pro SSD by měl být nastaven na nulu. I/O plánovač CFQ (vybraný atributem scheduler) není pro SSD tím nejlepším; deadline je lepší volba. Je také nutné dávat pozor na velikost bloků daného zařízení a podle toho zarovnat systémy souborů; více o tom v tomto PDF.
Zpět k tématu – Ric poznamenal, že kromě technických problémů jsou tu i organizační komplikace. Jaderní vývojáři jsou obvykle dost specializovaní: SCSI a SATA disky řeší rozdílní lidé. Samotnou blokovou vrstvu má na starosti oddělená, malá skupina. Za každým systémem souborů stojí zase jiný tým a těch máme opravdu mnoho. A všechny tyto skupiny lidí musejí spolupracovat, aby zařízení NVM na Linuxu fungovala optimálně.
Pro plné využití NVM budou nutné nové programovací modely a API. Na takovou změnu je třeba čas, ale hardware tu může být cobydup. Proto Ric říká, že je musíme se současnými API rozchodit co nejlépe, co to jen půjde; tomu říká „plazení“. V této fázi budou zařízení NVM používána přes původní blokové API, stejně jako SSD teď. Klíčem bude tato API co nejvíce urychlit. Je to prý škoda, ale potřebujeme blokový ovladač, který z těcho cool věcí udělá cosi nudného. Z kódu pro I/O je také nutné vypudit nadbytečnou režii.
Ted Ts'o navrhoval, že ačkoliv je obtížné přesunout aplikace k novým API, je snadné zařídit, aby je knihovny jako sqlite používaly. To by mohlo aplikacím přinést výkonnostní zlepšení beze změn v kódu. Bylo poukázáno na to, že uživatelé jsou někdy líní aplikace třeba jen překompilovat, takže než se to dostane ke koncovým uživatelům, může to chvíli trvat.
Současný stav „plazení“ je takový, že blokové ovladače pro NVM jsou ve vývoji. Jsme také svědky cachovacích technologií, které umí využívat NVM pro rychlejší přístup k tradičním úložným zařízením. Do verze 3.9 byl začleněn target dm-cache a mechanismus bcache jde do verze 3.10. Ric řekl, že ve vývoji jsou i různá řešení specifická pro konkrétní výrobce.
Přechod do fáze „chůze“ znamená upravit stávající systémy souborů. Jedním evidentním vylepšením může být přesun žurnálů na rychlejší zařízení; lze přesunout i často vyžadovaná metadata. Pro získání nejvyššího výkonu bude ale nutné předělat transakční logiku, tedy zbavit se existujících bariér a operací flush. Btrfs má aktuálně částečnou schopnost „dynamic steering“, která je krokem v tomto směru, ale přesto zbývá spousta práce.
Je také na čase uvažovat o vytvoření nových API pro aplikace pro přístup na úrovni bajtů; vývojáři aktuálně uvažují nad tím, jak by vývojáři mohli chtít k NVM přistupovat. Ric zmínil, že ctihodné rozhraní mmap() bude muset podstoupit důkladné zhodnocení a „nemusí být možné ho zachránit“. Vývojáři aplikací se budou muset o schopnostech zařízení NVM naučit a k tomu je nejprve nutné jim do rukou dát příslušný hardware.
To nemusí být snadné. Během přednášky si mnoho lidí stěžovalo, že tato zařízení jsou „skoro k mání“ už posledních deset let, ale přesto se nikdy neobjevila. Tejun Heo řekl, že nic není vytesané do kamene; nikdo neví, jakou výkonnostní charakteristiku budou zařízení mít a jak by se pro ně mělo optimalizovat. Říká se, že to by se mělo změnit a vývojáři by měli dostat hardware jako první (pod NDA). Ale zatím je těžké něco odhadovat.
Pak Ric řekl, že ve fázi „běhu“ budou nová API na úrovni zařízení, která budou moci systémy souborů a úložiště používat. Budeme mít nové systémy souborů navržené přímo pro NVM (později se mluvilo o tom, že Fusion-IO takový systém souborů má a v budoucnu jej uvolní). Storage Network Industry Association má pracovní skupinu věnovanou právě těmto problémům. Ric řekl, že přechod chvíli potrvá a bude bolestivý, podobně jako přechod na 64bitové systémy.
Následná diskuze se dotkla řady témat, prvním byla jednoduchá otázka: proč nepoužívat zařízení NVM jako RAM, ze které zkrátka po vypnutí nezmizí obsah? Problémem tohoto přístupu je to, že ačkoliv se NVM může chovat jako RAM, jiné aspekty – jako životnost – se mohou lišit. Přílišné zápisy na zařízení NVM mohou jeho životnost značně zkrátit.
Dále se mluvilo o tom, jak bude obecně těžké podporu těchto nových typů zařízení do Linuxu dostat. Komunita je víc než jen jádro; pro vytvoření úplného systému je nutné více vrstev projektů. Pro mnoho výrobců je tato komunita záhadou. Dotáhnout funkce do stavu, kdy jsou uživatelům užitečné, může trvat mnoho let. Příkladem je paralelní NFS, na kterém se pracuje alespoň deset let, ale teprve teď se mu dostává komerční podpory – a to jen na klientech.
Dalším bodem diskuze byla replikace dat. S obyčejnými blokovými zařízeními je replikace dat mezi více zařízeními relativně jednoduchá. Se zařízeními NVM, ke kterým přistupuje uživatelský prostor přímo, mizí bod, kde je možné komunikaci odchytávat, takže jádro nemá jak data replikovat.
Došlo i na téma důvěryhodnosti zařízení. Aplikace nemusejí být zvyklé na to řešit paměťové chyby; to se možná bude muset změnit. Nová API budou proto muset obsahovat funkce pro počítání kontrolních součtů a kontrolu chyb. Boaz Harrosh poukázal na to, že dokud nebudeme znát chybovou charakteristiku těchto zařízení, nebudeme se proti chybám moci bránit.
Abychom to shrnuli: blížíme se do nového zajímavého světa, ale zatím není stále jasné, jak ten svět bude vypadat a kdy k nám vlastně dorazí. V době, kdy zařízení NVM budou běžně dostupná, pro ně snad už budeme v jádře mít dobrou podporu, ale komplikovanějšímu softwaru možná potrvá, než bude schopen nového hardwaru plně využít. Bude to zajímavý přechod.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cznvmalloc() a postupně přepisovat kód tak, aby části, které se jen čtou, mohly být v NVR, protože jen autor kódu ví, co bude potřebovat zapsat jen jednou. Ale nevěřím, že se to stane, byl by to příliš velký zásah do systému i aplikací.
Mnohem více věřím, že bude vznikat nový filesystém, který nebude figurovat jako blokové médium, ale jako médium nového typu a nebude mít ty vrstvy, které optimalizují použití blokových zařízení s velkou latencí a navíc bude mít zcela jinou strukturu, protože mazací blok, zapisovací blok a čtecí adresa/blok mají zcela jiné velikosti a na ně je třeba práci optimalizovat. (tak jako pro práci s diskem je jiná optimalizace než pro práci s páskovou jednotkou)
Flash memory is an electronic non-volatile computer storage device that can be electrically erased and reprogrammed.(První řádek z Wikipedie.) To jestli se jiné technologie uchytí či dokonce zvítězí bude záležet na tom, kolik nabídnou vlastností za ekonomicky přijatelnou cenu. V současnosti se u NVM jedná v prvé řadě o flash. Jasně, že SSD má navíc řadič, který, i vzhledem k tomu, že se dosud nedohodli, co by vlastně za charakteristiky flash memory měla sdělovat OS, fixluje a předstírá systému, že je to disk. Ale tohle je fakticky to, co jsem psal už před tím časem: Flash musí poslat reálné údaje o své charakteristice a v systému se musí vyrobit nový přístup/zařízení k tomuto novému druhu paměti.
SSD nedokáže provádět opakovaný zápis na náhodnou pozici, což je základní vlastnost (a vůbec definice) všech RAM pamětí. SSD je akorát velká EEPROMka, není potřeba vymýšlet nové způsoby přístupů pro něco, co existuje a používá se už desítky let. On-chip flash paměti (například ty vestavěné v telefonech s Androidem) se ani jako disky netváří a systém s nimi tak zachází (u Androidu pomocí YAFFS2).