3 ms·

>someone to make a decision about the one true way to do things. Things don't really work this way in free and open source development. There is no one person

>someone to make a decision about the one true way to do things. Things don't really work this way in free and open source development. There is no one person to make decisions, consensus is reached when the quality of something raises "above the bar" and actually improves things for all involved parties. If someone wants there to be an über-library that serves everyone's use case then it's up to them to go and do the work to build that. And it has been getting better in this regard. For example KDE and GNOME used to have their own IPC, multimedia & audio mixing backends, but now both have converged on DBus, GStreamer and PulseAudio, in part because these were intentionally built to be flexible low-level solutions. I'm sure there are more examples of this too but those are the first that come to mind.

Mister_Snuggles 8y ago
You're absolutely right. I wonder if something like DBus and PulseAudio could happen with my UNC pain point. With the assumption that the goal is for "vi //server/share/file.txt" to work the same as "notepad.exe \\server\share\file.txt" does on Windows, here are my thoughts. First off, notepad.exe doesn't really care about the fact that it's a UNC path. It just opens the file with CreateFile (either CreateFileW or CreateFileA). There would need to be replacements for the libc file functions. These could be a shim in front of libc, or baked right into libc. Note, there's a LOT more needed than "just" new file functions - any functions that do anything with paths need to be looked at. Shells would likely need some changes to work properly, though it's not like the Windows shell can truly do much with UNC paths - copying files to/from works, but you can't cd into them. How does it ask for credentials? If it's via DBus, a desktop environment provide the authentication prompts, but what about a pure-commandline system? Maybe the transport is just SSH and relies on the existing public key authentication? But what if you're just doing a one-off thing and don't want to set that up? Using SSH is probably a decent idea since it's got authentication, security, and a file transfer protocol, already built in. On top of all of this, when you open //server/share/file.txt for writing, what does that actually mean? Is there a file descriptor? How does that work with the kernel? Does libc now manage all file descriptors with only a subset corresponding to kernel file descriptors? Could a pure user-space solution fake this well enough to actually work? Would this need to be a FUSE filesystem along with some daemon to automatically unmount the remote servers when the mount is no longer needed? Would it be something like the automounter, just a lot better? Does a kernel need changes for any of this to work? This is one of those things that touches so many layers and potentially interacts with so many parts of the system, potentially all the way down to the kernel. My guess, and I don't actually think this will happen, is that Apple will do something like this on Mac OS X and have a reasonable mapping to the BSD world underneath, then someone in the Linux community will come along and do something similar in a way that's better suited for Linux. As a parallel, Apple came out with launchd in 2005 to replace init scripts, systemd made an appearance in 2010 - both do very similar jobs, with launchd tailored to the needs of MacOS and systemd tailored to the needs of Linux. Maybe something similar could happen with UNC-like file sharing.
- meditate 8y ago
  All that has been doable for quite some time, you could mount SMB shares like that with smbfs since early releases of Samba, and later with the CIFS fs driver. You do need root to mount things that way, so it isn't ideal. For the more complicated stuff it can be done but not everything is available via a simple GUI. GNOME and KDE have their own virtual filesystem layers in userspace, GVfs and KIO, I don't know what KIO does but GVfs supports a bunch of network backends and has a FUSE driver that can mount its own virtual filesystems and expose them to outside applications. So the features are there but I don't think they are well-presented right now, maybe someone can prove me wrong though. It would have been nice if the kernel had better support for fine-grained control over filesystems like HURD or Plan 9 do. But instead it was decided that it was better to handle those things with userspace daemons, so that's where we are now.
  - Mister_Snuggles 8y ago
    These aren't the same thing though. The GNOME and KDE VFS layers only apply for applications written for those APIs. It's not a universal thing. Being able to mount a CIFS filesystem is fine, but it's not the same thing. In Windows, you can basically use a UNC path anywhere because CreateFile knows how to deal with it. The point is that you don't need to mount the remote filesystem (the Windows-equivalent being mapping a network drive). What I'm really looking for is the user experience, not the underlying protocol. On Windows, I can just go "notepad.exe \\server\share\file.txt" and edit the file, on Linux I need to either use a KDE application or go through the ceremony of mounting the remote filesystem. It's the fact that the feature is silo'd into GNOME and KDE (and the fact that it doesn't even exist on Mac OS, but that's another issue) that bugs me.
    - meditate 8y ago
      There is currently no kernel interface that I know of to do that, and I don't think it would be too hard to hook into an open() on an invalid path and try to do something (mount a network fs, call out to GVfs or KIO, etc), but I can tell you you will meet resistance if you try to because things like "//stuff" and "smb://stuff" are already valid local file paths in Linux. So I leave it up to you to figure out how to do this without breaking things.

Mister_Snuggles 8y ago

You're absolutely right. I wonder if something like DBus and PulseAudio could happen with my UNC pain point. With the assumption that the goal is for "vi //server/share/file.txt" to work the same as "notepad.exe \\server\share\file.txt" does on Windows, here are my thoughts. First off, notepad.exe doesn't really care about the fact that it's a UNC path. It just opens the file with CreateFile (either CreateFileW or CreateFileA). There would need to be replacements for the libc file functions. These could be a shim in front of libc, or baked right into libc. Note, there's a LOT more needed than "just" new file functions - any functions that do anything with paths need to be looked at. Shells would likely need some changes to work properly, though it's not like the Windows shell can truly do much with UNC paths - copying files to/from works, but you can't cd into them. How does it ask for credentials? If it's via DBus, a desktop environment provide the authentication prompts, but what about a pure-commandline system? Maybe the transport is just SSH and relies on the existing public key authentication? But what if you're just doing a one-off thing and don't want to set that up? Using SSH is probably a decent idea since it's got authentication, security, and a file transfer protocol, already built in. On top of all of this, when you open //server/share/file.txt for writing, what does that actually mean? Is there a file descriptor? How does that work with the kernel? Does libc now manage all file descriptors with only a subset corresponding to kernel file descriptors? Could a pure user-space solution fake this well enough to actually work? Would this need to be a FUSE filesystem along with some daemon to automatically unmount the remote servers when the mount is no longer needed? Would it be something like the automounter, just a lot better? Does a kernel need changes for any of this to work? This is one of those things that touches so many layers and potentially interacts with so many parts of the system, potentially all the way down to the kernel. My guess, and I don't actually think this will happen, is that Apple will do something like this on Mac OS X and have a reasonable mapping to the BSD world underneath, then someone in the Linux community will come along and do something similar in a way that's better suited for Linux. As a parallel, Apple came out with launchd in 2005 to replace init scripts, systemd made an appearance in 2010 - both do very similar jobs, with launchd tailored to the needs of MacOS and systemd tailored to the needs of Linux. Maybe something similar could happen with UNC-like file sharing.

meditate 8y ago
All that has been doable for quite some time, you could mount SMB shares like that with smbfs since early releases of Samba, and later with the CIFS fs driver. You do need root to mount things that way, so it isn't ideal. For the more complicated stuff it can be done but not everything is available via a simple GUI. GNOME and KDE have their own virtual filesystem layers in userspace, GVfs and KIO, I don't know what KIO does but GVfs supports a bunch of network backends and has a FUSE driver that can mount its own virtual filesystems and expose them to outside applications. So the features are there but I don't think they are well-presented right now, maybe someone can prove me wrong though. It would have been nice if the kernel had better support for fine-grained control over filesystems like HURD or Plan 9 do. But instead it was decided that it was better to handle those things with userspace daemons, so that's where we are now.
- Mister_Snuggles 8y ago
  These aren't the same thing though. The GNOME and KDE VFS layers only apply for applications written for those APIs. It's not a universal thing. Being able to mount a CIFS filesystem is fine, but it's not the same thing. In Windows, you can basically use a UNC path anywhere because CreateFile knows how to deal with it. The point is that you don't need to mount the remote filesystem (the Windows-equivalent being mapping a network drive). What I'm really looking for is the user experience, not the underlying protocol. On Windows, I can just go "notepad.exe \\server\share\file.txt" and edit the file, on Linux I need to either use a KDE application or go through the ceremony of mounting the remote filesystem. It's the fact that the feature is silo'd into GNOME and KDE (and the fact that it doesn't even exist on Mac OS, but that's another issue) that bugs me.
  - meditate 8y ago
    There is currently no kernel interface that I know of to do that, and I don't think it would be too hard to hook into an open() on an invalid path and try to do something (mount a network fs, call out to GVfs or KIO, etc), but I can tell you you will meet resistance if you try to because things like "//stuff" and "smb://stuff" are already valid local file paths in Linux. So I leave it up to you to figure out how to do this without breaking things.