Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »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í.