Qu'on sursaute au premier abord en lisant 2Go, je veux bien. Qu'ensuite on se permette des commentaires, comme le tien d'ailleurs, sans s'être une seconde renseigné sur les tenants et les aboutissants de la chose, ainsi que sur le projet de façon plus générale, je trouve ça, pour le moins, extrêmement dommage.
On ne peut pas comparer l'avancée de deux projets en voyant "celui-là a supporté ça en X mois, celui-là en X années". Pas sur des projets dont la conception et les fondements sont totalement différents. Dans Unix, les systèmes de fichiers sont implémentés comme des objets à part, ayant juste à répondre à quelques appels définis par un VFS. Il est bien évident que dans ce contexte, il n'y a aucun problème pour supporter les systèmes de fichiers de plus de 2Go. Le Hurd fait le choix d'implémenter les systèmes de fichiers en tant que pagers associés à un "backing store" spécial (le système de fichiers sur disque). C'est une conception qui simplifie beaucoup de choses et permet une très grande flexibilité, à mon avis. Mais au moment de l'écriture concrète d'ext2fs, les auteurs font le choix d'avoir quelque chose qu'on sait limité, mais simple et stable : mapper tout le système de fichier en mémoire. Or sur IA-32, les espaces d'adressage font 4Go. On enlève la place réservée au noyau (comme sur tous les autres systèmes d'exploitation), on est autour de 2Go. La supprimer signifie reconcevoir un système permettant de mapper en mémoire juste ce qu'il faut, quand il le faut. C'est loin d'être trivial, et changer ext2fs c'est pendant un temps rendre extrêmement instable le système - et donc, ralentir le développement de toutes les autres parties.
Tout ça pour dire que ça n'est pas une "limitation à la con", parce qu'ext2fs serait une implémentation simplissime, le genre de trucs qu'on écrit à la va vite au début. Et en aucun cas ça ne permet de juger de l'avancée du projet. Au moment où ext2fs avait déjà cette limitation, le Hurd supportait déjà les sous-Hurd, c'est à dire l'exécution de plusieurs systèmes presque totalement indépendants, en parallèle, depuis plusieurs années. Chose que ni Linux avec chroot, ni FreeBSD avec jail, ni aucun autre système libre ne supporte. Le Hurd supporte effectivement le système de "jetons" dont j'ai maintes fois parlé. Je peux d'ores et déjà avoir un FTPd qui tourne sans -aucun- droit et qui les gagne en cours d'exécution, sans bidouille, sans problème. Je peux d'ores et déjà avoir mon ext2fs en utilisateur. Je peux d'ores et déjà lancer sans crainte mon ftpfs. Des choses que Linux n'est pas capable de faire, après quatorze ans de développement. Les projets n'évoluent pas forcément pareil, il faut s'y faire. Et les réactions ricanantes de certains me font désespérément penser à l'européano-centrisme d'autres face aux sociétés dites "primitives". Aussi inutile et biaisé.
On précisera par ailleurs que le patch pour ext2fs existe depuis plusieurs années. S'il n'a pas été intégré plus tôt, c'est par manque de testeurs. Il a été annoncé, y compris sur des sites francophones. C'est très vite de juger que de mettre en cause les développeurs du projet pour un tel "retard".
[^] # Re: heeeuu
Posté par Manuel Menal . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 10.
On ne peut pas comparer l'avancée de deux projets en voyant "celui-là a supporté ça en X mois, celui-là en X années". Pas sur des projets dont la conception et les fondements sont totalement différents. Dans Unix, les systèmes de fichiers sont implémentés comme des objets à part, ayant juste à répondre à quelques appels définis par un VFS. Il est bien évident que dans ce contexte, il n'y a aucun problème pour supporter les systèmes de fichiers de plus de 2Go. Le Hurd fait le choix d'implémenter les systèmes de fichiers en tant que pagers associés à un "backing store" spécial (le système de fichiers sur disque). C'est une conception qui simplifie beaucoup de choses et permet une très grande flexibilité, à mon avis. Mais au moment de l'écriture concrète d'ext2fs, les auteurs font le choix d'avoir quelque chose qu'on sait limité, mais simple et stable : mapper tout le système de fichier en mémoire. Or sur IA-32, les espaces d'adressage font 4Go. On enlève la place réservée au noyau (comme sur tous les autres systèmes d'exploitation), on est autour de 2Go. La supprimer signifie reconcevoir un système permettant de mapper en mémoire juste ce qu'il faut, quand il le faut. C'est loin d'être trivial, et changer ext2fs c'est pendant un temps rendre extrêmement instable le système - et donc, ralentir le développement de toutes les autres parties.
Tout ça pour dire que ça n'est pas une "limitation à la con", parce qu'ext2fs serait une implémentation simplissime, le genre de trucs qu'on écrit à la va vite au début. Et en aucun cas ça ne permet de juger de l'avancée du projet. Au moment où ext2fs avait déjà cette limitation, le Hurd supportait déjà les sous-Hurd, c'est à dire l'exécution de plusieurs systèmes presque totalement indépendants, en parallèle, depuis plusieurs années. Chose que ni Linux avec chroot, ni FreeBSD avec jail, ni aucun autre système libre ne supporte. Le Hurd supporte effectivement le système de "jetons" dont j'ai maintes fois parlé. Je peux d'ores et déjà avoir un FTPd qui tourne sans -aucun- droit et qui les gagne en cours d'exécution, sans bidouille, sans problème. Je peux d'ores et déjà avoir mon ext2fs en utilisateur. Je peux d'ores et déjà lancer sans crainte mon ftpfs. Des choses que Linux n'est pas capable de faire, après quatorze ans de développement. Les projets n'évoluent pas forcément pareil, il faut s'y faire. Et les réactions ricanantes de certains me font désespérément penser à l'européano-centrisme d'autres face aux sociétés dites "primitives". Aussi inutile et biaisé.
On précisera par ailleurs que le patch pour ext2fs existe depuis plusieurs années. S'il n'a pas été intégré plus tôt, c'est par manque de testeurs. Il a été annoncé, y compris sur des sites francophones. C'est très vite de juger que de mettre en cause les développeurs du projet pour un tel "retard".