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 !

Linus Torvalds explique pourquoi la longévité des développeurs Linux est une bonne chose : « C'est un bon signe »,
Lance-t-il sans répondre à la question du passage à la future génération de mainteneurs

Le , par Patrick Ruiz

28PARTAGES

11  0 
Les principaux mainteneurs du noyau Linux sont des quinquagénaires. Certains se rapprochent même de la soixantaine. Ce sont des âges pour lesquels on est considéré dans certains pays comme étant trop vieux pour exercer dans la filière du développement de logiciels. C’est donc sans surprise que la question du passage à la future génération de mainteneurs du noyau Linux revient constamment sur la table. Très évasif sur cet aspect, Linus Torvalds signe que « c’est une bonne chose que les vieux continuent à être à la manœuvre » tout en soulignant la difficulté le potentiel impact de cet état de choses sur l’intégration des jeunes mainteneurs.

« Il peut sembler difficile d’intégrer l’équipe de mainteneurs en tant que jeune qui voit tous ces séniors encore aux commandes », reconnaît-il. C’est en toile de fond le débat sur le choix entre le langace C et le Rust pour le futur du développement du noyau qui prend un coup de neuf. En effet, les principaux mainteneurs du noyau Linux sont des habitués du langage C dont l’âge commence par le chiffre 5. Certains se rapprochent même de la soixantaine. La nouvelle génération de mainteneurs du noyau Linux semble plutôt constituée d’utilisateurs du langage Rust dont certains se plaignent déjà du traitement que leur infligent les habitués du langage C.


Les habitués du langage C n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust

Les rapports font en effet état de ce qu’un sous-ensemble de contributeurs au noyau en langage C sont déterminés à rendre la vie dure aux mainteneurs Rust. Motif : Ils considèrent que Rust n’apporte pas de plus-value significative et préfèrent donc que ce langage de programmation soit mis de côté dans le cadre du développement du kernel.

Les mainteneurs du noyau réfractaires à la mise à jour des bases de code du noyau Linux vers le langage Rust ont fait savoir quelle est leur position lors d’une présentation des systèmes de fichiers Linux et des besoins en termes de migration des bases de code vers le Rust. Il était question pour ces derniers de créer des passerelles permettant de faciliter l’atteinte de cet objectif. L'un des membres de l'auditoire a exprimé son désaccord en disant : « Vous essayez de convaincre tout le monde de passer à la religion du Rust, mais cela n’arrivera pas. »


Ces derniers multiplient donc des attitudes qui frustrent certains mainteneurs Rust qui choisissent de quitter le navire : « Ce type de traitement est exactement la raison pour laquelle j'ai entamé le projet @redox_os en partant de zéro et en l'écrivant principalement en Rust. Il y a beaucoup de résistance aux changements bénéfiques, même mineurs, dans Linux et les projets connexes. C’est la raison pour laquelle je n'essaie même plus de contribuer au noyau Linux. Il y a des projets pour lesquels vous devrez inévitablement faire passer vos changements devant des mégalomanes pédants et condescendants, et si le noyau Linux n'est pas seulement développé par ce type de personnalité, il est aussi contrôlé par lui de manière écrasante. »


Linus Torvalds lui-même est pourtant d’avis que le langage Rust est une solution d’avenir pour le développement du noyau.

Il considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

En effet, il y a une liste de griefs qui reviennent à l’encontre du langage C : les problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. D’après les chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE), 15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans sont liées à des dépassements de mémoire tampon.

De plus, certains benchmarks suggèrent que les applications Rust sont plus rapides que leurs équivalents en langage C. Et c’est justement pour ces atouts que sont la parité en termes de vitesse d’exécution en comparaison avec le C, mais surtout pour la sécurisation et la fiabilité que de plus en plus d’acteurs de la filière du développement informatique recommandent le Rust plutôt que le C ou le C++.

Ainsi, en adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit ces atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo.

Source : Linus Torvalds

Et vous ?

Quel impact le comportement des habitués du langage C est-il susceptible d’avoir sur le futur du développement du noyau Linux ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

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

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

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

Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 22/10/2024 à 18:09
Linus Torvalds est de plus en plus frustré par le matériel bogué et les attaques théoriques du processeur
Moi aussi ! (mais on s'en fout)
9  0 
Avatar de eomer212
Membre confirmé https://www.developpez.com
Le 22/10/2024 à 18:50
je me rappelle d'une époque, l'époque "bénie" (j'étais jeune, beau, et je le suis toujours dans ma tête) ou n'y avait pas de coprocesseur, et ou il fallait comprendre comment calculer un sinus à partir d'entiers en assembleur.
bref, on devait ramer comme des malades pour sortir les processeurs et les cartes graphiques vga de leur létargie. il fallait comprendre le materiel, et en particulier le processeur, son fonctionnement et ses limites. qu'on pouvait éventuellement dépasser, par la ruse et l'intelligence.
une des astuces existantes était le déroulé de code.
on déroule des fonctions qui auraient du faire un saut pour boucler, pour éviter le plus possible les branchements qui brisent la prédiction ou le pré chargement de code du processeur.
c'est con, c'est basique, et c'est très, très efficace.
moi je dis ca. mais bon, je peux me tromper, mais je pense que ca doit encore marcher..
en passant, un petit coucou extrêmement révérencieux à Mr Torvald, à qui nous devons tous beaucoup.
10  1 
Avatar de JP CASSOU
Membre confirmé https://www.developpez.com
Le 24/10/2024 à 10:53
Ne parlons pas des sites, applis et logiciels bogués et inutilisables

De plus en plus complexes, lourds, lents, bogués et au final inutilisables au quotidien, au point qu'un acte d'achat ou une transaction avec l'internet actuel prend 5x plus de temps qu'une opération à la finalité identique effectuée avec le Minitel des années 1980.

Faudrait peut-être penser à faire un "gel des technologies" et arrêter de concevoir 40.000 frameworks, 2.500 langages de programmation et 38 tonnes de librairies.

Le 64 bits grand public existe depuis le début des années 2000.

Nous avons des applications métier dont on ne se sert pas (ou plus) étant donné leur lenteur et lourdeur au point de rendre les procédures manuelles plus rapides et fiables
7  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 24/10/2024 à 17:34
Citation Envoyé par floyer Voir le message
Dans l’exemple, le replay, c’est gratuit donc c’est toi le produit. Si tu regardes Netflix, il ok, c’est payant mais tu n’as pas de pub. Dans un marché bien fait, tu aurais une offre Premium sans pub.

Bon, le replay gratuit c’est un peu faux… les opérateurs payent les chaînes pour diffuser ce qui est gratuit via la TNT. (Mais en échange, il me semble qu’ils ont droit à une TVA moindre).
Netflix est payant, mais il ne faut pas croire que tu n'es pas aussi un produit. Tes habitudes de visionnage sont judicieusement étudiées.
6  0 
Avatar de petitours
Membre émérite https://www.developpez.com
Le 24/10/2024 à 11:21
Citation Envoyé par JP CASSOU Voir le message
Ne parlons pas des sites, applis et logiciels bogués et inutilisables

De plus en plus complexes, lourds, lents, bogués et au final inutilisables au quotidien, au point qu'un acte d'achat ou une transaction avec l'internet actuel prend 5x plus de temps qu'une opération à la finalité identique effectuée avec le Minitel des années 1980.

Faudrait peut-être penser à faire un "gel des technologies" et arrêter de concevoir 40.000 frameworks, 2.500 langages de programmation et 38 tonnes de librairies.

Le 64 bits grand public existe depuis le début des années 2000.

Nous avons des applications métier dont on ne se sert pas (ou plus) étant donné leur lenteur et lourdeur au point de rendre les procédures manuelles plus rapides et fiables
+1
L’évolution des "technos", avec des châteaux de carte compatibilités douteuses et tout cloud servent depuis une bonne 15n d'année uniquement des objectifs de captage client qui ne peut plus regarder un truc sans échapper à la pub, ou faire quelquechose sans laisser un log ou tout simplement plus disposer des données qu'il a envoyé sur une plateforme ou dans le cas des films qu'il a acheté, obligé de rester là, soumis à son prestataire pour continuer à profiter de ce qu'il a déjà acheté et le tout en se faisant assommer de pub ciblées par les données qu'il n'a pas voulu donner même s'il a évidement coché la 5ieme case en partant de la gauche sans quoi le bouton n’apparaissait pas.
Je trouve ça extrêmement frustrant de voir autant de moyens techniques et d'énergie mobilisée pour des services qui assurent de moins en moins la fonctionnalité de base.

Exemple hier soir, et de plus en plus fréquent. Je regarde un film en replay en me payant des tas de pubs (inutiles puisque elles créent en moi un profond rejet) et paf, erreur technique qui s'affiche à 20 min de la fin. On pourrait s'interroger sur la nécessiter d'une liaison internet et d'un serveur surpuissant pour simplement regarder un film mais j'ai surtout mis une bonne demie heure à retrouver là où j'en étais dans le film, car l'avance rapide était non seulement buguée à revenir sans arrêt à 0 mais en plus ça s’arrêtait à chaque période de pub pour me la passer en intégralité. L'appli c’était la pub au service du fournisseur, à la base ça sert à regarder des films, ça ne sait plus faire.

Tu achètes un film, tu ne peux pas le télécharger
Tu achètes de la musique ou le même film, tu as besoin d'une connexion internet et de continuer à payer la plateforme pour voir et écouter ce que tu as déjà acheté
5  0 
Avatar de JP CASSOU
Membre confirmé https://www.developpez.com
Le 25/10/2024 à 10:40

et le tout en se faisant assommer de pub ciblées par les données qu'il n'a pas voulu donner même s'il a évidement coché la 5ieme case en partant de la gauche sans quoi le bouton n’apparaissait pas.
D'un Internet ouvert des débuts, on en est arrivé à un Web fermé de toutes parts et un Net-poubelle:
- Obligation de créer un compte par site, ou pas loin
- Paywalls et cookieswalls, surtout les "Refuser et s'abonner"
- Pub omniprésente
- Résultats de recherche non pertinents
- Sites marchands qui t'imposent de remplir un formulaire de 50 champs pour connaître le prix d'un appareil
- 100% des forums sont à inscription obligatoire (corollaire: la V95 d'un forum est de moins de trois mois - La V95 correspond au temps écoulé entre l'ouverture du forum et le moment où 95% des posts ont été publiés)
- 99% des sites web sont obsolètes
- 90% des bannières cookies ne respectent pas le RGPD
- Pour une question technique, les 100 premiers résultats de Google, c'est du publi-rédactionnel
- 80% des sites web et intranets institutionnels (et aussi d'entreprises) ont une disponibilité inférieure à 95%.
- Le nombre de bugs dans les sites Web est proprement ahurissant. Lors de la période 2003 (ADSL chez moi) à 2012 (arrêt du Minitel), je faisais les démarches critiques sur le Minitel. Plus simple, plus rapide (surtout les 36.13 et 36.14 - les autres étant volontairement ralentis) et surtout plus fiable.

Je pense sincèrement qu'il faut repenser complètement le net en ajoutant un protocole sécurisé et simplifié, pour tout ce qui concerne le commerce en ligne, les démarches administratives, les banques et la santé.
Ce protocole devrait avoir les caractéristiques suivantes:
- Mode texte exclusivement
- Accès par authentification à plusieurs facteurs
- Limitation du poids des pages à moins de 200 Ko (sauf téléchargement)
- Utilisable pleinement sur des connexions très lentes
- Fiabilité proche de 100%

Bref, un protocole proche du Minitel ou Gemini (port 1965)
-
5  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 15/10/2024 à 14:08
Citation Envoyé par Jipété Voir le message
Et voilà comment on embrouille les gens :

2288 / 20 = 114,4 ! ! !
Ahurissant de constater que personne n'a remarqué ça...
En même temps c'est pas bien grave, on reste dans le même ordre de grandeur.
Il y a d'autres approximations bien plus embêtantes, comme le fait que ces erreurs ne représentent qu'un partie des erreurs que peut prévenir le Rust et qu'une bonne partie de la période remonte à une époque ou les vulnérabilités mémoire étaient peu surveillées.

Ces deux dernières années le nombre de CVE remonté est énormément plus élevé et c'est en très grosse majorité des erreurs mémoire qui viennent des drivers, preuve s'il en fallait que le choix de permettre de faire des drivers en Rust est pertinent.

Citation Envoyé par vVDB.fr Voir le message
Pourquoi n'y aurait il pas une relecture du code en C par une IA qui dirait votre code est merdeux, incompréhensible ?
Les problèmes du C sont-ils suffisamment documentés ? Documentation nécessaire pour entraîner une IA qui n'est qu'un bon automate probabiliste... On n'oublie pas qu'une IA est un truc instruit avec des biais et pas intelligent. C'est suffisant pour pas mal de contrôles.
Il y a depuis longtemps pas mal de contrôles de plus en plus fins, par des outils divers (fuzzer, analyseurs statiques, ...) beaucoup plus efficaces que des IA de type LLM, qui ne sont absolument pas adaptées. C'est très bien pour améliorer la sécurité mais ça n'est pas une aussi bonne garantie qu'un langage qui interdit complètement les erreurs mémoires..
4  0 
Avatar de Jules34
Membre émérite https://www.developpez.com
Le 24/10/2024 à 14:43
Citation Envoyé par petitours Voir le message
Je trouve ça extrêmement frustrant de voir autant de moyens techniques et d'énergie mobilisée pour des services qui assurent de moins en moins la fonctionnalité de base.
Disons que la technologie n'est pas mise au service des individus mais du marché et de ses attentes.

Ce qui fait que le marché ET la technologie finiront par faire l'objet d'un rejet massif, personne n'aime les pubs, personne n'aime être ciblé et surtout personne n'aime être pris pour un abruti... tout en payant pour ses services.
4  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 25/10/2024 à 16:00
À quoi bon créer un nouveau protocole… s’il ne distribue pas la pub, il sera boudé par les créateurs de contenus.

HTTP permet de distribuer du fichier texte… mais si les sites sont plus lourds (HTML, animation, etc…) c’est aussi plus attrayant. Pas sûr qu’un retour au Minitel ait un succès. (Il faut une adhésion des deux côtés). On peut très bien faire un site avec un sous ensemble d’HTML (H1/H2/P/A par exemple). Je note que Stéphane Bortzmeyer semble derrière gemini… mais son blog est déjà très simple en matière de présentation et ne devrait pas poser de problème de fiabilité de consommation de ressources, etc. (Ok pas si simple, le bandeau de navigation ne s’affiche pas sur le smartphone en mode portrait). On peut déjà faire simple avec ce que l’on a !
4  0 
Avatar de floyer
Membre éclairé https://www.developpez.com
Le 02/10/2024 à 12:54
Citation Envoyé par OuftiBoy  Voir le message
Voilà une partie très intéressante. Je reprend les chiffres donnés: 2288 en 20 ans. 2288/20 = 144,4. 15,9% de ces vulnérabilités à des problèmes lié au C (gestion mémoire, dépassement de tampons, allocation non libérées, accà des zones mémoire invalide ou libérée, etc)

15,9% de 144,4, c'est en arrondissant [B]30[/], soit 1,5 vulnéralité par an. Comparée à l'immense base de code du noyau linux, c'est particulièrement faible. Et ça n'implique certainement de changer le langage utilisé pour ce noyau.

1,5 par an cela fait peu… mais regarde :

https://www.cvedetails.com/product/4...l?vendor_id=33

645 vulnérabilité en 2024 (pas encore terminée) pour des corruptions de mémoire.

Même si cette année semble catastrophique, on est bien au delà des 1,5 par ans. (17 mini… 70 ou plus dans la plupart des années). On n’a pas les mêmes sources.

645 qui pourraient en grande partie être évité par une language plus sûr, cela fait réfléchir.
3  0