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

Címkék

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. 

Hozzászólások

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.”

(Nem célom folytatni a múltkori vitát) Mikor az Ubuntu Warty megjelent én is azért váltottam rá dektopon  21 évvel ezelőtt (kimondani is fáj, hát még leírni), mert egy fél éves ciklusokban megjelenő, STABIL rendszert ígértek friss alaprendszerrel és aktuális (vagy ahhoz közeli) alkalmazás verziókkal. Ezt be is tartották, és mivel akkor még híre-hamva sem volt az LTS-nek, ezért nem is lehetett cél egyfajta béta tesztelése a később megjelenő stabil kiadásnak. Ez persze leginkább a desktop felhasználóknak volt jó még akkor is, mikor jött a Unity aztán elment, majd jött az upstart és az is elment, de végeredményben stabil volt minden verziója és a bugokat viszonylag gyorsan javították (ha más nem, hát a következő releasezel). Aztán persze kiadták 2006-ban az első LTS-t , hogy ne csak az olyan Linux Pistikék örüljenek az Ubuntunak, mint én, hanem már a fizetős célközönség is. Ennek ellenére továbbra sem (és azóta sem) volt arról szó, hogy a köztes verziók egyfajta béták lennének. A két hónap csúszás persze (a 06.06 ugye júniusban került kiadásra) azért mutatja, hogy erre a verzióra kicsit jobban rágyúrtak a srácok. Szóval (elméletben) igaz az a megállapítás, hogy stabilitásban nem-, hanem csak támogatásban más az LTS és a non LTS verzió. Egyébként LTS-re sem azonnal vált senki éles környezetben néhány önsorsrontó és szabad szex hívő kivételével, hanem megvárja az U1-et (kb. +3 hónap), a rutinosabbak meg az U2-is akár. Tehát ha csak nincs különösebb oka a sietségnek, akkor kb. akkor váltasz új LTS-re, mikor az előző non LTS támogatása már lejár. Stabilitásról ennyit. (Tudom, hogy ezt mind tudod, csak elkapott az írás mert már vagy 10 éve nem kommenteltem ide a HUP-ra 🥹 ) Az egyértelmű, hogy valamilyen cutting edge fícsört nem a következő LTS-be fognak beleerőltetni, mert az orbitális szopás lehet, hanem valamelyik interim verzióba, szenvedjenek vele a béta teszter Pistikék. Ezeket azonban előbb-utóbb meg kell lépni (pl. systemd - arra is mekkora ellenérzés volt/van, Gnome3, Wayland, python3, stb).

A mostani eset annyiban más, hogy a fejlesztői szerint is egy bevallottan félkész (vagy inkább nem teljesen kész), nem kitesztelt cuccot akarnak benyomni pont egy LTS előtti kiadásba. A problémák garantáltak, de valóban érthető az a hozzáállás, hogy ha bekerül egy kiadásba, akkor sokkal nagyobb a nyomás a fejlesztőkön, hogy záros időn belül a kijelölt célokat teljesítsék. Ezért aztán viszont nekem sérül az az vállalt kijelentés, hogy minden kiadás stabil, legalábbis szándékosan bugos/félkész komponensek nincsenek benne. Igazából csak nem értem ezt a sietséget. Szerencse a szerencsétlenségben, hogy pont olyan alap komponensről van szó, amelyik könnyen cserélhető, vagy lehet opcionális telepítéskor, vagy valamilyen hibrid megoldás, félig ez félig az, hogy a korábbi működés megmaradjon.

Akkor az ubuntu stabil kiadás  is olyan mint a Tesla  autopilot, azaz nem stabil ?

Ugyanis tudtommal a köztes változatok is stabil kiadások, csak rövid támogatási idővel. Van külön testing repo, ahol beleférnek az ilyen bakik, és van az LTS ami a hosszú támogatási időt ad.

Fedora 42, Thinkpad x280

Könnyen belátható józan paraszti ésszel, hogy egy 10+ évig támogatott LTS kiadás, amiben a hibákat folyamatosan javítják a .1, .2, .3, .4 stb. point release-ekben, az stabilabb tud lenni, mint egy fél évig támogatott kiadás, amiben kimondottan az új dolgokat próbálják és tesztelik ki. Az Ubuntu 16.04-nek pl. 7 point release-e volt ... Egyébként pedig:

  • “Interim releases give users a chance to preview new features and updates ahead of the next LTS release.” Ubuntu

  • “As an interim release, this is the perfect time to test new features in your application or get the benefits of the latest open source software versions, with support for 9 months…” Ubuntu Community Hub

  • “Ubuntu 25.04 is an interim release… serves as a platform for testing new developments ahead of the next Long-Term Support (LTS) release.”“ Ubuntu Community Hub

Egyértelműen le van írva, hogy tesztelés folyik bennük. A "test", "preview" szavak nem a stable ismérvei. 

De, aki széllel szemben kíván hugyozni, én nem akarom megakadályozni benne.  🤷‍♂️

trey @ gépház

Jó hát idézni én is tudok:

There are 2 types of Ubuntu releases: Interim and LTS. Each Ubuntu LTS is maintained for 10 years total: 5 years of standard support + 5 years of ESM. Interim releases are maintained for 9 months.There are 2 types of Ubuntu releases: Interim and LTS. Each Ubuntu LTS is maintained for 10 years total: 5 years of standard support + 5 years of ESM. Interim releases are maintained for 9 months.

Sehol nem írja, hogy az interim relase az igaából egy testing ...

Mert attól hogy valami preview, vagy new feature nem jelenti azt hogy annak ennyire fosnak is kell lennie, de ubuntuéknál igen.

Fedora 42, Thinkpad x280

Tehát összefoglalom: 

HA valaki a fentiek ellenére sem érti, hogy mi a különbség az LTS és az őszi kiadások közt, azon nem lehet segíteni. Lehet mantrázni bármit: HA stabilitást akarsz, akkor LTS.

Tehát trey nem tudja értelmezni az LTS fogalmát.  

LTS: Long-term_support

Ebből semmilyen módon nem következik, hogy a stabil és nem LTS kiadás egy testing ág lenne, netán az unstable kísérletezés instabil világát kellene megvalósítania. 

Az LTS csak a támogatási ciklus hosszában jelent többet a szintén stabil de nem LTS kiadásokhoz képest. 

Hát igen, ezeket a képességeket gimnáziumban kellett volna megszerezni. Szakközépben némi plusz önszorgalommal még abszolválható az elvárható szövegértelmezési képesség, de szakmunkásban teljesen esélytelen. 

Amit itt (is) a Canonical művel az Ubuntu hivatalos stabil kiadásaival szánalmas. Ezt rajtad kívül mindenki érti, (plusz esetleges más ide tévedő IT betanított munkások) 

Jaja, érdekes, mert én tudom értelmezni a szöveget, nekem nincs is bajom azzal, hogy amit értelmeztem, azt is kapom. Nektek van, akik olyasmit látnak stabilnak, amiben tesztelés folyik deklaráltan. 

Azt hiszem, neked kellene visszakotródnod az ált. isk. 3. osztályig ... :D

“Ubuntu 25.04 is an interim release… serves as a platform for testing new developments ahead of the next Long-Term Support (LTS) release.

trey @ gépház

"Every six months between LTS versions, Canonical publishes an interim release of Ubuntu, with 25.10 being the latest example. These are production-quality releases and are supported for 9 months..."

https://ubuntu.com/about/release-cycle

Lefordítsam neked magyarra? 

Jellemző rátok, okoskodó szakikra, hogy még azt sem tudjátok mi nem tudtok. Ezzel fordított arányban a magabiztosságotok az egekben van. Dunning–Kruger-hatás

Előbb azt fordítsd le, amit én idéztem. Production quality, amiben nem működik a date parancs miatt a frissítés ... ne röhögtesd ki magad, mert még úgy maradsz :D Az a különbség közted, meg köztem, hogy te a nyeretlen kétéves vagy, aki minden szart elhisz, amit az interneten olvas, én meg 20+ év gyakorlati tapasztalatomnak - igen, a sajátomnak - hiszek. 

Szerintem itt te vagy a palimadár ...

trey @ gépház

Hivatalos Ubuntu oldalról idéztem. Veled szemben forrást is megjelölve. 

Nekem diplomám van ebből, nem bölcsész, vagy matek-fizika tanár, ezt tanultam mielőtt szoftvermérnök lettem. Bár szövegértésben természetesen a bármilyen diplomás megüti ezt a szintet, és képes értelmezni egy ilyen szöveget. Te meg az autószerelő szakmunkás végzettségeddel képzeled magad közénk tartozónak, nem vagy az. Csak egy bohóc. Az "élet iskolájában" tanult IT betanított munkás. 

Egyébként cikked címe: Rust-hoz köthető dátum bug akadályozza az Ubuntu 25.10 telepítések automatikus frissítéseit
vs
általad becitált "Ubuntu 25.04", 
de ez már tényleg csak apróság.

További jó szopkodást akkor, diplomás úr! El ne hidd annak, aki 20+ éve csinálja, annak hidd el, aki tanítja! 

(aki tudja csinálja, aki nem, az tanítja ... meg is jöttünk :D)

🍿

Te meg az autószerelő szakmunkás végzettségeddel képzeled magad közénk tartozónak

Sírnak most a diplomás beosztottaim :D

trey @ gépház

Aki benézte, az nem én vagyok, aki 20+ éve használ sikeresen Ubuntu-t személyes és üzleti célokra is, hanem te, aki annyira hülye vagy, hogy nem érted meg, amit levezettem: egy fél éves támogatással rendelkező disztribúció NEM LEHET olyan stabil, mint amit 10+ évig reszelnek és akár 7 point release-t is megér. Mérnök úr: point relese = karantartási kiadás, amiben bugokat és hibákat javítanak. 

Húzz vissza az iskolapadba, lenne még mit tanulnod. Vagy iratkozz be hozzám, majd adok neked a kurzus végén olyan papírt, amivel nem csak a segged törölheted. 

trey @ gépház

Mégiscsak lefordítom, mert láthatóan inkább csak képzeled, hogy érted az angol szöveget de valójában nem érted. 

"Every six months between LTS versions, Canonical publishes an interim release of Ubuntu, with 25.10 being the latest example. These are production-quality releases and are supported for 9 months..."

"Az LTS verziók között félévente a Canonical kiad egy köztes (interim) Ubuntu kiadást, amelyre a 25.10 a legújabb példa. Ezek termelési minőségű (production-quality) kiadások, és 9 hónapig támogatottak..."

még egyszer a forrás: https://ubuntu.com/about/release-cycle

A fentiek alapján én csak azt kérdezném tőled trey hogy szerinted mi garantálja azt hogy hasonló hiba nem fog bekerülni a következő LTS-be?

Az én értelmezésem szerint az LTS annyit garantál hogy az élettartama alatt a csomagokban nem lesz (API) "breaking change".
Pont ilyen bug az simán lehet. 

Hogy ez bekerült a production release-be az nekem a gyenge teszteltséget mutatja.

Ha volna olyan az LTS definíciójában hogy abba olyan csomag nem kerülhet bele ami nem volt benne legalább egy non-LTS-ben előtte, na az már egyfajta minőségbiztosítást tudna adni (inkább folyamat szemléletű mint valódi technikai dehát ez van).

A fentiek alapján én csak azt kérdezném tőled trey hogy szerinted mi garantálja azt hogy hasonló hiba nem fog bekerülni a következő LTS-be?

Ismerve a programozói szakmát, semmilyen garancia nincs arra, hogy egy szoftverbe vagy szoftvergyűjteménybe ne kerüljön be bug. Semmilyen leírt szöveg nem fogja meggátolni. Éppen ezért nem leírt szövegeknek hiszünk, hanem több évtizedes gyakorlati tapasztalatoknak. 

trey @ gépház

Érdekes megközelítés. A mérnöki gyakorlat pont azért támaszkodik a leírt folyamatokra és minőségbiztosításra, mert a hibák elkerülhetetlenek, és kezelni kell őket. De a tapasztalat biztos mindent felülír. A a production quality egy hivatalos definíció, de bízzunk inkább a több évtizedes érzésben, mert a szövegek úgysem számítanak. Világos szakmunkás logika.

Meg hát a a hídépítésben is "több évtizedes gyakorlati tapasztalat", hogy néha-néha összeomlik egy híd, hagyjuk is a statikai számításokat és a szabványokat a fenébe. Úgyis jön a bug. LOL! :-D

A mérnöki gyakorlat pont azért támaszkodik a leírt folyamatokra és minőségbiztosításra, mert a hibák elkerülhetetlenek

Akkor már megvan miért ilyen ócskák a szoftverek.

A a production quality egy hivatalos definíció

Ott leírva inkább nevezném marketingnek. 

mert a szövegek úgysem számítanak

Főleg, ha azok ellentmondanak a gyakorlatnak. 

