MDN (Wikipedie), dnes MDN Web Docs, původně Mozilla Developer Network, slaví 20 let. V říjnu 2004 byl ukončen provoz serveru Netscape DevEdge, který byl hlavním zdrojem dokumentace k webovým prohlížečům Netscape a k webovým technologiím obecně. Mozille se po jednáních s AOL povedlo dokumenty z Netscape DevEdge zachránit a 23. července 2005 byl spuštěn MDC (Mozilla Developer Center). Ten byl v roce 2010 přejmenován na MDN.
Wayback byl vydán ve verzi 0.1. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána nová verze 6.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově se lze k síti Tor připojit pomocí mostu WebTunnel. Tor Browser byl povýšen na verzi 14.5.5. Thunderbird na verzi 128.12.0. Další změny v příslušném seznamu.
Meta představila prototyp náramku, který snímá elektrickou aktivity svalů (povrchová elektromyografie, EMG) a umožňuje jemnými gesty ruky a prstů ovládat počítač nebo různá zařízení. Získané datové sady emg2qwerty a emg2pose jsou open source.
Byla vydána (𝕏) nová verze 25.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 25.7 je Visionary Viper. Přehled novinek v příspěvku na fóru.
Před 40 lety, 23. července 1985, společnost Commodore představila první počítač Amiga. Jednalo se o počítač "Amiga od Commodore", jenž byl později pojmenován Amiga 1000. Mělo se jednat o přímou konkurenci počítače Apple Macintosh uvedeného na trh v lednu 1984.
T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Byla vydána nová verze 2.4.65 svobodného multiplatformního webového serveru Apache (httpd). Řešena je bezpečnostní chyba CVE-2025-54090.
Společnost Proton AG stojící za Proton Mailem a dalšími službami přidala do svého portfolia AI asistenta Lumo.
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: