IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le remplacement de GNU Coreutils par Rust progresse et certains binaires sont maintenant plus rapides,
Selon le développeur principal du projet

Le , par Bill Fassinou

48PARTAGES

15  0 
Parallèlement à la tendance plus large de l'industrie consistant à transférer le code sensible à la sécurité vers des langages permettant une gestion sécurisée de la mémoire comme Rust, un effort a été fait pour écrire un remplacement de GNU Coreutils basé sur Rust. La semaine dernière, Sylvestre Ledru, le développeur principal du projet Rust Coreutils, a annoncé que le projet est en bonne voie et apporte des améliorations significatives par rapport à l'ancienne implémentation en C. Rust Coreutils continue également d'augmenter son niveau de compatibilité avec GNU Coreutils.

Alors que le mouvement en faveur des langages à mémoire sécurisée, et de Rust en particulier, continue de croître, il est intéressant d'examiner l'un des efforts à plus grande échelle visant à porter du code C existant depuis des décennies vers Rust. Le projet uutils, aussi connu sous le nom de Rust Coreutils, vise à réécrire en Rust tous les utilitaires individuels inclus dans le projet GNU Coreutils. Créé à l'origine par Jordi Boggiano en 2013, le projet vise à fournir des remplacements immédiats pour les programmes Coreutils, en ajoutant la protection contre la concurrence d'accès et la sécurité de la mémoire que Rust fournit.



Rust Coreutils comprend les programmes de base de manipulation des fichiers, des processus et du texte qui sont censés exister sur tous les systèmes d'exploitation basés sur GNU. Le projet Coreutils a été créé pour consolider trois ensembles d'outils qui étaient auparavant proposés séparément, Fileutils, Textutils, et Shellutils, ainsi que d'autres utilitaires divers. Beaucoup de programmes inclus dans le projet, tels que rm, du, ls, et cat, existent depuis plusieurs décennies et, bien que d'autres implémentations existent, ces utilitaires ne sont pas disponibles pour des plateformes comme Windows dans leur forme originale.

Collectivement, les programmes Coreutils sont considérés comme des fruits mûrs pour lesquels une version fonctionnelle basée sur Rust pourrait être produite dans un délai raisonnable. Les exigences pour chaque utilitaire sont claires et beaucoup d'entre eux sont conceptuellement simples, ce qui ne veut pas dire que le travail est facile. Selon les auteurs, l'utilisation de Rust dans le cadre de ce projet contribuera à accélérer ce processus puisqu'un grand nombre d'erreurs de mémoire et d'autres comportements indéfinis sont entièrement éliminés. Elle ouvre également la porte à l'utilisation d'un multithreading efficace et sans concurrence.

Cela pourrait accélérer certains programmes dans certaines conditions. Rust Coreutils donne également l'occasion de ne pas se contenter de réimplémenter Coreutils, mais aussi d'améliorer la fonctionnalité de certains utilitaires afin d'offrir une meilleure expérience utilisateur, tout en maintenant la compatibilité avec les versions GNU. Par exemple, des demandes de fonctionnalités qui ont longtemps été rejetées dans le projet Coreutils, comme l'ajout d'une option de barre de progression pour des utilitaires comme mv et cp, sont actuellement prises en compte dans cette réécriture en langage Rust.

Sur la page GitHub du projet, on peut trouver un tableau avec les utilitaires divisés en trois colonnes : "Terminé", "À mi-chemin", et "À faire". La colonne "À faire" du tableau comporte les utilitaires sur lesquels aucun travail n'a encore été fait ou les utilitaires qui sont en cours d'implémentation initiale. Les utilitaires de la colonne "À mi-chemin" ont des options manquantes qui n'ont pas encore été implémentées, ou leur comportement est légèrement différent de leurs homologues GNU dans certaines situations. Toutefois, le fait qu'un programme soit marqué comme "Terminé" ne signifie pas que tous les tests passent.

Cela ne signifie pas non plus que l'utilitaire est aussi performant ou efficace en mémoire que la version GNU. À l'heure actuelle, Ledru et les siens semblent avoir bien évolué dans le projet ; 88 utilitaires sont marqués comme "terminés", 18 sont "à mi-chemin" et la colonne "À faire" comporte un seul utilitaire. Ledru a publié samedi une mise à jour sur Rust Coreutils, dont la version 0.0.12 vient de sortir. Non seulement uutils devrait être plus sûr, mais certains binaires afficheraient maintenant des performances "significativement" meilleures que celles du paquetage GNU pour des commandes comme head, cut et d'autres commandes courantes.



Il y a maintenant des dizaines de contributeurs qui apportent chaque mois plus de 400 correctifs à cet effort. Ils restent sur le défi de combler l'écart de compatibilité pour ces utilitaires avec les commandes GNU en amont. Le seul binaire restant à implémenter est "stty". En plus de leurs travaux d'optimisation et de compatibilité, les développeurs vont également s'efforcer de permettre à Debian et Ubuntu de basculer facilement par défaut vers les Coreutils Rust sans nécessiter de bidouillages ou de configurations particulières.

Bien que de nombreux progrès aient été réalisés pour amener uutils dans un état utilisable, il faudra un certain temps pour qu'il atteigne la stabilité et la maturité de GNU Coreutils. Par ailleurs, un aspect important du projet uutils dont il faut être conscient est sa licence. Tous les utilitaires du projet sont sous la licence permissive MIT, au lieu de la licence GPLv3 de GNU Coreutils. Cela le rend potentiellement plus attractif pour une utilisation dans des endroits où les logiciels sous licence GPLv3 ne sont pas adoptés en raison de ses restrictions sur la tivoïsation, entre autres choses.

La décision d'utiliser la licence MIT n'est pas sans susciter des critiques ; certains qui ont commenté ce choix auraient préféré voir une licence copyleft appliquée à un projet de ce type. La principale critique fait écho aux arguments concernant les licences de logiciels libres dans le passé : "une licence non copyleft est préjudiciable aux libertés des utilisateurs finaux puisqu'elle permet à une personne ou à une organisation d'incorporer n'importe quelle partie du projet dans un dispositif ou dans la distribution d'autres logiciels sans fournir le code source, de sorte qu'il est impossible de l'étudier, de le modifier ou de l'améliorer".

L'on craint également que le choix de la licence ne soit fait pour maximiser l'utilisation de Rust sans tenir compte des autres effets ; le remplacement des outils sous licence GPL par des alternatives sous une licence plus permissive est considéré par certains comme un pas en arrière.

Sources : Sylvestre Ledru, Rust Coreutils (uutils)

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du projet Rust Coreutils ?
Que pensez-vous du passage de la licence GNU GPLv3 à la licence MIT ?

Voir aussi

Les derniers correctifs du projet Rust for Linux montrent que le langage Rust avance à grands pas vers le noyau, Torvalds estime que cela pourrait être prêt pour la version 5.14

Kerla : un nouveau noyau de système d'exploitation écrit en Rust et compatible avec l'ABI Linux, ce qui devrait permettre d'exécuter les binaires Linux sans aucune modification

Plusieurs améliorations ont été apportées au support de Rust dans le noyau Linux, personnalisation de core et alloc, abstractions et mises à jour des pilotes

Projet Protissimo : l'Internet Security Research Group veut sécuriser la mémoire du noyau Linux avec Rust et fournit au dev Miguel Ojeda un contrat d'un an pour travailler dessus à plein temps

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 01/02/2022 à 15:16
Connaissant l'intérêt de Microsoft pour Linux, Je trouve le changement de licence carrément inquiétant.
6  0 
Avatar de vanquish
Membre chevronné https://www.developpez.com
Le 02/02/2022 à 9:02
Citation Envoyé par archqt Voir le message
Et pourquoi ça gène la licence MIT, au contraire je trouve.
En tant que développeur, je préfère la licence MIT.
Cela me permet de ne pas ré-inventer la roue même si je travaille au sein d'un système propriétaire.

Mais du point de vue de l'utilisateur final cela veux dire qu'il n'aura pas forcement accès au source ce qui est complétement contraire à la philosophie GNU dont c'est le credo absolu.
S'ils sont tous les 2 compréhensibles, les 2 points de vues sont totalement inconciliables.

Je pense que c'est peut-être pour cela que ledru ne veux pas rentrer dans le débat.
Dire qu'il a 0 intérêt à rentrer dans le débat ne veux pas forcement dire qu'il s'en moque, mais peut-être que c'est une perte de temps, tant le débat sera sans fin et source de prises de bec infinis.

Un débat GPL/MIT c'est comme les débats Windows/Linux : la certitude de nourrir le troll.
3  0 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 03/02/2022 à 1:18
Citation Envoyé par archqt Voir le message
Je ne comprend pas pourquoi publier sous MIT (uniquement) au lieu d'une double licence MIT/GPL.
Et c'est quoi l'intérêt ? si c'est en MIT celui qui veut peut l'inclure dans du code GPL, donc ce n'est pas bloquant.
Le but de la GPL n'est pas de "permettre à ceux qui veulent", mais de "obliger ceux qui ne veulent pas", à respecter certains engagements.
si du code MIT est utilisé dans un logiciel sous GPL, l'éditeur n'a aucune obligation "GPL" sur ce morceau de code, et, par exemple, peut tout a fait refuser de livrer les sources correspondant à la partie sous MIT.

Si je ne me trompe pas, Mozilla Firefox est publié sous MPL/GPL, mais Firebird ne l'est que sous MPL.
En conséquence, Firebird ne pourra jamais intégrer Enigmail nativement (plugin de sécurisation d'échange par mail), car étant sous licence GPL.
...je ne sais pas ce qu'est devenu ce problème depuis le passage à la version MPL 2.0.
3  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 01/02/2022 à 17:52
Citation Envoyé par Bill Fassinou Voir le message

Que pensez-vous du passage de la licence GNU GPLv3 à la licence MIT ?
Autant, le Ledru fait ce qu'il veut de son code, autant j'espère ne pas voir ce truc arriver dans Debian et remplacer la GNU Core Utils.

Encore que d'après ce ticket Github, Ledru a l'air de dire que le choix de la licence n'est pas le sien et qu'il n'était pas là quand ça a été décidé.

En revanche, en lisant entre les lignes il dit aussi qu'il s'en fout complètement:

I am 0 interest in starting a license debate (I care if the license is DFSG - Debian Free Software Guidelines) and spend time on it. I would rather use my limited time to make rust/coreutils ready for production.

Moreover, as we don't have any copyright assignment, it would be a lost of work to get sign off from everyone to relicense this software. I am pretty sure that some people have stronger feeling than I do about this! [...] So, sorry but won't fix!
Et
ok, make more sense.
However, it would certainly trigger some conversations that I don't have time or motivation for. Sorry.
1  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 02/02/2022 à 9:26
Citation Envoyé par vanquish Voir le message
En tant que développeur, je préfère la licence MIT.
Cela me permet de ne pas ré-inventer la roue même si je travaille au sein d'un système propriétaire.
Oui.

Citation Envoyé par vanquish Voir le message

Mais du point de vue de l'utilisateur final cela veux dire qu'il n'aura pas forcement accès au source ce qui est complétement contraire à la philosophie GNU dont c'est le credo absolu.
S'ils sont tous les 2 compréhensibles, les 2 points de vues sont totalement inconciliables.
Exactement.

Citation Envoyé par vanquish Voir le message

Je pense que c'est peut-être pour cela que ledru ne veux pas rentrer dans le débat.
Dire qu'il a 0 intérêt à rentrer dans le débat ne veux pas forcement dire qu'il s'en moque, mais peut-être que c'est une perte de temps, tant le débat sera sans fin et source de prises de bec infinis.
Oui et non. Le gars est aussi chez Debian et Ubuntu, si l'on en croit sa page Github, et il ambitionne de pousser ça sur Debian, sur un des rares systèmes qui étaient encore relativement libres, ouverts et pas à la botte d'une grande boîte... Du coup le gars ne peut malheureusement pas ne pas avoir d'avis sur le sujet :/
1  0 
Avatar de esperanto
Membre émérite https://www.developpez.com
Le 02/02/2022 à 9:38
Eh bien, ceux qui n'arrêtaient pas de nous casser les pieds avec l'appellation Gnu/Linux vont en avoir pour leurs frais.
Ça tombe bien parce que si j'en comprends le principe j'aurais préféré Linux+GNU. En anglais, ce qui est à gauche d'un nom est généralement perçu comme un adjectif (même si ce n'est pas le cas à la base, regardez le mot science fiction en anglais, sans le tiret il n'a pas exactement le même sens qu'en français!) du coup l'appellation Gnu/Linux, malgré le slash, pourrait faire croire que Linux fait partie du projet GNU, ce qui n'a jamais été le cas.