trey @ gépház

Egy "date" szintű funkcionalitást - különösen ha rendelkezésre áll egy már validált implementáció - triviális letesztelni, fentebb leírtam hogyan.
Azért is tudom ezt biztosan mert nemrégen egy nagyon hasonló feladatom volt és sikeresen megugrottuk.
Még olyan csavar is volt benne hogy a végrehajtott nagyjából 100M teszt során kijött néhányszáz olyan eset aminek alapos vizsgálata során kiderült hogy az új implementáció a helyes és a régi rossz.

Bocs, de most nem írtál semmit, csak visszavonulót fújtál, amit meg is értek. A mérnöki tudományok nem a hitről szólnak, hanem a mérésekről. Én mértem 20 éven keresztül, te meg weboldalon olvasott dolgokból alapítasz egyházat. 

Lehet, hogy mégis nagyobb mérnök vagyok, mint te ... 

trey @ gépház

Vegyük észre hogy a "stabil" szót itt két különböző kontextusban használjuk:

- egyrészt van az API-stabilitás (azaz változatlanság) - ezt ígéri az LTS
- másrészt van a runtime stabilitás (azaz nem-összerohadás) - ezt ígéri a production quality

Elvileg az interim release-nek is production qualitynek kéne lennie, de nem kell adni api-stability-t

Gyakorlatilag az interim release se nem ad runtime stability-t, se nem ad API stability-t

Kiegyezünk ebben a megfogalmazásban?

Sőt, van egy harmadik stabilitás is, mégpedig magának a disztribúciónak a stabilitása. Majdnem azt mondanám, hogy ebből a szempontból szinte csak ez van. A disztribúción belüli program olyan, amilyen - talán az egyetlen elvárás, hogy a disztribúció készítői az upstreamból ne unstable állapotú programokat tegyenek bele, ezen belül az aktuális (nem fejlesztői) upstream simán lehet bugos (sőt, kötelező, elvégre hibátlan program nincs). Az upstream minőségéért a disztribúció karbantartói nem tudnak felelősséget vállalni, legfeljebb azt tudják megcsinálni, hogy ha a program nagyon bugos, vagy bármiért nem illeszthető normálisan a disztribúcióba, akkor kihagyják.

Két cowboy bemegy a kocsmába. Az egyik odasúgja a másiknak:

- Látod ott azt a faszit a pultnál?

- Melyiket?

- Hát ott azt bajszosat!

- De melyiket?

- Hát azt a széles kalaposat

- De hát melyiket?

Erre az első cowboy előkapja a coltjait, és puff-puff-puff. Szépen lelődöz majd' mindenkit a pultnál ülők közül. Majd ezt mondja:

- No látod végre? Azt, aki ülve maradt. No, hogy azt én hogy utálom.

===

(Valamiért ez jutott eszembe. Mondhatták volna azt is, hogy az Ubuntu core nem érintett, minden más meg igen. De nem, e helyett felsorolták a minden mást.)

Kissé meghasonlott vagyok. Egyrészt igen, vicces, másrészt, ahogy a python zen mondja, explicit is better than implicit. Ilyen esetben nem baj ezt így kiírni (de ja, elfért volna egy "vessző a a core nem érintett", de gondolom, aki írta, abban fel sem merül, hogy az elég niece. 

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.

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

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.

Lényegében erről van szó. Ezt még frissességmániásként is elismerem, hogy a fejlesztőkkel elszaladt a ló az utóbbi években, a windows-osokkal is, hogy rohannak az új verzióval, túl gyorsan pörgetik, adják ki szűk határidőkre a félkész hülyeségeket, közben meg a fejlesztőket senki nem hajlandó megbecsülni, megfizetni, erre rájön még az AI-val fejlesztés hanyagsága, ez pedig szépen meg is hozza az eredményét. Inkább fejlesszenek lassabban, legyen csak fele olyan időközönként új verzió, ha nincs kész valami, addig ne adják ki, meg ne erőltessék bele jelentős másik projektbe vagy disztróba. Nincs értelme ennek a kapkodásnak.

Példának tudom hozni a legutóbbi problémás Win11 frissítést, aminél SSD-k tünedeztek el, most így 2 hónap múltán megszűnt a probléma, egy újabb update-tel, de a MS tagadja, hogy bármilyen bug lett volna, a felhasználói SSD-inek firmware-jére és hűtési hibájára mutogatnak. Sose tudjuk meg, hogy mi okozta, zárt kód hátránya.

Ez a 25.10 + uutils fiaskó azért annyival jobb, hogy itt legalább a hibák kitudódnak, és javításra is kerülnek, nincs rejtegetés, titkolózás, másikra mutogatás. A Rust-ot én se szeretem, de itt most nem az volt a ludas mégse, egyszerűen a uutils még nincs kész teljesen, nem áll kész éles bevetésre. Ez akkor is fennállna, ha C-ben vagy C++-ban írnák.

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.”

Annyira nem. Egyébként elírtam, nem becsüli senki a fejlesztőket, helyett nem becsüli senki a tesztelőket akartam írni, csak először elveszett a hozzászólásom, és túl gyorsan gépeltem újra. Régebben a tesztelést sokkal komolyabban vették.

Én azt mondtam régen is, hogy nem jó túl régi verzión lenni. Azt sehol nem mondtam, hogy mindenkinek kötelező a legeslegújabbat használni. Egyes esetekben az is szükséges, csak általános jelleggel nem igaz. Törekedni kell azonban, hogy ne maradjon le túlzottan az ember verzióban, ha már az újabbak ki vannak adva. Az egy teljesen más, amit itt legutóbb írtam, hogy eleve a fejlesztőknek kiadni sem kéne ilyen gyors ütemben.

Még olyan tapasztalt veteránok is beleesnek ebbe a hibába, mint Torvalds, ő is állandóan kapkod az 1 hetes beolvasztási ablakával, amiből surlódás van, hogy nagy kódokat az ablak végén küldenek be. Közben meg csinálhatná, hogy 1 héttel meghosszabbítja, 1 hétig be lehetne küldeni, mint eredetileg, akár a legutolsó napon is, de saját magának utána adna 1 extra hetet, hogy átnézi a beküldéseket, nem kéne kapkodnia. Jó, minden kernelkiadás emiatt 1 héttel később jelenne meg, azon az élete senkinek se fog múlni. Csak hát most divat kapkodni, hama-hama, egy hetet se várhat semmi.

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.”

Ha meg másként csinálná, és tologatná a release ciklusokat, akkor egy másik, hozzád hasonló megmondóember róná fel, hogy beleesett a halogatás hibájába. Nem is tudom, vajon mi lenne, ha elfogadnád, hogy az ő helyzetében ő maga kialakítja, hogy az általa irányított projekt milyen elvek szerint működjön?

Egy nagy projekt esetében mindenképpen ki kell jelölni egyfajta határidőt, és minél szerteágazóbb a projekt, annál inkább ragaszkodni kell hozzá - legalábbis azok felé, akik felelősek is a határidő betartásáért.

Egyszer jó pár évvel ezelőtt voltam egy Solaris koncerten, ha jól rémlik, akkor jelentették be a Marsbéli Krónikák II kiadási dátumát, és akkro hangzott el a zenekar menedzserének a szájából: 'legjobb múzsa a határidő'. Nyilván részben viccnek szánta, de azért van benne igazság, még akkor is, ha a másik dolog, hogy vakon ragaszkodni a határidőhöz akkor is, ha látszik, hogy nem lesz jó az eredmény, szintén hülyeség.

*Rusthoz

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

A rust-coreutilst tákoló elvtársaknak üzenném hogy a legacy rendszerek migrációjához már elég rég feltalálták a "parallel run" intézményét. 
Tehát csak oda kéne rakni a régi "date"-et alá, ráfuttatni a mindenféle input paraméterekre aztán komparálni.
És ha nem azt adja mint a régi akkor javítani kéne.

0.x verzióban nem szégyen az akármekkora méret a régi kód miatt.

Felnézett az óriási arcra. Huszonöt év kellett hozzá, hogy megtanulja, miféle tudás rejtőzik a programnyelv mögött. Ó, kegyetlen, szükségtelen félreértés! Ó, konok, önfejű számkivetés a szerető kebelről! Két ginszagú könnycsepp szivárgott le az orra tövébe. De most már rendben van, minden rendben van, a küzdelemnek vége. Diadalt aratott önmaga fölött. Szerette a Rust-ot.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Blama, de attól még nem kell temetni.

"De legalább memóriát kezelni tudnak... "

Dakota közmondás :D

Na lehet megint jajveszékelni hogy csunyaruuuust elrondiccsa a linugzot.,