L’article semble être une traduction (parfois assez étrange) de cet article sur LWM (lien en fin de texte). Si vous lisez l’anglais, la VO sera sans doute plus claire.
Un enseignement intéressant, c’est que, d’après ce compte-rendu, même des discussions ultra-techniques de gens très expérimentés comme les intervenants du Kernel Maintainers Summit sont percluses de préférences personnelles et d’autres considérations plus politiques que techniques. C’est pas étonnant – ça reste des humains – mais toujours un bon rappel.
Notons qu'une partie du problème comme soulevé dans l'article d'origine c'est aussi le fait que les mainteneurs et même beaucoup de développeurs du noyau ne connaissent pas ou peu Rust ce qui rend la cohabitation potentiellement difficile : faut quelqu'un pour relire et intégrer ce code et le maintenir une fois qu'il est intégré. Et cela peut se comprendre que les mainteneurs qui sont déjà souvent un peu sous l'eau au niveau tâches qu'ils aient du mal à suivre dans cette voie pour l'instant faute de compétences.
Ce n'est pas simple, la cohabitation ne sera clairement pas un long fleuve tranquille même si ça semble bien progresser.
Driver authors tend not to understand concurrency, he said, and a lot of the code there is broken and unfixable. So it is unsurprising that there is interest in bringing in a language that better supports the writing of correct and safe code.
Ça ressemble à du solutionnisme : on a un problème de formation humaine, on va le résoudre avec un outil technique…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Pour le coup sur ce sujet même formé, l'erreur est très très rapide, surtout sur une base de code aussi large et complexe. J'avoue qu'avoir l'aide d'un compilateur intransigeant pour ce point est quand même une solution qui aime même ceux qui savent faire.
C'est quand même plus agréable de se concentrer sur les fonctionnalités que sur le fait de savoir si ta variable a bien était mise avec une barrière mémoire ou autre volatile pour que le thread X développé par un autre puisse y accéder sans soucis.
Ceci ne va pas être une solution magique non plus, car vu le milieu tu vas avoir besoin de soucis de performances et dupliquer au minimum ta mémoire, donc pas forcément ce que va recommander Rust par défaut (je ne suis pas expert dans le sujet, je peux me tromper sur ce point). Mais dans pas mal d'endroit ça va simplifier un peu et faciliter la relecture d'une bonne partie du code je pense (modulo la formation des mainteneurs, ça prendra du temps).
Posté par Thomas Douillard .
Évalué à 9.
Dernière modification le 10 janvier 2024 à 12:02.
Les techniques de "borrowing" vont permettre de faire des équivalents sûr de "move semantics" en C++ : les parties du code qui ont un besoin en mémoire se passent le relai de manière à ce qu’il n’y en ait qu’une seule qui puisse modifier la mémoire. Donc pour du partage de mémoire rust semble dans l’idée plutôt adapté sans payer le coût de la copie, cf. la doc de rust sur les références et le borrowing.
Ceci ne va pas être une solution magique non plus, car vu le milieu tu vas avoir besoin de soucis de performances et dupliquer au minimum ta mémoire, donc pas forcément ce que va recommander Rust par défaut (je ne suis pas expert dans le sujet, je peux me tromper sur ce point).
De ma compréhension, la majeure partie du travail de rust c'est d'avoir un langage qui permet de faire l'analyse statique assurant qu'un seul thread peut modifier la mémoire à tout moment. C'est vérifié statiquement et ça ne consiste grosso modo qu'à une annotation des types pour marquer cette possibilité. Dans le code compilé tu n'a plus rien.
Posté par jmiven .
Évalué à 10.
Dernière modification le 10 janvier 2024 à 12:04.
Ça ressemble à du solutionnisme : on a un problème de formation humaine, on va le résoudre avec un outil technique…
Oui c'est vraiment désolant ! C'est comme dans les années 50. Les programmeurs faisaient plein d'erreurs bêtes dans leur code machine, mais au lieu d'améliorer leur formation, on a voulu solutionner en s'encombrant d'un "assembleur". À croire qu'on n'apprendra jamais !
Là c'est comme si le constat de départ dans les années 50 étaient les programmeurs ne comprennent rien à l'informatique :-)
Le constat de départ c'est que le parallélisme c'est un sujet compliqué sujet à de nombreuses erreurs.
S'assurer qu'on a de bonnes perfs en parallélisant des tâches ou actions tout en ayant aucun effet de bord c'est une gymnastique intellectuelle difficile surtout quand tu ne connais pas le logiciel dans son intégralité car il est trop gros. Un effet de bord est vite arrivé.
Il faut être très rigoureux, tu as vite oublié la protection mémoire quelque part qui va bien et du coup tu as un conflit d'accès à la donnée, ou utilisé la protection mémoire au mauvais endroit et du coup tu as un interblocage.
Même quand tu es formé à la question ces erreurs arrivent car on ne peut pas penser à tout tout le temps. Comme la gestion de la mémoire d'ailleurs, s'assurer que tout est alloué une fois au bon endroit à la bonne taille et la mémoire libérée une fois au bon endroit de manière systématique c'est aussi difficile. Même des développeurs expérimentés et formés t'introduisent des failles de sécurité car la mémoire est mal gérée ou des crashs car mince la libération de la mémoire n'a pas été faite au bon endroit (ou un accès a été fait là où il ne fallait pas).
Et en plus manque de bol avec le parallélisme, le débogage est difficile quand un problème survient. Bogues difficiles à identifier, à reproduire, lire le code pour identifier le problème est rarement suffisant, etc. Donc quand ça arrive tu perds un temps fou dessus.
Bref, si un langage avec un compilateur permet de dire "ici ça pue, bogues potentiels à venir, corrige ou marque ce bout de code comme "je sais ce que je fais"" cela simplifie grandement la tâche, en particulier pour les gens formés qui pourront se concentrer sur l'architecture plutôt que de reproduire des bogues compliqués.
AMHA hors de cas simples, un humain ne sait pas faire de programmes parallèles correct : c'est à dire à la fois qui gagne en performance et qui reste sûr d'un point de vu fonctionnel.
On pourra trouver des développeurs et des équipes qui repoussent un peu les limites du « cas simples », mais rien de véritablement pérenne.
Ce n'est pas une question de technologie, les problèmes que résolvent les langages à runtime ne protègent pas de tout et les CPU ont eux aussi du mal à résoudre ce problème. Rust non plus n'est pas une silver bullet qui garanti aucune erreur, c'est juste qu'il en élimine de base plus que la plupart des autres.
On casse des pierres avec des pioches, certains font ça avec un coup bien placé, mais ils ne sont pas nombreux et ne le font pas dans autant de conditions que n'importe qui avec une pioche. Le fait que des mineurs existent ne rend pas les pratiquant d'art martiaux moins impressionnants et je suis sûr que ces derniers ne se disent pas que les mineurs leur pique leur travail artisanal avec une organisation industrielle et des outils.
Je n'ai pas dit que Rust était une solution parfaite à ces problèmes. Outre l'erreur d'implémentation du compilateur et du runtime, il ne peut en effet identifier tous les problèmes potentiels. Mais il apporte une aide précieuse malgré tout.
Ah oui non je parlais de présenter les choses différemment surtout parce que présenter la question de rigueur ou d'oubli par exemple donne l'impression (à mon avis) que c'est accessible alors que ça n'est pas le cas à mon avis.
Posté par kantien .
Évalué à 3.
Dernière modification le 14 janvier 2024 à 01:14.
Là c'est comme si le constat de départ dans les années 50 étaient les programmeurs ne comprennent rien à l'informatique :-)
Je ne crois pas que le constat soit là, mais il me semble analogue à un certain principe constitutif du groupe Bourbaki. Ce groupe fut fondé, dans les années 1930, par des mathématiciens normaliens pour mettre de l'ordre dans l'exposé de l'édifice mathématique de leur époque, et ils avaient pour principe qu'à 50 ans on quitte le groupe.
Lors d'un émission d'Àpostrophes de Bernard Pivot, Jean Dieudonné, un ancien membre du groupe, fut interrogé sur ce principe. Pivot, lui demandant si cela voulait dire que l'on ne valait plus rien, se fit offrir cette réponse :
Si vous voulez, on est attaché à ce que l'on a appris étant plus jeune et, dans Bourbaki, on avait le désir de présenter les mathématiques les plus récentes sous leur forme la plus évoluée. Et bien, l'homme d'un certain âge a tendance à renâcler devant cette nécessité , il s'en tient à ce qu'il a appris étant plus jeune et ça c'est très mauvais.
Rien de neuf sous le soleil : une génération en remplace une autre, et l'ancienne s'accroche à ses habitudes.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
Le problème fondamental du solutionnisme technologique c’est pas uniquement "bon on a un problème, voilà une solution technologique qui va la résoudre", c’est aussi "bon, on a un problème, on a pas de solution mais spa grave on va forcément s’en sortir par la technique !"
Là c’est pas tout à fait la même chose. On a un problème, on sait que la technique peut aider, il y a manifestement de toute manière besoin de formation dans les deux cas. Sauf que sans Rust, on a déjà eu des années pour former les mainteneurs et les développeurs de drivers, et manifestement la montée en compétence est assez compliquée pour tout le monde vu que le problème est toujours là bien que le code Linux soit globalement mûr.
Et on sait que du point de vue technique … il y a des solutions logicielles qui peuvent aider les devs ou les forcer à plus de rigueur, le compilateur Rust laissera pas passer facilement certaines classes de bug. Reste à faire monter les mainteneurs en compétence aussi, c’est un problème de formation humaine. On a juste troqué un problème de formation humaine par un autre mais laquelle est la plus difficile ?
Concernant la source proprement dite, bien que je ne visite pas très souvent ce site, j'ai malheureusement l'impression que c'est devenu une habitude des "auteurs" de leurs articles.
Beaucoup de ceux-ci ont des tournures de phrase assez bizarre. De là a dire les articles sont traduis automatiquement, il y a un pas que je ne franchirais pas; pour la simple et bonne raison que certains traducteurs automatique ferait un peu mieux !
# La source
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 8.
L’article semble être une traduction (parfois assez étrange) de cet article sur LWM (lien en fin de texte). Si vous lisez l’anglais, la VO sera sans doute plus claire.
Un enseignement intéressant, c’est que, d’après ce compte-rendu, même des discussions ultra-techniques de gens très expérimentés comme les intervenants du Kernel Maintainers Summit sont percluses de préférences personnelles et d’autres considérations plus politiques que techniques. C’est pas étonnant – ça reste des humains – mais toujours un bon rappel.
La connaissance libre : https://zestedesavoir.com
[^] # Re: La source
Posté par Renault (site web personnel) . Évalué à 9.
Notons qu'une partie du problème comme soulevé dans l'article d'origine c'est aussi le fait que les mainteneurs et même beaucoup de développeurs du noyau ne connaissent pas ou peu Rust ce qui rend la cohabitation potentiellement difficile : faut quelqu'un pour relire et intégrer ce code et le maintenir une fois qu'il est intégré. Et cela peut se comprendre que les mainteneurs qui sont déjà souvent un peu sous l'eau au niveau tâches qu'ils aient du mal à suivre dans cette voie pour l'instant faute de compétences.
Ce n'est pas simple, la cohabitation ne sera clairement pas un long fleuve tranquille même si ça semble bien progresser.
[^] # Re: La source
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ça ressemble à du solutionnisme : on a un problème de formation humaine, on va le résoudre avec un outil technique…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: La source
Posté par Jean Gabes (site web personnel) . Évalué à 10.
Pour le coup sur ce sujet même formé, l'erreur est très très rapide, surtout sur une base de code aussi large et complexe. J'avoue qu'avoir l'aide d'un compilateur intransigeant pour ce point est quand même une solution qui aime même ceux qui savent faire.
C'est quand même plus agréable de se concentrer sur les fonctionnalités que sur le fait de savoir si ta variable a bien était mise avec une barrière mémoire ou autre volatile pour que le thread X développé par un autre puisse y accéder sans soucis.
Ceci ne va pas être une solution magique non plus, car vu le milieu tu vas avoir besoin de soucis de performances et dupliquer au minimum ta mémoire, donc pas forcément ce que va recommander Rust par défaut (je ne suis pas expert dans le sujet, je peux me tromper sur ce point). Mais dans pas mal d'endroit ça va simplifier un peu et faciliter la relecture d'une bonne partie du code je pense (modulo la formation des mainteneurs, ça prendra du temps).
[^] # Re: La source
Posté par Thomas Douillard . Évalué à 9. Dernière modification le 10 janvier 2024 à 12:02.
Les techniques de "borrowing" vont permettre de faire des équivalents sûr de "move semantics" en C++ : les parties du code qui ont un besoin en mémoire se passent le relai de manière à ce qu’il n’y en ait qu’une seule qui puisse modifier la mémoire. Donc pour du partage de mémoire rust semble dans l’idée plutôt adapté sans payer le coût de la copie, cf. la doc de rust sur les références et le borrowing.
[^] # Re: La source
Posté par barmic 🦦 . Évalué à 4.
De ma compréhension, la majeure partie du travail de rust c'est d'avoir un langage qui permet de faire l'analyse statique assurant qu'un seul thread peut modifier la mémoire à tout moment. C'est vérifié statiquement et ça ne consiste grosso modo qu'à une annotation des types pour marquer cette possibilité. Dans le code compilé tu n'a plus rien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La source
Posté par jmiven . Évalué à 10. Dernière modification le 10 janvier 2024 à 12:04.
Oui c'est vraiment désolant ! C'est comme dans les années 50. Les programmeurs faisaient plein d'erreurs bêtes dans leur code machine, mais au lieu d'améliorer leur formation, on a voulu solutionner en s'encombrant d'un "assembleur". À croire qu'on n'apprendra jamais !
[^] # Re: La source
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Éviter les erreurs bêtes, c'est une bonne raison.
Là c'est comme si le constat de départ dans les années 50 étaient les programmeurs ne comprennent rien à l'informatique :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: La source
Posté par Renault (site web personnel) . Évalué à 10.
Le constat de départ c'est que le parallélisme c'est un sujet compliqué sujet à de nombreuses erreurs.
S'assurer qu'on a de bonnes perfs en parallélisant des tâches ou actions tout en ayant aucun effet de bord c'est une gymnastique intellectuelle difficile surtout quand tu ne connais pas le logiciel dans son intégralité car il est trop gros. Un effet de bord est vite arrivé.
Il faut être très rigoureux, tu as vite oublié la protection mémoire quelque part qui va bien et du coup tu as un conflit d'accès à la donnée, ou utilisé la protection mémoire au mauvais endroit et du coup tu as un interblocage.
Même quand tu es formé à la question ces erreurs arrivent car on ne peut pas penser à tout tout le temps. Comme la gestion de la mémoire d'ailleurs, s'assurer que tout est alloué une fois au bon endroit à la bonne taille et la mémoire libérée une fois au bon endroit de manière systématique c'est aussi difficile. Même des développeurs expérimentés et formés t'introduisent des failles de sécurité car la mémoire est mal gérée ou des crashs car mince la libération de la mémoire n'a pas été faite au bon endroit (ou un accès a été fait là où il ne fallait pas).
Et en plus manque de bol avec le parallélisme, le débogage est difficile quand un problème survient. Bogues difficiles à identifier, à reproduire, lire le code pour identifier le problème est rarement suffisant, etc. Donc quand ça arrive tu perds un temps fou dessus.
Bref, si un langage avec un compilateur permet de dire "ici ça pue, bogues potentiels à venir, corrige ou marque ce bout de code comme "je sais ce que je fais"" cela simplifie grandement la tâche, en particulier pour les gens formés qui pourront se concentrer sur l'architecture plutôt que de reproduire des bogues compliqués.
[^] # Re: La source
Posté par barmic 🦦 . Évalué à 2.
Je ne le présenterais pas comme ça.
AMHA hors de cas simples, un humain ne sait pas faire de programmes parallèles correct : c'est à dire à la fois qui gagne en performance et qui reste sûr d'un point de vu fonctionnel.
On pourra trouver des développeurs et des équipes qui repoussent un peu les limites du « cas simples », mais rien de véritablement pérenne.
Ce n'est pas une question de technologie, les problèmes que résolvent les langages à runtime ne protègent pas de tout et les CPU ont eux aussi du mal à résoudre ce problème. Rust non plus n'est pas une silver bullet qui garanti aucune erreur, c'est juste qu'il en élimine de base plus que la plupart des autres.
On casse des pierres avec des pioches, certains font ça avec un coup bien placé, mais ils ne sont pas nombreux et ne le font pas dans autant de conditions que n'importe qui avec une pioche. Le fait que des mineurs existent ne rend pas les pratiquant d'art martiaux moins impressionnants et je suis sûr que ces derniers ne se disent pas que les mineurs leur pique leur travail artisanal avec une organisation industrielle et des outils.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La source
Posté par Renault (site web personnel) . Évalué à 5.
Je n'ai pas dit que Rust était une solution parfaite à ces problèmes. Outre l'erreur d'implémentation du compilateur et du runtime, il ne peut en effet identifier tous les problèmes potentiels. Mais il apporte une aide précieuse malgré tout.
[^] # Re: La source
Posté par barmic 🦦 . Évalué à 2.
Ah oui non je parlais de présenter les choses différemment surtout parce que présenter la question de rigueur ou d'oubli par exemple donne l'impression (à mon avis) que c'est accessible alors que ça n'est pas le cas à mon avis.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: La source
Posté par kantien . Évalué à 3. Dernière modification le 14 janvier 2024 à 01:14.
Je ne crois pas que le constat soit là, mais il me semble analogue à un certain principe constitutif du groupe Bourbaki. Ce groupe fut fondé, dans les années 1930, par des mathématiciens normaliens pour mettre de l'ordre dans l'exposé de l'édifice mathématique de leur époque, et ils avaient pour principe qu'à 50 ans on quitte le groupe.
Lors d'un émission d'Àpostrophes de Bernard Pivot, Jean Dieudonné, un ancien membre du groupe, fut interrogé sur ce principe. Pivot, lui demandant si cela voulait dire que l'on ne valait plus rien, se fit offrir cette réponse :
Rien de neuf sous le soleil : une génération en remplace une autre, et l'ancienne s'accroche à ses habitudes.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: La source
Posté par Thomas Douillard . Évalué à 10.
Le problème fondamental du solutionnisme technologique c’est pas uniquement "bon on a un problème, voilà une solution technologique qui va la résoudre", c’est aussi "bon, on a un problème, on a pas de solution mais spa grave on va forcément s’en sortir par la technique !"
Là c’est pas tout à fait la même chose. On a un problème, on sait que la technique peut aider, il y a manifestement de toute manière besoin de formation dans les deux cas. Sauf que sans Rust, on a déjà eu des années pour former les mainteneurs et les développeurs de drivers, et manifestement la montée en compétence est assez compliquée pour tout le monde vu que le problème est toujours là bien que le code Linux soit globalement mûr.
Et on sait que du point de vue technique … il y a des solutions logicielles qui peuvent aider les devs ou les forcer à plus de rigueur, le compilateur Rust laissera pas passer facilement certaines classes de bug. Reste à faire monter les mainteneurs en compétence aussi, c’est un problème de formation humaine. On a juste troqué un problème de formation humaine par un autre mais laquelle est la plus difficile ?
[^] # Re: La source
Posté par Skilgannon . Évalué à 1.
Concernant la source proprement dite, bien que je ne visite pas très souvent ce site, j'ai malheureusement l'impression que c'est devenu une habitude des "auteurs" de leurs articles.
Beaucoup de ceux-ci ont des tournures de phrase assez bizarre. De là a dire les articles sont traduis automatiquement, il y a un pas que je ne franchirais pas; pour la simple et bonne raison que certains traducteurs automatique ferait un peu mieux !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.