OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
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.
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.13.6.tar.xz time tar xf linux-3.13.6.tar.xz real 0m6.016s user 0m5.932s sys 0m1.428s du -sh linux-3.13.6 414M linux-3.13.6TMPFS "ramdisk":
time tar xf /home/tomas/test/linux-3.13.6.tar.xz real 0m5.874s user 0m5.904s sys 0m0.616s
root@Emil:/mnt/ramdisk# time tar xfj linux-2.4.0.tar.bz2 real 0m2.345s user 0m2.340s sys 0m0.248s root@Emil:/mnt/ramdisk#
root@Emil:/mnt/tmp# time tar xfj ../ramdisk/linux-2.4.0.tar.bz2 tar: linux/drivers/net/atari_bionet.c: Cannot write: No space left on device tar: linux/drivers/scsi/FlashPoint.c: Cannot write: No space left on device tar: linux/drivers/scsi/sym53c8xx.c: Cannot write: No space left on device tar: linux/drivers/isdn/hisax/l3dss1.c: Cannot write: No space left on device tar: linux/drivers/isdn/hisax/l3_1tr6.c: Cannot write: No space left on device tar: linux/drivers/usb/usb-ohci.h: Cannot write: No space left on device tar: Exiting with failure status due to previous errors real 0m3.082s user 0m2.880s sys 0m0.508s root@Emil:/mnt/tmp#Coz je dobre. Zkusim jeste defaultni jadro, mam 3.8-trunk-amd64, mozna se tedy neco zmenilo.
Cache ma urcite vliv ale pri instalaci se pouziva take a fs nejspis nebude primountovany synchronne, ne? IMHO by system musel mit kriticky malo pameti, aby velikost cache tlacil hodne dolu.Ne, ale balickovac bude pravdepodobne dost casto volat sync, aby byl system v konzistentnim stavu, kdyby se neco pokazilo.
Nejaky napad, jak merit lepe?Napriklad pri mereni rychlosti zapisu opavdu merit dobu, nez se data zapisi na disk. Jinak se meri neco, na cem se kod FS vubec nepodili. Poradit nekomu nasazeni brtfs bez znalosti zateze mi neprijde nejlepsi napad, v tom pripade je rozhodne lepsi ext4 nebo xfs (+ pripadne LVM), protoze je mnohem mensi sance, ze dany clovek narazi na "prekvapeni".
Chci použít FS pro inkrementální zálohy - udělat snapshot, ten inkrementálně odzálohovat (tzn. přenést jen změny) na jiný stroj.
Já tohle dělám už déle než dva roky (viz článek http://www.abclinuxu.cz/clanky/btrfs-lepsi-system-souboru-praxe#inkrementalni-zalohovani-pomoci-snimku-a-rsync) a je to bez problémů.
Teď si chci (až bude v geologicky dohledné době trochu víc času) pohrát se send / receive (zbavit se rsyncu) (viz http://www.heronovo.cz/dva-zpusoby-zalohovani-snapshotu-btrfs/). Co jsem zkoušel, tak to funguje dobře a rychle, ale dlouhodobější zkušenosti ještě nemám.
Za mě tedy ano, je to dobrý nápad, jak je to spolehlivé si musí každý odpovědět sám.
Disk bude sloužit jen pro data, systém bude jinde - dávat pod Btrfs LVM je blbost, ale co MBR nebo GPT? Jsou k něčemu dobré, nebo můžu dát s klidem Btrfs na celý fyzický disk? (ve skutečnosti vzdálené diskové pole, ale o tom místní OS neví a nemusí řešit žádné RAIDy nebo spojování více disků dohromady).
Osobně to mám nad partišnou (MBR), což bych i doporučoval spíše z důvodu evidence (některé OS, když vidí prázdný disk bez partišen, tak se na něj vrhnou, ovšem pokud je tam pro ně neznámý oddíl, tak tomu dají pokoj). Zde bych tedy radil oddíl (MRB nebo GPT, je to jedno).
Od jaké verze jádra považujete Btrfs za "dost dobře použitelné"?
3 roky. (Verzi nevím.)
Komprese asi není dobrý nápad. Jsou nějaké další věci, na které si dát pozor?
Komprese je dobrý nápad, pokud člověk ví jak pracuje. Je nesmysl ji používat na oddíl s nekomprimovatelnými daty a taky na oddíl se sice komprimovatelnými daty, ale s velmi malými soubory (menšími než je blok fs, obvykle 4kiB). Ideální by tedy byly textové soubory o velikostech od 1MB a větší . Neočekávejte ale rychlejší čtení dat, očekávejte úsporu místa.
Jak s defragmentací? Radši ruční než automatická? Jak často ji spouštět?
Dříve jsem to pouštěl z cronu jednou denně, teď mám autodefrag. Větších změn jsem si nevšiml.
Jaké procento zaplněnosti disku je podle vás v pohodě a kdy už byste běželi přidávat další disky?
Staré pravidlo říká 80% zaplněnosti, ono to spíše záleží na způsobu použití. Pokud bych měl na disku převážně velké soubory vzniklé jako reflink, které se postupně zaplňují, tak bych byl i u 50% nervózní. Ale disk se dá přidat vždy.
Teď si chci (až bude v geologicky dohledné době trochu víc času) pohrát se send / receive (zbavit se rsyncu) (viz http://www.heronovo.cz/dva-zpusoby-zalohovani-snapshotu-btrfs/). Co jsem zkoušel, tak to funguje dobře a rychle, ale dlouhodobější zkušenosti ještě nemám.jj, jde mi hlavně o to send/receive, tedy zálohování na úrovni FS, ne na úrovni souborů - těch bude totiž hodně a budou malé, takže rsync by nebyl moc efektivní a zálohování by trvalo dlouho. Nejvíc mě na tom právě láká to, že FS bude vědět, co se od minule změnilo a při zálohování odešle jen ty změny a nebude se to muset znova kontrolovat soubor po souboru.
Staré pravidlo říká 80% zaplněnosti, ono to spíše záleží na způsobu použití. Pokud bych měl na disku převážně velké soubory vzniklé jako reflink, které se postupně zaplňují, tak bych byl i u 50% nervózní. Ale disk se dá přidat vždy.Soubory budou malé a budou jich řádově tisíce (většinou jednotky tisíc nebo méně) v adresáři. Těch 80 % je v pohodě, s tím jsem tak nějak počítal, stejně je potřeba držet nějakou rezervu pro případný náhlý nárůst dat.
někdy mě právě trochu znervózňuje nadávání některých lidí na Btrfs
Kdyby se měl člověk řídit podle toho, na co lidé nadávají v diskusích, tak by nemohl použít nic . Kolem fs se vedou stejné flamy jako kolem vim / emacs, kde / gnome a intel / amd apod. Hlavně to chce zálohovat, ale to platí také pro každý fs. Btrfs je stále ve vývoji a je třeba s tím počítat. Ale podle mého názoru výhody převažují (a to mám i btrfs na rootu debianu, kde opravdu aptitude rychlostně moc nevyniká; jenže aptitude není to nejdůležitější na co ten počítač mám, že jo).
Hlavně to chce zálohovat, ale to platí také pro každý fs. Btrfs je stále ve vývoji a je třeba s tím počítat.To je pravda, ale já právě zvažuji mít primární data na Btrfs a zálohovat taky na Btrfs pomocí Btrs nástrojů/vlastností...
Nebo bys taky radši zálohovat třeba XSF -> Ext4?
Ano.
Ono to samozřejmně záleží na tom, jak dalece chceme nebo můžeme zajít. V naší firmě se servery zálohují (+ je tu ještě replikace) na zálohovací server a odtud ještě na pásku (data jsou tak min. na 4 místech, pásky se po čase uloží do trezoru a koupí se další), svoje soukromá data zálohuji na druhý server a ty důležitější mám ještě na externím mediu (takže všechno 2x, něco 3x). Krom toho mám ještě většinu dat v gitu, takže na více pracovních místech.
Byl bych velmi opatrný mít všechna data na jednom FS a to ještě k tomu na FS ve stavu vývoje (přestože jsem za 3 roky neměl s BTRFS žádný problém a nikdy nedošlo ke ztrátě dat).
Tiskni
Sdílej: