Je suis tout à fait d'accord, je ne comprend pas pourquoi lorsque je branche une clé usb, elle est montée dans /media, et pour un point de montage smb, c'est juste nautilus qui y a accès à travers une pile logicielle.
L'outil standard mount sait très bien faire tout ça non ?
J'utilise un greffon nautilus tout simple mais bien pratique : ouvrir le répertoire courant dans un terminal.
Et bah ça ne marche pas dès que c'est un point de montage autre que /, /home, /media/disk !
En fait j'ai découvert un peu par hasard que depuis gvfs ils sont montés dans ~/.gvfs/nom_de_la_ressource, et avec cd pouf je suis dans le répertoire (mais le gfreffon nautilus-open-terminal est devenu inutile puisqu'il faut que je fasse cd à la main).
GVFS peut être très pratique, sans logiciel de lecture de CD je peux faire aplay ~/.gvfs/point\ de\ montage\ cdda\ sur\ sr0/Track\ 1.wav par exemple, ou accéder au point de montage avec un navigateur de fichier extérieur à gnome (simplement le sélecteur de fichier d'une appli non gnome).
Mais pourquoi est-ce gvfs qui fait ça et pas fuse qui est bien plus bas niveau ? gvfs utilise peut-être fuse ça se trouve, je ne sais pas, mais je préférerai que la pile logicielle soit système → outil? → gnome → nautilus
système → outil? → sh
système → outil? → kde → dolphin
plutôt que système → gnome → nautilus
système → gnome → sh
système → gnome → kde → dolphin
En fait j'ai remarqué avec le temps que les environnements de bureau très utilisés ont tendance à développer à leur niveau des outils qui devraient être dessous, mais manquant ou peu développé, comme l'automount des périphériques amovibles (CD, clé USB) en leur temps lorsque udev/hal n'étaient pas là. Ça permet d'apporter tout de suite le fonctionnement demandé par l'utilisateur même si ce n'est pas optimal.
Ça apporte un avantage aussi pour la portabilité, que ce soit sous GNU/* ou *BSD, en utilisant peu le sous-système on est plus portable.
Mais c'est toujours de la rustine, ça ne reste accessible qu'au programme compatible avec la pile logicielle du DE, et tout comme X11 est un OS au dessus de l'OS, Gnome, KDE etc. tendent à devenir des OS dans l'OS qui se mettent à gérer les périphériques.
Heureusement, après quelques temps, quand les outils systèmes sont développés, ils sont adoptés, mais c'est dommage que ce soient d'abord les développeurs de DE qui développent la fonctionnalité avant le développeur OS, mais c'est compréhensible, l'automount de périphériques amovibles et de ressources réseau c'est une priorité du développeur d'interface graphique qui a besoin que ça se fasse depuis son clicodrome, pas pour le développeur système qui ne touche pas au clicodrome.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: blagues
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Microsoft renoue avec ses fondamentaux. Évalué à 6.
L'outil standard mount sait très bien faire tout ça non ?
J'utilise un greffon nautilus tout simple mais bien pratique : ouvrir le répertoire courant dans un terminal.
Et bah ça ne marche pas dès que c'est un point de montage autre que /, /home, /media/disk !
En fait j'ai découvert un peu par hasard que depuis gvfs ils sont montés dans ~/.gvfs/nom_de_la_ressource, et avec cd pouf je suis dans le répertoire (mais le gfreffon nautilus-open-terminal est devenu inutile puisqu'il faut que je fasse cd à la main).
GVFS peut être très pratique, sans logiciel de lecture de CD je peux faire
aplay ~/.gvfs/point\ de\ montage\ cdda\ sur\ sr0/Track\ 1.wavpar exemple, ou accéder au point de montage avec un navigateur de fichier extérieur à gnome (simplement le sélecteur de fichier d'une appli non gnome).Mais pourquoi est-ce gvfs qui fait ça et pas fuse qui est bien plus bas niveau ? gvfs utilise peut-être fuse ça se trouve, je ne sais pas, mais je préférerai que la pile logicielle soit
système → outil? → gnome → nautilussystème → outil? → sh
système → outil? → kde → dolphin
plutôt que
système → gnome → nautilussystème → gnome → sh
système → gnome → kde → dolphin
En fait j'ai remarqué avec le temps que les environnements de bureau très utilisés ont tendance à développer à leur niveau des outils qui devraient être dessous, mais manquant ou peu développé, comme l'automount des périphériques amovibles (CD, clé USB) en leur temps lorsque udev/hal n'étaient pas là. Ça permet d'apporter tout de suite le fonctionnement demandé par l'utilisateur même si ce n'est pas optimal.
Ça apporte un avantage aussi pour la portabilité, que ce soit sous GNU/* ou *BSD, en utilisant peu le sous-système on est plus portable.
Mais c'est toujours de la rustine, ça ne reste accessible qu'au programme compatible avec la pile logicielle du DE, et tout comme X11 est un OS au dessus de l'OS, Gnome, KDE etc. tendent à devenir des OS dans l'OS qui se mettent à gérer les périphériques.
Heureusement, après quelques temps, quand les outils systèmes sont développés, ils sont adoptés, mais c'est dommage que ce soient d'abord les développeurs de DE qui développent la fonctionnalité avant le développeur OS, mais c'est compréhensible, l'automount de périphériques amovibles et de ressources réseau c'est une priorité du développeur d'interface graphique qui a besoin que ça se fasse depuis son clicodrome, pas pour le développeur système qui ne touche pas au clicodrome.
ce commentaire est sous licence cc by 4 et précédentes