Názory k článku
Ubuntu 26.10 by mělo plně přejít na Rust Coreutils, vývojáři ladí chyby

Spíš to není tak jednoduché. Starý kód plný technického dluhu se samozřejmě přepisuje. A přepisuje se tak, že se ten starý kód zdokumentuje, pokryje testy a předělává po jednotlivých malých komponentách.
A tady už si můžeme klást otázku, jestli jsou coreutils dostatečně malá komponenta.Nebo jestli by se na to dalo jít ještě po menších kusech.

Souhlasím, že to není tak jednoduché. Však sám Unix byl krátce po svém zrodu přepsán z Assembleru do C. Někteří dokonce doporučují v určité fázi vývoje něčeho nového to celé udělat znovu z jedné vody načisto, ale se zkušenostmi získanými během první fáze. Ovšem v tomto případě se nemohu zbavit dojmu, že ty důvody jsou spíše náboženské než racionální.

Sám jsem se ve své kariéře už setkal s velkým přepisem před 20 lety - šlo o rozsáhlou knihovnu pro simulace a matematické modelování v oboru částicové fyziky GEANT - z FORTRANu 77 do C++. Spousta lidí se tenkrát shodovala na tom, že něco takového si může dovolit dělat jen instituce financovaná ze státních peněz, protože vynaložené úsilí bylo neúměrné benefitům. Argumenty byly tenkrát také ve stylu "Fortran je starý jazyk, C++ je moderní, luxusní, bezpečnější, má objekty..." Moc bych se nedivil, kdyby tam dnes sílily podobné hlasy, jen s/C++/Rust, s/FORTRAN/C++. Přitom moderní Fortran (F90 a výš) by byl býval pro ten účel mnohem přirozenější a vhodnější. Někdy v té době také ve stejné instituci vznikal framework "Root" pro analýzu dat, jenž ke skriptování používá interpretované C++ (jeho uživatelé se na tento framework obyčejně odkazovali jako na "froot" = fu..ing root). Zkrátka C++ bylo tenkrát velice v módě a každý měl potřebu všude vidět třídy a objekty - většinou bohužel špatně, což nám zůstalo do dnešních dnů.

V zásadě mně asi žíly netrhá, když někdo pociťuje nepřekonatelné nutkání programovat v Rustu, ale protože ho nenapadá nic nového užitečného, co by mohl vytvořit, tak přepisuje existující věci. Asi jako když někdo překládá Shakespeara do klingonštiny. Vadit mi to začne, až když mě někdo začne nutit tou klingonštinou mluvit.

Změnilo se toho hodně (LLM nástroje pro práci s kódem kupříkladu asi úplně nebyly, že?) Navíc ty uvdené případy nejsou úplně srovnatelné s přepisem Coreutils, už jenom kvůli těm byznys rozdílům).

Ono to „rozhodnutí“ o neudržování často není vědomé rozhodnutí, spíš ta údržba tak nějak vyšumí. Každopádně pokud jsou ty staré nástroje udržované, včetně balíčků, není přece problém si je do Ubuntu nainstalovat.

Vynechána není polovina, a Canonical se pro přechod rozhodl z důvodu, že u těch nových nástrojů očekává v budoucnu méně chyb a snazší údržbu a rozvoj.

Jo nemůžu se dočkat až se to jednou přepíše <absurdní nadsázka> do nodejs+TypeScript nebo do Electronu</absurdní nadsázka>.

Přijde mi, že hlavním lákadlem pro Canonical je spíš licence: MIT. Oni čistou GPL nemají moc rádi. Buď mají projekty s GPL + contributor agreement, kde mají výhradní právo přelicencování, nebo MIT. V obou případech jde o mít možnost to vydat pod uzavřenou licencí a je to hlavně proto, že je to atraktivní pro investory.

Už to tu někdo zmiňoval jako že tohle je ta motivace (a jinak to nedává smysl), ale moc se mi to nezdá, byť samozřejmě Canonicalu do hlavy nevidím(e).
Z hlediska celého systému (produktu) jsou tohle relativně minoritní a obecné komponenty, pokud by někdo v budoucnu řešil např. uzavření jejich vývoje, nějaké proprietární modifikace atp.
Jinými slovy, dokážu si představit jaké možnosti pro firmu otevře např. CLA přílepek u specifických věcí jako je LXD, Snapcraft atp., ale moc mi tohle nedává smysl u coreutils (Máme pro vás lepší, proprietární verzi md5sum s fíčurami navíc).
Navíc ty uutils/coreutils existovaly už předtím, než se do toho Canonical vůbec zapojil, co jsem koukal, tak první commity jsou z roku 2013. Permisivní licence (MIT, Apache 2.0) jsou v podstatě standardní záležitostí u valné většiny rustových knihoven/bedýnek, které se pak při sestavení staticky linkují. Tady jich jsou použité stovky. A zas pak není úplně nezvyklé, že pokud je výsledný nástroj otevřený tak také převezme tu MIT licenci.

Pokud je to kvůli licenci, proč stejně nepreferují ZSH na úkor BASH jako macOS, který je na tom co se týká afinity k licencím stejně.

protože se navenek chovají hodně jinak?

toto uz jsem parkrat cetl a videl i na YT; v podstate je to trosku parazitovani na casu lidi, co to pisou.

Petre (Jirko, Davide) - toto je tema na dobry clanek

Neni problem nainstalovat starsi balicky, ale jen docasne, kdyz Canonical avizoval, ze puvodni sudo uz asi v pristi verzi vyjmou z repo. Coz mi prijde divne a uspechane, protoze jsem prave zjistil, ze nefunguje ani Ansible, coz fakt neni okrajova zalezitost a resi se to uz pul roku.

Kde to prosím avizovali? Nemůžu ty zmínky najít, díky.

Neni problem nainstalovat starsi balicky, ale jen docasne, kdyz Canonical avizoval, ze puvodni sudo uz asi v pristi verzi vyjmou z repo.
To je takový problém používat balíčky mimo oficiální distribuční repository? Připadá mi zvláštní chtít po někom jiném, aby pro mne zadarmo udržoval nějakou okrajovou funkcionalitu, a zároveň se tvářit, že použít balíček mimo oficiální distribuční repository je pro mne moc práce.

Ale jestli Canonicalu platíte za nějaké zajímavé množství licencí, určitě pro vás ten původní balíček budou rádi udržovat.

Vy jste s tím opakováním toho, že chci něco zadarmo naprosto neuvěřitelný. Něco dlouho fungovalo a Canonical se rozhodl to změnit, když ten produkt za který to nahrazuje ještě ani není finální, takže to co já potřebuji bude možná doděláno.

Nedává mi smysl co dělají, ale nevyčítám jim to, zcela očividně se snažím najít nějaké řešení a prostě o tom tlachám v diskusi, abych se třeba něco nového dozvěděl. Jestli něčemu něco fakt nepomůže, jsou to vaše žvásty pořád dokola, že chci něco od někoho zadarmo, váš přínos v té diskusi je naprosto záporný.

Vy jste s tím opakováním toho, že chci něco zadarmo naprosto neuvěřitelný.
Ono je potřeba to opakovat. protože zpočátku je člověk vděčný, že něco dostává zadarmo. A když se to pořád opakuje, tak si na to zvykne. A když si zvykne, získá dojem, že na to vlastně má nárok.

nevyčítám jim to
Asi jsem četl jiné komentáře.

Jestli něčemu něco fakt nepomůže, jsou to vaše žvásty pořád dokola, že chci něco od někoho zadarmo, váš přínos v té diskusi je naprosto záporný.
Díky mně jste zjistil, že tu funkcionalitu můžete do Rust Coreutils doimplementovat (pokud o to budou mít správci zájem), můžete zaplati někoho, kdo to implementuje, nebo můžete použít balíček mimo distribuci. Tj. máte k dispozici i jiná řešení než čekat, až to vyřeší někdo jiný.

Psal jsem například: "A teď co s tím, zatím vynucuji zpět původní sudo, tak to jsem z toho vyšel úplně super."

to není výkřik, že by to za mě měli hned vyřešit, ne?

Jádro toho, na co jsem reagoval, je citované před mou reakcí.

No, podle jejich issue trackeru je za tím jasné rozhodnutí nepřidávat do jejich implementace sudo LDAP.

