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 !

Fatigue des Mainteneurs dans le Noyau Linux et rôle de l'IA dans le développement open source
Une vision partagée par Linus Torvalds au sommet Open Source de la Fondation Linux

Le , par Bruno

16PARTAGES

7  0 
Lors de l'Open Source Summit Japan, Linus Torvalds, le créateur de Linux, a abordé divers sujets, tels que la prochaine itération du noyau Linux, la fatigue des mainteneurs et le rôle futur de l'intelligence artificielle (IA) dans le développement open source. Il a partagé des détails sur la version 6.7 du noyau Linux, soulignant que le rôle de mainteneur exige un goût pour évaluer le code des autres et une présence constante. De plus, il a évoqué son évolution personnelle en tant que leader de projet.

Au cours du sommet Open Source de la Fondation Linux au Japon, Torvalds a discuté de la situation actuelle de Linux avec son ami proche Dirk Hohndel, responsable de l'Open Source chez Verizon. Hohndel a soulevé la question de la fatigue des mainteneurs, notant que les mainteneurs du noyau Linux se sentent de plus en plus dépassés par ce rôle essentiel et exigeant.


Torvalds a répondu en soulignant qu'il est plus facile de trouver des développeurs que des mainteneurs, et que le rôle de mainteneur nécessite un certain goût pour juger le code des autres, une qualité qui peut être innée mais nécessite également de la pratique sur de nombreuses années.

En ce qui concerne l'utilisation de Rust dans le noyau Linux, Torvalds a souligné son importance pour éviter la stagnation, anticipant son intégration progressive dans des parties importantes du noyau au cours de l'année à venir. Il a noté que bien que Rust ne se soit pas encore imposé comme la prochaine grande nouveauté, son intégration active dans les pilotes et les sous-systèmes majeurs commencera dans l'année à venir.

En parlant de l'avenir, Hohndel a évoqué les "modèles de langage à grande échelle (LLM) de l'intelligence artificielle". Torvalds a exprimé sa conviction que l'utilisation de ces modèles pour écrire du code deviendra une réalité, soulignant que l'automatisation a toujours été présente dans le domaine de la programmation.

Les deux intervenants ont également discuté du prochain lancement du noyau Linux, Linux 6.7, avec Torvalds diffusant la quatrième version candidate avant son départ pour Tokyo. En prévoyant une sortie aux alentours de la période de Noël, Torvalds a souligné l'importance de la Fondation Linux en tant qu'espace neutre favorisant la collaboration au-delà des intérêts individuels et commerciaux, expliquant ainsi sa décision de soutenir la Fondation Linux plutôt que de travailler dans une entreprise Linux.

Diversité et inclusivité au sein de la communauté du noyau Linux

La discussion entre Linus Torvalds et Dirk Hohndel au sommet Open Source de la Fondation Linux offre un aperçu intéressant des défis auxquels sont confrontés les mainteneurs du noyau Linux. La question de la fatigue des mainteneurs, soulevée par Hohndel, met en lumière un aspect crucial et souvent négligé du développement open source.

La constatation que les mainteneurs se sentent de plus en plus dépassés dans leur rôle souligne une réalité préoccupante au sein de la communauté Linux. Cela souligne également la nécessité de trouver des solutions pour atténuer la pression exercée sur ces acteurs clés du processus de développement.

La réponse de Torvalds, bien que soulignant la difficulté de trouver des mainteneurs par rapport aux développeurs, met en avant la nécessité d'avoir un "goût" pour évaluer le code des autres. Cette caractéristique, qu'il considère comme innée et nécessitant des années de pratique, pourrait être interprétée comme une barrière à l'entrée pour ceux qui souhaitent prendre en charge le rôle de mainteneur. Cela pourrait susciter des questions sur la diversité et l'inclusivité au sein de la communauté du noyau Linux, en particulier si ces qualités sont perçues comme innées plutôt que développées avec le temps.


La remarque selon laquelle il est plus facile de trouver des développeurs que des mainteneurs soulève par ailleurs des questions sur la manière dont la communauté peut encourager davantage de personnes à assumer ces responsabilités critiques. Identifier des solutions pour rendre le rôle de mainteneur plus accessible et attractif pourrait contribuer à résoudre le problème de la fatigue des mainteneurs.

La discussion entre Linus Torvalds et Dirk Hohndel expose les défis et les préoccupations valables entourant la fatigue des mainteneurs, elle soulève également des interrogations sur la manière dont la communauté peut élargir et diversifier la base de mainteneurs pour garantir la pérennité et la vitalité du noyau Linux.

Source : Vidéo

Et vous ?

Selon vous, pourquoi Torvalds considère-t-il la Fondation Linux comme un espace neutre crucial pour la collaboration au-delà des intérêts individuels et commerciaux, par rapport à travailler dans une entreprise Linux ?

Que pensez-vous la diversité et l'inclusivité au sein de la communauté du noyau Linux dans le contexte de la difficulté de trouver des mainteneurs, selon les remarques de Torvalds ?

À votre avis, quelle est la perspective de Dirk Hohndel sur les modèles de langage à grande échelle de l'IA et leur impact potentiel sur l'écriture de code, et comment cela s'aligne-t-il avec les idées de Torvalds ?

Quelles sont les implications possibles de l'intégration active de Rust dans les pilotes et les sous-systèmes majeurs du noyau Linux, telles que mentionnées par Linus Torvalds ?

Voir aussi :

Rust dans le noyau Linux: un projet prometteur, mais pas sans complications. La communauté dresse un bilan, lors de l'édition 2023 du Kernel Maintainers Summit

Trois systèmes d'exploitation Linux axés sur les jeux battent Windows 11 dans les benchmarks de jeux : Arch Linux, Pop!_OS et Nobara OS, selon les résultats des évaluations de ComputerBase

Une nouvelle mise à jour de Systemd permettra à Linux de bénéficier de l'infâme "écran bleu de la mort" de Windows, mais la fonctionnalité a reçu un accueil très mitigé

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

Avatar de NotABread
Membre habitué https://www.developpez.com
Le 26/08/2024 à 16:27
@23JFK Qu'est-ce qui fait vieux/dégueulasse dans la syntaxe Rust ? As-tu un exemple que tu considères plus modern/exemplaire ?
5  0 
Avatar de NotABread
Membre habitué https://www.developpez.com
Le 26/08/2024 à 13:45
> Quels sont les avantages et les inconvénients de Rust par rapport au C pour le code du noyau ?
Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
La sécurité de la mémoire et de la concurrence garanti à la compilation et sans ramasse-miette est LE point fort de Rust. Cependant, Rust reste relativement jeune et son écosystème manque de maturité (lib parfois incompatible entre elle à cause du multithreading, grosse tendance à la sur-inclusion de dépendances, beaucoup en version 0.x, pas encore de framework UI qui se soit démarqué, ...)
C ne sera pas mis au placard par Rust dans la prochaine décennie au sein de Linux pour une simple: Linux est majoritaire écrit en C et le restera car aucun ne veut tout ré-écrire en Rust.

> Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
En théorie, on peut faire du code sûr en C, en pratique cela demande beaucoup d'effort et d'attention. Le monde est vaste et complexe, il y aura toujours un pour trouver un scénario tordu auquel le développeur n'aura pas pensé et qui causera une mauvaise manipulation de la mémoire. Même pour opensshd, logiciel solide et exemplaire, on a trouvé un scénario menant à une mauvaise manipulation de mémoire.
Il est facile de blâmer les développeurs mais ils restent humain, soumis à la fatigue, aux deadlines et aux ressources limités. L'usage d'un langage garantissant sûreté de la mémoire et performance permet de combler le manque d'attention ou de forcer la main sur les problèmes mémoires.

> Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?
Pour l'UEFI, BIOS, driver et microcode, oui, cela fera sense car se sont des parties critiques pour un OS, mais aussi parce que sont des programmes très isolé du reste en dehors de ce qu'ils exposent.
Pour des logiciels plus orienté utilisateur (tableur, logiciel de peinture, calculatrice, ...), non car tant que la haute performance et la stabilité ne sont pas primordiales (et que l'écosystème de Rust ne sera pas mature) il n'y a pas de raison à privilégier python ou un kit webapps à Rust
4  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 27/08/2024 à 2:58
Lambda calcul avec closure, tuples… ce sont des éléments de sémantique, pas de syntaxe. (La syntaxe c’est plutôt le choix des accolades, begin/end, parentheses…). Et ce n’est pas parce que le lambda calcul ou les tuples (proposé par Python d’ailleurs) datent de 1958 avec Lisp que c’est une mauvaise chose.

Les types… comment un langage peut être sûr en vérifiant la cohérence à la compilation des types sans cela ? Et côté performance, il faut bien des types statiques comme en C. Non je ne vois pas où est le procès.

Le typage dynamique (Lisp, Python, Javascript…) c’est bien pour des scripts, du prototypage… dès que l’on fait des choses plus sérieuses, le typage statique (Typescript…) s’impose, et dans les langages assez modernes, l’inference de type évite que ce soit trop une gêne.

En quoi let est redondant… il indique la déclaration d’une variable par opposition a une affectation qui ne marche qu’avec des variables déjà crées. Cette distinction contribue aux vérifications sémantiques et permet de détecter des erreurs. Par ailleurs il permet l’inférence de type (let a=42)… évitant de devoir préciser le type si celui inféré est adéquat.
4  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 27/08/2024 à 10:25
La syntaxe de Rust ne me semble pas parfaite non plus (je pense qu’il faut un peu d’habitude). Notamment pour les chaînes de caractères (où il y a pas mal de & à placer ici où là).

Mais critiquer la syntaxe avec let et les tuples alors que c’est assez naturel:

let tuple = ('Hello', 5, 3.14);

Je pense que l’exemple est fort mal choisi.

Bon évidemment tuple.0 surprendra le programmeur Python (habitué à tuple[0]). Mais pas de quoi disqualifier le language.
3  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 27/08/2024 à 19:47
Citation Envoyé par 23JFK  Voir le message
Pour le let, c'est surtout qu'il faille saisir 3 lettres à chaque fois... il ne semble pas y avoir d'opérateur séquentiel comme en C : pour être clair sa donne des trucs du genre ("en C" int a, b, c, d ; "en Rust" let a : u64 let b : u64 let c : u64 let d : u64 ) Désolé, mais à la fin, c'est le C qui gagne.

En Rust, on peut écrire :

Code Rust : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
fn main() { 
    let (a, b, c, d); 
    a = 1; 
    b = 2; 
    c = 3; 
    d = 4; 
    for (id, value) in [("a", a), ("b", b), ("c", c), ("d", d)] { 
        println!("{id} == {value}"); 
    } 
}
On peut aussi écrire :

Code Rust : Sélectionner tout
1
2
3
4
5
6
fn main() { 
    let (a, b, c, d) = (1, 2, 3, 4); 
    for (id, value) in [("a", a), ("b", b), ("c", c), ("d", d)] { 
        println!("{id} == {value}"); 
    } 
}
3  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 30/08/2024 à 7:49
Il y a de gros projet sérieux en Python mais le prob n'est pas là, on parle du noyau là. Je ne pense pas que le Python soit adapté à ça.
3  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 27/08/2024 à 17:47
Effectivement, si taper des lettres de plus t’est pénible, le C est peut-être préférable (peut-être lorgner sur APL réputé plus compact ?). Mais les constructions de plus haut niveau (pas de malloc à transtyper), free implicite, etc font que le language présente des avantages. J’avoue que j’aurais a priori plus confiance pour du code en Rust qu’en C. S’il compile, tu as déjà une partie des bugs potentiels détectés. Les autres aspects me semblent un peu secondaires.

(J’utilise actuellement plutôt OCaml qui est assez efficace, même si moins que C/Rust, mais présente le bon niveau d’abstraction).
2  0 
Avatar de NotABread
Membre habitué https://www.developpez.com
Le 27/08/2024 à 17:53
Je trouve la comparaison un poil injuste dans la mesure où le cas idéal de Rust est d'user de l'inférence de type alors qu'en C, on préféra expliciter le type.
Donc, en utilisant le typage automatique, Rust fait gagner une lettre (auto fait parti du standard 23 de C). Quite à pousser le vise sur le nombre de lettre, on peut compter le nombre de lettre des types de base:
- 'double' => 'f64'
- 'float' => 'f32'
- 'unsigned long long int' => 'u64'.
Bref, je trouve l'argument un peu léger, je ne pense pas qu'un code C en équivalent Rust soit significativement plus long pour le rayer des potentiels remplaçant de C.
Par contre mentalement, ça peut être agaçant de taper trois fois les même lettres partout dans le code.
2  0 
Avatar de prisme60
Membre régulier https://www.developpez.com
Le 10/01/2024 à 10:56
Comme toutes les nouveautés, cela se paye, mais cela est nécessaire pour avoir une amélioration de la qualité du noyau. Personnellement, je suis un fervent partisan du Rust, et des API bien construites. Une bonne API doit être intuitive et dans la mesure du possible rendre tout mauvais usage impossible. Pour un tel résultat, il faut notamment un typage fort que l'on a pas en C (C++). Le Rust sans unsafe interdit les transtypage à base de cast (comme caster un entier en pointeur, ou un pointeur d'un type dans un pointeur d'un autre type).
1  0 
Avatar de JPLAROCHE
Membre expérimenté https://www.developpez.com
Le 11/01/2024 à 15:42
Avoir une belle voiture au top de ses performances, répondant à ce que l'on attend d'elle, mais n'avoir qu'un seul ingénieur capable de remonter le réveil, n'est pas encourageant pour l'avenir, il est important d'activer l'engagement d'acteurs pour la suite de Linux.
ps( j'ai vécu cela )
1  0