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 kutil domácí - Funguje / nefunguje to je jen část problému. Mnohem...

  • Článek je starý, nové názory již nelze přidávat.
  • 24. 4. 2026 11:46

    kutil domácí

    Funguje / nefunguje to je jen část problému.

    Mnohem větší problém je (nikoli pro korporace, které to vnucují), že to není pod GPL licencí, rezivé Coreutils jsou pod MIT licencí.

    Osobně preferuji GPL kdekoli to jen jde. Chci skutečně svobodný software, který nemohou korporace sežrat a ukrást pro sebe.

  • 24. 4. 2026 12:58

    Michal Šmucr
    Stříbrný podporovatel

    Osobně preferuji GPL kdekoli to jen jde. Chci skutečně svobodný software, který nemohou korporace sežrat a ukrást pro sebe.

    Já to chápu jako principiální postoj, stejně jako si dovedu představit, že někdo např. ze stejných důvodů v určitém projektu nepoužije třeba LLVM/Clang a bude to vyvíjet a podporovat sestavování jen s GCC.
    Ale v tomhle konkrétním případě, prakticky vzato bych si spíš pokládal otázku, co by korporace získaly uzavřeným vývojem svých Coreutils nebo suda? A jinak mimochodem to původní sudo mělo ISC licenci (víceméně jako BSD) a nikdo se nad tím, minimálně veřejně, ani nepozastavil.

  • 24. 4. 2026 20:45

    kutil domácí

    Ale v tomhle konkrétním případě, prakticky vzato bych si spíš pokládal otázku, co by korporace získaly uzavřeným vývojem svých Coreutils nebo suda?

    A z jakého jiného důvodu Coreutils přepisují?

    Dělají to protože Rust je memory safe? Určitě? S kompilerem jazyka, který se programátorům údajně mění pod rukama? Nebylo by lepší jít cestou memory safe C kompileru, který už, možná jako reakce na Rust, taky vzniká? Nebylo by mnohem snazší důkladněji auditovat GNU Coreutils?

    A pokud jde o bezpečnost, proč se to snaží tak moc uspěchat? Nevyzkoušený kód přináší, kromě nedoladěnosti očividně i bezpečnostní rizika. Viz report přímo od Ubuntu https://discourse.ubuntu.com/t/an-update-on-rust-coreutils/80773

    A pokud to dělají kvůli licenci, co přesně tím sledují? Co jim MIT licence přinese? MIT licence neukládá povinnost zveřejnit zdrojáky k distribuovaným binárkám. MIT licence dovoluje přidat kód z takto licencovaného programu do komerčního uzavřeného software. Možná se tak nestane (brzy) v Ubuntu. Ale je toto cíl? Mít k dispozici uzavřitelné utility kompatibilní s GNU Coreutils?

    Těžko zpochybnit, že to budí podezření.

    Nechce se mi věřit, že to je jenom Rust fanatismus i když toho je tam asi taky vrchovatě.

  • 24. 4. 2026 21:32

    Ondra Satai Nekola
    Zlatý podporovatel

    Mozna nejdriv zjistit, ze na velkou cast tvych recnickych otazek je docela prijatelna realna odpoved?

  • 24. 4. 2026 21:53

    Filip Jirsák
    Stříbrný podporovatel

    Shodou okolností je na všechny kutilovy víceslovné zjišťovací otázky odpověď „ne“.

  • 24. 4. 2026 22:49

    Michal Šmucr
    Stříbrný podporovatel


    A pokud to dělají kvůli licenci, co přesně tím sledují? Co jim MIT licence přinese? MIT licence neukládá povinnost zveřejnit zdrojáky k distribuovaným binárkám. MIT licence dovoluje přidat kód z takto licencovaného programu do komerčního uzavřeného software. Možná se tak nestane (brzy) v Ubuntu. Ale je toto cíl? Mít k dispozici uzavřitelné utility kompatibilní s GNU Coreutils?

    To se mi jako motivace opravdu zdá jako blbost. Co by komerční firmy získaly tím, že projekt typu Coreutils si budou moct forknout, vyvíjet nějakou proprietární verzi a nevracet to do projektu. Není případné změny jednodušší prostě upstreamovat? Chápu tohle třeba u nějakých serverových produktů, databází atp. kde můžu mít třeba nějaký otevřený základ a pak prodávat i odvozené verze za peníze, případně omezit komerční užití. Nedovedu si upřimně představit monetizaci Coreutils.
    Navíc to pozadí, proč je to pod MIT/Apache 2.0 a to že tohle mají ty linkované crates, co to používá, jsem tu psal v jiném postu.
    A stran ostatních produktů pod podobnými licencemi, mimo původního suda a ntp, tak třeba OpenSSH nebo OpenSSL taky nejsou pod GPL. Jsou to všechno důležité komponenty, najdete je skoro v každé linuxové distribuci už roky.

    Fakt nevím, ale občas mi to přijde ta snaha vidět vždycky za roh trochu přehnaná.
    Sami autoři ty důvody píšou vcelku jasně.. https://uutils.github.io/
    A ano téměř hned se typicky projeví hromada rozumbradů.. co všechny důvody stejně zpochybní a nabídnou své vysvětlení nebo technický rozbor (Cabal, Rust sekta.. anti-GPL.. přeci nejsou tak pitomý, stejně to neřeší 100% chyb, já sám chyby v C nikdy nedělám, navíc jsem si tohle vyřešil už před 30 lety - podívej se do adresáře utils na gizmo_alloc.c, gizmo_threads.c takže.. atd :)

    Ten projekt začal už před víc než deseti lety a na začátku byli nejspíš opravdu nadšenci. Pak se to s pokračujícím vývojem možná zalíbilo i Canonicalu a sponzorům.
    Jinak chápu, pro někoho to výchozí nasazení do distribuce může být předčasné. Zas si myslím, že se na tom dají najít i světlé stránky, protože měli jasný deadline, dostalo to vcelku velkou expozici, nechali si udělat ty zmíněné analýzy a můžou spousty věcí relativně rychle dotáhnout, což bude benefitem pro všechny uživatele projektu.

  • 25. 4. 2026 8:25

    Filip Jirsák
    Stříbrný podporovatel

    Problém s GPL licencí není přímo u samotného díla, ale spíš u děl odvozených. Udělat proprietární verzi Coreutils moc smysl nedává. Mít možnost udělat systém pro podnikové přihlašování a správu (obdobu Active DIrectory od Microsoftu) a propojit to i se sudo a dalšími utilitami, aniž bych to jako odvozené dílo musel zveřejňovat pod GPL, to smysl dává. Nemusí to být v tuto chvíli konkrétní plán. Je to prostě jen nezavření si té možnosti. A třeba důvod, proč Canonicalu dává smysl zrovna tenhle projekt podpořit.

    Nemyslím si, že Rust Coreutils vznikly kvůli změně licence. Ale chápu, že když se zbavují staré zátěže, zbaví se i GPL. (Sic!)

  • 26. 4. 2026 15:19

    Michal Šmucr
    Stříbrný podporovatel

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

  • 24. 4. 2026 15:47

    Filip Jirsák
    Stříbrný podporovatel

    O tom, co je „skutečně svobodný software“, se dají vést dlouhé spory. Pro mne jsou licence jako BSD, MIT, Apache nebo Mozilla svobodnější než GPL.

  • 25. 4. 2026 11:22

    Kate

    Já to beru podle toho čí svobodu zohledňujeme. Pokud svobodu vývojáře, je určitě svobodnější BSD / MIT a podobné.

    Pokud svobodu software, přijde m isvobodnější GPL a spol. Protože mu poskytuje ochranu před uzavřením.

    Pokud o někom řeknu že je "svobodný člověk", taky tím nemyslím svou svobodu kdykoliv ho omezit.

    25. 4. 2026, 11:23 editováno autorem komentáře

  • 25. 4. 2026 12:00

    Filip Jirsák
    Stříbrný podporovatel

    V druhém odstavci bych místo „software“ použil „koncového uživatele“. GPL dává větší svobodu koncovému uživateli, BSD/MIT dává větší svobodu vývojáři. A já jsem holt vývojář :-)

  • 25. 4. 2026 22:11

    kutil domácí

    ...čí svobodu zohledňujeme...

    Pokud svobodu software, přijde mi svobodnější GPL a spol. Protože mu poskytuje ochranu před uzavřením.

    Ano, právě to jsem měl na mysli, protože to vnímám víc z pohledu koncového uživatele a malého správce než vývojáře.

  • 24. 4. 2026 18:38

    acx99

    Snad alespon GPLv3.

    To se tak stane, ze mame GPLv2 kernel v miliarde zarizeni, kde ho nelze ale svuj spustit nelze, protoze to vezme jen podepsany....

    Tekze sice teoreticky mate zdrojaky, ale svobodu fakt ne.