
AppFS, a FUSE filesystem via HTTP for running software without installing it - rkeene2
http://appfs.rkeene.org/
======
rgovostes
This is built into OS X:

hdiutil attach
[https://adiumx.cachefly.net/Adium_1.5.10.1.dmg](https://adiumx.cachefly.net/Adium_1.5.10.1.dmg)
-shadow Adium.shadowfile

The -shadow option allows the image to be mounted read-write, with writes
being redirected into the shadow file.

~~~
peeters
I'm not an Apple guy so let me ask a naive question: is this even close to a
functional equivalent? Quick research makes this look like just mounting a
remote filesystem.

That's very different than being a package format, with dependency resolution,
caching equivalent files, etc.

~~~
rgovostes
Yes it is mounting a remote filesystem, it does not have all the same
features. I was replying to the title "a FUSE filesystem via HTTP for running
software without installing it," which the above command permits; the linked
page (at least without exploring deeper into the site) doesn't describe
dependency resolution. Caching will performed by the kernel, but I don't know
how it operates in a multi-user environment.

~~~
rkeene2
Dependency resolution is implicit to the design -- the entire global namespace
is available on every system so any dependencies are resolved as they are
requested.

That is, if you have an executable such as "ls" that relies upon the dynamic
linker provided by "glibc", then the glibc requested will be fetched
automatically because you attempted to open the dynamic linker.

Additionally, the design is superior to the single-user nature of a remote
disk image in that each user's writes are redirected to their own home
directory (by default, you can change this in a config file).

Even further, it allows for setuid files to be handled safely which is
sometimes needed (e.g., "sudo" or "chrome-sandbox").

Caching is handled by the kernel for the VFS cache but also by a more
persistent disk cache so that you can use applications offline as long as you
have cached them (by running them, usually) ahead of time.

------
ohpauleez
While I like the foundation of this idea, I'd love to see it taken to the next
logical conclusion: Drop HTTP for a better suited protocol (like 9P), and
correctly handle the interaction of union'd (namespaced) filesystems.

~~~
rkeene2
The backend actually doesn't care about the protocol used and indeed any
protocol could be transparently substituted in using the config file...
However there is nothing that makes 9P better suited in this particular case
since the resources requested are completely static URLs with the exception of
the "index" resource which lists the SHA1 of the list-of-packages as well as
the digital signature of the "index" file itself.

------
anonbanker
from a security standpoint, this is terrifying. one infected application over
FUSE could potentially compromise thousands of users.

~~~
rkeene2
It's the same as any other package repository being compromised. There's
currently no key revokation, like most package systems but being based on
X.509 it certainly supports it.

Additionally the only part of AppFS that runs as a privileged user is the
daemon itself, unlike most package systems where there is an install step that
can run arbitrary scripts as a privileged user.

~~~
anonbanker
Sadly, X.509 has been rendered useless due to certificate authority
compromises, and the need to trust keys from those CA's. if something else was
chosen, it might be far less terrifying.

~~~
rkeene2
What ? The CA AppFS trusts has never been compromised and you are free to
replace it. It sounds like you think SSL/TLS is being used or something or
that many certificate authorities are trusted.

------
AdrianRossouw
is this another implementation of zero-install, by the guys who did the rox
filer (port of riscos file manager to *nix) ?

~~~
rkeene2
It is very similar with some small (but significant) differences: 1\. It
doesn't require a huge manifest per site, instead the manifests are broken
down into: list-of-packages-per-site and list-of-files-per-package 2\. There
are no special directories in the same namespace that regular files can live
in 3\. It is deduplicated (every file is referenced by its SHA1) making the
need for making packages share files that they have in common unnecessary. 4\.
It lives in a more sane place in the UNIX filesystem (/opt) 5\. It doesn't use
special characters to denote special meaning (this is why I stopped using
LazyFS) 6\. It uses FUSE instead of its own kernel module

