Oulà, doucement avec la philosophie Unix. La colle qui unit tous ces outils, c’est le shell, le truc un peu bâtard, mi langage de programmation, mi interface utilisateur. Un truc qui sert à gérer la hiérarchie de fichiers (via cp, mv, ls & co), à faire du traitement de texte (via tr, sed, less, cat, etc.), ou encore à gérer les processus (nice, &, jobs, fg, bg, C-Z), ou leur communication avec des performances désastreuses (les entrées/sorties avec le tube). Bref un truc sous-optimal (mais un couteau suisse super souple) !
De plus, où situer la barre pour identifier si un ensemble de fonctionnalités doit être scindé ou fusionné ? Après tout le moindre éditeur fera très certainement du remplacement, n’est-ce pas pourtant dévolu à sed ? Pourquoi d’un autre côté avoir tout de même un sed, à quoi sert tr alors ? Notons que sed, puisque l’exemple me plait bien, a une effusion de fonctionnalités, avec un langage propre à lui (et ne parlons pas de awk).
Pour finir remarquons que la philosophie unix est essentiellement horizontale : on empile pas les couche, mais chaque élément communique avec l’autre plutôt que de s’appuyer dessus.
La question se pose alors pour un système de fichier, fondamentalement son but est de gérer nos disques. Alors pourquoi empiler les couches ? C’est-à-dire d’abord transformer les volumes physiques en volumes logiques, ensuite avec ces volumes logiques faire des partitions, ensuite à partir de ses partitions gérer un chiffrage, puis encore par dessus le système de fichier.
Deux hypothèses :
— Soit séparer chaque fonction a un coût négligeable (et a donc tout intérêt à la séparation), dans ce cas il y a tout intérêt à le faire et ce sera fait dans btrfs, alors le problème n’est qu’une histoire de nom (c’est juste qu’on appelle l’ensemble btrfs). Sachant que les différents outils séparés existent toujours pour celui qui veut de la souplesse (lvm&co), c’est-à-dire des éléments interchangeables.
— Soit il y a des gains notables et dans ce cas il est pertinent de regrouper les choses (car il ne faut pas oublier que la philosophie Unix s’appliquent aux outils de « haut niveau » et qu’elle conduit à des performances déplorables).
Pour appuyer mon propos, un petit extrait de man btrfs :
Nul doute que le binaire en question commence par un bon gros équivalent à un switch des cavernes sur la commande en premier argument. Il est alors plus question d’esthétique que de philosophie pour faire un binaire machin-subvolume, un autre btrfs-filesystem, et enfin truc-device. De pauvres liens symboliques dans le bin et tu n’y aurais vu que du feu ! :P
Pour finir, de ce que j’ai compris de btrfs, tout est représenté sous forme d’arbre, données, méta-données, et j’en passe, tout passe par la même structure, le fameux copy-on-write B-tree. Il y a fort à parier que l’ajout de fonctionnalités était surtout du pissage de code plus que de la conception (totalement dédié à un B-tree performant et fiable). Et vu qu’au final btrfs a évolué plutôt vite il me semble, et qu’on se retrouve avec le fsck qui tarde, je ne pense pas que le bousin soit un grosse usine à gaz.
[^] # Re: Toujours lamêmequestion
Posté par BB . En réponse à la dépêche btrfs avance à grands pas. Évalué à 10.
Oulà, doucement avec la philosophie Unix. La colle qui unit tous ces outils, c’est le shell, le truc un peu bâtard, mi langage de programmation, mi interface utilisateur. Un truc qui sert à gérer la hiérarchie de fichiers (via cp, mv, ls & co), à faire du traitement de texte (via tr, sed, less, cat, etc.), ou encore à gérer les processus (nice, &, jobs, fg, bg, C-Z), ou leur communication avec des performances désastreuses (les entrées/sorties avec le tube). Bref un truc sous-optimal (mais un couteau suisse super souple) !
De plus, où situer la barre pour identifier si un ensemble de fonctionnalités doit être scindé ou fusionné ? Après tout le moindre éditeur fera très certainement du remplacement, n’est-ce pas pourtant dévolu à sed ? Pourquoi d’un autre côté avoir tout de même un sed, à quoi sert tr alors ? Notons que sed, puisque l’exemple me plait bien, a une effusion de fonctionnalités, avec un langage propre à lui (et ne parlons pas de awk).
Pour finir remarquons que la philosophie unix est essentiellement horizontale : on empile pas les couche, mais chaque élément communique avec l’autre plutôt que de s’appuyer dessus.
La question se pose alors pour un système de fichier, fondamentalement son but est de gérer nos disques. Alors pourquoi empiler les couches ? C’est-à-dire d’abord transformer les volumes physiques en volumes logiques, ensuite avec ces volumes logiques faire des partitions, ensuite à partir de ses partitions gérer un chiffrage, puis encore par dessus le système de fichier.
Deux hypothèses :
— Soit séparer chaque fonction a un coût négligeable (et a donc tout intérêt à la séparation), dans ce cas il y a tout intérêt à le faire et ce sera fait dans btrfs, alors le problème n’est qu’une histoire de nom (c’est juste qu’on appelle l’ensemble btrfs). Sachant que les différents outils séparés existent toujours pour celui qui veut de la souplesse (lvm&co), c’est-à-dire des éléments interchangeables.
— Soit il y a des gains notables et dans ce cas il est pertinent de regrouper les choses (car il ne faut pas oublier que la philosophie Unix s’appliquent aux outils de « haut niveau » et qu’elle conduit à des performances déplorables).
Pour appuyer mon propos, un petit extrait de man btrfs :
Nul doute que le binaire en question commence par un bon gros équivalent à un
switchdes cavernes sur la commande en premier argument. Il est alors plus question d’esthétique que de philosophie pour faire un binaire machin-subvolume, un autre btrfs-filesystem, et enfin truc-device. De pauvres liens symboliques dans le bin et tu n’y aurais vu que du feu ! :PPour finir, de ce que j’ai compris de btrfs, tout est représenté sous forme d’arbre, données, méta-données, et j’en passe, tout passe par la même structure, le fameux copy-on-write B-tree. Il y a fort à parier que l’ajout de fonctionnalités était surtout du pissage de code plus que de la conception (totalement dédié à un B-tree performant et fiable). Et vu qu’au final btrfs a évolué plutôt vite il me semble, et qu’on se retrouve avec le fsck qui tarde, je ne pense pas que le bousin soit un grosse usine à gaz.