Megjelent a Rust-ban írt Coreutils helyettesítő 0.1-es kiadása

Szerszám

Megjelent a Rust Coreutils 0.1-es kiadása. Sebessége párban van, néhol gyorsabb mint a Linux világban mindenütt jelen levő GNU Coreutils. Hogy mennyire nem csupán egy l'art pour l'art kezdeményezésről van szó, az Ubuntu projekt azt tervezi, hogy alapértelmezetten szállítja majd az ősszel megjelenő Ubuntu 25.10-ben ...

Starting with Ubuntu 25.10, my goal is to adopt some of these modern implementations as the default. My immediate goal is to make uutils’ coreutils implementation the default in Ubuntu 25.10, and subsequently in our next Long Term Support (LTS) release, Ubuntu 26.04 LTS, if the conditions are right.

Részletek itt.

( NevemTeve | 2025. 05. 25., v – 08:39 )

Akkor mostantól systemd és rust nélküli disztróra kell guglizni. Ja és AI nélküli.

Sajnos sok olyan dologra is költöttek abból a lóvéból, ami faszság. Miért kell újra feltalálni a kereket (pl: Btrfs)? Aztán 10-15 év alatt rájönnek, hogy hoppá, a DEC / Sun már megoldotta azt a problémát, csak alkalmazni kellene azt a technikát. Lásd: ZFS.
Írhatnék akár a Solaris zone-ról is. Nyilván ez nem Docker - picit másra való.

A ZFS sokáig nem úgy nézett ki, hogy full featured supportálva lesz. Talán most se teljes a supportja a kernelben, de fixme. Licensz vonatkozásában szintén nem merültem el a részletekben, talán ott is adódhat probléma.
btrfs koncepciója így alapvetően imho nem volt fasság. Igény az lenne rá.

Ettől függetlenül igen, biztosan költöttek fasságra is a lóvéból. Számomra az egyik legfájdalmasabb a systemd volt. El kellett volna kerülni.

Mindez nem változtat azon, hogy bsd-vel könnyen megszopod egy egyszerű driver támogatással. Szervernek még csak-csak, de desktop-ra kb. olyan, mint a linux volt 25 éve: válogatni kell hozzá a hw-t. Ami laptop-nál eleve kötöttebb.
Először 2004-ben szerettem volna freebsd-t tenni egy akkor csúcs laptopra. Hamar rájöttem, hogy nem lesz wifim, nem lesz hangom. Végül gentoo lett a gépen.
2022-ben futottam neki utoljára a freebsd-s laptop koncepciójának, nem sokkal több sikerrel. Biztosan találnék olyan vasat, ha direkt keresnék, amivel minimalizálható a szopás, de ennyit nekem nem ér meg. Túl kényelmes lett az élet linux-szal, minden fasságával együtt is.

Sokak csalódottságának oka szerintem az irreális elvárásokban gyökerezik, és a dolgok okának meg nem értésében. A linux már rég túl van azon a korszakán - annak minden előnyével és hátrányával -, hogy a lelkes community reszelgeti meg veregeti bele a faszát, meg hogy színtiszta elvek mentén megy a fejlesztés. Aki ezt az utóbbi élményt keresi, annak tényleg ott a bsd.

Meglátjuk.

gcc is lett kb. mindenre. Amire nem, arra kiderült, hogy nem is igazán kell.
Ma se igazán buzulunk már 68k-val.
Meg aztán az egzotikus platform mindig is szopás volt. A c-s világban is.

Meg a rust-os coreutils nem azt jelenti, hogy ezentúl nem lesz karban tarta az eredeti c-s forráskód. Egyelőre még messze preview fázisban van, soká fog ez még prod-ban megjelenni.
Szerintem szabadjon ilyeneket csinálni. Aztán az idő majd úgyis eldönti, mire van igény és mire nincs.

Meg azért legyünk reálisak. Van két platform ami lefedi a világ 99%-át. Az egyik az x86, a másik pedig az arm. Minden más vagy azért nem releváns mert nem gnu-s cuccokat futtatnak rajta vagy pedig azért mert a valóságban kutyát se érdekel.

Emlékszem amikor komplett Sun Solaris gépek mentek a zúzdába, rack-estül, mindenestül.

Akkor mostantól systemd és

Hu de utalom a systemd-t. Amitol a windows windows, az szamomra  a registry. A systemd ezt az "elmenyt" hozza.

Alap szerver es desktop usecase eseten kb. nincs is bajom (mivel nemigen kell hozzanyulni), de mostanaban embedded kornyezetben is mozgolodok.

Embedded Linux: random gyarto adott ubuntut addig kokanyol míg elindul.

Ilyen kornyezetben valamihez systemd kelljen, noh, hat isten ovjon.

Kar, hogy ez terjedt el. Kene egy normalisabb valtozat, ami azt a par usecaset lefedi ami miatt eletrekelt, de ugyanakkor nem egy nagy blob hatasat kelti, amihez, mint buddhahoz lehet fordulni, ha valami egyedit szeretnél.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Felreertetted: hozza kell nyulni a systemd-hez, valamit pluszba be kell tenni (pl. gpio pinek ujramappelese, pinek ujradefinialasa (pl. pwm pin)).

Egyaltalan dolgozni kell a systemdvel, mig desktopon es serveren ez nagyon marginalis, kb. sose kell, igy nem is zavar senkit se a systemd hulyesegei.

 

Kb. ugy kell elkepzelni, mint windows eseteben. Amig nem kell a registryben turkalni, addig kb. mindenki semlegesen all hozza, sot valaki azt mondja, hogy milyen jo, hogy minden egy helyen van, de fasza igy.

Aztan amikor konyekig a szarban turkalsz, es kb. realizalod, hogy egy allapotgep belsejeben random valtozokat allitgatsz at, akkor felfordul a gyomrod.

No a systemdvel kb. ugyanez a helyzet.

 

De mondhatnam a szaros 127.0.0.57 dns-et. Multkor nem oldotta fel a helyi halon a gep nevet, valahogy mar abba is fixen be lett drotozva a 8.8.8.8 (de ez csak megerzes).

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Jah tipikus server usecase, amire ki lett talalva. Persze a bugok joresze (kenyszerusegbol) ott fixalva van.

Barhol elakadsz van kismillio talalat *pont a te problemadra* a neten, vagy chatgpt *elsore* kidobja a jo .service fajlt.

 

Azert regen beleneztel a shell scriptbe, es irtal egy sajatot olyan usecasera amilyenre akartal.

Ertem, hogy az nem volt eleg, es lepni kellett. De ez egy kokanyda. Minden nezopontbol.

 

Persze lehet valtani mashova, csak akkor ertened kell a systemd-hez is (mert az van kb. mindenhol), es a sajat egyedi cuccodhoz is (pl. runit), es utana kb. egymagad vagy a vilag ellen. Mindegy. Tul van ez mar magyarazva. Eppen mukodo cucc a kerekotoje az elegans megoldasnak.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Jah tipikus server usecase, amire ki lett talalva. 

Akkor mi a gond ? Az hogy, random gyártó embedded systemd -t rak, nem a systemd baja. Rakhatna openwrt -t is, mert abban nincsen systemd, és elég embedded.

Tehát megint itt vagyunk: https://hup.hu/comment/3190140#comment-3190140  

Azaz neked max az nem tetszik, hogy a kókány gyártó, kókány szarjában, kókányolt dolgok szarul mennek, és neked is kókányolni kell ...

Hihetetlen ...

Fedora 41, Thinkpad x280

meg 1x: desktop es server usecasere jo, mert valaki mar belefutott elotted a bugjaba.

Barmi egyedit szeretnél, akkor belefutsz valami kokany korlatozo szarba.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"tipikus server usecase, amire ki lett talalva. Persze a bugok joresze (kenyszerusegbol) ott fixalva van."

Lófaszt van fixálva... Szépen backward-kompatibilisen őrizgetve vannak a bugok is. A systemd-notify - ami egy igen kifejezetten szerver-oldali use-case-re van - pl kezdetektől fogva (15 éve) szar és szerintem már úgy is marad. Az van, hogy a package maintainer-ek megtanulták, hogy mik azok a funkciók, amiket kerülni kell.

Meg megszokták az emberek, hogy ilyen szép egysoros-ostorosok kellenek, ha azt szeretnéd, hogy a service-ek közötti függőségek rendesen menjenek:

ExecStartPost=/bin/bash -c 'for ((I=60; I>0; I--)); do echo "Waiting for healthcheck on localhost:8443, Remaining attempts: $$I"; [ "Ready" == "`curl --silent --fail --connect-timeout 2 http://localhost:8443/healthcheck`" ] && exit 0; sleep 1; done; echo "Timed out waiting for Ready"; exit 1'

Tipikusan szerver-oldali dolog az is ha valami HA clusteringet használsz (pl pacemaker/corosync), na ott kb az első dolog, hogy a systemd-t eltakarítod útból és a clusterezett service-t teljesen kiveszed a systemd felügyelete alól.

A systemd-resolved is egy nagy bajforrás szerver oldalon is.

Régóta vágyok én, az androidok mezonkincsére már!

Például mert +1 problémaforrás. De felőlem attól még csinálhatnának benne nagyszerű új dolgokat. (Mondjuk még okosabb mesterséges intelligenciát, amelyik a megfelelő eszközökkel összekapcsolva megszabadítja a Földet a legsúlyosabb gondjától. Ja, hogy az pont mi vagyunk. Pech.)

Nekem itt főleg az előítéletekkel van bajom. Ha valami szar, lehet kritizálni. De itt még nem is tartunk. Arról szól a hír, hogy a 0.1-es verzió mostanra lefordul. A nélkül születnek itt a vélemények, hogy egyáltalán ezt valaki kipróbálta vagy megnézte volna. Mert ha rust, akkor biztos csak szar lehet. Gyakran olyan emberek szerint, akik gyanús, hogy nem programoztak soha c-ben sem.

Van mögötte egy koncepció és egy várt benefit. Valakinél úgy jött ki a matek, hogy érdemes belevágni, lesz megtérülése. Az idő majd eldönti, bejött-e.

Lehet tőlem JavaScript-ben újraírt bash-t is csinálni, ha valaki úgy ítéli meg, hogy számára lehet ebben benefit. Aztán majd kiderül, hogy mások számára is hasznos-e. Lehet persze zéró ismerettel, elfogultsággal is hozzáállni ezekhez a kérdésekhez. Csak ennek a hőbörgésen kívül nem látom más célját.

( Fisher v | 2025. 05. 25., v – 09:40 )

Hurrá, akkor már nem kell sokat várni az első új ls vagy seq bugra.

Minél magasabb szintű eszközök, minél közelebb a felhasználóhoz és az internethez (webes alkalmazás hívogatja valamelyik parancsot a háttérben), annál fontosabb, hogy a memóriakezelési gixereket ki lehessen küszöbölni. Persze ott van, hogy még ez sem elég az üdvösséghez, van sok más hibaforrás és jobban bízhat a fejlesztő egy már jól bejáratott eszközben, mint egy frissen újraírtban.

( egmont | 2025. 05. 25., v – 20:58 )

Új coreutils release-nél át szoktam futni a NEWS fájlt. A csomagban és elődeiben 30+ éve reszelgetik a speciálisabbnál speciálisabb esetek kezelését, hogy minden úgy menjen, ahogy a felhasználó várná. A legritkább esetben, ha egyáltalán, javítanak olyasmi hibát, ami a Rust nyelv természeténél fogva abban elő sem fordulhatott volna. Egy friss, Rust-ban újraírástól biztos jobb lesz.

( Raynes v | 2025. 05. 29., cs – 00:43 )

Nekem nem lenne bajom, hogy létezik egy ilyen rust-os coreutils-alternatíva, más licenccel. Lehetnek projektek, amibe egynek elmegy.

A Canonicaltól megint vakmerő, hogy beleerőlteti az egyik legmainstreamebb disztróba, holott még nem 100%-ban kompatibilis a GNU coreutils-szal, ami eltörhet szkripteket. Tipikus Canonical-féle bajkeverés, erőszakos „innoválás”, hogy valamivel kitűnjenek (mint előtte az upstart, Mir, Unity DE), most meg a Snap erőltetése, illetve az uutils bevezetése, meg 25.04-től /run/utmp kiszedése, ami eltör néhány klasszik toolt (w, who parancsok), illetve a cpufreq scaling kiszedése a sysfs-ből, hogy csak systemd-n keresztül lehessen állítani. Ráadásul ezzel nem csak a saját felhasználóikat szivatják meg, hanem a sok Ubuntu-ra épülő disztróval is kitosznak.

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

Lehet, hogy csak nem a megfelelő disztrót használod.

Technikai oldalról magam sem értek egyet az általad említett döntésekkel, ugyanakkor megértem őket. Nálunk is az van, hogy ha kitalálunk valami újat, bele kell tenni éles termékbe, különben soha nem lesz rendesen kipróbálva, tesztelve. That's life.

Meglátásom szerint a Canonical eleve nem azokat tekinti az Ubuntu célcsoportjának, akik egyáltalán tudják, mi a sysfs.
Vannak all-about-choice disztrók is. Ez nem tartozik közéjük. ¯\_(ツ)_/¯

Félreértetted, én nem használok Ubuntut, pont az ilyenek miatt, de hallom mások panaszkodásából, hogy épp miket zúdít rá a Canonical a felhasználókra. Nagyon nem kéne őket szopatni. A Linux még nincs annyira elterjedve, még nem akkora fokú vele szemben a bizalom, hogy ennyire meg lehessen ingatni. Azért lenne, ha Canonical kicsit óvatosabb lenne.

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

Vagy észre kellene venni, hogy nem az Ubuntu az egyetlen desktop linux.
Gentoo-t tizenöt éven keresztül használtam. Imádtam. Tényleg igaz volt a szlogenjük: gentoo is all about choice.
Igaz, egységsugarú júzernek nem ajánlanám. De van arch, van debian.
Ezt a nagy DE-buzériát meg pláne nem értem. Egy fluxbox-nál többre valójában nincsen szükség.

Igen, én is a minimalista rendszer híve vagyok, standalone WM, stb.. Én sem használnék Ubuntut, sem annak származékát, de azt kell érteni, hogy ezek népszerűek, sok embernek az Ubuntu=Linux, és ha Shuttleworh-ék erőltetik ezeket a hülyeségeket, eljátsszák a bizalmat a Linuxszal szemben. Sok user eleve ezért hagyná ott a WIndowst, mert ott a MS szivat ilyenekkel mindenkit, átnyergelnek Linuxra, ahol a Canonical jóvoltjából szintén azt látják, hogy a multi szopat, csak máshogyan, akkor szerinted mire fognak következtetni? Elárulom, hogy nem arra, hogy akkor váltanak Gentoo + fluxboxra, hanem jegelik a Linuxot egy életre, elkönyvelik, hogy egy szar, és pattintják is vissza a Windowst.

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

Engem is, de sajnos mindig lesznek ilyenek, és nem lehet nekik elmagyarázni, hogy ez nem igaz. A média, meg a közösségi média hatása.

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