Po Canonicalu a SUSE oznámil také Red Hat, že bude podporovat a distribuovat toolkit NVIDIA CUDA (Wikipedie).
TrueNAS (Wikipedie), tj. open source storage platforma postavená na Linuxu, byl vydán ve verzi 25.10 Goldeye. Přináší NVMe over Fabric (NVMe-oF) nebo OpenZFS 2.3.4.
Byla vydána OpenIndiana 2025.10. Unixový operační systém OpenIndiana (Wikipedie) vychází z OpenSolarisu (Wikipedie).
České základní a střední školy čelí alarmujícímu stavu kybernetické bezpečnosti. Až 89 % identifikovaných zranitelností v IT infrastruktuře vzdělávacích institucí dosahuje kritické úrovně, což znamená, že útočníci mohou vzdáleně převzít kontrolu nad klíčovými systémy. Školy navíc často provozují zastaralé technologie, i roky nechávají zařízení bez potřebných aktualizací softwaru a používají k nim pouze výchozí, všeobecně známá
… více »Během tradiční ceremonie k oslavě Dne vzniku samostatného československého státu (28. října) byl vyznamenán medailí Za zásluhy (o stát v oblasti hospodářské) vývojář 3D tiskáren Josef Průša. Letos byly uděleny pouze dvě medaile Za zásluhy o stát v oblasti hospodářské, druhou dostal informatik a manažer Ondřej Felix, který se zabývá digitalizací státní správy.
Tor Browser, tj. fork webového prohlížeče Mozilla Firefox s integrovaným klientem sítě Tor přednastavený tak, aby přes tuto síť bezpečně komunikoval, byl vydán ve verzi 15.0. Postaven je na Firefoxu ESR 140.
Bylo oznámeno (cs) vydání Fedora Linuxu 43. Ve finální verzi vychází šest oficiálních edic: Fedora Workstation a Fedora KDE Plasma Desktop pro desktopové, Fedora Server pro serverové, Fedora IoT pro internet věcí, Fedora Cloud pro cloudové nasazení a Fedora CoreOS pro ty, kteří preferují neměnné systémy. Vedle nich jsou k dispozici také další atomické desktopy, spiny a laby. Podrobný přehled novinek v samostatných článcích na stránkách Fedora Magazinu: Fedora Workstation, Fedora KDE Plasma Desktop, Fedora Silverblue a Fedora Atomic Desktops.
Elon Musk oznámil (𝕏) spuštění internetové encyklopedie Grokipedia (Wikipedia). Zatím ve verzi 0.1. Verze 1.0 prý bude 10x lepší, ale i ve verzi 0.1 je podle Elona Muska již lepší než Wikipedia.
PSF (Python Software Foundation) po mnoha měsících práce získala grant ve výši 1,5 milionu dolarů od americké vládní NSF (National Science Foundation) v rámci programu "Bezpečnost, ochrana a soukromí open source ekosystémů" na zvýšení bezpečnosti Pythonu a PyPI. PSF ale nesouhlasí s předloženou podmínkou grantu, že během trvání finanční podpory nebude žádným způsobem podporovat diverzitu, rovnost a inkluzi (DEI). PSF má diverzitu přímo ve svém poslání (Mission) a proto grant odmítla.
Balík nástrojů Rust Coreutils / uutils coreutils, tj. nástrojů z GNU Coreutils napsaných v programovacím jazyce Rust, byl vydán ve verzi 0.3.0. Z 634 testů kompatibility Rust Coreutils s GNU Coreutils bylo úspěšných 532, tj. 83,91 %. V Ubuntu 25.10 se již používá Rust Coreutils místo GNU Coreutils, což může přinášet problémy, viz například nefunkční automatická aktualizace.
Napadla mě taková myšlenka. Co je vlastně pro provoz serveru, za předpokladu že chceme mít aspoň trochu aktuální SW, lepší / bezpečnější?
A) dist-ugrade jednou za 6-12 měsíců? (většina distribucí včetně Debianu stable jehož cyklus je ale delší)
B) roll-up updates prakticky pořád po kouskách? (například debian, pokud uvedeme místo skutečného jména verze kód "testing")
Mezi mnoha uživateli je rozšířen názor, že rolling updates z praktického hlediska výsadou pouze jediné distribuce. Asi ji nebudu pro jistotu ani jmenovat, nebo mě zas nějaký zdejší vymaštěný ichtyl bude popichovat, že porušuju slib. Jak jsem ovšem zjistil, není to tak úplně pravda. Stejně jako jsou neustále slyšet kecy o nadřazenosti DEB nad RPM podkládané jakými hrozbami dependecy-hellu, který nikdo už řadu let nepotkal, tak i tohle je pěkný nesmysl. Jak jsem si vyzkoušel, upgradovat distribuci zvládá také Opensuse. A rozhodně nebude podle dostupných informací samotné. Podobně lze údajně upgradovat i Mandrivu. V případě opensuse, jediné co k tomu stačí je Zypper...
Jednoduchá anketní otázka: Který "bezplatný" systém by jste nasadili na svůj server nebo server, který máte spravovat?
Packagekit je poměrně zajímavý projekt, který má za cíl sjednocení package managementu napříč distribucemi. Jelikož jako front-end ma obě hlavní rozhraní - GUI (Qt + GTK) a CLI, existuje reálná šance že se tento systém prosadí. Ve Fedoře je již defaultním frontendem balíčkovače, v SUSE zdá se je už využíván při updatech jako backend suse updateru, a konečně je velká šance, že se objeví i v Ubuntu. Obrovskou výhodou tohoto systému je, že všechny aplikace mohou používat Packagekit, jako backend. Všechny instalace kodeků, jak je známe z ubuntu, všechny ty aktualizace, to vše může být napsaáno, a v mnoha distribucích už je napsaáno pro Packagekit. A co je hlavní. Packagekit, jakožto multiplatformí systém podporuje řadu backendů. Člověk si tedy může ve své disribuci zvolit kterýkoli podporovaný package manager, a jelikož systém používá Package-kit, nepředstavuje to pro něj žádný problém.
Tak dost. Dnes můj pohár trpělivosti s Debilianem přetekl. Z testovaného serveru jej okamžitě vykopnu. Jsem vlastně rád, protože aspoň bezpečně vím, že Debian, ani jeho deriváty na svých strojích už nechci vidět. O debilitě jeho package managementu jsem zde napsal dost. A 4 z 5 zubních lékařů, pardon čtenářů Abclinuxu, se mnou nesouhlasí. Na závěr snad zhrnutí, všeho možného, co mě tak z použití Debianu napadlo, že nefunguje, funguje blbě, či naprosto nelogicky - ovšem podle uživatel a vývojářů je to prý nejlepší způsob....Původně jsem měl v plánu monstrozní shrnutí, ale protože mě někdo již předběhnul s důkladným popisem, tak nebudu plýtvat elánem, sám bych to lépe nenapsal: Why Debian Is Not My Favourite Operating System
Než půjdete příště volit vemte rozum do hrsti. Další oranžádovou tsunami už prosím ne!!!
wire64@ubuntu-desktop:~$ sudo aptitude install xterm
[sudo] password for wire64:
Čtu seznamy balíků... Hotovo
Vytvářím strom závislostí
Čtu stavové informace... Hotovo
Čtu rozšířené stavové informace
Inicializuji stavy balíků... Hotovo
Zapisuji rozšířené stavové informace... Hotovo
Následující balíky budou ODSTRANĚNY:
aumix{u} libtagc0{u} thunar-data{u} xfdesktop4-data{u}
0 balíků aktualizováno, 0 nově instalováno, 4 k odstranění a 2 neaktualizováno.
Potřebuji stáhnout 0B archivů. Po rozbalení bude uvolněno 15,3MB.
Chcete pokračovat? [Y/n/?] y
Zapisuji rozšířené stavové informace... Hotovo
(Čtu databázi ... nyní je nainstalováno 165107 souborů a adresářů.)
Odinstalování balíku aumix ...
Odinstalování balíku libtagc0 ...
Odinstalování balíku thunar-data ...
Odinstalování balíku xfdesktop4-data ...
Zpracování spouštěčů pro balík man-db ...
Zpracování spouštěčů pro balík libc6 ...
ldconfig deferred processing now taking place
Čtu seznamy balíků... Hotovo
Vytvářím strom závislostí
Čtu stavové informace... Hotovo
Čtu rozšířené stavové informace
Inicializuji stavy balíků... Hotovo
Zapisuji rozšířené stavové informace... Hotovo
wire64@ubuntu-desktop:~$
čím déle používám desktopová prostředí, tím více začínám být alergický na různé kýčovité cipoviny v kolotočářském stylu. Hopsající kurzory, lesklá tlačítka, milion widgetů, to všechno je perfektní halo na efekt, ale prakticky to člověk neužije. Dnes jsem se omylem zalogval do Gnome a jsem zděšen. Až teď zjišťuju, jak je moje KDE 4.1.3 pomalé, přičemž KDE 4.2 je u mě pořád bugovité, a rychlost stejné jako u KDE 4.1.3.
O nechutném bugu v Opensuse, způsobující nemožnost vypalovat a mnoho dalších problémů se tu již napsalo dost. Kdo si pamatuje slavný výrok Aničky o neblahé kvalitě Opensuse 11.1 a přechodu na Debian, tak tento výrok zazněl právě v diskuzi pod timto tématem. Na internetu existuje bezpočet "udělej si sám" návodů, jak tento problém opravit. Od nepřiřazení uživatele do příslušné skupiny, přes změnu přístupových práv k /dev/sr0, až po editaci /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy. Co se tak matně vzpomínám, z návodů mi nepomohl žádný, ale vypalování jsem "nějak" neidetifikovatelnou alchymií pokus omyl zprovoznil. Mezi tím vyšly záplaty hal a automountfs. Zá se že všechno je OK. Pak odešel HDD...
Hledám a hledám a stále nenacházím. Dpkg/deb má jednu nepříjemnou vlastnost. Na rozdíl od rpm/rpm není neinteraktivní. člověk spustí instalaci nějaké hromady balíků, a pak aby čekal, a pořád na něco odpovídal. Nějak pořád nemůžu pochopit na co mám milión stavů balíčků. Balíček je nenainstalován. Balíček je stažen ale nenainstalován. Balíček je stažen nainstalován ale nezkonfigurován. Balíček je nainstalován a zkonfigurován. Balíček buď instaluji a nebo neinstaluji. Zbytek je sebemrskačství. A proč ho sakra musím konfigurovat při instalaci? --asume=yes pořádně nefunguje, ostatně už z principu se nedá na všecho odpovědět ano/ne :-) člověk aby ten systém pořád vodil za ručičku... :-(
Nějaké tipy na plně automatizovanou instalaci DEB balíků?
Celý flame byl zbytečný. Nakonec jsem se odpovědi nedobral ani od mantainerů Debianu, přesto odpověď existuje a nakonec jsem ji po dlouhém hledání našel sám. I když jste mi tady vynadali do spousty škaredých věcí, přesto vám sem přidám rozřešení našeho sporu. Né proto, že jsem měl skutečně pravdu. Ale čistě proto, kdyby náhodou některého uživatele Debian/Ubuntu zajímalo, jak to stím Aptem, Aptitude a pokročilými Solvery do budoucna vypadá. Nemusíte tento zápisek číst, a nadávky si odpusťte. Není nad čím flamovat. Funkcionalita dependency solveru, který mi v Debianu chybí skutečně bude přidána. Asi to nebude tak růžově úžasné, ani totálně nepotřebné, jak mě zde mnozí s blbouni křikem přesvědčovali... Jako kdybych kritizoval je a né APT.
Nedalo mi to. Po několika předešlých zápiscích, kdy hromada Debianistů a Ubuntáků řvala jako smyslů zbavená jsem konečně našel konkrétní podklady pro to, co jsem si jako laik již všiml dávno. Pokud například do Ubuntu nainstaluju KDE 4.1.3 a následně upgraduju na KDE 4.2, tak po odstranění experimental repozitáře s KDE 4.2 a nějakého balíku od KDE 4.2 zkončil APT s neřešitelným problémem - doslova dependecy hellem. Takovou situaci prostě vyřešit neumí. Přitom řešení jen tak trapně jednoduché, že ho vymyslím i sám. Problém nastává v situaci, kdy né každé řešení je takto jednoduché a smyslem správce balíků by mělo být zejména to, vyřešit systém závislostí. Že to není jen můj "dojem" ukazuje i názorný test schopností vyřešit nějaký model závislostí. Jen tak mimochodem, Smart, který je v ubuntu dostupný, problém vyřešil.