Byla vydána verze 7.0 open source platformy pro správu vlastního cloudu OpenNebula (Wikipedie). Kódový název nové verze je Phoenix. Přehled novinek v poznámkách k vydání v aktualizované dokumentaci.
E-mailový klient Thunderbird byl vydán ve verzi 140.0 ESR „Eclipse“. Jde o vydání s dlouhodobou podporou, shrnující novinky v upozorněních, vzhledu, správě složek a správě účtů. Pozor, nezaměňovat s průběžným vydáním 140.0, které bylo dostupné o týden dříve.
Organizace Video Games Europe reprezentující vydavatele počítačových her publikovala prohlášení k občanské iniciativě Stop Destroying Videogames.
Společnost Raspberry Pi nově nabzí Raspberry Pi Camera Module 3 Sensor Assembly, tj. samostatné senzorové moduly z Raspberry Pi Camera Module 3.
Cathode Ray Dude v novém videu ukazuje autorádio Empeg Car (později Rio Car) z let 1999–2001. Šlo o jeden z prvních přehrávačů MP3 do auta. Běží na něm Linux. Vyrobeno bylo jen asi pět tisíc kusů, ale zůstala kolem nich živá komunita, viz např. web riocar.org.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.7.
Wayland byl vydán ve verzi 1.24.0. Jde o menší vydání po více než roce. Více funkcionality bývá přidáváno v průběžných vydáních Wayland Protocols.
Textový editor Geany byl vydán ve verzi 2.1. Jde o udržovací vydání po bezmála dvou letech. Obsahuje drobná vylepšení vyhledávání, aktualizace podpory zvýrazňování syntaxe a dále převážně opravy chyb.
Byly zveřejněny videozáznamy, dostupné také s prezentacemi přímo z programu, a také fotogalerie z open source komunitní konference DevConf.CZ 2025 konané od 12. do 14. června v Brně.
Navigace se soukromím CoMaps postavena nad OpenStreetMap je nově k dispozici v Google Play, App Store i F-Droid. Jedná se o komunitní fork aplikace Organic Maps.
cp --reflink=always
) a data duplicit smaže,
- a tím se uvolní místo na HDD.
Použil jsem příkaz:
sudo duperemove -dr /mnt/btr_archive --hashfile=/mnt/btr_archive/Duperemove/duperemove_archive.hashfile
Už to jede asi 10 dnů a zatím se žádné místo neuvolnilo. Hashfile už zabírá 11 GB. Ze začátku HDD byl slyšet permanentně jak načítá data, teď už jen občas. V termínálu to vypisuje něco jako:
0x55b96b1268e0] Dedupe for file "/mnt/btr_archive/Duperemove/duperemove_archive.hashfile" had status (1) "data changed". [0x55b96b1269a0] (5/5) Try to dedupe extents with id a78ec70c [0x55b96b1269a0] Dedupe 49 extents (id: a78ec70c) with target: (131072, 131072), <jméno souboru>a pak to stojí třeba hodinu, HDD nic nedělá, ale proces duperemove vytěžuje CPU na 25%. Mám to nechat běžet dál a čekat, že za pár dnů to skončí a uvolní místo na HDD nebo to mám stopnout a zkusit jinak?
a pak to stojí třeba hodinu, HDD nic nedělá, ale proces duperemove vytěžuje CPU na 25%.Řekl bych, že máš jedno jádro ze čtyř vytíženo na 100%. Doporučil bych raději bees, verzi 0.11.
Je. A má být?
Je bambilion způsobů jak vytvořit subvolume. A deduplikace nemusí fungovat vždy podle tvých představ.
Já to řešil tak, že jsem měl lokální Btrfs ale ty snapshoty jsem rsyncoval na sdílený disk - pak to vyrábělo jen rozdíly.
Je bambilion způsobů jak vytvořit subvolume.
Já tedy vím o ± dvou a půl (subvolume create
/ subvolume snapshot
/ receive
). Zbytek z toho bambilionu mi asi nějak unikl. (Stárnu, příliš chlastám, atd.)
Já to řešil tak, že jsem měl lokální Btrfs ale ty snapshoty jsem rsyncoval na sdílený disk - pak to vyrábělo jen rozdíly.
Huh? Odkdy rsync
vyrábí jen rozdíly? Má sice volbu --inplace
, která je velmi žádoucí, ale v žádném případě nemůže nahradit „hlubší povědomí“ :-P o snapshotech.
--inplace
pomáhá, ale vůbec neřeší efektivní přejmenování / přesun souborů / adresářů. V takových případech rsync
brutálně duplikuje. Rozdílové snapshoty na Btrfs se duplikaci vyhnou.cp --reflink
: rsync
umí zachovat pouze hardlinky na úrovni celých souborů, zatímco o cp --reflink
na úrovni bloků nemá ponětí → hurá, zase všechno zduplikovat!Zachování (pouze) rozdílů při synchronizaci mezi zdrojovým Btrfs se snapshoty a cílovým Btrfs s kopiemi příslušných snapshotů lze docílit například (a možná jedině) pomocí btrfs send -p ... | btrfs receive ...
(Hlavně nezapomenout na -p
…)
Neřeším.
Ne že by včely nebyly super, ale nemám pro ně momentálně nasazení, protože moje data nemají příliš mnoho duplicit.
Spíš se snažím existující ne-duplicity (snapshoty, cp --reflink
atd.) zachovat a nezduplikovat omylem. To mi prozatím vždy stačilo (== nezabralo povážlivě moc místa).
Mám jednoduchý zálohovací skript, který (0) sejme snapshot na zdroji, (1) přenese snapshot na cíl (efektivně, pouze rozdíly) a (2) „exponenciálně“ naředí minulé snasphoty, aby byly směrem do minulosti postupně stále řidší. (Je-li zdroj malý a cíl velký, pro úsporu místa stačí držet na zdroji jenom jeden minulý snapshot a víc snapshotů si zachovávat jen na cíli. Aby efektivní diffy fungovaly (na obou stranách), stačí jen ten jeden snapshot.)
rsyncoval na sdílený disk - pak to vyrábělo jen rozdíly.Ty máš zřejmě na mysli rozdíly přírůstkových snapshotů. Já ale potřebuji zdeduplikovat různé větve snapshotů ve kterých jsou shodné soubory. V tom mi rsync ani send/receive nepomůže. Navíc bych považoval za krok zpátky používat rsync místo send/receive.
To byla ještě jiná doba, kdy byla maximální kapacita fyzického disku 1TB. Snapshotovaly se domovské adresáře v rámci nodu, kde ten virtuál běžel. A ten rsync jsem použil, když jsem to pak potřeboval sesypat na jeden disk, jako extra zálohu. Dnes už to nepoužívám, protože jsou uživatelské adresáře sdílené z Netappu.
Tiskni
Sdílej: