Je croyais avec une lecture (un peu trop rapide) du titre que c’était l’outil de bcache (un système pour avoir un cache SSD devant un disque plus lent), mais non ce n’est que l’outil de bcachefs, un système de fichier expérimental qu’il convient de ne pas utiliser en production pour le moment, donc bon, c’est pas la mort.
Par contre le commentaire sur l’instabilité de l’écosystème rust est très intéressant.
ce commentaire est sous licence cc by 4 et précédentes
De ce que je vois ce n'est pas Rust qui soit instable mais BCacheFS. Il dit c'est compliqué se maintenir à long terme in outils qui n'a pas de maintenance longue… surtout concernant un FS. Effectivement si pour un logiciel comme Firefox il suffit de mettre à jour les binaires et au pire on perd l'historique et les favoris (qui sont relativement simple à migrer) autant pour un FS cela peut s'avérer beaucoup plus périlleux de faire évoluer un disque volumineux pour l'adapter… surtout si le PC crash en plein milieu…
Autrement dit, tant que le FS n'est pas bien stabilisé en terme de structure il vaut mieux attendre…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
L’instabilité de l’écosystème rust est clairement pointée du doigt dans les citations de l’article:
I got some help from the Rust team who says that the common practice is to relax the dependencies of Rust software so that it builds in Debian. So errno, which needed the exact version 0.2, was relaxed so that it could build with version 0.4 in Debian, udev 0.7 was relaxed for 0.8 in Debian, memoffset from 0.8.5 to 0.6.5, paste from 1.0.11 to 1.08 and bindgen from 0.69.9 to 0.66. […] you may wonder how any distribution could sanely package this. […] anyone who needs to support bcachefs-tools long-term has to carry the support burden on their own, and if they bundle it’s dependencies, then those as well.
Traduction:
J'ai reçu de l'aide de l'équipe Rust qui a dit que la pratique courante est d'assouplir les dépendances des logiciels Rust pour qu'ils se construisent dans Debian. Ainsi, errno, qui avait besoin de la version exacte 0.2, a été assoupli pour pouvoir être construit avec la version 0.4 dans Debian, udev 0.7 a été assoupli pour 0.8 dans Debian, memoffset de 0.8.5 à 0.6.5, paste de 1.0.11 à 1.08 et bindgen de 0.69.9 à 0.66. […] vous pouvez vous demander comment une distribution peut raisonnablement empaqueter cela. […] quiconque a besoin de supporter bcachefs-tools à long terme doit prendre sur lui la tâche du support, et s'il empaquette ses dépendances, de celles-ci également.
L’outil lui-même est instable, mais l’écosystème l’est tout autant, et c’est pourquoi le mainteneur du paquet Debian jette l’éponge : maintenir l’outil est une chose, maintenir l’écosystème de rust est une autre chose, et comme on pourrait dire dans d’autres domaines « il a pas signé pour ça ».
ce commentaire est sous licence cc by 4 et précédentes
Je ne comprends pas tout. Les dépendances Rust sont compilées avec le binaire. Il n'y a donc pas de gestion des dépendances Rust dans la distribution. Là est toute la différence avec un langage interprète comme PHP ou Python (d'où les venv)…
Il peut y avoir des dépendances à des librairies externes mais il est toujours possible de les compilées avec. La seule librairie externe qui reste c'est la libc du noyau ce qui ne pose jamais problème.
C'est à la limite l'étape de compilation qui peut être un peu plus complexe mais Rust est très bien équipé pour ça avec la configuration cargo. Je ne vois pas ce que C a de plus. (Il est même bien moins bien outillé sur ce point). Les outils qu'il manque dans Rust ce serait tous les outils d'analyse statiques de C… mais Rust en a beaucoup moins besoin et cela ne gêne en rien la compilation mais le développement.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
PS et s'il y a des dépendances à modifier c'est parceque l'outil à été développé sous un autre OS que Linux (Windows, BSD ou un Linux très spécial sans libC) parceque Rust est beaucoup plus portable que C. Alors oui pour changer d'OS ça peut être un peu plus sioux… mais si ce n'est que des versions… ce n'est pas la mort.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Les dépendances Rust sont compilées avec le binaire. Il n'y a donc pas de gestion des dépendances Rust dans la distribution. Là est toute la différence avec un langage interprète comme PHP ou Python (d'où les venv)…
C'est une question de linquage dynamique ou statique, rust comme C et C++ support les 2.
Il peut y avoir des dépendances à des librairies externes mais il est toujours possible de les compilées avec. La seule librairie externe qui reste c'est la libc du noyau ce qui ne pose jamais problème.
Debian recompile lui-même tous les paquets donc Debian doit pouvoir recompiler les paquets si possible (voir strictement) sans utiliser autre chose qu'apt.
C'est à la limite l'étape de compilation qui peut être un peu plus complexe mais Rust est très bien équipé pour ça avec la configuration cargo. Je ne vois pas ce que C a de plus.
La critique n'est pas sur le langage mais l'écosystème qui évolue vite. Le fait que rust facilite l'utilisation de bibliothèques diverses et que ces dépendances soient strict oblige les mainteneurs à faire des hacks (qu'on peut retrouver ailleurs, mais ça a toujours été une grande source de débat dû au fait que ça peut introduire des bugs). Ça rejoint un peu https://linuxfr.org/users/jeanas/journaux/mon-inquietude-sur-les-dependances-en-rust
Sur LinuxFR c'était plus une critique générale des dépendances qui rajoute de la complexité potentiel… et là c'est un cas concret de problème qui n'était pas explicité (pensé)
Effectivement la complexité croit expannotiomellement avec la taille de l'arbre de dépendances.
En C comme cela se gère à la main on doit mettre des path en environnement et des librairies dynamiques… ce qui fait que l'on limite naturellement les dépendances. En outre les librairies dynamiques ne sont pas trop contraignantes… au pire ça plante à l'exécution si un appel de fonction à changé ou est absent (comme on utilise généralement moins de 10% de la librairie ça passe).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
L’environnement de compilation ça marche, même si littéralement la compilation est un sous-ensemble du build, à chaque fois que j’entends ou lit « environnement de compilation », je pense quand même à ce qui produit et délivre le produit final.
ce commentaire est sous licence cc by 4 et précédentes
# bcachefs ≠ bcache
Posté par Thomas Debesse (site web personnel) . Évalué à 3 (+0/-0).
Je croyais avec une lecture (un peu trop rapide) du titre que c’était l’outil de bcache (un système pour avoir un cache SSD devant un disque plus lent), mais non ce n’est que l’outil de bcachefs, un système de fichier expérimental qu’il convient de ne pas utiliser en production pour le moment, donc bon, c’est pas la mort.
Par contre le commentaire sur l’instabilité de l’écosystème rust est très intéressant.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: bcachefs ≠ bcache
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
Je crois qu'il y a un rapport tout de même. Il me semble avoir lu que BCache à été l'inspiration de BCacheFS
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: bcachefs ≠ bcache
Posté par Thomas Debesse (site web personnel) . Évalué à 3 (+0/-0).
Oui mais ça veut dire que l’absence de cet outil ne devrait avoir aucune incidence sur les usages de bcache.
Ce sont deux paquets différents :
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: bcachefs ≠ bcache
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
De ce que je vois ce n'est pas Rust qui soit instable mais BCacheFS. Il dit c'est compliqué se maintenir à long terme in outils qui n'a pas de maintenance longue… surtout concernant un FS. Effectivement si pour un logiciel comme Firefox il suffit de mettre à jour les binaires et au pire on perd l'historique et les favoris (qui sont relativement simple à migrer) autant pour un FS cela peut s'avérer beaucoup plus périlleux de faire évoluer un disque volumineux pour l'adapter… surtout si le PC crash en plein milieu…
Autrement dit, tant que le FS n'est pas bien stabilisé en terme de structure il vaut mieux attendre…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: bcachefs ≠ bcache
Posté par Thomas Debesse (site web personnel) . Évalué à 3 (+0/-0).
L’instabilité de l’écosystème rust est clairement pointée du doigt dans les citations de l’article:
Traduction:
L’outil lui-même est instable, mais l’écosystème l’est tout autant, et c’est pourquoi le mainteneur du paquet Debian jette l’éponge : maintenir l’outil est une chose, maintenir l’écosystème de rust est une autre chose, et comme on pourrait dire dans d’autres domaines « il a pas signé pour ça ».
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: bcachefs ≠ bcache
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+0/-1).
Je ne comprends pas tout. Les dépendances Rust sont compilées avec le binaire. Il n'y a donc pas de gestion des dépendances Rust dans la distribution. Là est toute la différence avec un langage interprète comme PHP ou Python (d'où les venv)…
Il peut y avoir des dépendances à des librairies externes mais il est toujours possible de les compilées avec. La seule librairie externe qui reste c'est la libc du noyau ce qui ne pose jamais problème.
C'est à la limite l'étape de compilation qui peut être un peu plus complexe mais Rust est très bien équipé pour ça avec la configuration cargo. Je ne vois pas ce que C a de plus. (Il est même bien moins bien outillé sur ce point). Les outils qu'il manque dans Rust ce serait tous les outils d'analyse statiques de C… mais Rust en a beaucoup moins besoin et cela ne gêne en rien la compilation mais le développement.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: bcachefs ≠ bcache
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
PS et s'il y a des dépendances à modifier c'est parceque l'outil à été développé sous un autre OS que Linux (Windows, BSD ou un Linux très spécial sans libC) parceque Rust est beaucoup plus portable que C. Alors oui pour changer d'OS ça peut être un peu plus sioux… mais si ce n'est que des versions… ce n'est pas la mort.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: bcachefs ≠ bcache
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Non s'il y a des versions à modifier c'est parce qu'il n'a pas été écrit avec le cadre de dépendance de la distribution en tête
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: bcachefs ≠ bcache
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
C'est une question de linquage dynamique ou statique, rust comme C et C++ support les 2.
Debian recompile lui-même tous les paquets donc Debian doit pouvoir recompiler les paquets si possible (voir strictement) sans utiliser autre chose qu'apt.
La critique n'est pas sur le langage mais l'écosystème qui évolue vite. Le fait que rust facilite l'utilisation de bibliothèques diverses et que ces dépendances soient strict oblige les mainteneurs à faire des hacks (qu'on peut retrouver ailleurs, mais ça a toujours été une grande source de débat dû au fait que ça peut introduire des bugs). Ça rejoint un peu https://linuxfr.org/users/jeanas/journaux/mon-inquietude-sur-les-dependances-en-rust
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: bcachefs ≠ bcache
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-0).
Merci, je vois un peu mieux.
Sur LinuxFR c'était plus une critique générale des dépendances qui rajoute de la complexité potentiel… et là c'est un cas concret de problème qui n'était pas explicité (pensé)
Effectivement la complexité croit expannotiomellement avec la taille de l'arbre de dépendances.
En C comme cela se gère à la main on doit mettre des path en environnement et des librairies dynamiques… ce qui fait que l'on limite naturellement les dépendances. En outre les librairies dynamiques ne sont pas trop contraignantes… au pire ça plante à l'exécution si un appel de fonction à changé ou est absent (comme on utilise généralement moins de 10% de la librairie ça passe).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: bcachefs ≠ bcache
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Même si tu ne fais pas du dynamic linking, tu dois quand même gérer l'environnement de build (quelqu'un peut me traduire ça en vrai français?).
[^] # Re: bcachefs ≠ bcache
Posté par Thomas Debesse (site web personnel) . Évalué à 3 (+0/-0).
L’environnement de compilation ça marche, même si littéralement la compilation est un sous-ensemble du build, à chaque fois que j’entends ou lit « environnement de compilation », je pense quand même à ce qui produit et délivre le produit final.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: bcachefs ≠ bcache
Posté par Psychofox (Mastodon) . Évalué à 3 (+0/-0).
Oui et on me souffle dans l'oreillette que j'aurais du dire chargement dynamique des bibliothèques pour dynamic linking.
J'ai eu un gros blanc quoi.
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.