3 ms·

Those who don't run Plan 9 are doomed to re-implement it. Poorly. http://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/ubiquitous_fileserver.pdf http://doc.

Those who don't run Plan 9 are doomed to re-implement it. Poorly. http://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/ubiquitous_fileserver.pdf http://doc.cat-v.org/plan_9/misc/ubiquitous_fileserver/ubiqu...

vezzy-fnord 11y ago
Actually, I think the chief initial architect of Linux namespaces (and bind mounts) was Al Viro [1], an ex-Plan 9 developer. So he's well aware of that, but evidently a poor concession is better than nothing at all. [1] Citation: http://www.ibm.com/developerworks/library/l-mount-namespaces/ http://www.ibm.com/developerworks/library/l-mount-namespaces...
- angersock 11y ago
  Good to know! I've spent the weekend reading Plan 9 papers, and it's just all such a shame. They tried to save us!
  - vezzy-fnord 11y ago
    Yep, that's why Al Viro is such an abrasive yet highly entertaining grump. He makes Linus Torvalds look like a sensitivity training counselor in comparison, but his argumentative style is great (query "site:lwn.net al viro udev" for a fun way to waste some time). A veteran Linux kernel hacker who hates udev and cgroups. Yep.
    - e12e 11y ago
      Do you know if he's back on the lists/development in full force? Looks like he had some very serious medical issues last year: http://lwn.net/Articles/439635/ http://lwn.net/Articles/439635/
Animats 11y ago
"In the end, the only safe way to allow unprivileged mounts may be the filesystem in user space (FUSE) mechanism, which isolates the filesystem code into a separate user-space process." Which is how QNX, the message-passing real-time OS, does it. All file systems are in user space. ZIP file systems were added easily, for example. QNX has a process which starts at boot time to manage pathname connections to "resource manager" programs. Programs can register for a portion of the pathname space. Pathnames are a level of abstraction below file systems. Linux keeps adding the ability to put more in user space, with interprocess message passing, drivers in user space, and file systems in user space. But the old in-kernel code for the same things never gets thrown out, and the bolted-on user space capabilities are slower than the kernel ones. Message passing support and CPU dispatching have to be tightly integrated for this to work fast, and because message passing is an afterthought in UNIX/Linux, it never is.

vezzy-fnord 11y ago

Actually, I think the chief initial architect of Linux namespaces (and bind mounts) was Al Viro [1], an ex-Plan 9 developer. So he's well aware of that, but evidently a poor concession is better than nothing at all. [1] Citation: http://www.ibm.com/developerworks/library/l-mount-namespaces/ http://www.ibm.com/developerworks/library/l-mount-namespaces...

angersock 11y ago
Good to know! I've spent the weekend reading Plan 9 papers, and it's just all such a shame. They tried to save us!
- vezzy-fnord 11y ago
  Yep, that's why Al Viro is such an abrasive yet highly entertaining grump. He makes Linus Torvalds look like a sensitivity training counselor in comparison, but his argumentative style is great (query "site:lwn.net al viro udev" for a fun way to waste some time). A veteran Linux kernel hacker who hates udev and cgroups. Yep.
  - e12e 11y ago
    Do you know if he's back on the lists/development in full force? Looks like he had some very serious medical issues last year: http://lwn.net/Articles/439635/ http://lwn.net/Articles/439635/

Animats 11y ago

"In the end, the only safe way to allow unprivileged mounts may be the filesystem in user space (FUSE) mechanism, which isolates the filesystem code into a separate user-space process." Which is how QNX, the message-passing real-time OS, does it. All file systems are in user space. ZIP file systems were added easily, for example. QNX has a process which starts at boot time to manage pathname connections to "resource manager" programs. Programs can register for a portion of the pathname space. Pathnames are a level of abstraction below file systems. Linux keeps adding the ability to put more in user space, with interprocess message passing, drivers in user space, and file systems in user space. But the old in-kernel code for the same things never gets thrown out, and the bolted-on user space capabilities are slower than the kernel ones. Message passing support and CPU dispatching have to be tightly integrated for this to work fast, and because message passing is an afterthought in UNIX/Linux, it never is.