Les « GNU Core Utilities » ont été réimplémentés en Rust grâce à « uutils »

Version imprimable

16/03/2021, 19h34
Bruno

1 pièce(s) jointe(s)

Les « GNU Core Utilities » ont été réimplémentés en Rust grâce à « uutils »
Les « GNU Core Utilities », un paquetage du projet GNU contenant des outils de base pour les OS de type Unix, ont été réimplémentés en Rust,
faciles à compiler sur différentes plateformes

De nombreux utilitaires GNU, Linux et autres, sont utiles pour les administrateurs systèmes et autres utilisateurs. Des efforts ont été faits par le passé pour les porter sur Windows. Cependant, il se trouve que ces projets sont soit vieux et abandonnés, soit écrits en C et spécifique à une plateforme, soit hébergés sur CVS (les CVS permettent de créer des branches d'un projet où chaque branche contient le code du projet dans différents états), ce qui rend plus difficile l’apport des nouveaux contributeurs. Rust fournit aujourd’hui un bon moyen, indépendant de la plateforme, d'écrire des utilitaires de systèmes qui sont faciles à compiler sur différentes plateformes.

Pièce jointe 593557

Rappelons que GNU est un système d'exploitation libre. Il est constitué de paquets publiés par le projet GNU ainsi que de logiciels libres publiés par des tiers. Rust est un langage de programmation compilé multiparadigme, conçu par Graydon Hore alors employé chez Mozilla Research, avec la contribution du créateur de JavaScript Brendan Eich. Utilisé par plusieurs grandes entreprises et par de nombreux développeurs dans le monde, Rust est devenu le langage de base pour certaines des fonctionnalités fondamentales du navigateur Firefox et de son moteur Gecko, ainsi que pour le moteur Servo de Mozilla.

« Mozilla a incubé Rust pour mieux développer Firefox et contribuer à un meilleur Internet », avait écrit Bobby Holley, membre du conseil d'administration de la fondation Mozilla et Rust, dans une déclaration. « Avec cette nouvelle fondation, Rust aura la possibilité de se développer, tout en continuant à amplifier certaines des valeurs fondamentales que Mozilla partage avec la communauté Rust ».

Le mois dernier, Microsoft, Google, AWS, Huawei et Mozilla se sont associées pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation. L'annonce avait été faite par Ashley Williams, Directeur exécutif par intérim de la fondation, le 8 février sur le site Internet de l'organisation. « Aujourd'hui, au nom de l'équipe de Rust, je suis heureux d'annoncer la création de la Fondation Rust, une nouvelle organisation indépendante à but non lucratif chargée de gérer le langage de programmation et l'écosystème Rust, en mettant l'accent sur le soutien de l'ensemble des responsables qui régissent et développent le projet ».
Pour parvenir à écrire des utilitaires de systèmes avec Rust, les utilisateurs doivent respecter un certain nombre de prérequis :
- Rust (cargo, rustc) ;
- Sphinx : nécessaire pour la documentation ;
- Gzip : nécessaire pour l'installation de la documentation ;
- GNU Make : nécessaire pour construire la documentation.
uutils suit les canaux de publication de Rust et est testé sur les versions stable, bêta et nightly. Sous Windows et Redox, seule la version nightly est testée actuellement. Il existe actuellement deux méthodes pour construire uutils : GNU Make et Cargo. Cependant, bien qu'il y ait deux méthodes, sous Unix , les deux systèmes sont requis pour la construction et seul Cargo est requis sous Windows. Pour les deux méthodes, le dépôt doit tout d’abord être récupéré grâce aux commandes :

$ git clone "https://github.com/uutils/coreutils"
$ cd coreutils

La méthode Cargo

Cargo est le système de construction et le gestionnaire de paquets de Rust. La plupart des programmeurs Rust utilisent cet outil pour gérer leurs projets Rust car, Cargo prend en charge de nombreuses tâches comme la construction du code, le téléchargement des dépendances dont le programme a besoin et la construction de ces bibliothèques. Construire uutils en utilisant Cargo est facile car, le processus est le même que pour tout autre programme Rust. Pour conserver les informations de débogage, la compilation peut être effectuée sans le paramètre –release :

$ cargo build –release

Étant donné que la commande ci-dessus tente de construire des utilitaires qui ne fonctionnent pour l'instant que sur des plateformes de type Unix, voici, ci-dessous, la commande pour Windows :

$ cargo build --release --no-default-features --features windows

Si vous ne voulez pas construire tous les utilitaires disponibles sur votre plateforme dans le binaire multicall (le binaire Busybox-esque), vous pouvez aussi spécifier ceux que vous voulez construire manuellement. Par exemple :

$ cargo build --features "base32 cat echo rm" --no-default-features

Si vous ne voulez même pas construire le binaire multicall et préférez simplement construire les utilitaires en tant que binaires individuels, c'est également possible. Par exemple :

$ cargo build -p uu_base32 -p uu_cat -p uu_echo -p uu_rm

Alors que pour certains programmeurs, Cargo n'apporte pas de plus-value par rapport à l'utilisation de rustc (un compilateur pour le langage de programmation Rust), la plupart des programmeurs Rust n'invoquent pas rustc directement, mais le font à travers Cargo.

La méthode GNU Make

GNU Make est un outil qui contrôle la génération des exécutables et des autres fichiers non-sources d'un programme à partir des fichiers sources du programme. Make obtient ses connaissances sur la façon de construire votre programme à partir d'un fichier appelé makefile, qui répertorie chacun des fichiers non sources et la façon de le calculer à partir d'autres fichiers. La construction des utilitaires systèmes à l'aide de make est également un processus simple.
$ make

Pour construire tous les services disponibles, à l'exception de quelques-uns, voici, la commande à utiliser :

$ make SKIP_UTILS='UTILITY_1 UTILITY_2'

Pour ne construire que quelques-uns des services disponibles, la commande suivante doit être utilisée :

$ make UTILS='UTILITY_1 UTILITY_2'

Les « GNU Core Utilities » réimplémentés en Rust sont sous licence GPL 3.0 ou ultérieure. Des centaines d'entreprises dans le monde entier utilisent Rust en production pour des solutions multiplateformes et économes en ressources. Des logiciels connus et appréciés, comme Firefox, Dropbox, et Cloudflare, utilisent ce langage. De la startup à la multinationale, du système embarqué au service web à haute disponibilité, Rust est une excellente solution.

« Mon meilleur compliment envers Rust est qu'il est ennuyeux, et c'est un fantastique compliment », déclare Chris Dickinson, Ingénieur chez npm Inc. Pour Antonio Verardi, Ingénieur infrastructure chez Yelp, les développeurs disposent de tous les outils pour réussir à écrire du code en Rust. La documentation, l’outillage et la communauté sont tous simplement fantastiques.

Source : GNU

Et vous ?

:fleche: Avez-vous une expérience avec les utilitaires de base GNU ?
:fleche: Quel est votre avis sur ce dépôt réimplémenté en Rust ?

Voir aussi :

:fleche: Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

:fleche: Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

:fleche: Microsoft annonce Rust/WinRT, une projection du langage Rust pour les API Windows Runtime, implémentée comme une bibliothèque basée sur des fichiers d'en-tête

:fleche: GNU Octave 6.1.0, le langage de haut niveau pour les calculs numériques, est disponible, avec plusieurs améliorations et prévoit la suppression du support de Qt4 dans la version 7
17/03/2021, 11h50
smarties

Avez-vous une expérience avec les utilitaires de base GNU ?
Oui, quand on utilise Linux en tant que développeur ou pour administrer des serveurs à distance, on est confronté. Quand je faisais des études à l'IUT Informatique de La Rochelle, on a eu aussi des cours dessus.

Quel est votre avis sur ce dépôt réimplémenté en Rust ?
C'est dans l'ère du temps de réécrire en Rust pour conserver les performance tout en se prévenant des éventuelles failles. Après, les programmes sont relativement simples donc le risque de faille est plus faible.
Sinon, je pensais que ça serait RedoxOS qui serait à l'origine de ce projet.
A quand l'intégration dans les dépôts du coup ?
17/03/2021, 15h14
Uther

A priori Redox a choisi de baser son implémentation des core-utils sur ceux de BSD et non de GNU, pour avoir quelque chose de plus simple.
https://github.com/redox-os/coreutils
19/03/2021, 12h44
gangsoleil

Hello,

Mais quel est l'intérêt ??
Le code est sous CVS, c'est pas forcément l'idéal, mais si vraiment c'était un soucis, il suffit de le mettre dans GIT, et hop c'est résolu.

Ré-écrire des outils comme cat, à quoi ça sert ?? Vraiment, j'ai regardé la liste des utilitaires, et à part pour mettre sur son CV "j'ai participé à un projet en RUST", je ne vois pas l'intérêt. À aucun moment. Et pourtant j'utilise ces outils tous les jours.

Et pour l'argument de la compilation, je pense que le C est supporté sur beaucoup plus de plateformes que RUST, donc là encore ce n'est pas un argument -- d'ailleurs, cargo qui est nécessaire pour ce projet, n'existe que pour Linux, Mac et Windows. Les autres, débrouillez-vous à partir de sources.

Si ces gens se mobilisaient à apporter leur aide à des projets existants plutôt que de vouloir réinventer l'eau tiède en moins bien, les outils progresseraient plus vite.
19/03/2021, 18h32
disedorgue

@gangsoleil: Je suis d'accord avec toi, en ce moment, il y a des annonces comme quoi, il serait bien de réécrire tout le noyau linux en rust...
Ca vient peut-être de là.

Il y a eu la javamania, maintenant on a la rustmania :ptdr:
25/03/2021, 16h35
dissert

Intérêt à prouver

Alors d'abord les GNU Core utilities sont les softs les plus stables jamais implémentés, justement à cause des principes de ces outils : un outil <=> un usage élémentaire.

Et ça a été fait pour servir de socle en étant super solide. Et au vu de leur utilisation (depuis la sortie de Karate Kid 2 : vous vous souvenez, si vous étiez nés ?).

En réimplémentant ça, c'est-à-dire en faisant un fork, il faut faire une double maintenance.

Ca part peut être d'une bonne intention, mais franchement, c'est une mauvaise idée.
26/03/2021, 11h23
Uther

Citation:

Envoyé par gangsoleil

Ré-écrire des outils comme cat, à quoi ça sert ?? Vraiment, j'ai regardé la liste des utilitaires, et à part pour mettre sur son CV "j'ai participé à un projet en RUST", je ne vois pas l'intérêt. À aucun moment. Et pourtant j'utilise ces outils tous les jours.

On peut voir un certain intérêt d'avoir une base de code plus moderne dans un langage plus sécurisé, même si ça va en effet avec l'inconvénient qu'elle est moins mise a l'épreuve. Ca n'est jamais qu'une implémentation parmi d'autre, rien n'oblige a l'utiliser.

Citation:

Envoyé par gangsoleil

Et pour l'argument de la compilation, je pense que le C est supporté sur beaucoup plus de plateformes que RUST, donc là encore ce n'est pas un argument -- d'ailleurs, cargo qui est nécessaire pour ce projet, n'existe que pour Linux, Mac et Windows. Les autres, débrouillez-vous à partir de sources.

Je ne connais pas la liste exacte, mais cargo existe sur d'autre plateformes, au moins sous BSD.

Citation:

Envoyé par gangsoleil

Si ces gens se mobilisaient à apporter leur aide à des projets existants plutôt que de vouloir réinventer l'eau tiède en moins bien, les outils progresseraient plus vite.

Chacun a le droit de faire ce qu'il veux au niveau qu'il veut. Parfois ça ne sert a rien, mais si Linus Torvalds n'avait pas choisi de faire son propre noyau "just as a hobby" au lieu de participer à un truc plus professionnel comme GNU Hurd, on aurait pas eu Linux.

Citation:

Envoyé par disedorgue

@gangsoleil: Je suis d'accord avec toi, en ce moment, il y a des annonces comme quoi, il serait bien de réécrire tout le noyau linux en rust...
Ca vient peut-être de là.

Il n'y a aucune annonce sérieuse de réécrire Linux en Rust. Il est juste envisagé de rendre disponible les outils qui permettent d'écrire des drivers en Rust, rien de plus.

Citation:

Envoyé par dissert

Alors d'abord les GNU Core utilities sont les softs les plus stables jamais implémentés, justement à cause des principes de ces outils : un outil <=> un usage élémentaire.

Alors certes GNU Core Utilities sont des outils simple comparés à un navigateur ou une base de données, mais ça n'est certainement les softs les plus stables jamais implémentés, les plus simple non plus.
Les core utils BSD sont relativement plus simples.
26/03/2021, 11h49
Axel Mattauch

Je suis d'accord avec la majorité des commentaires.
En tant que tel, pas d'intérêt à refondre en quoi que ce soit des implémentations validées depuis longtemps.
Réécrire en plus moderne n'est pas un but en soi, sauf si le module nécessite une maintenance ou que le langage du module existant est obsolète ou moribond. L'inconvénient du fork est trop élevé au regard de bénéfices incertains.
En tant qu'exercice, pour une version expérimentale donc, je peux le concevoir, si l'objectif est d'évaluer l'usage de ce langage pour des nouveaux développements dans Linux.

J'ai une certaine appréhension quand je lis que "Microsoft, Google, AWS, Huawei et Mozilla se sont associées pour créer la Fondation Rust".

Connaissant la propension de ces Mégasaurus à phagocyter toutes les activités tierces, et les orienter selon leurs décisions, un RUST GAFAMless me semble une condition sine qua non pour laisser entrer RUST dans Linux.

Citation:

Envoyé par Uther

Il n'y a aucune annonce sérieuse de réécrire Linux en Rust. Il est juste envisagé de rendre disponible les outils qui permettent d'écrire des drivers en Rust, rien de plus.

Mouais...
En tout cas, ce qui me gène la-dedans c'est après avoir compilé par exemple:
Code:

1 2 3 4 5 6 7 $ cat ./xtst.rs fn main() { println!("Hello, world!"); } $ rustc xtst.rs $ ./xtst Hello, world!
on est ok, mais si on fait un ldd sur l’exécutable:
Code:

1 2 3 4 5 6 7 $ ldd ./xtst linux-vdso.so.1 (0x00007ffc79179000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa435558000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa435535000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa43551a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa435328000) /lib64/ld-linux-x86-64.so.2 (0x00007fa4355cb000)
On voit derrière la libc...
Si la recompile des Gnu Core Utilities sont dans le même cas... c'est en mon sens un peu contre productif :aie:

27/03/2021, 07h10
Uther

La libc et les core utils ça n'est pas la même chose. La libc est juste utilisée comme interface avec le kernel vu que c'est le seul moyen stable de le faire dans tous les OS. Sous Linux on pourrait faire des appels systèmes en assembleur à la place, vu que l'interface est bien définie, mais je ne vois pas trop ce qu'il y aurait à y gagner.

Quand on utilise Rust pour faire son propre OS ou des drivers, on utilise le mode #![no_std] qui retire toute les dépendances au noyau et donc à la libc. La bibliothèque standard est du coup déduite au core (plus d'allocation, d'IO, ...)
27/03/2021, 09h01
disedorgue

Bah, si, ça serait un premier pas pour aller vers ça:
https://www.developpez.com/actu/3084...inux-Plumbers/

Et même si coté noyaux, on ne l'utilise pas la libc, il faut quand même la refaire via rust (et assembleur)...

PS: Personnellement, je m'en fiche un peu de tout ça, mais vu comment certain déblatère sur le C/C++ vis à vis de rust, il serait de bon gout pour ces gens de fournir un rust complètement épuré du C/C++
27/03/2021, 14h40
Uther

Se passer totalement de la glibc est possible, ça a été fait pour Redox (un OS en Rust).

Le problème n'est pas au niveau de Rust mais de la plupart des OS, pour lesquels la libC c'est ce qui sert d'interface stable au kernel. Rust n'y est pour rien, il en a besoin si il veut pouvoir utiliser les fonctionnalités de l'OS (thread, IO, allocation mémoire,...) sans risquer d'être cassé par une mise à jour.
29/03/2021, 15h27
gangsoleil

Citation:

Envoyé par Uther

Chacun a le droit de faire ce qu'il veux au niveau qu'il veut. Parfois ça ne sert a rien, mais si Linus Torvalds n'avait pas choisi de faire son propre noyau "just as a hobby" au lieu de participer à un truc plus professionnel comme GNU Hurd, on aurait pas eu Linux.

Je n'ai jamais dit qu'ils n'avaient pas le droit de faire ce qu'ils veulent, je dis que je pense que ça ne sert à rien.
Est-ce que Linus Torvalds a cherché à refaire exactement ce qui existait, ou bien est-ce qu'il a fait autre chose :) ? Ici, on parle d'une ré-écriture isofonctionnelle.