Open source RDP (Remote Desktop Protocol) server xrdp (Wikipedie) byl vydán ve verzi 0.10.0. Z novinek je vypíchnuta podpora GFX (Graphic Pipeline Extension). Nová větev řeší také několik bezpečnostních chyb.
Rocky Linux byl vydán v nové stabilní verzi 9.4. Přehled novinek v poznámkách k vydání.
Dellu byla odcizena databáze zákazníků (jméno, adresa, seznam zakoupených produktů) [Customer Care, Bleeping Computer].
V lednu byl otevřen editor kódů Zed od autorů editoru Atom a Tree-sitter. Tenkrát běžel pouze na macOS. Byl napevno svázán s Metalem. Situace se ale postupně mění. V aktuálním příspěvku Kdy Zed na Linuxu? na blogu Zedu vývojáři popisují aktuální stav. Blíží se alfa verze.
O víkendu 11. a 12. května lze navštívit Maker Faire Prague, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
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:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz