Rust-hoz köthető dátum bug akadályozza az Ubuntu 25.10 telepítések automatikus frissítéseit

Bug

Az Ubuntu projekt bejelentette, hogy az Ubuntu 25.10-zel szállított, Rust-alapú uutils-változatban lévő date parancs hibája eltörte az automatikus frissítéseket:

A date parancsban található, mára megoldott hiba miatt néhány Ubuntu 25.10 rendszer nem tudta automatikusan ellenőrizni az elérhető szoftverfrissítéseket. Az érintett gépek közé tartoznak a felhős telepítések, a konténerképek, valamint az Ubuntu Desktop és Ubuntu Server telepítések. 

A bejelentés tartalmaz javítási útmutatót az érintettek számára. A rust-coreutils csomag 0.2.2-0ubuntu2 vagy korábbi verziói tartalmazzák a hibát; a javítás a 0.2.2-0ubuntu2.1 vagy újabb verziókban található. Ez a probléma nem érinti az apt paranccsal vagy más segédprogramokkal végzett kézi frissítéseket.

Az Ubuntu projekt a 25.10-es kiadással arra vállalkozott, hogy Rust-alapú coreutils és sudo implementáció bevezetésével felmérje, hogy a Rust-alapú segédprogramok alkalmasak-e a jövő áprilisra tervezett hosszú távú kiadásra. 

Ebben akkor is igazat adtam, de szerintem itt a Canonical a nem LTS, tesztelős verzióhoz képest is túltolta most. Ez az uutils még egy nagyon kiforratlan, fiatal projekt, félkész, nem lett volna szabad ráerőltetni senkire, még a tesztelősekre sem. Köztudottan nem ment még át minden automatikus GNU-s teszten sem.

Értem egyébként a Canonicalt, ők is látták, hogy félkész, de azt hitték, hogy ha bevezetik, akkor az népszerűsíti a projektet, felgyorsul a debugging folyamat, gyorsabban befejeződnek a félkész részek, ha a fejlesztők nyomás alá kerülnek, lesz tétje a projektnek, és nem ül le, mint az utóbbi években.

Ezt csinálták a Red Hat fejlesztők a GIMP-pel is, ott is már a végtelenségig húzódott a 3.0-ás verzió kijövetele, ezért nyomást tettek a fejlesztőkre, hogy gyorsabban kijöjjön. Elég megkérdőjelezhető, bugos is lett a kiadás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( DirtY_iCE | 2025. 10. 25., szo – 14:51 )

Kb ennek is annyi ertelme volt mint a whitelist/blacklist atnevezgeteseknek, csak joval nagyobb bug behozatali valoszinuseggel

I hate myself, because I'm not open-source.

( cstamas | 2025. 10. 25., szo – 15:00 )

Ha április 1-i kiadás, akkor arra megfelelő :).

( n.balazs v | 2025. 10. 25., szo – 15:43 )

Rustra szállt dust? :)

Nem véletlenül megy szinte mindenki LTS irányba.
Ami most a normál verzió, azt régen bétának hívták.
Ami most az LTS verzió, azt régen normál verziónak hívták.

Nem tudom hogy az Ubuntu publikálja-e a telepítési számokat, de szerintem a nem LTS verziók számai meredeken esnek, közben ezt akarják tesztkörnyezetnek használni, de egyre kevesebben akarnak tesztalanyok lenni, mivel már az előző LTS is "elég jó" volt. Emiatt ráadásul fragmentálódik a felhasználói bázis, sok helyen kivárják a 3 éves desktop support lejártát, és akkor váltanak az akkor már 1+ éves új LTS-re. Emiatt a friss LTS is kevesebb tesztelést kap...

Szerintem a hagyományos, rengeteg programot és libraryt tartalmazó, - app store-okat kiváltó - distrók ideje lassan lejár, csak az utód még nincs kész. Amikor megjelent az APT 26+ éve, egy csoda volt, hogy úgy tudtunk programokat felrakni, ami minden függőségét vitte magával. Ebben az időben Windowson az volt a megszokott, hogy az app belehányt egy csomó DLL-t a Windows könyvtárba, uninstall persze nem volt.

Ma már a legtöbb nagyobb alkalmazás (beleértve az Ubuntuban találhatóakat is, mint egy Chrome vagy egy LibreOffice) főleg saját maga szállítja a függőségeit, pont azért, hogy minél kevesebb külső függése legyen, és könnyebben lehessen úgy frissíteni, hogy közben az OS-t nem frissítjük. Hasonló célból jelent meg a Flatpak és az AppImage is, még hozzáadva a distrófüggetlen terjesztést.

A következő evolúciós lépés szerintem az immutable base distro + köré épített alkalmazás ecosystem / app store-ok, konténer registryk. Szerver oldalon már egyértelműen erre fele halad mindenki (Ubuntu Core, OpenSUSE Leap Micro és MicroOS, ... stb.). De már kliens oldalon is megjelentek az első fecskék, akár az Omarchy, akár a OpenSUSE Aeon.

Ugyanez látszik már a MacOS-ben is, az alaprendszer gyakorlatilag read-only, a factory reset egyszerűen törli a többi APFS volume-ot.