To nevím, jestli přímo souvisí s tím problémem, co zmiňoval. Sám jsem sudo-rs ještě nezkoušel, ale mělo by implementovat standardní rozhraní přes NSS (pravidla) a PAM (ověření). Tam jsou při použití SSSD normálně registrované knihovny a udělají ten potřebný lookup v LDAP, resp. Kerberu.
Přímý přístup ze sudo do LDAP serveru a schémat je trochu legacy věc, kterou si to nese z minulosti a případně systémů, které právě neměly vrstvy jako PAM a SSSD, co řeší i cachování, validitu atp. Co si pamatuju, tak i u další alternativních implementací suda jako např. doas (opendoas) bylo tohle přesně první, co se řešilo, že nebudou implementovat (spousta kódu, větší attack surface, funkcionalita by měla být řešena jinde).

Nejsem si tím ještě úplně jist, teprve jsem se v tom začal hrabat, ale nejde přímo o LDAP implementaci – tu řeší SSSD.

Sudo si pak přes NSS bere data ze SSSD. FreeIPA používá policy, která SSSD poskytuje.

Problém sudo-rs je spíš v tom, že zatím neumí použít NSS/SSSD backend pro sudo rules, což by neměl být tak složitý krok.

Velké množství změn, ne-li většina, znamená krátkodobé zhoršení situace (když nic jiného, tak samotná změna je starost navíc). Ale dělá se s výhledem, že dlouhodobě bude ta změna výhodná.

kromě toho, že by to mělo být bezpečnější, protože Rust je navržen bezpečnějším způsobem)
To ale samozřejmě není jediný důvod přechodu.Je to lepší a udržovatelnější také proto, že se to píše o desítky let později, s novými znalostmi. Zároveň je možné odstranit staré a málo používané funkce. Ono by to bylo lepší, i kdyby se to znovu napsalo v C – Rust je použit jenom proto, že proč ho nepoužít místo C, když už ho máme k dispozici. Jinak ale není hlavním účelem přepsat to do Rustu, ale napsat to podle současných znalostí. Rust je jen důsledek.

Jenže se obávám, že na tuhle změnu ještě správný čas nenazrál.
Jak píšete: samotná změna je starost navíc. Tak by se měla dělat až ve chvíli, kdy je nové řešení znatelně lepší, než to původní.
Kdyby k ní došlo až s odladěnými a funkčně shodnými utilitami, případně kdyby v původní variantě byla závažná chyba, kterou je jednoduché napravit právě tím přechodem, pak by to dávalo smysl.

To nejde. Bez zpětné vazby nezjistíte, jaké jsou tam chyby nebo co z toho, co uživatelé reálně používají, tam chybí.

Jenže takhle si vysloužíte jen zděšení a zavržení.
Celkové odsuzování tomu vylepšování moc nepomůže - to není vhodná zpětná vazba.

Já osobně proti tomu nahrazování v podstatě nic nemám, je mi celkem jedno, v čem byly ty utility naprogramované, pokud budou fungovat tak, jak mají, jak jsem zvyklý.
Jenže i já narazil na nekompatibilitu sudo-rs, kterou snadno a rychle vyřešilo nahrazení původním sudo. Problém je, že takhle ze mne žádnou další zpětnou vazbu nedostanou...

Jenže takhle si vysloužíte jen zděšení a zavržení.
Nikoli, tohle je jediná cesta, jak se posunout vpřed. Bylo to tak se vším – Wayland, systemd, btrfs…

Celkové odsuzování tomu vylepšování moc nepomůže - to není vhodná zpětná vazba.
Ano, celkové odsuzování ničemu nepomůže, není to vhodná zpětná vazba. Proto taky všichni celkové odsuzování ignorují. To, že se o tom hádá pár lidí v diskusi na Rootu nebo Redditu je vývojářům upřímně jedno.

Problém je, že takhle ze mne žádnou další zpětnou vazbu nedostanou...
Možná to problém je, ale rozhodně to není problém autorů sudo-rs.

Je mnohem lepší kráčet vpřed malými krůčky, než se rychle vrhnout do neviděné propasti. (Autora neznám, je to parafráze a nedaří se mi najít zdroj.)

Jak dlouho se prosazuje Wayland? A i to mi přijde příliš rychle!
U toho systemd šlo o výraznou změnu kvality, celého přístupu.
A btrfs je prostě další filesystém k použití, a neřekl bych, že by se nějak překotně cpal jako výchozí v distribucích.
Tohle mi spíš připomíná nucenou elektromobilitu nebo nahrazování žárovek LED zářivkami - v obou případech byl (je) zcela bezohledně prosazováno nové - lepší - řešení ještě ve chvíli, kdy vlastně není lepší.
Skoro bych se bál, že nám ty rustové coreutils taky nařídí EU. ;D

