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.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
for file in $(find -P ~/fotky -type f -exec md5sum '{}' \;|awk '{ sum[$1]++ ;path[$1]=$2 } END {for (meno in sum) if (sum[meno] == 2) print path[meno]}');
do rm -f $file && echo "Delete redundant file $file";done
#!/usr/bin/env python import os,md5 def CalcMD5(filename): buffersize = 1000000 sum = md5.new() f = open(filename) while True: data = f.read(buffersize) if not data: break sum.update(data) f.close() return sum.hexdigest() def removefile(name): print 'removing', name # os.remove(name) def removeduplicit(filelist): md5sums = {} for name in filelist: sum = CalcMD5(name) if not md5sums.has_key(sum): md5sums[sum] = name continue name1 = md5sums[sum] name2 = name print 'duplicit files: ', name1, name2 if os.path.getctime(name1) > os.path.getctime(name2): removefile(name1) md5sums[sum] = name2 else: removefile(name2) path = '.' sizes = {} for root, dirs, files in os.walk(path): for file in files: name = os.path.join(root, file) if not os.path.isfile(name): continue size = os.path.getsize(name) if sizes.has_key(size): sizes[size].append(name) else: sizes[size] = [name] for k in sizes.keys(): if len(sizes[k]) > 1: removeduplicit(sizes[k])Nejprve najde soubory, které mají stejnou velikost a teprve z nich počítá md5sum. Když najde duplicitu, smaže ten novější. Namátkou jsem to zkusil na jednom adresáři a vychází to asi desetkrát rychlejší než ten skript v BASHi.
rsync -avz /mnt/fotak/ /home/miso/fotky/
find -P ~/fotky/ -type f -exec md5sum '{}' \;|awk '{ sum[$1]++ } END {for (meno in sum) if (sum[meno] == 2) print meno}'
cmp -s file1 file2 && echo 'files are identical'
Porovnání md5sumy (32B) je daleko rychlejší, než porovnávat 2MB soubory.Jenže k vytvoření md5sum je potřeba oba soubory nejprve přečíst. A když už se čtou, tak je lepší je rovnou porovnávat. Jinou situací by bylo, kdyby se součty uchovávaly.
Nehledě na to, že vyhledání identických prvků v seznamu má kvadratickou složitost (pro 100 fotek bych skutečně nechtěl až 10000x porovnávat soubory).Jo, to mi došlo v okamžiku, kdy jsem odeslal svůj předchozí příspěvek. Samozřejmě, beru to zpět a jako bych nic neříkal
Ale ved to sa v tom skripte riesi.Kdepak. Skript po ukončení všechny md5 součty zapomene - nikam si je neukládá. Takže při každém spuštění musí každý soubor znovu přečíst. A já jsem tvrdil, že místo počítání md5 je rychlejší ty soubory přímo porovnávat. Ale můj argument platí pouze pro dva soubory, nikoli pro větší počet (viz Heronův komentář).
Hodnoty sa uchovavaju, pretoze sa hlada duplicita.
A já jsem tvrdil, že místo počítání md5 je rychlejší ty soubory přímo porovnávat.A důkaz máte ? Proč myslíte, že něco jako kontrolní součet existuje ? Právě proto, aby se nemusely porovnávat soubory celé. Je mnohem méně náročné udělat ze dvou souborů sumy a ty porovnat, než porovnávat dva soubory blok po bloku. Jestli chcete, ověřte si to experimentálně:
# nejdřív údajně "rychlejší" přímé srovnání $ time cmp 200M.file 500M.file real 0m36.040s user 0m3.212s sys 0m0.992s # a teď ta "pomalejší" metoda $ time md5sum 200M.file; time 500M.file xcom.isp 173d175343421da0336770946587dcb4 200M.file real 0m2.793s user 0m1.280s sys 0m0.380s 677b7d80c9d71ab984ce3cbdfa59cc84 500M.file real 0m5.435s user 0m1.332s sys 0m0.392sTakže ?
$ time md5sum 200M.file; time md5sum 500M.filenějak se mi do toho zamíchala práce vedle...
$ time cmp file1-20MB file2-20MB real 0m0.318s user 0m0.220s sys 0m0.068s $ time md5sum file1-20MB; time md5sum file2-20MB 13d9f78c4116943ac63cc6b0ed045f9a file1-20MB real 0m0.241s user 0m0.176s sys 0m0.052s 13d9f78c4116943ac63cc6b0ed045f9a file2-20MB real 0m0.258s user 0m0.180s sys 0m0.044sZkusím to nějak shrnout:
cmp -s
.
Právě proto, aby se nemusely porovnávat soubory celé. Je mnohem méně náročné udělat ze dvou souborů sumy a ty porovnat,Jak velká část souboru se asi načte při počítání md5? (hint: 100%)
Takže zopakuj test s cmp -s
Jak by podle tebe mohlo potlačení výstupu (-s, -q, --silent nebo --quiet) ovlivnit rychlost této operace (snad kromě několika mikrosekund, které jsou potřeba na vygenerování a vypsání výstupu) ??
Jak velká část souboru se asi načte při počítání md5? (hint: 100%)Porovnávání dvou (velkých ...) souborů znamená načíst kousek souboru 1, kousek souboru 2, porovnat, zahodit ... a tak pořád dokola; při tvorbě hashe se načítají jen n-té bajty ze souboru a z nich se počítají hashe, v paměti se nikdy nemanipuluje s takovými objemy dat. P.S.: Přesto jsem udělal test i s volbou -s, výsledek byl řádově stejný (cmp kolem 1 minuty, md5sum 5 sekund)
Jak by podle tebe mohlo potlačení výstupu (-s, -q, --silent nebo --quiet) ovlivnit rychlost této operace (snad kromě několika mikrosekund, které jsou potřeba na vygenerování a vypsání výstupu) ??Rychlost operace to ovlivní docela zásadně, protože nemusí zjišťovat kde se ty soubory liší. U různě velkých souborů tedy skončí hned jak zjistí jejich velikost.
při tvorbě hashe se načítají jen n-té bajty ze souboru a z nich se počítají hasheBavíme se o md5, takže tohle je nesmysl.
-s --quiet --silent Output nothing; yield exit status only.Mohl bys mi vysvětlit, jak to souvisí se samotným procesem porovnávání ? Tahle volba ovlivňuje jen standardní výstup, jestli to vypíše "Soubory jsou shodné" nebo jen vrátí nulu.
Better to keep your mouth shut and be thought a fool than to open it and remove all doubt.Aby vypsal, na kterém bajtu se soubory liší, musí je přečíst aspoň po ten bajt, i když jsou jinak velké a je od začátku jasné, že se budou lišit.
$ ls -1sh f1 f2 232M f1 314M f2 $ strace cmp -s f1 f2 ... open("f1", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=242081792, ...}) = 0 open("f2", O_RDONLY|O_LARGEFILE) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=328479232, ...}) = 0 _llseek(3, 0, [0], SEEK_CUR) = 0 _llseek(4, 0, [0], SEEK_CUR) = 0 exit_group(1) = ?
$ time cmp -s file1-20MB file2-20MB real 0m0.155s user 0m0.008s sys 0m0.120s
$ time cmp file1-20MB file2-20MB real 0m0.369s user 0m0.208s sys 0m0.092s $ time cmp -s file1-20MB file2-20MB real 0m0.143s user 0m0.020s sys 0m0.104sAle tato debata už je celkem dost off-topic
Tiskni Sdílej: