Dnes a zítra probíhají Arduino Days 2026. Na programu je řada zajímavých přednášek. Sledovat je lze od 17:00 na YouTube. Zúčastnit se lze i lokálních akcí. Dnes v Poličce v městské knihovně a zítra v Praze na Matfyzu.
Byla vydána beta verze Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.04 LTS mělo vyjít 23. dubna 2026.
Byla vydána aktualizována Příručka pro začínající wikipedisty a wikipedistky (pdf).
Ubuntu plánuje v budoucích verzích nahradit tradiční nástroje pro synchronizaci času (chrony, linuxptp a gpsd) novým, v Rustu napsaným ntpd-rs, který nabídne vyšší bezpečnost a stabilitu.
Byla vydána nová verze 7.6 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Správce hesel KeePassXC byl nahrazen správcem hesel GNOME Secrets. Bitcoinová peněženka Electrum byla povýšena na verzi 4.7.0. Tor Browser byl povýšen na verzi 15.0.8. Další novinky v příslušném seznamu.
Chris Down v obsáhlém článku „vyvrací mýty o zswap a zram“, vysvětluje, co vlastně dělají a jaké jsou mezi nimi rozdíly. Doporučuje vyhýbat se zram na serveru a bez OOM.
Porota v Los Angeles shledala firmy Google a Meta odpovědnými v přelomovém soudním sporu, který se týká závislosti na sociálních sítích; firmy musí zaplatit odškodné tři miliony dolarů (63,4 milionu Kč). Společnosti, které s verdiktem nesouhlasí, čelily obvinění, že své sociální sítě a platformy záměrně navrhly tak, aby si na nich děti vypěstovaly závislost. Porota došla k závěru, že technologické společnosti při navrhování a
… více »Jelikož vývojáři editorů Vim a Neovim začali při vývoji využívat LLM, Drew DeVault se rozhodl forknout Vim a vytvořil projekt Vim Classic. Vychází z Vimu 8.2.0148, tj. těsně před zavedením Vim9 skriptování.
Byla vydána nová verze 0.56 open source počítačové hry Unvanquished (Wikipedie), forku počítačové hry Tremulous. Instalovat ji lze také z Flathubu.
FreeCAD (Wikipedie), tj. svobodný multiplatformní parametrický 3D CAD, byl vydán ve verzi 1.1 (YouTube). Po roce a čtyřech měsících od předchozí verze 1.0. Přehled novinek i s náhledy v poznámkách k vydání.
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!!!
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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.