Pořád platí, co jsem psal na začátku – kdyby se ta nová řešení neprosazovala na váš vkus moc rychle, pořád bychom se trápili s těmi starými řešeními a přechodovými stavy. Jako u IPv6.

Ta řešení se mají prosadit sama, protože jsou lepší.
Ne nuceně, protože někdo rozhodl, že jsou lepší.

Ubuntu vás nikdo nenutí používat.

Vsak sa presadzuju "same", pretoze su lepsie...

Problemom su sietove efekty. Vyvojari svoje aplikacie neupdatuju, pretoze "na ubuntu to funguje". Ubuntu dlho ignorovalo wayland, pretoze "aplikacie nie su pripravene". Velmi dlho trvalo pochopit, ze aplikacie _nikdy_ nebudu pripravene, pokial nebudu musiet. Preto Redhat je od RHEL10 wayland only a Ubuntu nasledovalo. Inak by to bolo cakanie na Godota. No a vdaka tomuto tlaku je podpora uz aj v Chrome a Electrone, (takze Cisco moze updatnut Webex niekedy v nasledujucich 10 rokoch).

Vid tiez Apple. Ukaze roadmapu, povie, ze technologia X je od release Y deprecated a od release Z odstranena. Kto si dovtedy aplikaciu neupdatne potom uz nepobezi. A preto vie robit rozvoj rychlejsie.

Zrovna třeba to, že to nefunguje s Ansiblem by se asi dalo vyřešit dřív, než se to dá k testování lidem.

Všechno by se asi dalo vyřešit dřív, než se to dá k testování lidem. Otázka je, jestli by to byl nejlepší postup.

Souhlas. Ale jak už jsem tu několikrát zmiňoval, oni se v tomhle případě spíš přizpůsobili tomu ekosystému Rustích crates, které jsou vesměs všechny pod tou MIT/Apache licencí. Spousty z nich tam používají. Naopak je zas možné použít v jiných projektech funkcionalitu (třeba různé abstrakce napříč operačními systémy) z knihovny uucore https://crates.io/crates/uucore z uutils-coreutils. Tam pak samozřejmě to, že to není pod restriktivní copyleft licencí, může být pro ostatní projekty výhoda.

Jinak co se týká té další povinnosti z GPL vyplývající, tzn. poskytnutí zdrojových kódů uživateli i když tam nedělám žádné změny a jen to sestavím do binární podoby.
Tam by ten benefit pro nějaký komerční produkt, výrobce by podle mě byl pouze v případě, že by ty GNU Coreutils byl ten poslední komponent, co by tímhle způsobem musel řešit.
Protože jakmile tam bude ještě cokoliv dalšího s copyleft licencí, tak už stejně musím mít nachystaný nějaký přístupný repozitář, tarball, kde budou všechny zdrojáky, build skripty a ideálně i nějakou automatizaci (skript, CD úlohu), co to vyplivne po každém releasu. A pak už je mi vcelku jedno, jestli tam bude třeba kernel, out-of-tree moduly, glibc, util-linux, iproute.. nebo tam bude navíc ještě GNU Coreutils, klidně tam můžu přibalit i ty věci, co vyloženě nemusím (sudo, ntpd, OpenLDAP s permissive licencemi).
To je třeba z pohledu výrobce routeru, embedded zařízení, aplikace co se distribuuje s VM, kde mám systém from scratch.
Jinak ještě častější budou nejspíš případy, kdy je systém, příp. kontejner s proprietární aplikací založený na nějaké existující hotové distribuci. Pak bych měl zrcadlo se zdrojovými balíčky od toho, co je tam použité. A zas by mě nevytrhlo, jestli tam bude jeden z nich s GPL, BSD nebo MIT licencí.

Takže to je důvod, proč to osobně rozlišuju a spíš bych měl o licenci starost, kdyby se jednalo o produkt, co by se dal snadno uzavřít a monetizovat.
Plus samozřejmě pokud už se chce někdo vyloženě vyhnout copyleft licencím pro podobné multicall nástroje v userspace a má třeba nějaký uzavřený embedded systém, tak už roky může použít např. toybox (jako busybox pod MIT, používá se třeba v Androidu), nemusí čekat, až to někdo přepíše v Rustu. Stejně jako může svoje proprietární nástroje staticky linkovat s MUSL, který je také s MIT licencí.