AlmaLinux byl vydán v nové stabilní verzi 9.4 (Mastodon, 𝕏). S kódovým názvem Seafoam Ocelot. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Před 50 lety, 5. května 1974 v žurnálu IEEE Transactions on Communications, Vint Cerf a Bob Kahn popsali protokol TCP (pdf).
Bylo vydáno do češtiny přeložené číslo 717 týdeníku WeeklyOSM přinášející zprávy ze světa OpenStreetMap.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.10.38 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Google zveřejnil seznam 1220 projektů od 195 organizací (Debian, GNU, openSUSE, Linux Foundation, Haiku, Python, …) přijatých do letošního, již dvacátého, Google Summer of Code.
Na základě DMCA požadavku bylo na konci dubna z GitHubu odstraněno 8535 repozitářů se zdrojovými kódy open source emulátoru přenosné herní konzole Nintendo Switch yuzu.
Webový prohlížeč Dillo (Wikipedie) byl vydán ve verzi 3.1.0. Po devíti letech od vydání předchozí verze 3.0.5. Doména dillo.org již nepatří vývojářům Dilla.
O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Chci se zeptat, podařilo se někomu vypálit tento obraz tak, aby po kontrole vypáleného média dostal některý z těchto kontrolních součtů?
Nechápu, jak je to možné, ale nepodařilo se mi to ani jednou. Když obraz stáhnu na HDD, kontrolní součet (sha256sum) souhlasí. Ale ten obraz prostě nejde vypálit.
Na jednom počítači WinXP a Nero - obraz se vypálí (zkusil jsem vypálit jedno CD-R a jedno CD-RW), ale sha256sum /dev/sr0
nevrátí korektní součet nebo zhavaruje na I/O chybě (+-střídavě). dd if=/dev/sr0 | sha1sum
prozradí, že přes dd
projde o několik set kB méně dat, než odpovídá velikosti obrazu - na dvou různých počítačích s použitím tří různých distribucí dd
vrátilo méně dat, než by mělo (a vždy stejně, až při zkoušce na třetím zcela novém PC to vrátilo dat ještě o něco méně).
Další dva pokusy o vypálení proběhly na dalším počítači s poslední Fedorou a za použití K3b. K3b zhavarovalo pokaždé hned na začátku vypalování (jen pokaždé poničilo médium zaváděcí stopou), ještě před začátkem vypalování přitom spočítalo správný md5 součet souboru s obrazem.
V QEMU přitom z toho obrazu v pohodě nabootuji. Tak vážně nevím, co si o tom myslet.
Kouknul bych se sem: Chybně vypálený ISO obraz, následná kontrola vypálení skončí s chybou.
Dík za reakci, s tím nevypálením na druhé vypalovačce (na stroji s Fedorou) to byl planý poplach, ta palírna teď není schopná vypálit nic (resp. vypálí pár set kB na začátek média a skončí chybou), přitom jsem s ní ještě před čtrnácti dny bez problémů vypaloval. Už mám koupenou novou, budu zkoušet dál.
Pokud jde o odkazovanou diskusi - už jsem se setkal s tím, že dd if=/dev/sr0
vrátilo o pár set kB víc dat (začátek byl identický s image, na konci byly přilepeny nulové byty). Ale tady poprvé koukám na to, že z média vyleze méně bajtů (251904000) než je velikost image (252030976). Až teď mě napadlo porovnat kontrolní součet /dev/sr0
s kontrolním součtem prvních 251904000 bytů image - součty sedí. Rozdíl je 126976 bytů a opět kontrolním součtem jsem ověřil, že jsou to samé nuly.
Takže "záhada" je asi vyřešena - Nero je zřejmě "přechytralé" a nedopaluje nulové byty na konec média. A druhá vypalovačka zřejmě nefunguje, takže vlastně nevím, jak se zachová K3b. Vyzkouším.
Díky za nakopnutí, bylo to ve skutečnosti celkem prosté, ale tahle banalita byla součástí širšího okruhu nehod, které mě včera potkaly, takže už jsem se nedokázal při pokusu o řešení vymanit z myšlenkových stereotypů, které vedly k vytvoření záhady namísto k vyřešení problému.
Tiskni Sdílej: