Švýcarská AI centra EPFL, ETH Zurich a CSCS představila otevřený vícejazyčný velký jazykový model (LLM) s názvem Apertus. Vyzkoušet lze na stránce Public AI Inference Utility.
Byl vydán Linux Mint 22.2 s kódovým jménem Zara. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze novou XApp aplikaci Fingwit pro autentizaci pomocí otisků prstů nebo vlastní fork knihovny libAdwaita s názvem libAdapta podporující grafická témata. Linux Mint 22.2 bude podporován do roku 2029.
Čínská společnost Tencent uvolnila svůj AI model HunyuanWorld-Voyager pro generování videí 3D světů z jednoho obrázku a určené trajektorie kamery. Licence ale nedovoluje jeho používání na území Evropské unie, Spojeného království a Jižní Koreje.
Blender Studio se spojilo s kapelou OK Go a výsledkem je videoklip k písni Impulse Purchase. Stejně jako samotný 3D software Blender je i ve videoklipu použitý animovaný chlápek open source. Kdokoli si jej může stáhnout a upravovat.
Zig Software Foundation stojící za programovacím jazykem Zig publikovala finanční zprávu za rok 2024. Současně s prosbou o finanční příspěvek.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za srpen (YouTube). Vypíchnuta je podpora Tabulek Google, implementace Gamepad API a Cookie Store API nebo také podpora WebGL na Linuxu.
openSUSE Leap 16, včetně Leap Micra 6.2+, nově nabízí 24 měsíců podpory pro každé vydání. To je dva roky aktualizací a stability, což z něj činí nejdéle podporovanou komunitní distribuci vůbec. Leap se tak stává ideální platformou pro všechny, kdo hledají moderní, stabilní a dlouhodobě podporovanou komunitní Linux distribuci.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal dne 3. 9. 2025 VAROVÁNÍ před hrozbou v oblasti kybernetické bezpečnosti spočívající v předávání systémových a uživatelských dat do Čínské lidové republiky a ve vzdálené správě technických aktiv vykonávané z území Čínské lidové republiky. Varováním se musí zabývat povinné osoby podle zákona o kybernetické bezpečnosti.
Americká internetová společnost Google nemusí prodat svůj prohlížeč Chrome ani operační systém Android. Rozhodl o tom soud ve Washingtonu, který tak zamítl požadavek amerického ministerstva spravedlnosti. Soud ale firmě nařídil sdílet data s jinými podniky v zájmu posílení konkurence v oblasti internetového vyhledávání. Zároveň Googlu zakázal uzavírat dohody s výrobci mobilních a dalších zařízení, které by znemožňovaly
… více »Prvního září ozbrojení policisté zatkli na na londýnském letišti Heathrow scénáristu a režiséra Grahama Linehana, známého především komediálními seriály Ajťáci, Otec Ted nebo Black Books. Během výslechu měl 57letý Graham nebezpečně zvýšený krevní tlak až na samou hranici mrtvice a proto byl z policejní stanice převezen do nemocnice. Důvodem zatčení bylo údajné podněcování násilí v jeho 'vtipných' příspěvcích na sociální síti
… více »
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: