Google Chrome 154 byl prohlášen za stabilní. Nejnovější stabilní verze 154.0.8037.57 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Opraveno bylo 108 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Vláda sníží v příštím roce výdaje na IT služby státu o 1,4 miliardy korun. Úspory má umožnit lepší koordinace nákupu služeb napříč resorty prostřednictvím nového zmocněnce. Celkové roční výdaje státu na informační technologie a digitalizaci se podle údajů ministerstva průmyslu a obchodu pohybují okolo 20 až 25 miliard korun ročně, pro letošek bylo na 320 projektů vyčleněno 21 miliard.
Irská komise pro ochranu dat (DPC) uložila americké technologické společnosti Google ze skupiny Alphabet pokutu 403 milionů eur (9,8 miliardy Kč) za neoprávněné nakládání s údaji o poloze uživatelů. Firma podle komise porušila evropské nařízení o ochraně osobních údajů (GDPR). DPC uvedla, že při šetření zjistila, že si lidé nemuseli být vědomi skutečnosti, že jejich poloha byla využívána například k ovlivňování prostřednictvím reklam nebo k odvozování jejich zájmů, a mohli tak ztratit kontrolu nad svými osobními údaji.
Byla oznámena beta verze nového video kodeku Pyrowave pro streamování her v Steam Remote Play. S vysokou propustností a nízkou latencí. S podporou HDR a YUV 4:4:4.
Byl vydán Sublime Text 4 Build 4213. Sublime Text (Wikipedie) je proprietární multiplatformní editor textových souborů a zdrojových kódů. Ke stažení a k vyzkoušení je zdarma. Pro další používání je nutná licence v ceně 99 dolarů. Spolu se Sublime Merge je cena 168 dolarů.
Firma Anthropic, tvůrce AI modelu Claude, začala v oblasti Sanfranciského zálivu v tichosti provozovat vlastní biotechnologickou laboratoř. Anthropic prý chce pomocí AI urychlit hledání léků na nemoci, jimž farmaceutický průmysl dle názoru firmy věnuje příliš málo pozornosti. Firma tvrdí, že laboratoř se zatím soustředí především na základní biologii, nikoli přímo na vývoj léčiv. Farmaceutický výzkum je pro generálního ředitele Daria Amodeie velice osobní téma, jeho otec zemřel na hepatitidu C několik málo let před objevením účinné léčby.
Vědci z Googlu dokončili mapu všech neuronových spojení v mozku (tzv. konektom) samečka mušky octomilky obecné (drosophila melanogaster), hlavním cílem je komparativní analýza s již zmapovaným mozkem samičky. S tímto veřejně dostupným modelem, čítajícím přibližně 160 000 neuronů, se začali bavit nadšenci. Mozek mouchy pohání experimentálního kryptoburzovního bota Stonkfly, případně si zahrál počítačové hry Beat Saber, Mario64 a samozřejmě DOOM (gameplay videa). Ani mozek samičky nezůstal stranou, vyzkoušel si Minecraft.
Alibaba Cloud je dalším sponzorem nadace Omacom Foundation stojící za linuxovou distribucí Omarchy. Přislíbená částka je 3 miliony dolarů, tj. 1 milion dolarů ročně po dobu tří let. Stejná částka jako u DigitalOcean.
Byla vydána nová verze 262 správce systému a služeb systemd (Wikipedie, GitHub).
Canonical oznámil vydání Zephyr 26.04 LTS. Jedná se o komerční distribuci operačního systému pro mikrokontroléry Zephyr (Wikipedie) s podporou až 15 let.
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).