Si tu veux un système qui marche pour tous, il n'y a pas le choix, seulement deux solutions :
- une gestion par le noyau
- une gestion par bibliothèque
La gestion en mode noyau peut être faite le mieux possible, c'est à dire mettre le plus de code possible en mode utilisateur. C'est justement le cas de Fuse.
La gestion par bibliothèque a peu de chance d'être générique. Si on souhaite que cela marche quasiment partout, il faut l'intégrer au coeur de la libc. En effet, la libc est linké avec 99% des executables (au pif). Aucune autre bibliothèque n'a cette possibilité.
Mais il y a aussi d'autre problème, les fichiers de type fish:/..., cela est-il conforme à la norme POSIX ? On a critiqué pendant longtemps les C:, D: ... de Microsoft, les UNIX préférant le système de fichier unifié où tout est sous /.
Personnellement, je trouve cela génial de pouvoir intégrer un serveur ftp distant dans mon arborescence / et que l'accès au serveur ftp soit transparent, un peu comme NFS qu'on oublie facilement en tant qu'utilisateur.
Il faut effectivement améliorer la facilité pour un utilisateur de monter un système de fichier distant, améliorer la robustesse de l'ensemble mais cela me parait bien plus positif que de travailler sur les VFS de gnome ou de kde.
Après, on va me dire que, ragnagna, Fuse ne marche pas sur tous les UNIX propriétaire, ne marche pas sous Windows... Et bien tant pis pour eux ! Ils n'ont qu'a faire le portage. Le code source est accessible à la lecture pour tous ;-)
[^] # Re: Ce qui est dommage
Posté par Sytoka Modon (site web personnel) . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 3.
- une gestion par le noyau
- une gestion par bibliothèque
La gestion en mode noyau peut être faite le mieux possible, c'est à dire mettre le plus de code possible en mode utilisateur. C'est justement le cas de Fuse.
La gestion par bibliothèque a peu de chance d'être générique. Si on souhaite que cela marche quasiment partout, il faut l'intégrer au coeur de la libc. En effet, la libc est linké avec 99% des executables (au pif). Aucune autre bibliothèque n'a cette possibilité.
Mais il y a aussi d'autre problème, les fichiers de type fish:/..., cela est-il conforme à la norme POSIX ? On a critiqué pendant longtemps les C:, D: ... de Microsoft, les UNIX préférant le système de fichier unifié où tout est sous /.
Personnellement, je trouve cela génial de pouvoir intégrer un serveur ftp distant dans mon arborescence / et que l'accès au serveur ftp soit transparent, un peu comme NFS qu'on oublie facilement en tant qu'utilisateur.
Il faut effectivement améliorer la facilité pour un utilisateur de monter un système de fichier distant, améliorer la robustesse de l'ensemble mais cela me parait bien plus positif que de travailler sur les VFS de gnome ou de kde.
Après, on va me dire que, ragnagna, Fuse ne marche pas sur tous les UNIX propriétaire, ne marche pas sous Windows... Et bien tant pis pour eux ! Ils n'ont qu'a faire le portage. Le code source est accessible à la lecture pour tous ;-)