The Parrot Virtual File System
ccl.cse.nd.edu
ccl.cse.nd.edu
This approach is much more powerful than the Unix style of mounting. FUSE provides some degree of extensibility, but it is not composable. Pitman's post mentions the "chained hosts" of VMS. GNU Emacs TRAMP has a completely general and composable mechanism called "multi-hops": https://www.gnu.org/software/tramp/#Ad_002dhoc-multi_002dhop...
Using explicit remote pathnames as opposed to mounting is a very powerful idea, and I am glad it is becoming practical today. I think it is possible to write something like a portable Parrot as a library and set of shadow include files you could use to recompile applications.
It occurred to me I should provide a qualifier here. Single-tree Unix pathnames have one very powerful property that qualified schemes from the 1980s lack: self-similarity at every level of the directory hierarchy. This is why filesystem virtualization schemes like loop devices (CD and disk images, and things like EncFS), chroot, and overlays are possible and work so well. The 1980s schemes did not support these use cases and were more tedious to type out, and they rightly died out. But it is not either-or: TRAMP shows that you can have Unix pathnames for your local machine and qualified pathnames for when you need to specify where/how to access files.
TRAMP provides a pathname syntax for this kind of connection:
/ssh:bird@bastion|ssh:you@remotehost:/path
So the steps to get to the remote files are part of the pathname, and you can compose several steps with |. With FUSE, or any kind of mounting, this information is not part of the pathname; next time you need to access somewhere convoluted you have to set up the proxying/forwarding again.You can also share the pathname. It is easy to copy-paste an SHH to sudo to Docker container multi-hop; setting up and tearing down the mounts to do the same thing would be fairly involved.
However, that said, I wonder if it would still work in cases when a file is memory-mapped (via mmap() and friends) and modified directly in memory rather than direct FI/O calls. Would parrot still work in this case?
I guess things like sshfs or rclone already do similar things, but it would be really neat to see the performance characteristics of Parrot vs other solutions.
Edit: And now it's working.
I don't see any one command from this guide that the utility could be run before to enable this. https://www.raspberrypi.org/magpi/pi-zero-w-smart-usb-flash-...
Think of this program like automatically giving any program that has a "File -> Open" menu the ability to load files from FTP, or HTTP, or any other file serving protocol. You still need something serving up the data - it's just possible for you to treat it like any old file on your file system now.
http://archive.oreilly.com/pub/a/oreilly/news/parrotstory_04...