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.
Jen detail: removepkg timestampy nekontroluje. Nebo to aspoň v tom bordelu nemůžu najít.
delete_files() {
while read FILE ; do
if [ ! -d "$ROOT/$FILE" ]; then
if [ -r "$ROOT/$FILE" ]; then
if [ "$ROOT/$FILE" -nt "$ADM_DIR/packages/$PKGNAME" ]; then
echo "WARNING: $ROOT/$FILE changed after package installation."
fi
if [ ! "$WARN" = "true" ]; then
...
Ano. Minimálně dvakrát. Jednou test integrity, podruhé rozbalení /install ...Rozbalení jako extrakce obsahu archivu do filesystému se opravu provede jen jednou a využije se cache z předchozího "rozbalení v paměti" při testu integrity. Ale to je přece nutné. Přece se nebude naslepo rovnou provádět instalace, když může být nedokončena kvůli chybě v archivu. Sice by se trochu ušetřilo pokusným rozbalením do pomocného adresáře a v případě úspěchu pak přesunutím do kořene, ale přijde mi to jako zbytečná krkolomnost.
Ono je pěkné mít ls a grep, ale pak nemůžete čekat, že se dostanete u prohlížení balíčků pomocí pkgtool pod 40s při startu.To jsem moc nepochopil. Např. (nekešované)
triton@darkstar:~$ time ls /var/adm/packages | grep python
python-tools-2.4.1-noarch-1
python-2.4.1-i486-1
real 0m0.032s
user 0m0.016s
sys 0m0.006s
triton@darkstar:/var/adm/scripts$ time grep -lr usr/bin/nmap /var/adm/packages
/var/adm/packages/nmap-3.81-i486-1
real 0m0.028s
user 0m0.013s
sys 0m0.013s
Váš entuziasmus obdivuji a <nezprofanovaně>upřímně</nezprofanovaně> přeji úspěšné dotažení nápadu k cíli.
Happy coding
Z'LI0(%:`&/NRU`Y0"@8.L%.%PG(%!D>"<!@C(4&'?`UO!/$"K\2)+!1K',R'
2V,*3$D-EG4PC!<*(%%I"<*$`
`
P-M/600
triton@darkstar:~$ ls /var/adm/packages|wc -l
459
triton@darkstar:~$ du -s /var/adm/packages
15092 /var/adm/packages
dunric@darkstar:~$
Z'LI0(%:`&/NRU`Y0"@8.L%.%PG(%!D>"<!@C(4&'?`UO!/$"K\2)+!1K',R'
2V,*3$D-EG4PC!<*(%%I"<*$`
`
Pokud chcete zobrazit všechny balíčky v menu: x 500 = 16 seknud. (minimálně, něco ještě sežere režie shellu)Na pkgtoolu jsme se shodli. Já se snažil ukázat, že zobrazení všech 459 balíčků standardními nástroji trvá zlomky vteřin.
Tak jsem se díval podrobněji na archivy několika balíčků a zjistil jsem, že s železnou pravidelností je slack-desc až jako úplně poslední soubor v archivu. To znamená, že gzip -d se provádí 3x vždy na celý soubor.Pokud má tar v parametru místo seznam adresářů, přidává na dané úrovni jeho obsah reverzně. Sám nevím, proč tomu tak je.
To, na jaké pozici v taru se nachází slack-desc nebo jakýkoli jiný soubor přece nemá vůbec žádný vliv. Pokud chci cokoliv z tgz vyextrahovat, vždycky se prvně provede kompletní dekomprese gzipem.
Minule jsem souhlasně uvedl, že v installpkg je teoreticky prostor pro optimalizaci, kdy by se s jedním rozbalením vystačilo. Přibyl by ale mezikrok pro přesun z dočasného do kořenového adresáře, resp. úklid po narušeném archivu. I tak by to bylo sice rychlejší, ale přijde mi to méně elegantní řešení bez valného přínosu. Nebo vás napadá ještě jiný elegantnější nebo rychlejší algoritmus ?
Zkusil jsem si změřit čas testu a čas extrakce velkého tgz archivu(cca 60MiB) a test byl o 1/2 - 2/3 kratší (fs ext3, noatime).
Z'LI0(%:`&/NRU`Y0"@8.L%.%PG(%!D>"<!@C(4&'?`UO!/$"K\2)+!1K',R'
2V,*3$D-EG4PC!<*(%%I"<*$`
`
To, na jaké pozici v taru se nachází slack-desc nebo jakýkoli jiný soubor přece nemá vůbec žádný vliv. Pokud chci cokoliv z tgz vyextrahovat, vždycky se prvně provede kompletní dekomprese gzipem.
Má. Jakmile vyextrahuje ty soubory, které jsou požadovány, tak končí a dál nečte.
Zkusil jsem si změřit čas testu a čas extrakce velkého tgz archivu(cca 60MiB) a test byl o 1/2 - 2/3 kratší (fs ext3, noatime).
To je jasné.
... je slack-desc až jako úplně poslední soubor v archivu. To znamená, že gzip -d se provádí 3x vždy na celý soubor.
To, na jaké pozici v taru se nachází slack-desc nebo jakýkoli jiný soubor přece nemá vůbec žádný vliv. Pokud chci cokoliv z tgz vyextrahovat, vždycky se prvně provede kompletní dekomprese gzipem.Docela mě to překvapuje, ale asi nechápete základní strukturu tgz archivu. Všechny soubory jsou přidány do jednoho taru a tento archiv je potom jako jeden soubor komprimován např. gzipem, tj. vaše dedukce: slack-desc je na konci taru => gzip -d se musí provést na celý soubor, je chybná. To umístění má vliv až na druhou fázi, tj. rozbalení samotného taru.Má. Jakmile vyextrahuje ty soubory, které jsou požadovány, tak končí a dál nečte.
Z'LI0(%:`&/NRU`Y0"@8.L%.%PG(%!D>"<!@C(4&'?`UO!/$"K\2)+!1K',R'
2V,*3$D-EG4PC!<*(%%I"<*$`
`
Teď to zkouším a koukám, že to GNU tar takhle nedělá. Žádný program není dokonalý. :) Takže se vždy musí dekomprimovat třikrát celý soubor.Jsem rád, že jste si to moje tvrzení ověřil
Třeba vás to bude inspirovat k napsání vlastní implementace taru
Z'LI0(%:`&/NRU`Y0"@8.L%.%PG(%!D>"<!@C(4&'?`UO!/$"K\2)+!1K',R'
2V,*3$D-EG4PC!<*(%%I"<*$`
`
Tiskni Sdílej: