Si avvicina il mese di ottobre e, come ormai tutti gli utenti sanno, sarà il momento di veder pubblicata una nuova release di Ubuntu, per l’appunto la 25.10, il cui nome in codice è Questing Quokka.
La release sarà transitoria, come tutte quelle autunnali ed alcune primaverili (le 04 che non sono Long Term Support), e proprio per questa ragione servirà da banco di prova per l’introduzione di funzionalità che saranno, o chissà magari non saranno, incluse nelle prossime release a lungo termine.
Phoronix, come di consueto, fornisce un aiuto nell’identificare alcune delle funzionalità più interessanti, la prima delle quali è l’introduzione di sudo-rs come il nuovo default sudo del sistema operativo. Il progetto altri non è che la riscrittura in codice Rust dello storico sistema di elevazione dei privilegi.
L’obiettivo, indicato nella pagina GitHub del progetto è quello di avere “A safety oriented and memory safe implementation of sudo and su written in Rust.“, quindi sudo e su, pur non cambiando le modalità di interazione – per intenderci sarà sempre intorno al file /etc/sudoers che bisognerà lavorare per configurare i privilegi – consentiranno di ereditare i vantaggi di protezione della memoria che sono impliciti nel linguaggio Rust.
Un’altra componente scritta in Rust che sarà presente in Ubuntu 25.10 sarà coreutils, ovvero l’insieme dei binari fondamentali di qualsiasi sistema Linux. Giusto per dare un’idea dei dieci più utilizzati:
ls(lista file)cp(copia file)mv(sposta/rinomina file)rm(rimuove file)cat(concatena/mostra file)echo(stampa testo)chmod(cambia permessi)chown(cambia proprietario)head(prime righe di un file)tail(ultime righe di un file)
Binari che quotidianamente ciascuno di noi utilizza decine, se non centinaia di volte.
Ubuntu 25.10, come ogni distribuzione Linux, sta progressivamente implementando riscritture in Rust e la motivazione è la medesima di sudo: il linguaggio offre sicurezza intrinseca nella gestione della memoria, eliminando molte delle vulnerabilità tipiche delle implementazioni originarie in C.
Per quanto possa quindi considerarsi transitoria la distribuzione in uscita ad ottobre, è molto difficile che si ritornerà sui propri passi a proposito di queste scelte.
Del resto non è un caso se anche nel Kernel Linux, Torvalds e Kroah-Hartman hanno a lungo cercato di promuovere ed implementare codice Rust. Non senza qualche difficoltà, come abbiamo sempre raccontato, ma convinti del fatto – e le scelte di Ubuntu lo dimostrano – che il futuro sarà quello.
Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.
Che Dio ce la mandi buona 🙂
Sono parti troppo troppo importanti, ogni errore lo si paga caro prima o poi.
Ma del resto niente è immutabile e tutto prima o poi cambia, cambierà anche questo. Speriamo effettivamente in meglio.
Beh però la necessità della riscrittura è nata proprio dal fatto che sono parti troppo importanti e troppo esposte. Certo magari non sarà totalmente indolore, ma sicuramente ha il suo perché se tutti comunque ammettono i benefici.
e vabbè… sarà anche buona e bella, ma preferisco restare con la Debian….
Io sono dell'idea che ha poco senso riscrivere tool che funzionano e vengono manutenuti da anni
Sempre che l'obbiettivo non sia piano piano staccarsi dalla parte GNU per scopi al momento non ben definiti (ad oggi vedo solo scopi nefasti ma chi vivrà vedrà)
Infatti.
La mia impressione è che siano stati riscritti da zero in Rust semplicemente per avere un coreutils che non fosse in licenza GPL.
E buonanotte a Stallman, gli smanettoni e tutti quelli che volevano il “software libero”
Nah, la licenza è MIT, più aperta di così non si può: https://github.com/uutils/coreutils?tab=MIT-1-ov-file#readme
mmm non conosco la licenza mit ma nel link che posti non sembra parlare di quello che fa della GPL "la licenza amata dagli utenti e odiata dalle corporation" . Con la GPL se vuoi puoi modificare/ridistribuire/far pagare un software ma devi mantenere la stessa licenza. Qui non lo dice
Quindi se non è previsto specificatamente dalla licenza i nostri amici da un giorno all'altro possono prendere le loro coreutils e cambiare licenza magari con una proprietaria (e in quel caso mettersele dove non batte il sole)
MIT è la licenza più aperta che esista, quindi è perfettamente integrabile in soluzioni closed source o commerciali, ma è approvata da OSI, Debian e FSF.
Il rischio che citi c'è in qualunque progetto supportato/finanziato dalle corporation, ma la licenza MIT toglie ogni ipocrisia: puoi integrare liberamente il codice MIT nel tuo software chiuso, persino venderlo, ma devi sempre riconoscere la paternità e conservare la licenza.
A titolo personale è la mia licenza preferita.
ci sarebbe da discutere su: "MIT è la licenza più aperta che esista"
una licenza che obbliga i fork a rimanere open potrebbe essere considerata piu open.
MIT al massimo è la licenza piu permissiva che esista, ma non open
E qui @disqus_NrfNk76lhv:disqus arriviamo alla più centrale di tutte le questioni: cosa si intende per "aperto". Per me aperto vuol dire che chi produce il codice non si preoccupa della fine che farà, né di ricavarci profitto, ma solo del fatto che rimanga libero, pertanto in questo senso MIT è la più aperta e libera possibile, perché non vincola nessuno.
Ora apriamo il vaso di Pandora 🙂
Il discorso che fai tu è chiarissimo, il gene "aperto" si trasmette a qualsiasi derivato, ma per come la vedo io è anche un problema per la diffusione dei software open-source in generale e ciò che ha creato tutti i problemi che abbiamo raccontato in questi anni di progetti con codice aperto, poi chiuso, poi aperto ancora.
MIT è la licenza che ho scelto per tutti i miei progetti proprio per questo, ma è chiaro che la mia è una visione limitata dalle mie esperienze ed esigenze.
discorso lunghissimo, anche solo la definizione di "più aperta" sarebbe da discutere.
in ogni caso "tutti i problemi che abbiamo raccontato in questi anni di progetti con codice aperto" sono progetti non-GPL
magari mi sbaglio è.
PS (troll on) viva il software libero macos
Elastic era Apache eh…
esatto che è come mit
È vero che nessuno dei software citati per cambio di licenza non erano GPL, ma se si considerano licenze open solo quelle copyleft, l'open-source di oggi finisce… domani. Magari non il Kernel, ma Kubernetes sicuramente, che è Apache…
non ho mai detto di considerare open solo le copyleft, ma di non considerare più open le non-copyleft
AIUTO 😀 cmq non sono d’accordo, mi spingo a dire che Apache e MIT hanno salvato l’open-source per come lo conosciamo oggi.
ma modifiche o eventuali versioni modificate possono diventare proprietarie, non mi sembra un miglioramento anzi…
@lelec:disqus chi fa modifiche può anche non pubblicarle o renderle proprietarie, certo, ma la licenza MIT dovrà sempre essere presente.
Detto questo, purtroppo la poesia e il romanticismo del do ut des alla community si sono esaurite con l'introduzione delle business source license, e come abbiamo visto puoi avere Apache, GPL2, GPL3, quello che vuoi, ma nulla ti tutelerà dai rischi che le aziende che guidano gli sviluppi di certi prodotti cambino idea.
Essendo l'unico su cui posso agire, ed essendo fan della semplificazione, smetto di concentrarmi su quello che fanno o possono fare gli altri del mio codice, e cerco di dare l'esempio mantenendo un approccio collaborativo ed aperto il più possibile.
Concordo.
MIT non è male, come BSD.
Se poi Sony si prende porzioni di kernel BSD e li blinda nell' OS della PlayStation….beh la colpa non è certo della BSD Foundation.
Cioè ragazzi da come scrivete sembra quasi che chi fa software sotto licenza MIT sia il colpevole di furto di software, dobbiamo prendercela con chi prende quello che gli serve senza dare un centesimo e chiuderlo in un codice per usi commerciali, non con chi sceglie quella licenza
scusami ma essendo ignorante relativamente alle licenze il tuo discorso non mi torna.
Io prende 10 righe di codice dal tuo progetto con licenza mit perché la licenza me lo permette e le metto in un software che rendo proprietario.
Come fa a rimanere la licenza MIT? In programma proprietario di 9000 righe pubblica sotto mit 10 righe?
Non ho detto che rimane MIT, ho detto che il fatto che all’interno del progetto ci sia codice MIT va segnalato, generalmente nel file LICENSE.
Wow tanta roba.
E' come costruire una villa con i mattoni del vicino mettendo però una targa sotto il lavello della cucina (che proprio devi andare a cercare)
No, è come usare il progetto dell’architetto che ha pagato il vicino per costruire una casa identica o, all’occorrenza, far fare le modifiche al tuo architetto per cambiare ciò che non ti piace rispetto al progetto originale, senza dare nulla indietro.
Prima di inorridire però, considera che è stato il tuo vicino a pubblicare i progetti in centro al paese, tu hai solo copiato, non hai commesso nessun illecito.
Finché è permesso dalla licenza non c'è nessun illecito.
Però non è il modello di open che mi piace.
Il mio modello è identico solo che il tuoi progetti vanno esposti in paese insieme a quelli del vicino e specifichi che i progetto originali sono di.
Poi non è scritto da nessuna parte ma se da quei progetti ricavo una buona somma di denaro una porzione dei miei guadagni la do all'autore originale (ovviamente sempre i proporzione a quanto ho usato del progetto)
Tornando al software faccio un fork di gimp. Da questo fork esce Photoshop 2. La porzione di codice originale e relative modifiche alla stessa restano open, volendo anche il resto ma senza obbligo. Se grazie a Photoshop 2 divento bilionario qualche soldino a gimp lo do ma per coscienza visto che a gimp devo molto
Ma quella di cui parli tu @fabriziopaolini:disqus è etica, non c'entra con le regole o la permissività. Il principio del mio discorso è che se ci fossero solo licenze copyleft l'open-source non avrebbe futuro.
A me queste derivate piacciono sempre meno.
Mi da l'idea che cerchino in tutti i modi di allontanarsi dalla loro mamma continuando però a bere i latte (con tanto di panierino per la sera) senza farsene accorgere dagli amci
– Ubuntu cerca di allontanarsi da debian come filosofia (rust + snap) però continua a prendere terabyte di pacchetti compilati e testati
– Mint cerca di allontanarsi da Ubuntu disconoscendo snap e alcune scelte filosofiche però sbandiera un supporto LTS non suo e idem come sopra prende il 90% dei pacchetti da debian (in modo più sporco perché almeno ubuntu non li prende dai repository debian.)
cit: "L'uomo era uomo quando si compilava da solo i driver delle periferiche"
Comunque vedrai che Debian userà anche lei le coreutils e sudo in Rust. Ed in ogni caso, la promiscuità che descrivi è la croce e la delizia dell’ope-source 🙂
Per quanto Rust sia un linguaggio che, sintatticamente, non mi fa impazzire trovo positivo che inizino ad introdurlo in questo modo. Una versione intermedia, strumenti che vengono usati in modo diffuso, questo gli permetterà di testare il linguaggio in modo affidabile.
Hanno riscritto strumenti di cui si sa praticamente tutto, cosi sarà più semplice capire cosa non funziona in Rust, se ci fosse qualcosa che non va.
Rust è un linguaggio molto giovane, quindi va testato per bene, prendendosi il tempo necessario. Devo ammettere che è un bel passo avanti rispetto a C e C++.
mmmm molto pericoloso riscrivere i comandi base… non si può mai sapere se in qualche script bash o altri tools, vengano usati parametri "strani" o in modi non convenzionali, dove il comportamento atteso può differire.