Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Potřeboval jsem najít optimální řešení k aktualizovaci velkých binárních souborů. Možná bude mít někdo z vás tip ještě na jiné řešení, ale já vyzkoušel následující tři (vyjmenováno vzestupně od nejhoršího k optimálnímu): xdelta3, rdiff, rsync.
K testovací účelům jsem si vyrobil přes mksquashfs dva velké binární soubory, ze dvou různých snapshotů adresáře s komplet nainstalovaným Debianem. Starší byl vytvořen 30. března 2020, před aktualizací a druhý 3. dubna 2020, když už bylo vše odladěno.
Zde si k vaší smůle neodpustím malou reminescenci. Neboť právě tehdy začala obyvatelstva ČR začala lámat všeobecná hysterie, která mimo jiné, vyhnala studenty ze škol. Nikdo na takovou situaci nebyl připraven, jenom já zaplesal štěstím protože jsem měl najednou dost času na to, abych implementoval do laboratorního disklessu dlouhodobě plánované úpravy, které měly za cíl umožnit studentům práci na strojích v počítačových laboratořích z domova.
Jak ti pozornější z vás už vědí, má zvýšená pracovní aktivita vyžaduje úměrně tomu zvýšenou míru duševní hygieny, takže jsem během výše vymezeného období jednoho měsíce napsal za účelem vypláchnutí hlavy tyto blogposty:
Z profesního hlediska to byla krásná doba, protože mi všeobecná paralýza z neobvyklé situace, spojená s absencí vyučujících i studentů v laboratořích, umožnila pracovat bez toho, že by na mne někdo tlačil, nebo chtěl abych dělal něco jiného. Takže jsem mohl o pět měsíců později, když ve vzduchu visela otázka zda se po 21. září 2020 bude učit prezenčně nebo distančně, s klidnou duší poznamenat, že laboratoře jsou už od jara připraveny na obě varianty.
Ale přejděme k hlavnímu tématu.
Ze staršího subvolume s cca 22GB dat vylezl přes mksquashfs soubor old.image
o velikosti 11GB. Z novějšího (cca 20GB) vypadnul soubor new.image
9,2GB. To bylo na můj vkus trochu moc dat na to, aby se takové soubory opakovaně tahaly ze stroje na stroj sem a tam po síti. Proto mne zajímalo:
Je utilita, kterou jsem zkoušel naposled. Vlastně jenom ze zajímavosti. A výsledky měla tak příšerné, že na ni milerád zapomenu. Takže jen pro úplnost. Pro vytvoření rozdílového souboru image.delta
jsem použil následující příkaz:
~# xdelta -e -s old.image new.image image.delta
Trvalo to příšerných 43 minut, a výsledkem byl rozdílový soubor image.delta
o velikosti 6GB. To mi stačilo a jen pro úplnost jsem ještě vyzkoušel vytvoření patchovaného souboru xdelta.image
:
~# xdelta -d -s old.image image.delta xdelta.image
To už naštěstí proběhlo poměrně rychle (55 sec.) a kontrolní součet souboru xdelta.image
odpovídal kontrolnímu součtu souboru new.image
. Ale pro značnou velikost rozdílového souboru už jsem nic dalšího (např. slučování rozdílových souborů) nezkoušel.
Tuhle utilitu jsem testoval jako první, protože jsem ji stejně musel nejdřív doinstalovat. Někomu se to může zdát jako drobnost, ale pro mne je důležité aby nástroj, který se má použít pro aktualizovaci souboru byl standardní součástí instalace. Což bohužel nebyl tento případ. Ale nešť.
Důležitá je totiž také velikost, byť ve srovnání s objemem zpracovávaných souborů zanedbatelná. A rdiff má pouhých 15kB a jen minimum závislostí.
Vytvoření rozdílového souboru v tomto případě proběhlo ve dvou krocích. Nejprve bylo potřeba vygenerovat pro výchozí starší soubor old.image
signaturu, datový soubor signature.file
, nezbytný pro vytvoření delta souboru, se změnami.
~# rdiff signature old.image signature.file
Tahle operace zabrala nějakých 22 sekund. A pak bylo možné přistoupit k vytvoření souboru rdiff.delta
se změnami.
~# rdiff delta signature.file new.image rdiff.delta
Docela to trvalo (protože jsem ještě netušil co mě čeká), ale po 14 minutách z této operace vypadnul soubor rdiff.delta
o velikosti 579MB. A to nebylo špatné. Takže bylo možné přistoupit k opatchování souboru old.image
.
~# rdiff patch old.image rdiff.delta rdiff.image
Rychlost, s jakou proběhlo patchování mne překvapila. Nový soubor rdiff.image
byl vytvořen během 8 sekund a kontrolní součet byl v pořádku. Delší čas, potřebný pro vytvoření rozdílového souboru by se dal zkousnout, ale víceméně náhodou jsem narazil na jednu nepříjemnou vlastnost, která mne od použití této utility odradila, i když by v reálu nemusela možná vadit. Zmíním se o ní v následující části.
Přiznám se, že jsem netušil, že bych tento nástroj využít i takovým způsobem. A tak jsem byl mile překvapen. Nejenom tím jak je to jednoduché, ale i tím, jak dlouho jednotlivé operace trvaly.
Funguje to tak, že se nejprve vygeneruje rozdílový soubor, v mém případě pojmenovaný rsync.delta
:
~# rsync --only-write-batch=rsync.delta new.image old.image
Zaskočilo mne, jak rychle tahle operace proběhla, protože za minutu a půl bylo hotovo a velikost rozdílového souboru rsync.delta
byla jen o 47MB větší, než součet velikostí souborů nezbytných pro rdiff – 689MB. Proto jsem byl zvědav jak dopadne aktualizace staršího souboru.
Ovšem v tomto bodě jsem se dopustil chyby, která mne následně přivedla k potenciálně problematickému chování utility '''rdiff'''.
Utilita '''rsync''' totiž aplikuje změny na původní, starší soubor. A já, místo abych ho zkopíroval a vytvořil soubor nový, aplikoval změny v rozdílovém souboru přímo na něj. Takto:
~# rsync --read-batch=rsync.delta old.image
Zhruba po půl minutě bylo hotovo a kontrolní součet byl stejný jako u souboru new.image
. To bylo velmi pěkné, ale přišel jsem tím o testovací soubor, protože byl zaktualizován. A tak jsem se jal vyrábět, ze stejného snapshotu soubor nový. Stejným způsobem jako prvně, ovšem až na jeden detail – zapoměl jsem odstranit aktualizovaný soubor s názvem old.image
.
Ukázalo se, že utilita mksquashfs
cílový soubor nepřepisuje, nýbrž aktualizuje. Takže obsah image ze 3. dubna byl nahrazen starší verzí z 30. března. Výsledkem byl tudíž jiný soubor, než původně. Nicméně, když už jsem tuhle chybu udělal, zkusil jsem vyzkoušet, jak si poradí rsync a rdiff když se pokusím na takový soubor aplikovat již vygenerované rozdílové soubory.
Nejprve jsem vyzkoušel rdiff, který nic nepřepisuje a vytváří nový soubor. Ten ho bez keců schroupnul, ale výsledek měl pochopitelně jiný kontrolní součet, než soubor new.image
. To nebylo pěkné.
Když jsem tutéž operaci vyzkoušel s utilitou rsync, tentokrát na kopii omylem aktualizovaného souboru old.image
, nebyly aplikovány žádné změny. Kontrolní součet zůstal stejný.
Pro další pokus jsem si vygeneroval stejný výchozí soubor jako prve, abych se ujistil, jestli mksquashfs
vyrobí stejný soubor. A skutečně, kontrolní součet odpovídal tomu, jaký měla původní verze new.image
. A s aktualizací tohoto souboru na novější už neměl rsync žádný problém.
Pravděpodobně využiju ten rsync, i když je o něco větší. To, jakým způsobem funguje mi vyhovuje, protože není nutné řešit starší verze souborů a já už vím jak zajistit, aby se vždy stáhnul ten správný rozdílový soubor. Zbývá jenom vymyslet odkud a přes jaký protokol, aby s tím bylo nejmíň cavyků.
Pokud jde o situaci ve škole, situace je trochu jiná, než byla před dvěma lety. Z mého pohledu ovšem výrazně horší, protože semestr začíná na můj vkus neúměrně brzy (19. září 2022). Je dost těžké skloubit dovolenou, kterou si musíte vybrat, s nejrůznějšími akcemi, které se plánují do období, kdy výuka neprobíhá. A najít dostatečně velké časové okno, kdy se ještě nepracuje v laboratořích, ale jsou zároveň k zastižení ti co ten laboratorní systém využívají, aby se včas vychytaly případné problémy. Dřív, než začne výuka a v laborkách opět začnou vysedávat studenti.
A tak jsem rád, že se mi podařilo realizovat alespoň dlouho plánované sjednocení uživatelských účtů. Bohužel přesun, vzhledem k množství naakumulovaných uživatelských dat, trval déle než jsem původně plánoval. Takže jsem přehodil prioritu následujících úkolů a původně plánovanou velkou aktualizaci odsunul až na zimu.
Číňany jsem přestal řešit přes fail2ban. Tedy přesněji řečeno přes jeho filtry. Jejich drzost už neznala mezí, takže je banuji rovnou hlava nehlava, dobrý, špatný, po celých subnetech. Žádný zajímavý obsah pro ně stejně nemám. A nevěřili byste jak díky tomu spadlo průběžné zatížení serveru.
A zcela závěrem pár slov k tomu umírání.
Z našich prarodičů zatím nikdo neumřel. Jenom otec měl v srpnu namále. Nechal si disciplinovaně píchnout čtvrtou dávku a jeho oslabený imunitní systém sejmula nějaká infekce tak, že skončil na dva týdny ve špitále. Nicméně se z toho zvetil, i když to vypadalo už velmi zle. Ne že by zrovna umřel. To by na tom asi bylo to nejmilosrdnější. Ale nedělám si iluze. 86, 86, 8̶3̶ (†10.9.2022), 82, 81, 80,… maximální věková hranice dožití jak ze strany mojí, tak ze strany ženy byla (u žen) 92 let. Pro muže bývala konečná do 80 let. Z nich se nejvíce let dožil otcův bratranec, který zemřel ve věku 88 let, v pondělí ráno 3.2.2020, na infarkt v ordinaci praktického lékaře. Měsíc před tím, než vypukla všeobecná kovidová hysterie.
Tiskni
Sdílej:
Kde jsi přišel na to, že s těmito nástroji nepracuji? Nevím teda jaké máš s nimi zkušenosti ty, ale já mnohaleté.
Pro zajímavost uvedu příklad z dob, kdy jsem v rámci disklessové infrastrutury spravoval také uživatelské účty. Teď už je neřeším, protože jsou na úložišti, které spravuje někdo jiný.
Tehdejší infrastrukturu tvořil několikanodový cluster a zálohy se sypaly na lokální disky. Co účet, to subvolume. Jinak bys jen stěží mohl používat kvóty. Bylo to desetitisíce snapshotů. A zažil jsem jednou pěkně horkou chvilku, kdy jsem čekal několik hodin než se mi to namountuje. Všechno klaplo, ale byl jsem orosený až na zadku. No a když jsem pak slučoval zálohy z těch lokálních disků na jedno místo, bylo potřeba to všechno sklepat tak, aby se to vešlo na disk. Já vím. Dnes v době 10TB HDD to už nikdo moc neřeší, ale hovořím o době před pěti lety.
V podstatě mi jde o to, minimalizovat objem přenášených dat, tak aby po síti běhalo jen to co je nezbytně nutné. Problém je, že u disklessu vlastně nikdo pořádně neví kolik dat se přenese, když stroje najednou zapne X studentů. Já si tuhle otázku položil, když jsem zkoušel řešení postavené nad Ganeshou, což byl rok 2016. Ovšem jak velkou roli to hraje jsem zjistil u disklessu provozovaného přes wi-fi, který používá lokální kešování. Jenže to má bohužel několik slabin. Ale dnes jsem podnikl praktický pokus, který mi dal uspokojivou odpověď, jak se jim vyhnout. Teď je ale na řadě konsolidace infrastruktury.