Ici si j'ai bien compris, la nouvelle implémentation n'est pas non plus une partie du projet GNU, au sens strict c'est une nouvelle implémentation des coreutils compatible avec les outils Gnu, et non une nouvelle implémentation des coreutils de Gnu.
Alors certes il existe déjà des versions de linux non Gnu (sous Busybox, par exemple, sans parler d'Android) mais c'est seulement maintenant qu'il y aura des distributions basées sur cette version Rust que la distinction va vraiment prendre tout son sens.

Le choix d'une licence sans copyleft devrait faciliter l'adoption dans des systèmes alternatifs, peut-être qu'on aura quelques variantes de BSD qui y trouveront un intérêt par exemple.
Ceux qui ne sont pas d'accord n'ont qu'à forker cette version Rust (après tout, le changement de licence MIT vers GPL ne pose aucun problème, l'inverse est plus compliqué)
Ou alors s'ils veulent vraiment du 100% GNU ils n'ont qu'à utiliser Hurd

Citation Envoyé par vanquish Voir le message
Mais du point de vue de l'utilisateur final cela veux dire qu'il n'aura pas forcement accès au source ce qui est complétement contraire à la philosophie GNU dont c'est le credo absolu.
C'est bien pour ça que je rappelle que Linux ne fait pas partie du projet Gnu. Debian non plus d'ailleurs. Ces deux projets ne sont pas obligés de prendre la philosophie Gnu au pied de la lettre.

Citation Envoyé par kain_tn Voir le message
Debian, sur un des rares systèmes qui étaient encore relativement libres, ouverts et pas à la botte d'une grande boîte.../
Ôtez-moi d'un doute, la licence MIT est bien considérée comme libre, non? Le fait d'inclure des outils sous licence MIT ne rend pas une distribution non libre, n'est-ce pas?

Citation Envoyé par vanquish Voir le message
Mais du point de vue de l'utilisateur final cela veux dire qu'il n'aura pas forcement accès au source ce qui est complétement contraire à la philosophie GNU dont c'est le credo absolu.
La licence MIT autorise la création de forks non libres, donc disponibles sans les sources. ça ne veut pas dire que tout projet utilisant ces outils sera dans ce cas. Alors certes il y aura probablement quelques OS qui utiliseront ces outils sous une forme non libre, mais ce n'est pas une raison pour condamner toutes les distributions qui les utiliseraient avec la licence originale. D'autant plus que contrairement à une licence avec Copyleft fort, le fait d'inclure un outil sous licence MIT ne contamine pas toute la distribution.
1  0 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 02/02/2022 à 14:25
Si développer sous GNU GPL est trop contraignant, quel serait le meilleur compromis ?
>> publier sous MIT, ou bien LGPL ?

Je ne comprend pas pourquoi publier sous MIT (uniquement) au lieu d'une double licence MIT/GPL.
A ma connaissance, on peut publier en multi licence même avec des licences incompatibles, alors pourquoi ce choix n'a pas été fait s'il revêt un grand intérêt à la fois côté développeur et côté utilisateur ?

Quelqu'un aurait une idée ?
1  0 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 01/02/2022 à 15:00
Si tous les buts du projet de réécriture en Rust ont été officiellement communiqués, il est très facile de dire si le choix d'une licence non copyleft est raccord avec leur buts à atteindre.
Ces buts, je ne les connais pas.
S'il s'avère que ce n'est finalement pas raccord, il sera facile d'identifier qu'elle concession a été faite, et pour servir quel but (déclaré ou non).
1  1 
Avatar de archqt
Membre émérite https://www.developpez.com
Le 01/02/2022 à 20:58
Et pourquoi ça gène la licence MIT, au contraire je trouve.
De toute façon les grosses entreprises elles ont les moyens de refaire si nécessaire. La GPL elle bloque qui ? les petits qui veulent pouvoir faire un peu de commercial avec.

A la limite une bonne licence est celle de Unreal, à partir de 1000 000$ tu payes un peu sur ce qui dépasse. Bon cela pourrait être dès 100 000$ tu payes 5% sur ce qui dépasse.
1  1 
Avatar de archqt
Membre émérite https://www.developpez.com
Le 02/02/2022 à 15:27
Je ne comprend pas pourquoi publier sous MIT (uniquement) au lieu d'une double licence MIT/GPL.
Et c'est quoi l'intérêt ? si c'est en MIT celui qui veut peut l'inclure dans du code GPL, donc ce n'est pas bloquant.
0  0