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.
Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.49.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Masivní výpadek elektrického proudu zasáhl velkou část České republiky. Hasiči vyjížděli k většímu počtu lidí uvězněných ve výtazích. Výpadek se týkal zejména severozápadu republiky, dotkl se také Prahy, Středočeského nebo Královéhradeckého kraje. Ochromen byl provoz pražské MHD, linky metra se už podařilo obnovit. Výpadek proudu postihl osm rozvoden přenosové soustavy, pět z nich je nyní opět v provozu. Příčina problémů je však stále neznámá. Po 16. hodině zasedne Ústřední krizový štáb.
Osobně se snažím dělat pravidelné inkrementální zálohy pomocí rsync. … V tuto chvíli je pro mě velikost výsledného souboru podstatná, zatímco čas na kompresi mě v podstatě nezajímá a může trvat klidně celý den.Všechno je to pouze o objemu dat. Pokud ti objem komprimovaných dat naroste do takové míry, že ti přestane na kompresi 24 hodin stačit – máš problém.
Krom toho, ze lrzip je neudrzovan, mozna bych ti doporucil podivat se na lzma2 treba v 7zipu (u me p7zip na freebsd). Tech prepinacu, hlavne co se tyce ram a velikosti ruznych slovniku je tam x a s dostatkem ram se dostanes dal nez s lrzip. 16gb ram je pro max kompresi nedostatecnych.A umí to deduplikaci? Protože to je pro mě docela killer feature.
Vedel by si povedať ako chceš programom definovať rozdiel v definícii dvoch technológií?Zajímá mě konkrétní řešení, pokud to chceš brát hypoteticko-filosoficky, tak na to nemám ani čas, ani náladu.
Pretože deduplikácia je slovníková kompresia, s pevnou dĺžkou slova a nekonečne dlhým slovníkom.Z praktického hlediska bych viděl menší zádrhel v tom nekonečném slovníku.
A ak urgentne potrebuješ funkčné riešenie, tak skús povedať cenovú hladinu. Hotových riešení pre deduplikáciu je plno. BSD s ZFS, Linux s BTRFS ...Tak jednoduché to zase není. Filesystém (např. btrfs) nebo blokové vrstva (např. vdo) s deduplikací je přece jiný use case než deduplikace při kompresi tarballu.
Ja nie, slovník sa nemusí alokovať na počiatku sveta.Pretože deduplikácia je slovníková kompresia, s pevnou dĺžkou slova a nekonečne dlhým slovníkom.Z praktického hlediska bych viděl menší zádrhel v tom nekonečném slovníku.
Áno. Pri deduplikácii na úrovni FS nepotrebuješ používať TAR.A ak urgentne potrebuješ funkčné riešenie, tak skús povedať cenovú hladinu. Hotových riešení pre deduplikáciu je plno. BSD s ZFS, Linux s BTRFS ...Tak jednoduché to zase není. Filesystém (např. btrfs) nebo blokové vrstva (např. vdo) s deduplikací je přece jiný use case než deduplikace při kompresi tarballu.
To jsem nepochopil. Rzip má jen o 0.1GB menší soubor, ale dekomprese trvá skoro o řád déle než u bzipu2 ?Záleží. Například u toho syncthing_delta.tar je to menší o 1.6GB než LZMA, což není zanedbatelné. Konkrétně to pálím na 25GB bluray, kde se každý volný gigabajt hodí.
A jak to vyjde s cenou elektřiny? Tedy jestli to znamená plný výkon 100W procesoru (plus běžící zbytek kompu a disky) po 1 hodinu na to abych ušetřil 1,5GB tak je to cca 0,5 Kč za elktřinu proti cca 1,2 Kč za cenu media (na rotačním disku). Před časem jsem kompresoval nějaké filmy do x265, ale postupně to oželím, protože i když film stisknu na cca 30'% původní velikosti, tak rychlost je někde kolem uspory 0,8 GB za hodinu výpočtu a to mi připadá málo efektivní.Elektřinu zanedbávám. Stojí tak málo, že se mi to v podstatě nevyplatí řešit. Počítač by stejně běžel tak jako tak, teď jen běží CPU na plný výkon. Šlo mi o to, že jinak bych musel pálit další bluray, trvalo by to další hodinu a byl by to další opruz, to dávat do vypalovačky, katalogizovat, nadepisovat a pak skladovat. Takhle se mi tam vešlo co jsem potřeboval. Na zálohování mám napsaný script, co všechno zkomprimuje, zašifruje, vytvoří md5sum a tak podobně, takže tam prostě přepíšu lrzip místo gzipu a tím to pro mě hasne.
#! /usr/bin/env bash # export ADDRESS="bystrousak@kitakitsune.org" export GPG_PARAMS="--recipient $ADDRESS --compress-level 0 -e --yes --output" function md5it { pv "$1" | md5sum - > "$1.md5sum"; } function pack_to_gpg { echo "Packing $2 .. " # tar -czO "$1" 2>/dev/null | gpg $GPG_PARAMS "$2"; tar -cO "$1" 2>/dev/null | pv -s $(du -sb "$1" | awk '{print $1}') | pbzip2 -5 -p3 -c | gpg $GPG_PARAMS "$2"; md5it $2; echo "done" } if [ -d bluray ]; then rm -fr bluray; fi mkdir bluray cd bluray pack_to_gpg /media/bystrousak/Internal/Backup/delta/xlit_delta xlit_delta.tar.bz2.gpg pack_to_gpg /media/bystrousak/Internal/Backup/delta/syncthing_delta syncthing_delta.tar.bz2.gpg pack_to_gpg /media/bystrousak/Internal/Backup/delta/dropbox_delta dropbox_delta.tar.bz2.gpg pack_to_gpg /media/bystrousak/Internal/Backup/delta/pocketbook_delta pocketbook_delta.tar.bz2.gpg cp /home/bystrousak/Plocha/scanny . md5it scanny
tady ale ztratite optimalizaci dle obsahu jednotlivych souboruJe to jen pocit, nebo to tak fakt je? Já myslel, že by na tom nemělo záležet, ale netestoval jsem to.
protoze problem je takovy sorted tar vyrobitČistě jen pro inspiraci: python má tarfile. Tím si to můžeš namixovat.
Jeste jsem se koukal na zpaq ktery by mel byt konkurenci lrzipu, zkusim prohnat testovaci data jeste nim v max nastaveni a dam vedet.Počkat, já psal ten článek právě o lrzipu s
-z
, což zapíná zpaq. Pokud myslíš zpaq jako program, tak to bude imho jen jiný frontend. Nebo ne?
Tiskni
Sdílej: