Svobodná webová platforma pro sdílení a přehrávání videí PeerTube (Wikipedie) byla vydána v nové verzi 6.1. Přehled novinek i s náhledy v oficiálním oznámení a na GitHubu. Řešeny jsou také 2 bezpečnostní chyby.
Lennart Poettering na Mastodonu představil utilitu run0. Jedná se o alternativu k příkazu sudo založenou na systemd. Bude součástí systemd verze 256.
Hudební přehrávač Amarok byl vydán v nové major verzi 3.0 postavené na Qt5/KDE Frameworks 5. Předchozí verze 2.9.0 vyšla před 6 lety a byla postavená na Qt4. Portace Amaroku na Qt6/KDE Frameworks 6 by měla začít v následujících měsících.
Byla vydána nová verze 2.45.0 distribuovaného systému správy verzí Git. Přispělo 96 vývojářů, z toho 38 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání. Vypíchnout lze počáteční podporu repozitářů, ve kterých lze používat SHA-1 i SHA-256.
Před 25 lety, ve čtvrtek 29. dubna 1999, byla spuštěna služba "Úschovna".
Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Různé drobnosti a užitečnosti na které narazím nebo sám vytvořím. Primárně se zaměřuji na věci, které mohou být zajímavé a užitečné pro ostatní uživatele GNU/Linuxu či typografického systému TeX, občas se tu ale určitě vyskytne i něco z úplně jiného soudku, např. z oblasti bezpečnosti apod.
Tak jsem narazil na limit ZIP archivu, o kterém jsem neměl povědomí. Nebýt rdiff-backup, tak jsem přišel o data.
Při balení souborů utilitou zip vznikl archiv velký zhruba 5,6 GiB. Pokud vím, tak balení proběhlo bez chybových hlášení a zip skončil s nulovým návratovým kódem. Naštěstí jsem se druhý den ještě na archiv díval a zarazilo mne, že Krusader v jeden moment při procházení zahlásil chybu. Ani zip po sobě nedokázal archiv rozbalit – data za 4 GiB byla nečitelná, původní soubory jsem mezitím smazal.
Přiznám se, že o tomto limitu ZIP archivů na maximálně 4 GiB jsem nevěděl. Dodatečně mi kolega říkal, že ZIP archivy prý mají ještě spoustu dalších nepříjemných limitů (na délku cesty, maximální velkost jednoho souboru apod.). To by mi ani tak nevadilo, ale co mne opravdu zaráží je to, že zip soubory bez jediného varování zabalil i přes limit a nakonec se tvářil, že je vše v nejlepším pořádku. Takto by se programy opravdu chovat neměly.
Jediné štěstí bylo, že vstupní soubory mi před tím několik dní ležely na disku nekomprimované. Nad ránem mi všechny soubory zálohuje rdiff-backup, takže je stačilo obnovit ze zálohy.
Docela mne překvapuje, že je o rdiff-backup poměrně málo slyšet a spousta lidí o něm neví. Podle mého je to geniální zálohovací nástroj (takže mu tu zkusím udělat trošku reklamu ).
Ideálně by dle mého měla být záloha v podobě samostatných normální souborů, případně souborů uložených v nějakém standardním rozšířeném archivu (typu ZIP, 7ZIP, TAR apod.). Prostě tak, aby bylo možné data obnovit standardními prostředky operačního systému (cp, tar, unzip...) bez potřeby pomoci použitého zálohovacího programu (člověk nikdy neví, jestli zálohu nebude potřebovat obnovit někde úplně jinde nebo za nějaký čas nezjistí, že potřebuje obnovit starou zálohu, u které ani pořádně neví, čím byla vyrobena). Určitě bych se vyhnul různým uzavřeným řešením, která zálohují do nějakého vlastního binárního formátu. Když zálohu nepůjde obnovit, tak je člověk v háji. Navíc se dost těžko zjišťuje, jestli zálohování vůbec proběhlo korektně (a bylo zálohováno všechno, o čem si člověk myslí, že bylo) apod.
Tohle řeší rdiff-backup. Je to snadno použitelný multiplatformní nástroj (Python) a bere ohledy na specialitky různých operačních systémů, respektive jejich filesystémů (a to i když běží pod jiným typem systému; např. informace o přístupových právech zachová, i když je záloha uložena na disku se souborovým systémem FAT – metadata o zálohovaných datech jsou rdiff-backupem uložena jako součást zálohy v běžných souborech ve speciálním adresáři na záložním médiu), přes síť pracuje podobně jako rsync, tzn. přenosy jsou efektivní.
Zálohování je transparentní – poslední záloha je úplně normální kopie souborů a adresářů (obnova pomocí cp). Starší zálohy je možné získat pomocí rdiff-backupu (v případě nutnosti by to ale snad šlo nějak rozparsovat i „ručně“) – do toho speciálního adresáře s metadaty se totiž ukládají rozdíly aktuální zálohy oproti předchozí verzi, takže je možné obnovit kteroukoliv předchozí verzi zálohy (protože se ukládají jen rozdíly (případně komprimované), tak to neplýtvá místem).
rdiff-backup se navíc „zdarma“ postará i o kontrolu konzistence všech verzí zálohy, protože součástí metadata jsou SHA-1 součty všech zálohovaných souborů. Dá se tak snadno ověřit, že je záloha v pořádku a záložní médium nám tiše nedegraduje (plus se to dá použít k rychlému důkladnému porovnání zálohy s aktuálním stavem dat – celé soubory se čtou jen z primárního úložiště, ze záložního (potencionálně pomalého) média se přečtou jen kontrolní součty).
Tiskni Sdílej:
Napadají mne hned dva – rozšířenost (tzn. nikdo – ani BFU na Windows bez nainstalovaného dodatečného software – nemá problém s rozbalením), rychlé listování obsahem archivu (to je hlavní důvod pro mne, proč místo TARu někdy používám ZIP).
rychlé listování obsahem archivu (to je hlavní důvod pro mne, proč místo TARu někdy používám ZIP).To jsem nějak nepobral. Vždyť PKZIP má Central Directory signaturu až na konci archivu, ne?
-z pro gzip, -j pro bzip2, -J pro xz, --lzma pro lzma.Ba co víc.
Popular tar programs like the BSD and GNU versions of tar support the command line options -z (gzip), and -j (bzip2) to automatically compress or decompress the archive file it is currently working with. GNU tar from version 1.20 onwards also supports --lzma (LZMA). 1.21 also supports lzop via --lzop, 1.22 adds support for xz via --xz or -J, and 1.23 adds support for lzip via --lzip. Both will automatically extract compressed gzip and bzip2 archives with or without these options.Tudíž stále nechápu o čem je řeč.
Mám tu GNU tar 1.21 na openSUSE 11.2. Faktem ale je, že není možné snadno projít obsahem archivu. Příklad: V Krusaderovi vstoupím od ZIP archivu jako do adresáře a prakticky okamžitě vidím adresářovou strukturu. Pokud to stejné zkusím udělat s komprimovaným TARem, tak to chvíli trvá (dle velikosti archivu) a je vidět, že musel dojít k dekompresi celého archivu. To stejné se děje pod Windows např. v Altap Salamander.
Nakonec ani výše popsané tar -*vjf IMHO nepracují jinak – tar stejně musí sekvenčně projít celý archiv a celý ho dekomprimovat – to že dekompresi zvládne sám a nepotřebuje k tomu externí program na tom nic nemění.
To, že komprese celého archivu místo jednotlivých souborů je účinější je samozřejmě pravda, nicméně těch pár ušetřených procent na velikosti archivu při dnešních cenách disků dle mého absolutně nevyváží nepohodlí při práci s takto komprimovaným archivem.
Velká škoda, že 7-Zip nepodporuje unixové speciální soubory (linky apod.).
... to že dekompresi zvládne sám a nepotřebuje k tomu externí program na tom nic nemění ...Tar potrebuje externé programy (len ich vie použiť automaticky).
RARAsi máme jiné představy o civilizaci :).
A to by mě zrovna zajímaly důvody. Mně na něm sice vadí, že je to uzavřený formát, nicméně co se týče kompresního poměru, zvládá svoji práci na jedničku, a to není jeho jediná přednost.V podstatě asi hlavně praktické důsledky toho, co píšeš. Tedy, že v části prostředí, kde se pohybuju, je potřeba software pro rar nejen doinstalovat (s tím bych byl celkem smířený), ale ještě třeba není součástí oficiálních repozitářů... takže jako formát archivu na péčko fajn, ale těžko bych to doporučil na něco pracovního.
Hlavně proč používat RAR? Kvůli kompresnímu poměru? 7-Zip s LZMA ho pobije. Speciální unixové soubory (linky apod.) neumí ani RAR ani 7-Zip, ale 7-Zip je open-source.
takže jako formát archivu na péčko fajnNejlepší formát na péčko je mov či m4v. Nemusíš nic rozbalovat ani shánět kodeky.
BTW: Co je to ten m4v. Jsem to zahlédl u Silverlightu. To asi nebude nic Applího, když v tom má prsty i Microsoft, že?
Blbost. Na péčko nejvíc ruluje Matroška s mnohem větší kupou featur a lepším návrhem.A k čemu ti tady v tomto případě ty features jsou? To jako že si s tím videem stáhneš i lubrikační gel či co?
BTW: Co je to ten m4v. Jsem to zahlédl u Silverlightu. To asi nebude nic Applího, když v tom má prsty i Microsoft, že?Dovzdělej se.
A k čemu ti tady v tomto případě ty features jsou? To jako že si s tím videem stáhneš i lubrikační gel či co?Třeba na to abych vypnul ty debilní komentáře režiséra.
a je to dokonalý - jeden pak může procházet zálohy podle data v adresářové struktuře - kždý snapshot má svůj adresář
omezeni zipu zale6i na verzi .... puvodne byl problem i 2 giga
S tímhle jsem se nesetkal. Jde o soubory, do kterých se přesně v době zálohování zapisuje? Je v logu rdiff-backup nahlášeno, že soubor nezálohoval? Tzn. je v logu vidět, že se to nezálohovalo?
S tímhle jsem se nesetkal. Jde o soubory, do kterých se přesně v době zálohování zapisuje? Je v logu rdiff-backup nahlášeno, že soubor nezálohoval? Tzn. je v logu vidět, že se to nezálohovalo?Týká se to jen souborů, které se změní během práce rdiff-backupu. Ano v logu to vidět je.