Že se při přepisu vytvoří nějaké nové chyby, je úplně normální.
Jistě.
Canonical někdy razantně tlačí své nedodělané alternativy, ale tady mi přijde, že postupují rozumně opatrně.
To ani ne. Naopak, chovají se jako banda dětí, které nikdy nevedli žádný skutečný projekt.
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
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.
Jak jste přišel na to, že to vůbec nefunguje? To, že věci v průběhu vývoje nefungují a musí se dokončit, než se začnou používat, to je normální.
Chápu, že někomu může vadit rychlý vývoj a raději by pomalejší vývoj. Dokonce bych pochopil i kdyby se někdo chtěl vrátit zpět. Ale tenhle přístup „všechno, co vzniklo do doby mé dospělosti je v pořádku a všechno, co se mění od té doby, je už špatně“, ten opravdu nechápu. To vám to není nápadné, že by se celý vývoj lidstva trvající minimálně stovky tisíc let měl zastavit zrovna v době vaší zletilosti? Proč ne o dvacet let dřív? Nebo o sto let, o sto tisíc let? Nebo o sto let později?
Což je ale něco podstatně jiného než „všechno nové je špatně“. Chápu to, že vám to vadí, když to používáte. Ale není to nic, co by bylo specifického pro přepis aplikací – funkcionalita se odstraňuje i v rámci běžného vývoje aplikací. O pár zpráviček níž je informace o odstranění podpory starých síťových ovladačů, ještě o něco níž o odstranění starých protokolů z OpenSSL.
Chápu, že to naštve, když to používáte. Ale zase je to zadarmo a je to opensource – takže pokud chcete někomu nadávat, tak jedině sobě, že to tam nedoimplementujete nebo nezaplatíte někoho, kdo to tam doimplementuje.
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.
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.
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ý.
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.