Projekt GNU dnes slaví 40. výročí. Přesně před čtyřiceti lety, 27. září 1983, Richard Stallman oznámil, že se chystá napsat s Unixem kompatibilní operační systém GNU (Gnu's Not Unix). Hlavní oslava a setkání hackerů probíhá ve Švýcarsku ve městě Biel/Bienne. Na programu je také přednáška Richarda Stallmana.
Byl vydán Mozilla Firefox 118.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout je nutno automatický lokální strojový překlad webových stránek. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 118 je již k dispozici také na Flathubu a Snapcraftu.
Byla vydána nová major verze 15.0.0 softwaru OCRmyPDF pro přidávání textové vrstvy k naskenovaným PDF dokumentům (PDF/A). Přehled novinek v poznámkách k vydání. OCRmyPDF využívá pro optické rozpoznávání znaků (OCR) engine Tesseract.
Karel Matějka zveřejnil druhé demo své chystané hry Bzzzt. Kromě verze pro Windows a macOS je dostupná i verze pro Linux. Plná verze hry má vyjít zanedlouho.
Noví Bulánci byli oficiálně vydáni. V roce 2021 bylo na Startovači na podporu vývoje této hry vybráno 7,3 miliónů Kč. Hra je zatím určena jenom pro Windows, díky Protonu ale běží také na Linuxu.
ChatGPT může vidět, slyšet a mluvit.
Upscaler je open source nástroj pro zvýšení rozlišení a vylepšení obrázků pomocí AI. Vývoj probíhá na GitLabu. Instalovat lze také z Flathubu. Stejně jako Upscayl je Upscaler postaven nad Real-ESRGAN.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.20.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
V Dublinu o víkendu proběhla dvanáctá iterace multimediální konference Video Dev Days, kterou pravidelně pořádá nezisková organizace VideoLAN. Záznamy přednášek z prvního a druhého dne jsou dostupné na YouTube.
LibrePCB, tj. svobodný multiplatformní softwarový nástroj pro návrh desek plošných spojů (PCB), dospěl po pěti letech vývoje do verze 1.0.0. Přehled novinek v příspěvku na blogu a v aktualizované dokumentaci. Zdrojové kódy jsou k dispozici na GitHubu pod licencí GPLv3.
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: