Ce 24 décembre, l'équipe de Redox OS (système d'exploitation que je vous présentais récemment) a annoncé la sortie de la version 0.6 de leur système d'exploitation.
Quoi de neuf ?
Un certain nombre de nouveaux projets ont été introduits depuis la version 0.5, et de nombreuses améliorations ont été apportées. De très nombreux bugs ont été résolus. Parmi les milliers de commits effectués depuis la dernière version, on peut mentionner les éléments suivants (en étant évidemment loin de l’exhaustivité) :
- rmm, une réécriture complète du gestionnaire de mémoire du noyau. Cela a permis d'éliminer les fuites de mémoire du noyau, qui étaient devenues un problème avec le précédent gestionnaire de mémoire. De plus, le support multi-core est beaucoup plus stable.
- Une grande partie du travail de RSoC, sponsorisé par des dons à Redox OS, a été intégrée dans cette nouvelle version. Cela comprend notamment des travaux sur ptrace, strace, gdb, le partitionnement de disque, la journalisation, io_uring.
- relibc a vu une grande quantité de travail, aboutissant à des améliorations pour tout ce qui en dépend (c'est-à-dire tout ce qui se trouve dans l'espace utilisateur).
- pkgar est un nouveau format de paquet. Il est beaucoup plus rapide à créer et à extraire que l'ancien format tar.
- cookbook a été repensé pour supporter un nouveau système de construction basé sur Rust. Ce système de compilation utilise des fichiers toml au lieu de scripts shell, et un certain nombre de paquets ont été portés sur ce système.
L’espoir au sein de l’équipe de Redox OS est d’avoir une publication des versions plus fréquentes. L’avenir nous dira s’ils y arriveront ou si cela restera un vœu pieux.
Mais encore ?
Ce qui n’est pas annoncé dans cette version : le caractère selfhosting ne semble pas encore atteint.
Si l’on en croît les discussions sur les forums, une des prochaines évolutions sera un installateur graphique. Des progrès concernant des drivers GPU sont sans doute aussi dans le pipe.
Alors, possible de l’utiliser tous les jours ?
À la question de savoir ce qui manque à Redox OS avant qu'il puisse utiliser toutes les capacités d'un ordinateur portable system76 (qui est l’employeur de Jeremy Soller, le créateur de Redox), Jeremy répond :
iwlwifi, une pile USB plus complète, i2c caché, accélération graphique.
Mais ce qui fonctionne, c'est plutôt cool. Ethernet, entrée, graphiques non accélérés, stockage nvme et ahci
Si vous voulez tester par vous-même, vous pouvez télécharger l'image de Redox OS 0.6.0.
# Des fuites mémoires en Rust ?
Posté par nokomprendo (site web personnel) . Évalué à 2.
Loin de moi l'idée de troller mais je suis un peu surpris de lire ça vu qu'on nous présente souvent Rust comme "memory-safe". Il y a une discussion à ce sujet sur HN : https://news.ycombinator.com/item?id=25536248
[^] # Re: Des fuites mémoires en Rust ?
Posté par tisaac (Mastodon) . Évalué à 3.
Pour ceux que cela intéressent de voir comme créer de fuites de mémoire avec Rust (et qui comprennent mieux que moi la programmation :-)): on trouve ceci dans la documentation de Rust.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Des fuites mémoires en Rust ?
Posté par claudex . Évalué à 7.
Alors, sans même aller dans la complexité d'un allocateur mémoire, tu peux avoir des fuites mémoire dans n'importe quel langage à mémoire gérer (Java, JavaScript, Python..) en gardant des références sur des objets qui ne sont plus utilisés. L'exemple le plus fréquent, est une liste/tableau qui n'est jamais vidé.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Des fuites mémoires en Rust ?
Posté par lhp22 . Évalué à 1.
Les références sont très précisément gérées en Rust. Tout l'intérêt de ce langage réside dans son borrow-checker extrêmement pointilleux.
Néanmoins, cela crée des situations intenables pour les développeurs. Il y a donc, au sein de la bibliothèque standard de Rust des petits bypass qui encapsulent une référence. Cette encapsulation fait que le borrow-checker est moins tatillon. MAIS dans ces petits bypass, il y a tout de même une gestion rigoureuse liée au borrow-checker pour garder une haute fiabilité en la gestion de la mémoire.
Sauf qu'à partir du moment où il y a ces petits bypass, des listes, il y a des petits trucs qui peuvent passer sous la ligne de flotaison du borrow-checker.
Et visiblement, ça apparaissait dans l'ancien code.
NB : borrow-checker = checkeur de référence. C'est le bout du compilateur rust qui invalide du code si des ressources se retrouvent partagées entre plusieurs variables (par exemple).
Voilà \o/
[^] # Re: Des fuites mémoires en Rust ?
Posté par claudex . Évalué à 7.
Je ne comprends pas du tout ce que tu veux dire et surtout en quoi c'est une réponse à mon commentaire. Rust ne fait rien pour t'empêcher de laisser des éléments dans une liste (et heureusement).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Des fuites mémoires en Rust ?
Posté par abriotde . Évalué à 4.
Une fuite mémoire c est quand tu consomme de la mémoire de manière iinutile. Tu aloue de la mémoire rien ne t interdit en Rust de le faire. Ce que Rust t empêche ou du moins fais bien c est t eviter de perdre toute référence à cette mémoire et donc t éviter de perdre cette mémoire de manière irréversible. Il t t'empêche aussi de croire que la mémoire est allouée alors qu elle n existe plus. Il te garanti une consistance de ton programme mais n'empêche pas par exemple une boucle infini.
[^] # Re: Des fuites mémoires en Rust ?
Posté par nokomprendo (site web personnel) . Évalué à 2.
Non, ça c'est juste une utilisation sous optimale de la mémoire.
Voila, ça c'est une fuite mémoire. Et apparemment Rust ne garantie pas leur absence.
[^] # Re: Des fuites mémoires en Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 4.
Comme dit plus haut, même les langages à Garbage Collector ne garantissent pas l'absence de fuites mémoire. Ce qui est garanti, c'est l'absence de data race, de double free, de dangling pointers … ; et en pratique il y a beaucoup moins de travail pour le programmeur afin d'éviter les fuites mémoire (99% du travail est fait automatiquement par le GC).
Rust apporte la même chose, à la compilation, sans GC.
[^] # Re: Des fuites mémoires en Rust ?
Posté par nokomprendo (site web personnel) . Évalué à 0.
Merci mais je ne vois pas ce que les GC viennent faire ici. Le but d'un GC, c'est principalement d'apporter de la simplicité, pas forcément de la memory-safety.
Donc oui, je veux bien croire que Rust est génial pour gérer la mémoire dans un projet système développé par des pros mais apparemment ça ne vaccine pas des refontes pour corriger des problèmes mémoires. Ce n'est pas une critique, c'est juste que ça m'a surpris par rapport à l'image que j'avais de Rust, et visiblement je ne suis pas le seul dans ce cas.
[^] # Re: Des fuites mémoires en Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 5.
Vu qu'on se sert principalement de langages à GC pour faire des services Web par exemple (Java/Python/PHP/Go…) et que la sécurité y est un élément important je dirai qu'on embrasse les différentes qualités qu'apporte un GC en général (même si les développeurs ne s'en rendent pas compte car ce sont des problèmes bas niveau). En fait la simplicité vient justement en partie du fait que des problèmes de memory safety n'existent pas. Donc la simplicité ce n'est pas seulement qu'on n'a pas besoin d'appeler
free().En ce qui me concerne j'ai déjà corrigé ici-même des gens qui disaient que Rust empêchaient toutes sortes de fuite mémoire. Ici par exemple, dans une dépêche Rust: https://linuxfr.org/news/rust-a-5-ans-retrospective#comment-1823413
Reste que ce n'est pas parce que ce n'est pas une solution miracle qui garantit qu'il n'y aura jamais besoin de "refontes pour corriger des problèmes mémoires" que ça ne veut pas dire que ça ne fait pas mieux que les autres langages (par exemple en faisant que ce genre de refonte est rare—rappelons que l'on parle d'un noyau qui est plus complexe qu'un programme lambda—nul miracle certes, mais un progrès quand même).
Comme je l'ai dit précédemment tu as des avantages des langages à GC (sécurité mémoire + on ne se préoccupe que rarement de libérer la mémoire à la main) mais sans le coup à l'exécution d'un GC (comme dans les langages à gestion manuelle de la mémoire). Oui c'est moins sympa que l'image "ça corrige tous les problèmes mémoire" (ce qu'aucun langage même lent et haut niveau ne peut faire), mais c'est déjà pas mal.
[^] # Re: Des fuites mémoires en Rust ?
Posté par nokomprendo (site web personnel) . Évalué à 0.
Quel rapport ? Ici, le sujet c'est Rust pour faire un OS.
Voilà c'est ça. Sauf que l'image elle vient peut-être aussi du fait que la memory-safety on nous la sert dès la page d'accueil de Rust alors que pour les fuites mémoires il faut aller en section 15.6 du manuel.
[^] # Re: Des fuites mémoires en Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 7.
Le rapport c'est que tu n'a pas compris les garanties qu'apporte Rust, alors j'utilise un paradigme plus connu, le GC, en espérant que tu le connaisses mieux, pour te l'expliquer… Mais visiblement tu préfères juste te plaindre que tu as été honteusement trompé.
Pour la bonne raison que les fuites mémoires ne posent pas de problème de memory safety . Ce sont des problèmes, de mémoire, mais qui ne posent pas de souci de sûreté ; les fuites mémoires sont évidemment prises au sérieux, et Rust rend leur présence beaucoup plus difficile.
Donc c'est normal que la sûreté soit mise en avant vu qu'elle est garantie (au revoir les buffer overflows, les dangling pointers, les accès non protégés inter-threads …—et surprise, c'est bien dans le cadre de l'écriture d'un OS), et qu'il faille un peu lire la documentation pour avoir les cas tordus de fuites mémoire.
[^] # Re: Des fuites mémoires en Rust ?
Posté par nokomprendo (site web personnel) . Évalué à -2.
Ah, effectivement, j'avais pas compris cela. Malheureusement, je ne vis pas dans le monde merveilleux de la mémoire infinie où les fuites mémoires ne sont pas un problème de sûreté. Merci pour ces explications bienveillantes.
[^] # Re: Des fuites mémoires en Rust ?
Posté par mahikeulbody . Évalué à 3.
Tu ne confonds pas sûreté et sécurité ?
[^] # Re: Des fuites mémoires en Rust ?
Posté par nokomprendo (site web personnel) . Évalué à 0.
Quand j'ai des calculs un peu bourrins à implémenter, une fuite mémoire c'est un crash assuré donc le résultat est à peu près le même qu'un dangling pointer.
Appelle ça "sécurité", "sûreté", "pas un problème de memory-safety" ou comme tu veux, pour moi c'est juste non.
[^] # Re: Des fuites mémoires en Rust ?
Posté par mahikeulbody . Évalué à 5.
Que ce soit "juste non" pour toi, c'est ton affaire. Là, si j'ai bien compris, GuieA_7 t'explique seulement que le memory-safety mis en avant dans la présentation de Rust que tu critiques est relatif à la sûreté et non à la sécurité (même si Rust prétend aussi améliorer cette dernière). Et donc que ta critique ne serait pas justifiée.
[^] # Re: Des fuites mémoires en Rust ?
Posté par nokomprendo (site web personnel) . Évalué à 0.
Formidable. Merci pour cette explication de vocabulaire. Du coup, pensez à aller corriger la page wikipedia sur la memory-safety, car elle mentionne les memory leaks (https://en.wikipedia.org/wiki/Memory_safety).
Perso, j'arrête là; j'ai eu une réponse satisfaisante ici https://linuxfr.org/nodes/122732/comments/1835522 et ce que je retiens c'est surtout que dès que ça parle de Rust, il faut redoubler de méfiance.
[^] # Re: Des fuites mémoires en Rust ?
Posté par xcomcmdr . Évalué à 4.
C'est juste du natif sans toutes les emmerdes du C, et plus haut-niveau.
Ce n'est pas le premier, ni le dernier à le proposer. C'est juste que pour une fois, ça a l'air de tenir ses promesses.
Ce n'est pas parce que je peux créer des fuites mémoire en C#, Rust, ou autre, malgré toutes les protections et en un tour de main que je vais aller dire que c'est de la merde.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Des fuites mémoires en Rust ?
Posté par GuieA_7 (site web personnel) . Évalué à 6.
Je ne sais pas ce que le terme technique "bourrins" signifie dans ton monde, mais un dangling pointer peut mener à des résultats faux, mais valides, et sans crash. Donc a un bug que tu ne verras peut-être jamais ; en général on considère que quand un dangling pointer provoque une segmentation fault on a de la chance !
Tu veux dire que comme aucun langage ne garantit l'absence de fuite mémoire, tu ne programmes pas du tout ?
[^] # Re: Des fuites mémoires en Rust ?
Posté par abriotde . Évalué à 3.
Mais si ça vaccine des problèmes mémoires du C mais ça n empêche pas tous les problèmes. Les problèmes que tu retrouve dans tous langages. Par exemple tu peux faire une boucle pour ajouter 5 fois 3 ce sera plus long que de faire l opération 3 fois 5. Eh bien la c est pareil tu peux a chaque qu on te demande un programme allouer la mémoire pour, ou tu peux regarder si tu en a pas déjà alloué à un programme qui a fini ça tâche. Dans le premier cas tu auras une fuite mémoire et au bout d un temps plus ou moins long tu aura consommé toute la ram….
C est une question d algorithmique pas de langage.
[^] # Re: Des fuites mémoires en Rust ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
Cadeau -->
'''''''':)# Vitesse de développement par rapport au C/C++
Posté par Ontologia (site web personnel) . Évalué à 3.
Une question que je me pose est : Il y a t-il un gain de temps substantiel par rapport à un développement en C/C++ ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Vitesse de développement par rapport au C/C++
Posté par nokomprendo (site web personnel) . Évalué à 3.
"C/C++" ça n'existe pas. Des OS écrits en C++, il ne doit pas y en avoir beaucoup, à part Haiku.
Pour le gain de temps, Rust apporte un système de type différent et un modèle mémoire qui évite les double-free, use-after-free… A priori, c'est plutôt une question de projet (les fonctionnalités prévues, l'équipe de dev et ses compétences…) que de langage.
[^] # Re: Vitesse de développement par rapport au C/C++
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
En C++, en plus de Haiku, il y a au moins SkyOS, Syllable et AtheOS (tous les 3 abandonnés aujour'hui), et surtout Fuchsia chez Google.
[^] # Re: Vitesse de développement par rapport au C/C++
Posté par Pol' uX (site web personnel) . Évalué à 3.
Perso j'aurais tendance à parier que le gain est coté maintenance (à long terme). Car le système de type aide à détecter des anomalies qui peuvent être courante en C.
Adhérer à l'April, ça vous tente ?
[^] # Re: Vitesse de développement par rapport au C/C++
Posté par GuieA_7 (site web personnel) . Évalué à 6.
Alors ce n'est pas tout à fait ce que tu demandes, mais j'avais lu cet article intéressant où l'auteur, fan de Kotlin, explique comment il a fini par trouver Rust aussi productif pour les projets complexes: https://ferrous-systems.com/blog/rust-as-productive-as-kotlin/
C'est une question complexe, et il faut commencer par se demander ce qu'on mesure. Exemple (avec des chiffres pipo): si un programme est développé en C en un 1 mois (avec des bugs critiques et complexes à corriger: mémoire, threads…), qu'un programme équivalent est fait en 2 mois en Rust (mais avec seulement 1% des bugs de la version C), et qu'il faudra au final 2 mois supplémentaires à la version C pour corriger les bugs les plus gros (sans atteindre la qualité du programme en Rust) ; alors que peut-on en conclure sur la productivité ? La réponse peut dépendre des cas, si on parle de time-to-market par exemple (et oui même si dans mon exemple là j'aimerais répondre simplement "Rust" pour des raisons de long termes, on sait bien qu'en pratique c'est plus compliqué).
[^] # Re: Vitesse de développement par rapport au C/C++
Posté par abriotde . Évalué à 1. Dernière modification le 29 décembre 2020 à 22:31.
Il y a aussi un autre problème, on a pas (ou très peu) de développeurs Rust avec 10 ans d expérience 90% Rust alors que beaucoup de développeurs ont 20 voire 30 ans d expérience C/C++. Et C comme Rust on des difficultés techniques qui demandent des années à maîtriser. Ce qui est sûr c est qu un développeur Rust "débutant" mettra plus de temps qu un développeur C expérimenté pour un même programme… peut-être que le développeur Rust ne sera malgré tout pas perdant pour autant car il aura moins de Bug critique…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.