Vlákno názorů k článku
Ubuntu 26.10 by mělo plně přejít na Rust Coreutils, vývojáři ladí chyby od heslokreslo - Sice to vůbec nefunguje, ale my to jednoduše...

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.