NB: Ceci est une traduction du courrier de Linus sur la liste de diffusion publique.
Mercredi, 19 Février 2025 à 22:42, Christoph Hellwig hch@infradead.org a écrit:
Le document prétend qu'aucun sous-système n'est forcé d'utiliser Rust. Linus a démontré que c'était faux. Et bien que vous ne le saviez peut être pas quand vous avez écrit ce document, vous le saviez parfaitement quand vous avez posté sur cette liste.
J'avais espoir que cette longue discussion aboutisse à quoi que ce soit de constructif, mais il semblerait que tout va de travers (ou tout du moins, le débat n'avance pas).
Dans les fait, la "pull request" que tu as rejeté NE TOUCHAIT PAS LA COUCHE DMA DU TOUT.
C'était littéralement juste un autre utilisateur de cette couche, dans un sous-répertoire complètement séparé, qui ne changeait pas le code que tu maintiens d'un quelconque manière.
Je trouve pénible que tu te plaignes de nouveaux utilisateurs de ton code, et que tu continue d'apporter ce type d'argument de merde.
Honnêtement, ce que tu as fait, c'est basiquement dire "en tant que mainteneur du DMA, je contrôle comment le code du DMA est utilisé".
Et ça n'est pas du tout comme ça que les choses fonctionnent.
C'est quoi la suite ? Dire qu'un driver en particulier ne peut pas utiliser le DMA, parce que tu n'aimes pas ce périphérique, et en tant que mainteneur tu contrôle qui peut utiliser le code ?
C'est littéralement ce que tu essayes de faire avec le code Rust.
Tu dis que tu es en désaccord avec Rust (dans le noyau Linux), ce qui est acceptable, personne ne t'as jamais obligé d'écrire ou de lire du code Rust.
Mais après, tu prends cette position pour affirmer que le code Rust ne peut même pas utiliser ou s'interfacer avec du code que tu maintiens.
Alors laisse moi être très clair: si en tant que mainteneur tu estimes que tu contrôle qui ou quoi utilise ton code, TU TE TROMPES.
Je te respecte techniquement, et j'aime travailler avec toi.
Et non, je ne cherche pas des gens qui disent "Amen" à tout, et j'aime bien quand vous me reprenez sur mes conneries. Je dis parfois des choses stupides, et il y a besoin de gens pour me tenir tête quand je débite de la merde.
Mais maintenant, c'est moi qui tiens tête à TON débit de conneries.
Donc ce courrier n'est pas à propos d'une quelconque "Politique Rust". Ce courrier est à propos d'un bien plus gros problème: en tant que mainteneur, tu es responsable de ton code, ok - mais tu n'es pas garant de qui l'utilise ni comment il est utilisé.
Tu n'as pas a aimer Rust. Tu n'as même pas t'en soucier. Cela a été clarifié dès le tout début, personne n'est soudainement obligé d'apprendre un nouveau langage, et les gens qui veulent uniquement travailler sur la partie C peuvent très bien continuer à le faire.
Donc pour revenir au coeur de ton propos :
Le document prétend qu'aucun sous-système n'est forcé d'utiliser Rust.
C'est bien vrai.
Tu n'es pas forcé d'accepter du code Rust, ou de te soucier de code Rust dans le DMA. Tu peux l'ignorer.
Mais "ignorer la partie Rust" signifie automatiquement que tu n'as aucun mot à dire non plus.
Tu ne peux pas avoir le beurre et l'argent du beurre. Tu ne peux pas dire "Je ne veux rien avoir à faire avec Rust", et ensuite dans la phrase suivante dire "Et ça signifie que le code Rust que je vais ignorer ne peux pas utiliser les interfaces C que je maintiens".
Les mainteneurs qui veulent s'impliquer dans la partie Rust peuvent le faire, et en étant impliqués, il vont avoir leurs mot à dire sur la conception des "bindings" Rust. Basiquement, ils deviennent également les mainteneurs des interfaces Rust.
Mais les mainteneurs qui choisissent "Je ne veux rien avoir à faire avec Rust" n'auront bien évidement pas besoin de se soucier des "bindings" Rust - mais en conséquence, ils n'auront également rien à dire sur ce qu'il se passe dans la partie Rust.
Donc quand tu changes les interfaces C, les développeurs Rust vont devoir gérer les retombées et corriger les "bindings" Rust. C'est un peu la promesse ici : il y a ce "mur de protection" autour des développeurs C qui ne veulent pas gérer les problèmes avec Rust, ils n'ont pas à se préoccuper de Rust.
Mais ce "mur de protection" va dans les deux sens. Si tu ne veux pas te préoccuper du code Rust, tu n'as rien à dire sur le code Rust.
En d'autres termes : le "personne n'est forcé de se préoccuper de Rust" ne veut pas dire "tout le monde est autorisé à mettre son veto sur du code Rust".
Tu vois ?
Et non, je ne pense pas qu'il y ait besoin que ce soit tout "noir et blanc". J'ai expliqué ci-dessus d'une manière très "noir et blanc" ("devenir mainteneur des "bindings" Rust également" vs "ne pas vouloir se préoccuper du tout de Rust"), mais dans bien des cas je suppose que la ligne sera bien plus floue, où un mainteneur d'un sous-système peut être conscient de l'existence des "bindings" Rust, et disposé à travailler avec la partie Rust, mais sans être très impliqué.
Donc vraiment, il n'y a pas besoin que cela soit "tout ou rien".
-- Linus
# Correction
Posté par Sébastien Le Ray . Évalué à 3 (+2/-0).
J'ai pertinenté (même si un peu de contexte aurait pas fait de mal) mais
"Cela a été prouvé incorrect par" c'est pas naturel, on n'utilise pas la voie passive pour ça en français, "Linus a démontré que c'était faux" pique moins les yeux.
Il manque les s
Impliqués, ils vont
À mettre son véto sur du code rust
Où
Voilà c'était le commentaire relou du matin (possible qu'en plus j'en ai loupé je suis sur le téléphone)
[^] # Re: Correction
Posté par David Delassus (site web personnel) . Évalué à 4 (+2/-0).
Merci pour les corrections !
J'avoue que j'ai encore du mal avec certaines expressions anglaises, je les comprends mais les retranscrire est parfois difficile. Je suis pas traducteur professionnel après tout :p Mais j'aime bien cet exercice occasionnel.
Si un modérateur peut éditer :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: Correction
Posté par Julien Jorge (site web personnel) . Évalué à 3 (+1/-0).
C'est fait, avec quelques modifs supplémentaires. Et merci pour cet intéressant journal :)
[^] # Re: Correction
Posté par Uther Lightbringer . Évalué à 3 (+2/-0).
Il faudrait également corriger "soir" en "soit" dans :
[^] # Re: Correction
Posté par gorbal . Évalué à 1 (+0/-0).
mais peut être pas très impliqué.
-> mais sans être très impliqué.
[^] # Re: Correction
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10 (+16/-1).
J'irai même plus loin !
Je réécrirais « bien que vous ne le saviez peut être pas quand vous avez écrit ce document, vous le saviez parfaitement quand vous avez posté sur cette liste » en « bien que vous ne le sussiez peut être pas quand vous écrivîtes ce document, vous le saviez parfaitement quand vous postâtes sur cette liste. »
Voilà. C'est important, quand même.
[^] # Re: Correction
Posté par legranblon (site web personnel) . Évalué à 0 (+0/-2).
Zut, mon doigt a moinsé par inadvertance, alors que j'aurais bien plussé …
[^] # Re: Correction
Posté par Zorro (site web personnel) . Évalué à 1 (+0/-0).
C'était beau, quand même, je trouve, le beau style.
# liens connexes
Posté par Krunch (site web personnel) . Évalué à 7 (+5/-0).
https://linuxfr.org/users/antistress/liens/ep1-linus-torvalds-would-reportedly-merge-rust-kernel-code-over-maintainer-objections
https://linuxfr.org/users/antistress/liens/ep2-greg-kroah-hartman-makes-a-compelling-case-for-new-linux-kernel-drivers-to-be-written-in-rust
https://linuxfr.org/users/woffer/liens/greg-k-h-tout-nouveau-code-ecrit-en-rust-pour-le-noyau-linux-est-un-gain-pour-tous
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: liens connexes
Posté par Frédéric COIFFIER . Évalué à 3 (+2/-0).
L'historique de l'affaire (en anglais) et qui date déjà du 30 janvier : https://lwn.net/Articles/1006805/
[^] # Re: liens connexes
Posté par vpo . Évalué à 1 (+0/-0).
Comme je voulais comprendre mais que je suis trop crevé et trop pressé pour lire le doc en anglais et en faire un résumé en français, j'ai demandé à un moteur de recherche avec de l'IA dedans de bien vouloir le faire pour moi. Ca vaut ce que ça vaut, mais c'est assez proche de ce que me propose aussi un "copilote" dans une suite bureautique affreusement propriétaire mise à disposition par mon employeur. Donc j'en déduis que le résumé doit être assez fidèle.
https://www.perplexity.ai/search/resume-en-francais-cet-article-nhWBzzz9S0aBnnxxb58wgQ
[^] # Re: liens connexes
Posté par da_kal . Évalué à 2 (+4/-3). Dernière modification le 22 février 2025 à 21:16.
Microsoft investi dans Rust
Azure vers Rust, ou ici
Microsoft migrent ses cores libs en Rust
Si Microsoft est même en avance sur nous où va le monde mon bon Monsieur ?
J'y pense en secouant le cocotier on va récupérer pleins de devs Microsoft s'ils se mettent à faire du Rust! Non?
# Clair
Posté par Jean Gabes (site web personnel) . Évalué à 10 (+13/-0).
Ça a le mérite d'être clair, et assume bien les choix de protéger les dev C qui sont encore majoritaire, et faire porter l'effort aux Rust. Et ce que ça implique comme limite de responsabilité entre dev et utilisateurs d'une interface.
Maintenant imaginez qu'un CTO dans votre propre société soit aussi clair sur ce qu'il sacrifie et pourquoi. Ça change non? :)
[^] # Re: Clair
Posté par nud . Évalué à 4 (+3/-1).
Clair mais un peu tardif.
[^] # Re: Clair
Posté par Jean Gabes (site web personnel) . Évalué à 3 (+2/-1).
C'est tout à fait vrai. Il semble dire qu'il attendais que ça se calme de soit même, mais en effet un mainteneur qui refuse le code d'un utilisateur, il aurait dû poper à ce moment là, et pas attendre. Et on ne peux pas dire que ça n'a pas fait du bruit.
[^] # Re: Clair
Posté par sebas . Évalué à 9 (+7/-0).
C'est peut-être le temps qu'il a pris pour étudier le code, pour pouvoir ensuite faire en connaissance de cause cette affirmation :
[^] # Re: Clair
Posté par uso (site web personnel) . Évalué à 10 (+9/-0).
Tu peux aussi rajoute le fait, que quelques postes plus haut, des mainteneurs disent avoir parlé en privé avec Linus.
Je suppose que ça à du pas mal discuter avant de répondre en public.
[^] # Re: Clair
Posté par Gof (site web personnel) . Évalué à 5 (+5/-2).
Ça prends moins d'une minute de regarder le patch et de voir que ça ne touche que des fichiers dans le répertoire
rustet aucun fichiers dans le répertoirekernel/dmani aucun autre répertoire dont Christoph Hellwig est mainteneur.Le patch en question touchait les fichiers suivants :
https://lwn.net/ml/all/20250108122825.136021-1-abdiel.janulgue@gmail.com/
[^] # Re: Clair
Posté par Christie Poutrelle (site web personnel) . Évalué à 10 (+10/-0).
Un commentaire avisé disait sur Phoronix (un sacré repaire de vieux réac' quand même) qu'il a probablement décidé volontairement de rester en retrait un temps pour voir si les choses s'arrangeraient d'elles même, de ne pas faire d'ingérence entre les responsables de subsystem et les contributeur. Il a probablement décidé de réagir au bon moment, quand il a vu que ça ne s'arrangeait pas et se transformait en drama. Ce n'est qu'un point de vue, il n'y avait probablement pas de "bon" moment pour ça, le fait d'y arriver dénote des points de contentions assez grave parmi les développeurs, et que certain abusent de leur position pour refuser systématiquement ce qu'ils n'aiment pas, ou quand ça provient de gens qu'ils n'aiment pas.
[^] # Re: Clair
Posté par mrintrepide . Évalué à 4 (+4/-1).
Les commentaires sur Phoronix (et la non-modération) m'ont stupéfait.
Hector Martin s'en est tellement pris, alors qu'il ne voulait qu'utiliser une interface Rust pour le DMA.
[^] # Re: Clair
Posté par Faya . Évalué à 10 (+18/-1).
Je suis allé lire, histoire de me faire une idée, :
OK… Je continuerai à ne pas lire les commentaires sur Phoronix.
[^] # Re: Clair
Posté par uso (site web personnel) . Évalué à 0 (+1/-2).
Un peu HS, mais si quelqu'un aurait posté ce commentaire ici, il ne se serait surement pas fait censurer, mais bien moinsser.
À votre avis, c'est due à quoi la différence de qualité entre linuxfr, et phoronix ?
La différence culturelle entre les États-Unis, et la France, la manière dont linuxfr est structuré avec ces pertinantage/mojnsage ou autres choses ?
[^] # Re: Clair
Posté par Faya . Évalué à 7 (+5/-0).
Pour être honnête je ne pense pas qu'on puisse dire qu'il y a "une différence de qualité entre linuxfr, et phoronix." Ou du moins pas sur la base de ce seul commentaire… Je suis sûr que certains ici auraient pu tenir le même discours, et là-bas il y a eu plusieurs réponses pour en montrer l'absurdité.
Ils nous ressemblent pas mal sur l'aspect "un sacré repaire de vieux réac'" mais le simple fait de traîner sur un forum internet c'est déjà un truc de vieux donc ça n'est sûrement pas étonnant.
[^] # Re: Clair
Posté par uso (site web personnel) . Évalué à 5 (+4/-0).
Effectivement, ceci dit de mémoire, les commentaires de phoronix, ont quand même tendances à être plus trollesque, et moins ouverts aux longs débat…
Par exemples, la dernière Foix que je suis allé voir un thread gcc vs clang, il me semble que les commentaires s'arrêtais à "gcc doit mourir" avec rarement de longue réponse explicative pour défendre une idée, comme on le trouve souvent sur linuxfr.
Ceci dit, en disant ça, je pense que j'ai un peu répondu à ma question, les commentaires de linuxfr, sont triés par réponse, ce qui crée plusieurs threads, et permet plus les débats.
Pour linuxfr "repère de vieux react", j'ai l'impression que généralement les journaux bien réactionnaires, pour défendre des idées d'extrêmes droites, sont rarement au-dessus de -20, donc il y a des react, mais ce sont pas eux qu'on entend le plus. (alors que les journaux bien à gauche tournent plus autours des -5/-10, mais arrive à être dans le positif des-fois)
Vieux con a la limite, on a encore toutes les news sur Window Maker. (et c'est très bien comme ça)
[^] # Re: Clair
Posté par barmic 🦦 . Évalué à 10 (+9/-1).
Les problèmes sont là depuis des mois. L'été dernier Linus expliquait que la situation était tendue. Il y a eu plusieurs départ de développeurs ou développeuses rust. Dont récemment le lead du projet Asahi après s'être fait prendre à parti violemment par Linus après que le développeur se soit trop étalé sur les réseaux sociaux.
L'entrée de rust dans le noyau est compliqué et c'est normal. Le problème n'est pas technique mais humain. Il y a une question de responsabilité mais aussi de communication importante. Il semble clair par exemple que les mainteneurs du projet placent leur ego dans le code qu'ils maintiennent. Voir débarquer un groupe de nouveaux qui t'expliquent que tes APIs sont mal décrites n'est pas particulièrement confortable.
Linus fait du Linus. Il aboie de temps en temps pour que les gens fassent moins de bruit, mais nous ne sommes pas dans une situation qui mène à des consensus forts. Tout le monde va souffrir mais tenter de continuer à avancer et bon an mal an les choses vont arriver sur un consensus mou. Dans l'intervalle un certains nombre de personnes auront jeté l'éponge.
Remarquez par exemple que le lead d'Asahi aura trouvé plus simple de s'attaquer à Apple Silicone que de contribuer à linux.
Il n'y a pas de solution simple mais je ne vois pas les aboiement de Linus comme la solution parfaite
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Clair
Posté par patrick_g (site web personnel) . Évalué à 10 (+13/-0).
Pour contribuer substantiellement à Linux il faut de la persistance et il faut éviter le drama qui braque les mainteneurs. Le lead d'Asahi a voulu obtenir une intégration trop rapide de son code et, quand il y a eu de la résistance, est parti chouiner sur les réseaux sociaux.
Tout ce qu'il ne faut pas faire.
Contraste ça avec le comportement exemplaire de Miguel Ojeda qui travaille inlassablement à convaincre les réticents, qui est constructif et persistant et qui sait que l'intégration de Rust dans le noyau est un marathon et pas un sprint.
[^] # Re: Clair
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Je te dis pas le contraire. Je dis que c'est de l'humain autant pour Asahi que pour ce dont parle Linus dans le journal (tu as d'autres exemples comme Christoph Hellwig qui explique que rust est un cancer). Ça n'est pas simplement des règles qu'il faut (c'est nécessaire mais pas suffisant) c'est que les gens arrivent à échanger de manière apaisée.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Clair
Posté par mrintrepide . Évalué à 3 (+2/-0).
Ce n'était même pas son code (l'api Rust pour DMA), c'est celui d'Abdiel Janulgue.
Il en avait besoin pour l'utiliser ailleurs. Le patch en était à la V8 pour être rejeté pour "no Rust code in DMA".
[^] # Re: Clair
Posté par reno . Évalué à 9 (+8/-1).
Il n'y en a pas car il y a des inconvénients à l'intégration de Rust dans Linux:
1. Rust n'a pas de spec ce qui va compliquer la vie des développeurs de gcc qui veulent compiler Rust.
2. clang ne supporte pas tout les systèmes que gcc supporte.
3. Linux utilise une version "nightly"(instable) de Rust.
4. un projet multi-langages est + compliqué à gérer qu'un projet "mono"-langage, spécialement quand un des langage est Rust car c'est un langage complexe, Zig/Odin/DasBetterC auraient été probablement plus simple à intégrer mais Zig n'est pas 1.0 (et n'est pas prêt de l'être) et les autres ne sont pas à la mode..
Ce qui ne veut pas dire qu'intégrer Rust dans Linux soit une mauvaise idée, clairement Rust apporte plein de bénéfices ne serait-ce que faire baisser la moyenne d'âge des contributeurs à Linux..
[^] # Re: Clair
Posté par Marotte ⛧ . Évalué à 6 (+4/-1). Dernière modification le 23 février 2025 à 21:31.
Entièrement d’accord. L’utilisation d’un langage différent de C (ou de code en assembleur quand ça se justifie) ne peut pas être refusé par principe. Par contre, absolument aucune concession ne peut être faite qui impliquerait une baisse de qualité du développement du noyau dans son ensemble, de l’organisation, et je dirais même : de l’intuition de Linus en ce qui concerne Linux.
C’est une question que je me suis déjà posé, sans creuser vraiment parce que je n’ai aucun intérêt à la faire mais : pourquoi Linux n’a jamais été forké ?
C’est là toute la puissance du libre, si Linus finit par être à côté de la plaque et prend de mauvaise décisions c’est tout naturellement qu’il y aura un fork.
Pour ma part je lui fait encore confiance et je suis persuadé que ses critiques sont justifiés. On ne peut pas faire des compromis pour des gens qui pense que développer en Rust le noyau Linux représente un quelconque avantage en soi. Et j’apprécie énormément Linus, autant que Linux, je suis complètement en accord avec sa façon de voir les relations humaines.
Amen ! ^^
[^] # Re: Clair
Posté par arnaudus . Évalué à 4 (+3/-2).
Android, ça compte pas?
La taille de la base de code est peut être un chouilla impressionnante pour un candidat au fork.
Mouais, enfin Linux ça se forke pas non plus comme ça. Il faudrait un accord de principe au moins entre les gros contributeurs, ce qui serait tellement énorme que l'équipe actuelle serait forcément au courant, et aurait l'occasion de discuter pour éviter le fork si c'était possible (voire de faire partir Linus si c'était lui le problème).
Je ne sais pas s'il y a beaucoup de gens qui sont en accord avec sa façon de voir les relations humaines.
De toutes manières, c'est très fréquent que la meilleure personne pour monter un truc ne soit pas du tout la meilleure personne pour le faire évoluer à long terme. C'est une règle pour les startups par exemple, qui sont en général revendues après leur succès pour mettre en place une équipe de direction qui va savoir gérer la phase suivante (où on ne peut plus faire n'importe quoi très vite). La longévité de Linus à la tête du noyau, en partant de son garage pour finir à gérer des consensus entre les 20 plus grandes multinationales IT du monde, reste assez impressionnante. Dans tous les cas, c'est seulement sa compétence technique qui peut expliquer sa longévité, parce que sans ça il aurait giclé depuis très très longtemps.
[^] # Re: Clair
Posté par Renault (site web personnel) . Évalué à 6 (+3/-0).
En effet, ça ne compte pas.
Déjà il faut clarifier ce dont on parle. Linux est un noyau c'est ce projet qui est édité par la Linux Foundation et maintenu par Linus Torvalds et les autres mainteneurs qui travaillent avec lui.
Android est un système d'exploitation complet qui utilise Linux et plein d'autres composants qui serait donc équivalente plutôt à Ubuntu / RHEL / Debian / Fedora, etc.
Android est vraiment différent sur plein d'aspect par rapport aux autres distributions, mais concernant le noyau lui même ce n'est pas très différent. Il y a quelques centaines / milliers de correctifs en dehors du noyau Linux "officiel" (mais c'est le cas pour toute distribution de toute façon), certains finissent dans le temps dans la branche principale, d'autres pas.
Ce n'est donc pas un fork car ils se basent toujours sur la branche principale pour fournir de nouvelles versions de leur côté, comme toute distribution Linux classique.
C'est en effet compliqué mais pas impossible.
S'il y a vraiment consensus que Linus Torvalds gère mal le projet d'une façon ou d'une autre, un fork pourrait arriver par un accord entre les gros contributeurs qui sont des entreprises. Ou en poussant Linus Torvalds à la retraite du projet.
[^] # Re: Clair
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Il me semble que pendant un temps Google a maintenu un fork de linux pour AOSP/Android.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Clair
Posté par gUI (Mastodon) . Évalué à 9 (+6/-0).
Non pas à ma connaissance. J'ai bossé sur l'AOSP de Gingerbread à Oreo, il n'y avait pas du tout de fork du kernel. Certains patches particuliers certes, mais comme bcp de fabricants font dans l'embarqué.
Je ne vois pas en quoi il feraient un "fork" de Linux, ça n'a strictement aucun intérêt, mis à part se cogner un boulot gigantesque qui serait fait gratuitement sinon.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Clair
Posté par arnaudus . Évalué à 4 (+1/-0).
Ça me semble tendu de définir le fork de cette manière, parce qu'il est quand même assez courant que les forks intègrent au fil de l'eau les corrections de bugs ou autre issus de la branche principale…
Il me semble qu'Android était né d'un fork assumé, par la volonté de pouvoir développer vite sans devoir gérer l'intégration des patches dans la branche principale. Mais c'était aussi clair que le fork n'avait pas forcément vocation à être défintif, puisque l'espoir de convergence était réel.
Tiens, grâce à un ternet, j'ai retrouvé ça, par exemple dans https://www.zdnet.com/article/linus-torvalds-on-android-the-linux-fork/ qui date de 2011:
"So, for the next few years, Android, while still a Linux, is indeed a Linux fork. In the long run, though, Torvalds is sure that Android will return to the mainstream Linux kernel. For better or worse though that may not be until 2016. Fortunately, for all end-users and almost all Android developers none of this will make any real world difference."
Donc, ça compte, ça ne compte pas comme un fork… C'est quand même pas si net. C'est un ex-fork, peut-être.
[^] # Re: Clair
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
Enfin là on ne parle pas de deux projets distincts qui de temps en temps se recopient des correctifs, on parle du fait que le noyau Linux d'Android c'est toujours le noyau Linux "principal" + une collection de correctifs maison.
C'est très différent, Android tire en permanence profit de ce qui arrive dans la branche principale et n'a clairement pas les ressources pour faire évoluer le noyau de manière totalement indépendante dans leur coin.
Mouais, c'est une branche out of tree comme on dit, comme l'a été pendant longtemps la branche Linux-rt par exemple, à mon sens ce n'est pas un fork.
Mais pour Torvalds c'était important que Android réduise l'écart avec le noyau Linux de base, car certains correctifs sont pertinents pour tout le monde, et cela simplifie la maintenance.
L'écart entre le Linux AOSP et Linux vanille a été fortement réduit aussi par rapport à cette époque. Mais même à l'époque le considérer comme "fork" n'a pas beaucoup de sens. Au sens git du terme c'était (et c'est toujours vrai) car ce sont des branches à part mais dans ce cas là le Linux vanille n'existe nul part car toutes les distributions ont leur propres branches +/- modifiées. D'autant plus que Android comme toutes les distros se rebasent toujours sur le noyau Linux principal, l'inverse étant faux. Le flux est donc toujours à sens unique ce qui confère le caractère "Linux officiel" qui fait référence pour tous ces projets.
Comme ce ne sont pas des projets indépendants à partir d'un point spécifique dans l'historique du code source, les considérer comme fork me semble abusif. Google ne développe pas un projet Linux indépendant du reste de l'écosystème maintenu uniquement par ses soins, s'ils voulaient remplacer le job abattu par le projet Linux officiel ils devraient recruter pas mal de monde en plus. En ce sens ils dépendent toujours des décisions de Torvalds et de ses mainteneurs.
[^] # Re: Clair
Posté par arnaudus . Évalué à 5 (+3/-1).
Linus a dit en 2011 "Android is a Linux fork", donc on peut discuter éternellement si à ton sens c'est un fork, mais c'est légitime de dire qu'Android a été un fork de Linux (en tout cas, c'était l'avis du responsable de Linux à ce moment, donc c'est un avis qui me semble tout à fait crédible).
Donc oui, Linux a été forké, et le fork a été progressivement réintégré dans le projet par des efforts des deux côtés. "Fork avorté", "faux fork", "fork temporaire", tu peux l'appeler comme tu veux, mais c'est faux de dire que Linux n'a jamais été forké.
[^] # Re: Clair
Posté par Renault (site web personnel) . Évalué à 3 (+4/-4).
Je pense que c'est surtout une question de définition plus qu'autre chose ici. J'ai bien précisé ce que j'entendais par fork ce que Linus n'a pas expliqué dans ce texte et selon la définition que je donne (qui me semble être la plus courante) Android n'a jamais été dans ce cas de figure.
Et je ne trouve pas la définition sous entendue par Torvalds (à savoir qu'Android avait des correctifs en dehors de la branche principale) soit très intéressante pour décrire cette situation, il y a d'autres termes plus adaptés selon moi comme branch out of tree.
[^] # Re: Clair
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Le projet deal quotidiennement avec ce genre de décisions.
La plupart de tes remarques consistent à dire qu’il y a plusieurs langages.
C’est pas dis qu’ils auraient étaient bien plus simple et payer le coût d’avoir 2 stacks pour avoir un second langage qui fait doublon avec celui que tu as déjà ne vaut pas forcément le coût. L’objectif c’est d’avoir la possibilité d’écrire un code plus sûre pas d’avoir un autre langage sinon C++ aurait était un candidat.
Odin semble être fait pour le confort plus que pour la sûreté. Tu peut appeler le langage D comme tu veux, je crois qu’on peut dire que D a échoué l’objectif qu’il s’est donné d’être le successeur de C. Pour Zig j’en sais rien. Mais ce que tu appelle hype (après 20 ans parler de hype est condescendant AHMA) c’est ce qui fait la différence entre se retrouver seul utilisateur du langage (et donc avoir une grosse dette technique) et avoir quelque chose de pérenne.
Si tu te pose la question de pourquoi rust GKH a rédigé un mail pour toi : https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Clair
Posté par Gof (site web personnel) . Évalué à 8 (+6/-0).
Note que le noyaux utilisé le dialecte GNU du C, qui lui non plus n'a pas de spec, et qui complique la compilation du noyaux avec clang par exemple.
Par exemple ? Est-ce que ces systèmes ont encore in intérêt pour de nouveaux drivers ou sous systèmes fait en Rust ?
C'est en effet in problème. Mais c'est aussi une solution temporaire. Car les développeurs Rust travaillent activement pour stabiliser les fonctionnalités nécessaire.
Oui, probablement.
# mode Brice on
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+9/-7). Dernière modification le 22 février 2025 à 11:17.
Bref les développeurs Rust quand y en a un ça va, mais dès qu'il y en a plusieurs, c'est là qu'il y a des problèmes.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mode Brice on
Posté par David Delassus (site web personnel) . Évalué à 5 (+6/-3).
Bref, les développeurs C quand ils codent ça va, mais dès qu'ils parlent, c'est là qu'il y a des problèmes.
A mince, on est plus vendredi, il aurait fallu attendre la semaine pour troller.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
[^] # Re: mode Brice on
Posté par Marotte ⛧ . Évalué à 4 (+6/-5).
TL;DR: Pourquoi des contributeurs souhaitent-ils écrire des parties du noyaux Linux en Rust ? Quel est cet intérêt, ou quels sont-ils, si important qu’il pourraient justifier une complexification global du projet, à plusieurs égards et de façon assez évidente.
Aucun langage à ce jour s’est montré à même de remplacer le C. S’il n’est pas devenu aussi rare qu’un Fortran ou Cobol, et qu’une « nouvelle » standardisation voit le jour tous les 15 ans environ, c’est peut-être qu’il est en pratique impossible de faire mieux en matière de langage, pour avoir un langage qui soit à la fois « de haut niveau », et réduit au strict minimum afin de rester assez générique pour être une abstraction des différents codes assembleurs.
En 2025 les ordinateurs fonctionnent toujours en manipulant des « mots mémoires », des « adresses ». Leurs architectures n’ont fondamentalement pas changé.
J’ai le souvenir d’une personne ayant appris le C très jeunes et n’ayant jamais fait le moindre effort pour s’ouvrir à un autre langage , qui répondait à celles et ceux qui lui demandaient pourquoi il n’avait jamais cru bon d’apprendre un autre langage : « J’ai toujours pu écrire les programmes que je voulais en C, toujours, pour quelle raison devrais-je passer du temps à apprendre un autre langage ? »
Me vient à l’esprit une réponse : pour le challenge intellectuel, pour ouvrir d’autres chemins de pensée, élargir son horizon. Puis tout de suite la réalisation qu’écrire un programme en C possède intrinsèquement tout le nécessaire pour un « exercice intellectuel de qualité », que les langage est par essence tellement versatile, tellement universel, qu’apprendre ou utiliser un autre langage doit être justifié sérieusement. Alors dans certains cas ça se justifie, bien entendu, mais dans le cas d’un noyau de système d’exploitation je me demande bien quel sont les prétextes avancés par les développeurs souhaitant introduire Rust, et l’ayant déjà fait, j’avais eu l’occasion de voir ça en m’astreignant à compiler un noyau Linux récent, par curiosité et humeur nostalgique. Quand j’ai commencé à utiliser Linux c’était courant de le faire, nécessaire pour un tas de trucs. Depuis je dirais au moins une quinzaine d’année je n’y avais plus jamais touché. Et bien ça n’a pas changé, en tous cas sur la manière de le faire, par contre c’est devenu vraiment énorme.
D’ailleurs faudra que je retente l’expérience. J’avais fait une tentative l’année dernière, le noyau a compilé mais pas booté. Faut dire que j’ai pas pris le mode easy : je suis parti de "allnoconfig" déjà. Comme je suis curieux j’allais souvent faire une recherche sur le web afin de savoir le quoi ou le pourquoi de telle ou telle option. Je faisais donc l’exercice sur plusieurs jours, ce qui m’a incité à mettre à jour le code source entre chaque session (tant qu’à faire dans le didactique… _o_). Donc forcément, en fusionnant à chaque fois la config déjà faite avec les nouvelles options disponibles (le fichier de configuration évoluant : nouvelles options, certaines renommée, c’est rare, des options qui disparaissent, assez rare aussi).
Je pense que je retenterai de manière moins hardcore la prochaine fois :)
si vous aimez bâtir des structures complexes d’objets simples, faites du C. Si vous préférez les structures simples d’objets complexes, alors C++ répondra à toute vos attentes et plus encore.
Si vous aimez Rust, alors écrivez en OS en Rust. Vous pouvez écrire un Unix en Rust, commencez par un micro-kernel bien sûr, pour faire quelque chose de pro, pas comme Linus et son Unix de bricoleur qui était déjà obsolète en 1994 !
[^] # Re: mode Brice on
Posté par antistress (site web personnel) . Évalué à 4 (+1/-0).
Tu n'as pas beaucoup cherché !
J'aime bien le reste de ton commentaire en soi, mais il manque le sujet…
[^] # Re: mode Brice on
Posté par G.bleu (site web personnel) . Évalué à 5 (+6/-2).
Tu y crois sérieusement ? Genre Moïse est descendu du mont Sinaï avec la copie originale du K&R C écrit sur des tablettes en pierre ^
Perso je pense que le longévité du C s'explique uniquement par le fait qu'il faisait le taff et était au bon endroit au bon moment, tout comme tout le monde s'accorde à dire que le Javascript c'est quand même bien pourri, m'enfin dans 30 ans on en bouffera sans doute encore.
Tu vas un peu vite en besogne, LE truc fondamental qui a changé est le fait que tous les ordinateurs modernes ont plusieurs cœurs et doivent donc gérer du parallélisme.
Et à ce niveau le C est complètement dépourvu (genre il a fallut attendre C11 pour avoir le concept de thread apparaître dans le standard).
À cela on peut aussi rajouter que la sécurité est un besoin majeur de l'informatique moderne. Et là encore le C accuse de son age.
Une fois ce constat fait sur le C, se pose naturellement la question de quoi faire. Et c'est la que le Rust apparaît comme révolutionnaire (oui j'ose le mot, parce qu'avoir un projet comme Linux ne serait-ce que considérer de l'utiliser c'est bien la preuve qu'il l'est !).
[^] # Re: mode Brice on
Posté par devnewton 🍺 (site web personnel) . Évalué à 6 (+7/-4).
Si la sécurité était vraiment un besoin majeur, c'est Java qu'il fallait prendre, car il est vraiment memory safe lui !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mode Brice on
Posté par fearan . Évalué à 5 (+8/-6).
Donc le C est dépourvu d'un concept rentré il y'a 14 ans dedans? Je m'interroge…
Pas vraiment, tu peux écrire un programme en C tout aussi sécurisé qu'en Rust; c'est 'juste', qu'il va falloir être un poil plus attentif, comme vérifier, les entrées, vérifier la taille des tampons dans les string, et te battre avec le compilo qui va optimiser ton code avec des boucle exit early, supprimer des mise à 0 de valeurs car on s'en sert plus, mais le soucis c'est pas le C.
Le Rust répond à une partie de ces problématique, et est plus sûr dans le sens où il est plus difficile de faire une grosse boulette avec la mémoire, mais il n'empêchera nullement le développer de coder un équivalent de exec /tmp/monfichierTemporaire avec des droit root.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 7 (+7/-2).
Ça fait 3 fois que je donne le lien, mais je pense sincèrement qu’au lieu de troller, lire les arguments d’un des premiers concernés serait un bon début à la discussion
https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par fearan . Évalué à 6 (+4/-1).
Je pense que tu te méprends sur le sens de mon commentaire, je ne dis pas qu'il faut empêcher Rust d'intégrer le noyaux, mais qu'il est possible d'avoir un niveau de sécurité comparable en C. Je n'ai pas dit que c'était facile (et j'aurais du ajouter … a la liste des choses auxquelles il faut faire attention, car la liste est longue)
Mais quand un mec annonce qu'un concepts est absent d'un langage alors que ça fait plus de 10 ans que c'est dedans, y'a comme qui dirait un petit décalage, un peu comme si j'allai critiquer le c++ pour son absence de lambda function.
Si tu veux mon avis sur Rust dans le noyau, c'est évidemment oui, et ça devrait être la norme pour toutes les API avec le userspace, (pour certaines, on pourrait, dans des cas spécifique, garder une interface old school)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mode Brice on
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4 (+3/-1). Dernière modification le 24 février 2025 à 17:08.
En réalité moins de 3 ans : Linus a ouvert la possibilité d’utiliser C11 au lieu de C89 en février 2022 (plus de dix ans après sa normalisation, donc), et le premier noyau à sortir compilé en C11 c’est la version 5.18, de fin mai 2022. Ça n’est pas parce qu’une fonctionnalité ou une version existe qu’elle est utilisable, en particulier dans le cas de projets énormes comme celui-ci.
PS : je n’ai pas vérifié si Linux autorise l’usage des Threads C dans ses règles internes.
La connaissance libre : https://zestedesavoir.com
[^] # Re: mode Brice on
Posté par Renault (site web personnel) . Évalué à 8 (+5/-0).
Cela m'étonnerait comme Linux doit proposer justement l'API qui permet à la bibliothèque C de proposer une telle fonctionnalité.
Linux a sa propre gestion des threads via des "kthread" qui n'ont rien de standard comme de nombreuses choses dans le noyau usuellement fournis par la bibliothèque C.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
c’est eux qui implémentent les threads donc non
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 7 (+5/-0).
Mais si la question c’est pourquoi est-ce qu’il faut du rust dans le noyau les erreurs argumentaires de quelqu’un qui ne contribue pas ne sont pas pertinent.
L’un des développeurs historiques explique que même si rust n’set pas une silver bullet, il peut rendre impossible l’énorme majorité des failles de sécurité qu’ils rencontrent. Peut être que le niveau en C de la LKML n’est pas très bon et qu’ils ne font pas assez attention. Mais il semble que des gens comme Linus et GKH ont plus d’espoir en rust qu’en la capacité du groupe à s’améliorer en C.
En fait ça va assez loin puisque le C semble poser des problèmes d’expressivité. Il y a un certain nombre de situations où c’était :
void*renvoyé pas cette fonction ?C’est ce genre de choses qui font passer les développeurs rust pour des fouille merde/empêcheurs de tourner en rond.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par Nicolas . Évalué à -5 (+5/-10). Dernière modification le 25 février 2025 à 12:59.
Le fait est que le C est un langage simple car permissif. Rust me semble un langage à la syntaxe assez absconse (mais je fais le même reproche à beaucoup de langages…).
Tout programme n'est pas destiné à un usage en environnement hostile (donc exit les problèmes de sécurité).
Perso j'ai jamais pu apprendre le Rust. Mon cerveau fait une syncope dès qu'il lit "en Rust une variable est une constante". Ça ou je pars en fou rire.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à -1 (+1/-4).
Je sais pas de quoi tu parle. Si l’objectif de ton commentaire c’est de dire que tu n’aime pas rust ? C’est bien noté.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par Nicolas . Évalué à -10 (+0/-11).
Dur dur l'autodérision. Allez péter un coup ça ira mieux.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 0 (+1/-3).
C’est une vraie question. J’ai bien compris ce que tu n’aime pas, mais je vois pas ce que ça vient faire dans la discussion.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par Nicolas . Évalué à -10 (+2/-13).
Et qu'est-ce qui te fait croire que je n'aime pas le Rust ? Aurais-je commis un crime de lèse-majesté ? Peut-on rire de tout ? De rust ? De systemd ? Pourquoi les nouvelles technos informatiques sont portées par des commu. toxiques ? Des jeunes générations envieuses de ne pas avoir connu son invention et veulent à tout prix "tuer le père" ?
Ça n'a pas grand chose à voir avec la discussion je le concède. Mais au départ ça ne devait être qu'une boutade en passant.
Significatif.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 6 (+7/-3).
En 5 phrases tu dis 2 fois qu’il te pose problème.
Non
Non
Bien sûr.
Je n’utilise pas rust je sais pas si on peut dire que je fais parti de sa communauté. Ne pas comprendre ta blague est un comportement toxique ?
Mon langage de prédilection et dont je suis un heureux utilisateur fait parti des langages que beaucoup de gens veulent voir mourir et qui et d’ailleurs est annoncé mort depuis longtemps.
D’une part le fait que ce soit une tentative d’humour ne veut pas dire qu’il n’était pas porteur de message. Ensuite quand une blague ne passe pas, ça ne me parait pas malin de blâmer l’auditoire.
De tes préjugés ? J’ai dis que je ne comprenais pas ton message et tu me catégorise de toxique et tente de me traiter de gamin. J’ai dis que la seule chose que je comprenais de ton premier messages était un point de vu sur rust.
Entrer tardivement dans un débat pour tenter une blague avec quelque chose qui n’a pas grand chose à voir avec la discussion pour ensuite dire que ceux qui ne te comprennent pas sont toxiques c’est gonflé, tu ne crois pas ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par thoasm . Évalué à 3 (+3/-3).
Une variable ne peut être affectée qu'une fois et ne plus changer de valeur. Par exemple un paramètre d'une fonction est affecté uniquement lors de l'appel de la fonction, et ne peut pas changer de valeur au cours de l'appel (il peut par contre devenir inaccessible).
Ce n'est pas vraiment contradictoire avec le fait d'être une variable, c'est comme en maths les paramètres de fonctions. Différents appels = différentes valeurs (variable), au cours d'un appel, ne change pas de valeur. Même principe que les variables déclarées "const" dans d'autres langages.
Et oui si tu fais une syncope rien qu'avec ça, formulation trollesque ou maladroite écartée, passe ton chemin ou évolue :p
[^] # Re: mode Brice on
Posté par Nicolas . Évalué à -3 (+3/-6).
Faut sortir le nez du guidon parfois… ça veut strictement rien dire "variable constante" ou "variable immuable" (et pas immutable). Que ce soit en math, en informatique, en Klingon. C'est juste du vocabulaire. On appelle ça un oxymore.
La seule autre fois où j'ai pu entendre cette expression c'est chez Jean-pierre Petit. Je pose ça là comme ça (mais c'est généralement pas bon signe).
[^] # Re: mode Brice on
Posté par thoasm . Évalué à 0 (+2/-5). Dernière modification le 25 février 2025 à 13:58.
Ah oui rien que ça, tu trolles naturellement ou tu te fais aider par une IA pour être aussi pertinent ? Tarte à la fraise (oui tu peux me la jeter au visage après) ?
[^] # Re: mode Brice on
Posté par Nicolas . Évalué à -3 (+2/-5).
La_distinction sociale.
Mais c'est très rigolo quand ça se retourne contre ceeux qui en abusent. Un peu façon Sganarelle, médecin malgré lui.
[^] # Re: mode Brice on
Posté par thoasm . Évalué à -1 (+0/-4).
Sinon question distinction, c'est très courant maintenant d'utiliser le mot clé "const" pour les variables immuables, il y a ça en C++ ou en javascript. Donc oui tu peux tenter de te distinguer mais ça va pas tellement être compris, o tempora, o maures.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à -2 (+1/-5).
Prend un bouquin de C et lit le chapitre sur le mot clef constante
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par uso (site web personnel) . Évalué à 0 (+1/-2).
En fait dans la réponse que tu as envoyée 2x, Greg KH explique que rust peu être un outil pour améliorer les API c.
Typiquement l'exemple du void *, qui est au final assez peu utiliser, car on lui préfère généralement un retour sur un pointeur d'un type définit, mais si on a une vielle API qui n'a jamais changé, alors on peut garder du code, moins sécure.
Et Rust met un coup de pied au cul pour améliorer les vielle API C, vers un meilleur C.
Et pour le débat C n'est pas sécure alors que Rust l'est, je dirai juste qu'il est aussi facile en C d'avoir un code sécure sans problème de gestion mémoire, qu'il est facile en Rust de comprendre et d'avoir confiance dans sa chaine de dépendance. (chose qui ne concerne pas le kernel, car il ne peut pas utiliser la plupart des lib rust, et on évite donc les problèmes de dépendances douteuses)
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Effectivement mais ce n’est pas la première raison qu’il cite. Il pousse à ce que les nouveaux drivers soient écrit en rust pour les garanties que ce dernier apporte.
C’est mieux mais tu ne peux pas par exemple en C (comme dans quasiment tous les langages) décrire la propriété d’un pointeur dans l’API. Si tu me renvoi un pointeur, suis‑je celui qui doit le libérer ou non ?
Est‑il plus facile de faire confiance en sa chaîne de dépendance en C ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par uso (site web personnel) . Évalué à 2 (+1/-0).
Effectivement, généralement, ça fait partie de la Documentation/Convention de nommage, et c'est facile de se tromper.
Je suppose que ça fait aussi partie des choses que peuvent rapporter les binding Rust pour le code C, ça force à re-réfléchir la gestion des ownership dans les API C.
Oui, vu que tu rajoutes toi-même la majorité des dépendances dans le Makefile/Cmake, et donc t'a moins de dépendances surprises, que cargo t'a sortie, tu ne sais pas vraiment comment.
Que c'est chiant à faire, et donc tu vas éviter d'en rajouter, sauf si besoins. (ça peut paraitre comme négative, mais c'est aussi la raison pour laquelle je préfère le C au C++, C me force à utiliser des fonctions quand je n'ai pas besoins d'un objet)
Que tu utilises généralement des lib dynamique, et donc tu peux faire confiance à l'OS pour fixer les faille de sécurité pour toi.
Fait des ldd dans tes /bin, et tu auras rarement plus de 20/25 dépendances.
En Rust, t'en a rarement moins de 120.
Et s'il y a une faille de sécurité, t'est forcé de re-packager ton application vu que c'est du static.
C'est dalleur l'un des blocages qu'à systemd pour adopter rust: https://lwn.net/SubscriberLink/1008721/7c31808d76480012/
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 2 (+1/-1). Dernière modification le 26 février 2025 à 00:49.
Ou alors ça donne plus de copier coller et ça fait reposer sur du code encore moins éprouvé ?
Je trouve toujours surprenant d'avoir à minima une affinité avec le libre et de trouver positif la difficulté de partager du code.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par Gof (site web personnel) . Évalué à 1 (+0/-1).
L'autre jour je devais compiler un projet CMake, et il a téléchargé pas mal de dépendance avec FetchContent_Declare et certaines dépendances avaient elle même des dépendances de cette façon.
(Et ironie: l'une de ces dépendance utilisait une lib en Rust Avec corrosion qui elle même avait des dépendances en Rust.)
Donc non, je ne pense pas que ce soit une différence.
Euh non. ldd n'est pas un bon exemple car Rust fait un build statique.
Et si tu prends un bin d'un truc un peu complexe comme une app avec une GUI, tu as aussi beaucoup de ligne dans ldd, même en C.
[^] # Re: mode Brice on
Posté par uso (site web personnel) . Évalué à 3 (+3/-1).
Oui, et moi, je connais des projects rust qui utilise cargo-audit et ont une CI qui fait particulièrement attention à quelles dépendances elles incluent.
Et quand tu regardes les failles de sécu dans les projects rust, des erreurs mémoire ou des races conditions t'en voient passer aussi.
Mais même si on regarde des gros projets (C++ pas C dalleur) comme on peut le voir ici :
https://gist.github.com/flibitijibibo/b67910842ab95bb3decdf89d1502de88
Bah, on ne dépasse pas les 100 lignes de dépendances (qui effectivement preuves être biaisé, car ça n'inclue pas les dépendances statiques).
En Rust, un programme en CLI, en a facilement plus de 100, en GUI, on est plus dans les 400.
Je ne dis pas que ce n'est pas possible d'avoir un projet C qui va tirer une armée de dépendance à lui, ou qu'un project Rust seras forcément plein de dépendance peu connue qu'on ne sait pas d'où elle vienne.
Juste que par défaut, rajouter des dépendances en C, c'est pas aussi simple que rajouter une ligne dans cargo.toml, et il faut le faire soi-même, donc t'en évite beaucoup si t'en a pas vraiment besoins.
Au même titre que rajouter une CI asan/valgrind ça prend du temps, au même titre que rajouter un cargo-audit dans un runner gitlab/hub c'est chiant.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
Ça n’a pas grand chose à voir avec le sujet. C’est en aucun cas une question de confiance en la toolchain. C’est juste qu’ils ont 150 binaires et ne veulent pas qu’une bibliothèque qui est utilisée par tous soit présente 150 fois pour une question d’espace disque. D’ailleurs ils disent qu’ils iraient peut être vers zig si ce dernier propose des bibliothèques partagée alors qu’il a son gestionnaire de paquets officiel à la cargo.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par uso (site web personnel) . Évalué à 1 (+1/-1).
Oui, et non, un peu plus haut, il dit que systemd est assez conservateur avec ses dépendances, qu'il utilise dlopen pour éviter les problèmes que tu pourrais avoir avec une lib statiquement linker. (ou dynamiquement à la compilation).
Dans la partie sur Rust ça parle effectivement d'espace disque, et de bibliothèque dynamique, mais combiner avec la réfection sur xz, et dlopen plus haut, tu peux voir comment cargo poserait problèmes avec une intégration dans systemd.
[^] # Re: mode Brice on
Posté par Lutin . Évalué à 3 (+1/-0).
Zig permet de programmer sa toolchain de build, c'est beaucoup plus flexible que cargo.
[^] # Re: mode Brice on
Posté par BAud (site web personnel) . Évalué à 2 (+1/-1).
la bonne pratique, c'est que l'appelant réserve la mémoire, comme ça il reste responsable de la libérer.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
J'en parle parce que c'était l'un des problèmes remonté par un précédent contributeur r4l qui a abandonné. Peut être que la bonne pratique pose des fois problème au sein du noyau.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par G.bleu (site web personnel) . Évalué à 2 (+3/-2).
Déjà "le mec" il aimerait que suis moins familier histoire d'avoir des échanges courtois, c'est pas la Linux kernel mailing list ici ;-p
Effectivement, stricto sensu mon commentaire aurait dû être "Et à ce niveau le C est PRATIQUEMENT complètement dépourvu".
Pour étayer, le C11 va te donner des briques de bases comme démarrer des threads et protéger de la mémoire avec des mutex ou des opérations atomiques.
En comparaison, Rust te donne des outils qui te garantissent qu'un mutex sera pris avant d'accéder à ce qu'il protège, que le mutex sera bien libéré, et qu'on ne pourra plus lire ou modifier la zone mémoire protégée une fois le mutex libéré.
Rien que ça c'est majeur quand il s'agit de maintenir une grosse base de code avec beaucoup de contributeurs vu qu'on vient de diminuer d'autant la charge des gens qui devront review le code, ainsi que la courbe d'apprentissage pour les nouveaux.
Oui, donc on est d'accord: obtenir un résultat donné en matière de sécurité demandera plus de ressource (temps, expérience des devs etc.) avec du C qu'avec du Rust.
https://en.cppreference.com/w/cpp/language/lambda
[^] # Re: mode Brice on
Posté par groumly . Évalué à 6 (+4/-0).
Bien que je comprenne le fond de ton message, le fait que t'ai prit cet exemple particulier de threads aide pas franchement.
Les threads C11 vont déléguer leur gestion a la libc, qui en retour, va la déléguer au kernel a un moment (parce que, ben, ouais, ya du scheduling etc, ce qui est le boulot du kernel), et vu qu'on est deja dans le kernel, on va dire que laisser le kernel déléguer a lui meme la gestion des threads, c'est pas forcement une victoire. Meme si y'a probablement des scenarios précis ou ca fait du sens.
[^] # Re: mode Brice on
Posté par fearan . Évalué à 4 (+1/-0).
Sur la garantie de libération j'aimerai bien voir. Je schématise mais est ce qu'un
va te rendre le mutex?
là j'ai pris un cas extrême, mais est-ce qu'on a une protection contre l'étreinte mortelle ?
J'ai un peu l'impression de lire les même commentaire qu'avec le garbage collector comme quoi y'a plus besoin de faire gaffe le garbage collector s'occupe de tout, résultat y'a des boulets qu'ajoute des objet dans des collections sans jamais les retirer, car ils pensent que c'est 'magique'.
Y'a un verrouillage complet de la mémoire? Y'a pas un autre processus qui pourrait venir y fourrer nez comme par exemple un gdb? Ou le même processus mais qui est dans la partie en C? Ou un petit firmware proprio qu'on a du charger sur lequel on a pas le contrôle.
tout à fait les protections et garanties fournie par rust sont les bienvenues, c'est un grand pas dans la bonne direction, mais je serai plus nuancée sur le lave plus blanc que blanc.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: mode Brice on
Posté par Fulgrim . Évalué à 4 (+3/-0).
Non, c'est lié à la notion de scope, quand ton mutex sort du scope c'est libéré et tu ne peux plus accéder, sachant que tu vas vite spontanément créer un scope au moment ou tu vérouilles le mutex (le langage t'y pousse).
Il y a toujours besoin de faire gaffe sur les questions de mutex, Rust va t'éviter certaines classes d'erreurs (du double accès en même temps), mais va pas beaucoup aider sur d'autres. Typiquement dans ton exemple de code, tu pourrais avoir syntaxiquement un accès ensuite à data, certe completement inaccessible en pratique mais c'est sans doute théoriquement indécidable (on n'est quand même pas loin du problème de l'arrêt). De même si tu as 2 mutex, il va pas pouvoir te garantir que tu n'as pas de deadlock, mais le langage va te pousser à n'avoir qu'un mutex et une struct dedans.
Pas un verrouillage, le compilateur va te garantir que ton code rust n'y met pas son grain de sel (et encore, tu peux surrement le contourner avec qq unsafe bien placé), pas que le reste du monde ne va pas le faire. Donc oui, une dépendance qui appelle un autre langage va permettre d'en sortir, un driver va pouvoir y accéder. Ce n'est pas du tout une protection cryptographique.
Pour moi, un des gros points d'interet de Rust est justement d'avoir réussi à construire une sorte d'entre deux entre garbage collector et tu manages ta mémoire. Cet entre deux n'est possible que parce que le langage t'impose des restrictions sur ce que tu peux faire (les règles d'ownership). Ces restrictions empechent pleins de programmes correctes de compiler mais permettent au compilateur de décider si et quand la mémoire peut être libérée ou est vérouillée. Les problèmes d'analyse de code tombe vite dans de l'indécidable dans le cas général, mais justement le langage n'est pas un cas général du fait des restrictions imposées. Ils ont réussi à relacher certaines restrictions, mais ne pourront sans doute jamais toutes les lever.
Sur le threading, je trouve le compromis pas aussi excellent que sur la gestion de la mémoire, on enlève certaines classes d'erreurs mais il en reste beaucoup, peut être qu'on trouvera mieux, et je trouve que "fearless concurrency" est trop marketing par rapport à la réalité, "lesser concurrency fear" serait plus réaliste
[^] # Re: mode Brice on
Posté par mrintrepide . Évalué à 8 (+7/-0).
Rust est autorisé, c'est donc une liberté et on devrait s'en arrêter là.
C et Rust sont les deux langages autorisés avec une priorisation du C.
Plusieurs développeurs ont indiqué que c'était plus simple de développer des pilotes en Rust sur les périphériques modernes. Notamment les pilotes graphiques Asahi pour Apple et NOVA pour Nvidia.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 4 (+3/-1).
L’avis d’un des plus vieux contributeur et mainteneur de la branche stable (entre autre) : https://lore.kernel.org/rust-for-linux/2025021954-flaccid-pucker-f7d9@gregkh/
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mode Brice on
Posté par karteum59 . Évalué à 3 (+1/-0). Dernière modification le 26 février 2025 à 06:06.
Tout le monde n'est pas de cet avis (voir par exemple "C Is Not a Low-level Language - Your computer is not a fast PDP-11")
[^] # Re: mode Brice on
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0).
Cet article est souvent cité à propos du C, mais il commence par une définition du bas niveau qui ne corresponds pas au C :
Si je comprends bien l'histoire racontée sur Wikipedia, au tout début le C a bien eu pour objectif de tirer parti du PDP-11, il a ensuite eu très rapidement pour objectif la portabilité et donc l'indépendance vis à vis du "métal".
Hors pour être portable, on ne peut pas exposer tous les détails possibles.
Mais cela ne veut pas dire que le C ne propose pas des opérations de bas niveau comme la gestion manuelle de la mémoire.
Bref un langage de bas niveau n'est pas un assembleur de haut niveau :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: mode Brice on
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Personnellement vu l’évolution des micro code inclus dans les CPU, je ne suis pas sûr que l’assembleur soit encore si bas niveau que ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Et sinon
Posté par antistress (site web personnel) . Évalué à -2 (+5/-10). Dernière modification le 23 février 2025 à 22:50.
toujours cette agressivité de ton, en plus en public, c'est difficilement supportable (et justifiable).
Les mérites de Linus ne l'autorisent pas a se montrer violent. Non mais c'est quoi son problème à la fin ?
[^] # Re: Et sinon
Posté par Gof (site web personnel) . Évalué à 5 (+3/-0).
Ce qui a changer comparer a avant c'est qu'il n'y a plus d'insulte et d'attaque personnelles er de gros mots
Alors que auparavant on aurait plutôt une insulte disant que c'est un con et que ceux qui pense comme lui sont des connards ou un truc du genre.
Bien que le message soit toujours direct en effet, il y a quand même une amélioration.
[^] # Re: Et sinon
Posté par barmic 🦦 . Évalué à 4 (+3/-1).
Ça arrive encore les attaques personnelles :
https://lkml.org/lkml/2025/2/6/1292
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et sinon
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+13/-2).
Il semble qu'on soit face à un problème de génération :
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et sinon
Posté par barmic 🦦 . Évalué à 4 (+3/-1).
Je n’ai pas de jugement sur ce qu’a fait Hector Martin. De ce que je comprends Hector Martin (un jeune de 35 ans) tentait d’intégrer des fonctions rust pour qu’elles soient utilisables dans n’importe quel driver rust et Christoph Hellwig a mis un veto dessus expliquant que c’est un cancer. Il ne s’agit pas d’un contentieux entre Hector et Hellwig avec ce veto Hellwig bloquait tous les drivers rust. La situation étant bloquée Hector s’est répandu sur son compte Matodon et cela a mené Linus à affirmer qu’Hector était le problème. Sauf que dans les 10 jours qui ont suivi c’est Hellwig qui se prend sa soufflante parce que finalement il semble que lui aussi avait un comportement problématique.
Ce que je vois personnellement c’est 3 très bons développeurs qui ne savent pas communiquer autrement qu’en étant véhéments, le noyau qui a perdu un contributeur important et beaucoup d’énergie consommée dans cette histoire.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et sinon
Posté par Christophe . Évalué à 10 (+8/-0).
Oui, le premier s'est fait réprimander pour son usage de Mastodon comme moyen de pression, le second pour son abus de pouvoir sur un patch qui ne le concernait pas.
Et Linus n'a pas spécialement apaisé la situation.
Parfois, tout le monde a tort.
[^] # Re: Et sinon
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 10 (+11/-3).
En quoi dire à quelqu'un que c'est peut-être lui le problème est une attaque personnelle si cela se justifie ? Il faut se montrer hypocrite ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Et sinon
Posté par barmic 🦦 . Évalué à 0 (+0/-2).
Je comprends pas. Il dit qu’il n’y a plus d’attaque personnel. Je fais remarquer que si et tu répond « et alors ? ». J’ai juste dit que ça existait.1
Moi mon seul point c’est qu’entre ceux qui utilisent leurs droits pour mener des combats politiques hors de leurs attributions, ceux qui font du brigading sur Mastodon, ceux qui se gargarisent d’être "thin blue line" (terme dont il est difficile aujourd’hui de ne pas le reporter aux Blue Lives Matter) : la gestion tardive et par coup de tête de Linus ne parait pas optimale.
après si tu veux vraiment lancer le débat. Il est tout à fait possible de dire que le brigading sur les RS n’est pas acceptable sans attaque personnelle. Dans un endroit qui se veut valoriser le mérite il me parait important d’attacher plus d’importance aux comportement qu’aux gens qui les font. C’est la différence entre « tu as fait une erreur » et « tu es une erreur ». ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et sinon
Posté par Sébastien Le Ray . Évalué à 2 (+2/-1).
Elle ne dit pas "et alors" elle réfute le fait qu'appeler un chat un chat soit qualifié d'attaque alors que ça peut être une simple constatation… Ce avec quoi je suis plutôt d'accord: refuser de nommer les choses pour ce qu'elles sont au nom d'une prétendue bienséance peut avoir des conséquences assez dramatiques (il suffit d'ouvrir un journal ces derniers mois pour le constater)
[^] # Re: Et sinon
Posté par thoasm . Évalué à 10 (+9/-2).
Il peut y avoir une nuance entre "le problème c'est toi" et "le problème, c'est ta réaction en l'occurrence". Le premier est essentialisant, potentiellement, si tu tombes sur quelqu'un de sensible (tout le monde peut l'être à un moment) et sur un moment de fragilité "bon, si le problème c'est moi, à quoi bon, je laisse tomber", alors que si c'est simplement une manière d'agir, c'est pas ce qui te définit en tant que personne et c'est modifiable.
[^] # Re: Et sinon
Posté par Sébastien Le Ray . Évalué à 2 (+3/-2).
Si tu choisis de parler aux gens comme à de la merde il faut pas non plus se plaindre du répondant en face. "Je qualifie le travail des autres de cancer mais merci de me traiter avec égards et modération" c'est un peu risible
[^] # Re: Et sinon
Posté par antistress (site web personnel) . Évalué à 4 (+3/-2).
L'exemplarité, pourtant, c'est efficace
[^] # Re: Et sinon
Posté par thoasm . Évalué à 3 (+2/-2).
C'est pas une demande de sa part, en l'occurrence, mais un principe ? D'une manière générale, adopter les méthodes qu'on condamne par ailleurs c'est pas forcément aller dans la bonne direction.
[^] # Re: Et sinon
Posté par devnewton 🍺 (site web personnel) . Évalué à 2 (+2/-3).
Essayons une gentille formulation: le problème c'est pas toi, mais ton comportement, ton mode d'expression, ta façon de penser et ta coupe de cheveux. Si tu changes tout ça, on pourra mettre envisager de mettre du Rust dans le noyau !.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et sinon
Posté par thoasm . Évalué à 1 (+0/-2).
Disons que si tu te définis par une manière agressive d'interagir avec les autres qui leur pose problème à eux, alors que toi ça te va très bien, il y a probablement du réglage à faire de ton côté. Tu trouves intolérable d'être heurté dans ta sensibilité et impensable de changer alors que tu l'exiges des autres pour interagir avec toi alors que du côté des autres heurtés dans leur sensibilité c'est à eux de changer, c'est pas symétrique du tout.
Dans un projet l'objectif commun c'est de faire avancer les choses :)
[^] # Re: Et sinon
Posté par barmic 🦦 . Évalué à 0 (+0/-2).
C’est tout le sujet. Pourquoi est-ce que tu écrit ton message ? Est-ce que c’est pour que les gens changent ou est-ce que tu ne veut juste plus travailler avec cette personne ?
Quand Hector réagit mal au comportement de Christoph, la seule réaction de Linus c’est « le problème c’est toi ». Au vu de ce qu’il se passait entendre ça c’est assez logique de partir.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et sinon
Posté par thoasm . Évalué à 2 (+1/-2).
C'est un peu l'étape d'après, si l'implicite est "si tu peux pas mettre de l'eau dans ton vin on va pas pouvoir continuer à travailler ensemble". Mais effectivement ils ont déjà causé en privé donc on a pas tout l'histo et l'implicite sous la main.
# .
Posté par M . Évalué à 4 (+4/-2).
Je vois rust un peu code ipv6.
Ca résoud certains problèmes, mais ça introduit d'autres choses pas forcément souhaitable.
Et pour avoir essayé de comprendre comment fonctionne rust, je trouve que certains truc sont un peu des hacks.
Par exemple on n'a pas un langage bien défini avec des lib par dessus.
La lib rust utilise des fonction interne du compilo, par ce que des choses sont pas possible.
Le tout statique est un frein à l'utilisation dans l'embarqué linux avec petite flash/ram.
Et je pense que certains mainteneurs linux ne sont convaincus de l'intérêt de rust.
Il y avait des commentaires intéressant sur lwn.
Ok c'est super d'avoir un code rust avec des classes de bug éliminés.
Mais si ça rajoute de la complexité et des bugs/backdoor de logique c'est perdu.
Que faire si le maintener ne se sent pas à l'aise avec rust ?
Lui imposer rust, le virer, lui proposer une aide (mainteneur en plus, ..)
[^] # Re: .
Posté par thoasm . Évalué à 6 (+4/-1).
C'est pas un "hack", c'est juste que ces fonctions de la lib sont des primitives du langages, qui seront spécifiées comme à part entière du langage. L'implémentation, du coup, sera laissée libre au compilo et cette histoire de "fonction interne au compilo" n'a pas grand sens, c'est le cas de n'importe quel mot clé avec une sémantique donnée dans n'importe quel langage, c'est le compilo qui implémente la chose. Souvent la lib de base fait partie à part entière de la spec du langage, quand il y en a.
[^] # Re: .
Posté par M . Évalué à 3 (+2/-1).
Je n'ai plus l'exemple en tête, mais le code en question avait fait l'objet de plusieurs PR et débats.
En C la partie language bas niveau et libc est quand même assez séparé.
C'est possible d'implémenter une libc sans devoir connaître le fonctionnement interne du compilo.
Au passage l'intégration linux a du forker des bouts de la lib core/std rust. Comment ça va évoluer avec les nouvelles versions des compilateurs (si les api internes sont cassés) ?
[^] # Re: .
Posté par thoasm . Évalué à 6 (+3/-0).
Sans détails plus que ça c'est difficile d'évaluer l'ampleur de ce drâme !
On va laisser les gens travailler, déterminer les bouts de code essentiels, voir si c'est une si grosse partie de code que ça. Linux à sa propre lib de base, j'imagine qu'il la font évoluer aussi parfois tout le monde s'en fout.
Les communautés Rust et Linux vont aussi probablement être à l'écoute l'une de l'autre, on verra comment ils gèrent ce genre de contraintes, version ement, norme …
Comme le reste : le jeu en vaut-il la chandelle ? Quels sont les bénéfices, les problèmes (avérés) qui sont vraiment durs à résoudre en pratique, est-ce un vrai fardeau ou alors bof la vie normale de l'évolution d'un code de cette ampleur et pas tellement plus, les solutions trouvées …
On peut causer dans le vague et un certain purisme de propriétés attribuées au C longtemps, il a toujours sa sémantique qui permet de faire relativement n'importe quoi facilement sans contrôle ni garantie dans la balance. Il y a probablement un prix à payer pour mettre ce genre de garanties dans Linux. Mais vu que les devs qu'on ne peut pas soupçonner d'incompetences reconnaissent que ça cause des bugs qui sont un fardeau à traiter, un peu tout le temps, la question n'est pas vraiment de savoir si le C a une API qui a t'elle propriété …
C'est si le cout d'avoir ces garanties est si important que ça contrebalance les bénéfices, et si l'intégration est si compliquée que ça et si pénible à maintenir.
Oui il y aura des problèmes d'intégration logicielle, et des problèmes humains, surtout au début. Mais en vitesse de croisières, concrètement… Tu trouves du temps de debuggage contre quelques bonnes pratiques d'intégration et du versionnement des compilos Rust et un peu de dialogue entre les projets ? Linux n'est pas un programme si insignifiant que sa voie ne pèse pas dans la balance et que Rust leur dise "merde".
[^] # Re: .
Posté par serge_sans_paille (site web personnel) . Évalué à 4 (+2/-0).
c'est beaucoup le cas pour la bibliothèque standard C++ également
[^] # Re: .
Posté par M . Évalué à 4 (+2/-0).
Mais pas en C.
Justement en c++ il y a plein de chose cachée. Ce qui rend difficile au débutant de comprendre ce qu'il y a derrière quelques ligne de code
[^] # Re: .
Posté par Pol' uX (site web personnel) . Évalué à 7 (+6/-1).
Pourtant, en C, même des praticiens confirmés ont des difficultés à comprendre ce qu'il y a derrière quelques lignes de code !
Adhérer à l'April, ça vous tente ?
[^] # Re: .
Posté par Ronan BARZIC . Évalué à 5 (+4/-0).
Heu ? statique ne veut pas dire que ce qui n'est pas utilisé est quand même ajouté au binaire final. Si tu programmes en C sur un petit microcontrolleur, tu fais du statique 99% du temps. Ce qui compte, c'est la capacité du linker à faire du "garbage collecting" sur le code object (-ffunction-sections -Wl,-gc-sections de gcc par example)
[^] # Re: .
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 2 (+1/-0).
Je pense que "le tout statique" est OK sur un micro-contrôleur.
Mais si tu fais de l'embarqué sous Linux comme dit au début et que tu utilises plusieurs binaires compilés en Rust, ils vont prendre plus de place et de mémoire que du C compilé avec une libc commune.
[^] # Re: .
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
rust ne compile pas la libc en statique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Abandon
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Christoph Hellwig a finalement abandonné. Ce mois ci le noyau aura donc perdu 2 grands mainteneurs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Abandon
Posté par patrick_g (site web personnel) . Évalué à 4 (+1/-0).
Et le lien LWN : https://lwn.net/Articles/1011819/
[^] # Re: Abandon
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Et je n’avais pas vu mais Karol Herbst est aussi parti suite grosso modo aux réactions suite au départ d’Hector Martin.
https://lists.freedesktop.org/archives/nouveau/2025-February/046677.html
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Abandon
Posté par antistress (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 26 février 2025 à 11:08.
Il n'a abandonné qu'une partie de son domaine (Christoph Hellwig Steps Down From One Of His Kernel Roles Following Rust Drama titre phoronix)
# Linus répondra-t-il à la controverse sur Linuxfr (DLFP pour les moules) ?
Posté par Yth (Mastodon) . Évalué à 0 (+1/-3). Dernière modification le 26 février 2025 à 14:17.
Rien n'est moins sûr, en effet, le Français n'étant pas une norme du C, il a peu de chance d'être intégré au kernel Linu-X, de toute façon il sera remplacé par l'américain quand le pays du fromage sera devenu le 233è état unis.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.