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 s'exprime à nouveau à propos du débat sur le choix entre C ou Rust pour le développement du noyau Linux
Et laisse entendre que le Rust peut aider à corriger des erreurs commises en C

Le , par Patrick Ruiz

52PARTAGES

25  0 
Après plus de 30 ans, un deuxième langage a fait l’objet d’adoption pour le développement du noyau Linux : Le Rust. La situation à date est telle que les mainteneurs habitués au langage C refusent de porter le code existant en Rust ou de passer du temps pour aider d’autres contributeurs à le porter en Rust. Linus Torvalds s’est à nouveau exprimé sur ce débat et il en ressort que le langage Rust peut aider à corriger des erreurs commises en langage C.

« Le C est, en fin de compte, un langage très simple. C'est l'une des raisons pour lesquelles j'apprécie le C et pour lesquelles beaucoup de programmeurs C apprécient le C, même si le revers de la médaille est évidemment que, parce qu'il est simple, il est aussi très facile de faire des erreurs », a-t-il déclaré.

En effet, Linus Torvalds est 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.


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

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. »

Source : Linus Torvalds

Et vous ?

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 ?
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 ?
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 ?

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 Uther
Expert éminent sénior https://www.developpez.com
Le 21/09/2024 à 13:44
Comme pour a peu prêt tout ce qu'on dit a propos de Rust, il y a une petite astérisque implicite qui dit indique "* sauf si on utilise du code unsafe".

En l’occurrence, ces fonctions ne sont normalement pas utilisées directement. Elles sont utilisées en interne par les types de base de la bibliothèque qui font des allocations sur le tas comme Vec, Box, Rc, ... A moins de vouloir remplacer ces types par des implémentations maison, on en a pas besoin.
5  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 NotABread
Membre actif https://www.developpez.com
Le 20/09/2024 à 22:25
Ca dépend d'où tu mets ta barrière entre le haut niveau et le bas niveau. Dans la mesure où Rust t'impose de savoir ce qu'il se passe avec la mémoire et que cela est une forte contrainte dans l'écriture d'un programme, je dirai plutôt que Rust est bas niveau, à l'inverse de Python qui est très permissif sur l'écriture et masque la gestion de la mémoire.
Mais d'après certain, C serait un langage de haut niveau d'après la définition Wikipédia d'un langage de haut niveau
https://fr.wikipedia.org/wiki/Langag...de_haut_niveau
Un langage de haut niveau fait abstraction des caractéristiques techniques du matériel utilisé pour exécuter le programme, tels que les registres et les drapeaux du processeur
Aussi, Rust et C sont du même ordre de grandeur du point de vu performance. Pour certain problème, C est devant, pour d'autre c'est Rust. On peut dire qu'ils sont au même niveau en perf
https://benchmarksgame-team.pages.de.../rust-gcc.html

Le gros avantage du C reste sa simplicité, qui font qu'il est facile d'écrire un compilateur pour une plateforme personnalisé. Si on connait bien l'assembleur et le C, on sait à peu près ce que donnera l'assembleur d'un programme C
4  0 
Avatar de fdecode
Membre habitué https://www.developpez.com
Le 23/09/2024 à 11:16
Citation Envoyé par NotABread Voir le message
Le multithread est assez simple en Rust. Tu peux utiliser tokio pour te faciliter la vie, sinon tu as des thread que tu peux créer assez simplement, ou utiliser des coroutines (fonction marquée async).
J'ai l'impression que les coroutines restent privilégiée car la répartition de leur exécution sir les threads est faite efficacement de base.
Je ne comprends pourquoi utiliser tokio pour du multithread.
tokio te fournit un runtime pour faire de la programmation concurrente, et dans ce cadre de gérer plus de threads que n'autorise l'OS.
Mais la programmation multithread (non asynchrone) est directement accessible depuis la librairie standard.
Le fait d'être asynchrone complexifie sensiblement la programmation comparé au multithread. Et le multithread sans runtime est plus performant pour paralléliser des sections de calcul courtes:

https://stackoverflow.com/questions/76481940/is-there-any-performance-advantage-to-use-async-await-amid-synchronous-code
Async/await does not give you any parallelism, only concurrency. That means that any sync operation using async/await to divide the work will just run one part after the other, not faster than without async/await and in fact slower because it adds overhead.

You can only get parallelism via threads, and you are limited to the number of cores you have in your system.

Some async runtimes do run the code in parallel, using multiple threads, so you will get some parallelism (and therefore speed) if you'll use them correctly; but this just adds overhead over using threads directly, or using a library such as rayon that avoids async/await and parallelizes the code using threads only.

If you're not I/O bound, don't use async/await. You have nothing to gain.
Par exemple, j'aurais plutôt tendance à utiliser rayon pour paralléliser un calcul sur une collection.
Citation Envoyé par NotABread Voir le message
Le plus dur, c'est de satisfaire le borrow checker qui demandera que le thread/la coroutine possède ce qu'il veut modifier ou que les potentiels data race soient protégés par des types sûrs (et attention, le compilo ne protège pas du dead lock ni des goulots d'étranglement).
Au passage, les scopes permettent de faire du multithread (sans runtime) avec des références (non mutables tout au moins). Pour faire la même chose avec tokio, ... il me semblait que pour l'instant, il fallait transmuter du lifetime.

Citation Envoyé par Uther Voir le message
Oui en Rust les références sont de simple pointeurs bas niveau. La différence et que le compilateur surveille la façon dont ils sont utilisés et leve une erreur si leur usage est susceptible de commettre une erreur mémoire.
Rust a aussi des pointeur simples, mais ils ne sont déréférençables que sans les blocs unsafe
Pour compléter cette réponse, une référence est un pointeur avec en plus de l'information abstraite apportée par le typage pour permettre au compilateur de contrôler l'usage de la mémoire.
En C on a un exemple d'information porté par le typage, avec le mot clef restrict. En terme d'optimisation à la compilation, il produit des résultats similaires aux références de Rust.

En revanche, les pointeurs/references Rust sont des fat pointers pour les slices et les trait objects.
4  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