Franchement on a vu mieux comme soft peu portable...
Je répète ce que j'ai répondu plus haut :
Que ça été porté ne signifie pas forcément que c'est portable, il a peut-être fallu qu'ils réécrivent de grosses parties du code, qui ne serait donc pas portable.
Les ports en question ne sont pas intégré chez l'upstream FUSE, pourquoi, sinon parce que ce seraient des grosses modifications et qu'ils ne voudraient pas les "couvrir" ?
J'ai regardé le code de la partie noyau de FUSE disponible sur SourceForge, et il n'y a pas une ligne de support pour d'autres OS que Linux, que des "linux.h", des appels spécifiques à Linux, etc. Ce n'est absolument pas portable.
Les "portages" en question ont donc dû être réécrits à partir de rien (pour la partie noyau).
Le problème c'est que kio ou autre ne permettent pas à une application de le voir de manière transparente. Donc même si c'est portable ça ne fait pas tout, il faut que les applications comportent de quoi le lire.
J'ai également déjà répondu plus haut : soit on choisit d'écrire un(des) module(s) noyau, qui ne peut pas être écrit de façon portable, mais on supporte toutes les applications, soit on écrit une bibliothèque en espace utilisateur (style KIO), qui ne supporte pas toutes les applications (mais déjà pas mal pour un utilisateur lambda qui se restreindrait à son environnement KDE/GNOME), mais qui peut être largement plus portable qu'un module noyau.
[^] # Re: Pas de VFS
Posté par Octabrain . En réponse au journal Monter un partage Samba sous Linux sans utiliser *VFS. Évalué à 3.
Je répète ce que j'ai répondu plus haut :
Que ça été porté ne signifie pas forcément que c'est portable, il a peut-être fallu qu'ils réécrivent de grosses parties du code, qui ne serait donc pas portable.
Les ports en question ne sont pas intégré chez l'upstream FUSE, pourquoi, sinon parce que ce seraient des grosses modifications et qu'ils ne voudraient pas les "couvrir" ?
J'ai regardé le code de la partie noyau de FUSE disponible sur SourceForge, et il n'y a pas une ligne de support pour d'autres OS que Linux, que des "linux.h", des appels spécifiques à Linux, etc. Ce n'est absolument pas portable.
Les "portages" en question ont donc dû être réécrits à partir de rien (pour la partie noyau).
Le problème c'est que kio ou autre ne permettent pas à une application de le voir de manière transparente. Donc même si c'est portable ça ne fait pas tout, il faut que les applications comportent de quoi le lire.
J'ai également déjà répondu plus haut : soit on choisit d'écrire un(des) module(s) noyau, qui ne peut pas être écrit de façon portable, mais on supporte toutes les applications, soit on écrit une bibliothèque en espace utilisateur (style KIO), qui ne supporte pas toutes les applications (mais déjà pas mal pour un utilisateur lambda qui se restreindrait à son environnement KDE/GNOME), mais qui peut être largement plus portable qu'un module noyau.