Man Yue Mo z GitHub Security Lab se podrobně rozepsal o již opravené zranitelnosti CVE-2023-6241 v Arm Mali GPU umožňující získání roota na telefonu Pixel 8 s povoleným MTE (Memory Tagging Extension).
V San José probíhá vývojářská konference NVIDIA GTC 2024. CEO společnosti NVIDIA Jensen Huang měl dvouhodinovou keynote, ve které představil celou řadu novinek: NVIDIA Blackwell platform, NVIDIA NIM microservices, NVIDIA Omniverse Cloud APIs, Project GR00T, …
Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Od 21. do 23. března proběhnou Arduino Days 2024. Sledovat bude možné oficiální streamy. Zúčastnit se lze i lokálních akcí. V Česku jsou aktuálně registrovány dvě: v Praze na Matfyzu a v Poličce v městské knihovně.
Letošní ročník konference LinuxDays se uskuteční o víkendu 12. a 13. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během letošního ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru, Facebooku nebo na Mastodonu, přidat se můžete také do telegramové diskusní skupiny.
Byla vydána nová major verze 2.0.0 a krátce na to opravné verze 2.0.1 open source online editoru Etherpad (Wikipedie) umožňujícího společné úpravy v reálném čase.
Matematický software GNU Octave byl vydán ve verzi 9.1.0. Podrobnosti v poznámkách k vydání. Nově je preferovaný grafický backend Qt a preferovaná verze Qt 6. V tomto vydání byly přepracovány funkce pro převod čísel z desítkové soustavy. Jako obvykle jsou zahrnuta také výkonnostní vylepšení a zlepšení kompatibility s Matlabem.
Společnost PINE64 stojící za telefony PinePhone nebo notebooky Pinebook publikovala na svém blogu březnový souhrn novinek. Vypíchnout lze, že pracují na virtuálním asistentu PineVox a zatím bezejmenných sluchátkách na lícní kosti (bone conduction).
Hyprland, kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, je již dva roky starý. Při té příležitosti byla vydána verze 0.37.0 (a záhy opravná 0.37.1 řešící chybu ve vykreslování oken). Nově závisí na knihovně hyprcursor, která poskytuje škálovatelné kurzory myši.
Začleňovací okno řady 3.5 je nadále otevřené, takže ještě nevyšly žádné vývojové verze. Patche mezitím stále proudí do jádra; souhrn toho, co bylo zatím začleněno, najdete níže.
Stabilní aktualizace: během posledního týdne žádné nevyšly. Verze 3.0.33, 3.2.19, 3.3.8 a 3.4.1 se revidují.
Lumpy reclaim měl svůj účel, ale někteří věřili, že jím je srazit systém na kolena pomocí trvalého trashování. Jiní to viděli tak, že jeho smyslem je komplikovat vmscan.c. Postupem času dostal měkčí boty a lepší chování, ale kompakce paměti musí být vylepšena, aby jej nahradila, takže tento patch lumpyho posílá do propadliště dějin.
-- Mel Gorman
Jiri [Kosina] je nyní označen za správce floppy.c. Veřejně jej při nejbližší příležitosti ocejchuji žhavým železem na čele.
-- Jens Axboe
Jako držitel práv v jádře zpochybňuji legalitu Matthewova návrhu a bylo by tragikomické, kdyby to skončilo tím, že Software Conservancy začne dělat právní kroky proti Fedoře.
-- Alan Cox
Vyšla verze 2.0 minimalistické knihovny klibc. Trochu opožděně kvůli průlomu do kernel.org, ale vývoj opět pokračuje. U větve 2.0 došlo k testování bootu a nasazování na Debianu, takže si jsme vcelku jisti, že by to většině z vás mělo fungovat, kdyby ne, dejte vědět. Největší změnou se zdá být řádná podpora bufferovaného I/O ve funkcích stdio.
Začleňovací okno pokračuje v plné síle, od minulých Jaderných novin se do hlavní řady dostaly další 4000 neslučovacích změn; celkem jde o více než 8600 změn ve verzi 3.5 a to ještě nejsme na konci. Nejvýznamnější změny viditelné uživatelům jsou:
Změny viditelné vývojářům zahrnují:
V době psaní tohoto textu zbývá do konce začleňovacího okna verze 3.5 ještě několik dnů. Po jeho uzavření vyjde závěrečný článek.
Unixové a unix-like systémy tradičně zaznamenávaly čas posledního přístupu všech souborů na systému. Tenhle přístup se v posledních letech přestal lidem zamlouvat, a to z jednoduchého důvodu: zapisování posledního času přístupu („atime“) zabírá spoustu šířky pásma I/O při čtení velkého množství souborů; vizte například tento článek z roku 2007. Nejhorší problémy s atime byly potlačeny přechodem k používání „relatime“ ve výchozím stavu; relatime aktualizuje atime maximálně jednou denně u souborů, které se nezměnily. Ale teď se ukázalo, že zaznamenávání atime může být problémem na btrfs a relatime tomu moc nepomůže.
Jednou z hlavních vlastností btrfs je copy-on-write. Bloky na disku nejsou nikdy měněny na svém původním místě; místo toho, jakmile je potřeba commitovat změnu, je dotčený blok okopírován a přepsán na novém umístění. Copy-on-write se týká metadat i dat; pokud jsou metadata souboru (jako například čas posledního přístupu) změněna, blok obsahující metadata bude okopírován na nové místo. To znamená, že operace, která čte mnoho souborů (například vytváření tar archivu nebo rekurzivní grep), může kvůli aktualizacím atime zapříčinit kopírování a přepisování spousty bloků s metadaty.
Není nutné dodávat, že to výkonu neprospívá, ale to ještě není to nejhorší. Jak Alexander Block upozornil, skutečný problém má co do činění se vztahem mezi atime, copy-on-write a snapshoty.
Btrfs poskytuje funkci rychlého snapshotování, která umožňuje vytvoření kopie stavu souborového systému v určitém čase. Jakmile je snapshot vytvořen, sdílí všechna data a metadata s „trunkem“ filesystému. Pokud je soubor změněn, výsledná operace copy-on-write oddělí trunk od snapshotu s tím, že se zachovají obě kopie dat. Takže snapshoty lze vnímat jako nenákladné, dokud se toho na souborovém systému moc neděje. Snapshoty sdílejí data a metadata, tudíž nepotřebují tolik dodatečného prostoru.
S atime je ale situace trochu jiná. Pokud někdo udělá snapshot systému a pak na něm udělá rekurzivní grep, tak může dojít k aktualizaci času posledního přístupu na všech otevřených souborech. To pak vede k copy-on-write operacím na inode každého souboru, což může vést k duplikaci spousty nebo všech inodes v souborovém systému. To zase vede ke spotřebě místa souborovým systémem; Alexander zaslal příklad, kde rekurzivní grep způsobí zmizení 2,2 GB volného místa. To je překvapivý důsledek operace, která měla být read-only.
V době, kdy se diskové kapacity počítaly na megabajty, se říkalo, že jedinou standardní funkcí unixových systémů bylo MoTD, které říkalo lidem, že mají pročistit své soubory. Atime pak bylo často používáno administrátory, kteří se v nouzi snažili uvolnit nějaké místo; jednoduše vyhledali málo užívané soubory a v závislosti na zoufalosti situace pak poslali seznam nepoužívaných souborů uživatelům, nebo je prostě přesunuli na pásku. Je docela ironie, že funkce, která kdysi mimo jiné pomáhala uvolňovat místo na disku, je nyní součástí problému.
Je třeba upozornit, že volba relatime tu moc nepomůže. K přepsání inode stačí jen jedna aktualizace atime. To, že relatime tyto aktualizace omezuje na maximálně jednou denně, až tak nepomáhá.
Uživatele také nepotěší další aspekt problému, na který Alexander poukázal: protože čtení dat může vyvolat spotřebu dat na souborovém systému, operace čtení mohou selhat s chybou „nedostatek místa na disku“ na plném souborovém systému. To může zkomplikovat nebo znemožnit nápravu problému okopírováním dat pryč ze souborového systému. Jakmile se to stane, tak už se nelze divit, že bude uživatel přemýšlet, proč vlastně sledování posledního přístupu potřebuje.
Proto Alexander navrhl, že by nemuselo být špatné defaultně používat „noatime“ na btrfs, i když to znamená, že se btrfs bude chovat jinak než jiné souborové systémy. Tento nápad byl rychle zamítnut s tím, že stále existují aplikace, které pro své fungování atime potřebují. Klasickým příkladem je poštovní klient mutt, který bez atime nedokáže říci, zda v poštovní schránce je nepřečtená pošta. Programy, které pročišťují dočasné adresáře (tmpreaper nebo tmpwatch) bez atime selžou. Jsou tu i hierarchická úložiště, kde se atime používá k rozhodování, kdy se soubory mají přesunout na pomalejší úložiště. Takže atime musí zůstat, leda by se uživatelé dostali do jiných nepříjemných trablí.
Prozatím je jedinou útěchou pro uživatele, kterým to vadí, explicitní mountování s volbou „noatime“. Navíc by bylo možné udělat nějaké úpravy v btrfs, aby byl problém potlačen; Boaz Harrosh navrhl zákaz aktualizací atime, jakmile se volné místo dostane pod určitou hranici, nebo přesunutí atime do jiné datové struktury. Ale nikdo asi na takových řešeních nepracuje. Takže se může stát, že jak se bude používání btrfs rozšiřovat, uživatelé budou občas překvapeni, že čtení souboru může způsobit spotřebu místa na disku.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
To jako že když mezi doručením a skutečným přečtením mailu proběhne zálohování, tak se vše označí jako přečtené?Tak trochu. A nedělá to jen mut, atime také používá příkaz finger a jiné mailové klienty. Osobně atime určitě za obsolete nepovažuji, spíše mne děsí souborové systémy, které nejsou schopny ani takovou trivialitu rozumně řešit. Na druhou stranu zřejmě mají jiné kvality, které jim dávají právo na existenci - v tom případě ať se mountují noatime. A na /var/spool je stejně asi vhodnější nějaký ext2345.
Osobně atime určitě za obsolete nepovažuji, spíše mne děsí souborové systémy, které nejsou schopny ani takovou trivialitu rozumně řešit.
Podstatou diskuse je, co kdo považuje za rozumné. Souborové systémy to vyřešit schopné jsou, jsou to metadata jako jakákoliv jiná. I pro ten BTRFS. Otázkou je, zda akceptovat nutný zápis v případě pouhého čtení. A také je otázkou, zda alokace dalšího bloku pro změněná metadata je problém. To si musí zvolit administrátor daného systému. Má dost možností volby.
muze se prepisovat na miste kde je a nepadat do snapu
To nejde. To by se potom měnila metadata i v tom snapshotu (což není nic jiného jen další nezávislý oddíl (subvolume), který jen vznikl jako clon, snímek, již existujícího subvolume), který je na původních datech už z definice nezávislý. V případě COW souborových systémů je nutné při každé změně alokovat nový blok. Obě subvolume můžete chtít nezávisle na sobě měnit a zde už je jasné, že nemohou mít nadále provázaná metadata.
FS kterej umi udelat snap, se totiz hodi (trebas) na umisteni databaze. A z te se vetsinou prevazne cte, a presne stim se pocita pri navrhovani prislusneho HW.Tohle ale přece řeší parametr
noatime
. Nedovedu si představit případ, kdy bych chtěl atime
aktualizovat, ale zároveň by mi nevadilo, že tam jsou v podstatě náhodné hodnoty. Takže volba ano/ne je podle mne dostačující.