Zero Install

Filesystem FAQ

For questions about Zero Install in general, see the general FAQ.

  1. How do I provide software using Zero Install?
  2. Isn't fetching stuff over the web really slow?
  3. Doesn't it require a fast Internet connection?
  4. The Zero Install filesystem is just another network filesystem, isn't it?
  5. Isn't is really hard to find applications if you always have to type URIs for them?
  6. What about dial-up users? They don't want on-demand loading when they're off-line.
  7. I understand that when I browse the web my computer caches the pages, images and stylesheets automatically so I don't need to manually 'install' multiple PNG images to see a page, but software is different!
  8. What about when resources move?
  9. How secure is this?
  10. What if something gets automatically removed from the cache while I'm up a mountain with my laptop?
  11. Why are you abandoning application directories after supporting them all these years?
  12. How do I link against a library such that when it's upgraded I get the new version automatically?
  13. Why did you write a new kernel module? What's wrong with CODA, UserVFS, etc?
  14. Why is it written in C?
  15. What was the inspiration for Zero Install?

How do I provide software using Zero Install?

You need to be able to upload some static files to a web server.

See the Documentation for packagers for instructions.

Isn't fetching stuff over the web really slow?

You have to get stuff over the web anyway the first time. The system caches everything, and will never even check that the cache is up-to-date if it can satisfy a request without updating.

There is no speed hit to using stuff once it's downloaded. The fact that everything is referenced by fixed URIs instead of having to search means that this system can actually be faster in some cases. Consider loading a shared library. At the moment, a program must, on startup:

  1. Load /etc/ld.so.cache and find the full path of each library from that.
  2. Load the actual library by its path.

With Zero-installation, this becomes:

  1. Load the actual library by its path.

It also removes the need to run ldconfig at install time (handy, since there is no 'install time' ;-), losing a major source of errors and user confusion.

Doesn't it require a fast Internet connection?

No! Installing using tarballs or traditional packages will typically mean downloading around three to four times as much data you would using the Zero Install filesystem, because Zero Install only downloads what you actually use.

When I tested it, installing the ROX-Filer CVS snapshot over a mobile phone GPRS link (approx 2.5 KB/sec) took 1m48s, with 265 K received, 13 K sent, although it may fetch more if you have less of the dependencies already (eg, an icon theme and the MIME database). The corresponding tarball is over 1Mb, using the same compression scheme.

The Zero Install filesystem is just another network filesystem, isn't it?

Yes. It uses HTTP to fetch a small index archive, and can then use any other system (HTTP, FTP or various peer-to-peer and mirroring systems) to fetch the actual data (see the technical details page for more information). This means that providing software though Zero Install is easy, because pretty much everyone can put stuff on a webserver, whereas it's often hard to find someone who will host other types of server.

The main difference between this and standard shares is the way the paths use the Internet DNS system. This allows us to link to resources by fixed paths, in the same way that I can put up a link to ROX on this web page without worrying about where the user has 'installed' the web page.

Isn't is really hard to find applications if you always have to type URIs for them?

Yes. As with the web, that works but it's not the intended way to do it. Like the web, you have links to the URIs, and you use the links normally.

For example, having opened the ROX-Filer directory showing Memo in the installation instructions, you can drag Memo from the window onto your panel. Now you access it by clicking on its panel icon; no URIs.

You could also put it on the pinboard, bookmark the directory, set a keyboard shortcut, or whatever. Web pages can provide the URIs in a clickable form (so clicking on a link opens the filer window). A 'distribution' could be nothing more than a web page listing links to high quality software for a particular audience.

Finally, if you want to get a newer version, or find related software, traditional systems mean you have to try and remember where you got it from, or hunt through the documentation. With the URI scheme, just choose 'Show Location' from the panel menu and the directory containing Memo (on the remote server) will be opened.

What about dial-up users? They don't want on-demand loading when they're off-line.

Various levels of granularity can be used. A user could tell the system to cache an entire application, for example. Of course, dial-up users might also appreciate that they have to download a lot less stuff in total. A user with a slow, but easy to start, Internet connection will probably prefer this scheme. A user who wants to take their laptop up a mountain, however, would probably want to get as much software as possible first.

However, knowing how much to download requires knowing what software the user may want to run in the future. Even the user doesn't know that. It's not a new problem. No modern system is 'closed'. There will always be an application that says "This program works well with 'foo'. You can get it from this web site...". Should installing the program also install 'foo'? Should installing ROX-Lib also install the README? The developer documentation? The python tutorial at python.org?

I understand that when I browse the web my computer caches the pages, images and stylesheets automatically so I don't need to manually 'install' multiple PNG images to see a page, but software is different!

Why?

What about when resources move?

Everything you've already accessed at least once will continue to work. Users trying software for the first time will find that it doesn't work due to broken links. This is not new, either. The download instructions for ROX-Filer tell users that they need to get GTK from www.gtk.org and libxml from www.xmlsoft.org. If those sites change their names, the download instructions will be broken. It really doesn't make any difference. As with the regular web, people can leave redirections to the new site.

The system administrator can also specify a list of redirections manually if required (this also allows all access to a particular library to use a modified version, for example). See the documentation page for details of the 0divert command.

How secure is this?

See the filesystem security issues document for details.

What if something gets automatically removed from the cache while I'm up a mountain with my laptop?

Currently, nothing is ever automatically removed from the cache. Users can choose the purging scheme that suits them. For users with broadband, that might mean removing anything that hasn't been accessed for a year. For users with dial-up and 80Gb disks, that probably means never ever removing anything.

You can run /uri/0install/zero-install.sourceforge.net/apps/ZeroClean to scan the cache for good removal candidates:

ZeroClean finds some files to remove

Why are you abandoning application directories after supporting them all these years?

I'm not. The examples use ROX application directories. Application directories provide an ideal user interface for this system, since they don't all have to be installed in a single directory (in PATH, etc). However, the system can be used for software not packaged as ROX-style applications too (libraries, in particular, require few changes).

How do I link against a library such that when it's upgraded I get the new version automatically?

Link against .../libfoo/latest-1.2.x. This is a symlink to, eg libfoo/1.2.3. If the user enters the 'libfoo' directory and does a refresh, the link will now point to 1.2.4 and that will be fetched on demand.

If a program relies on a bug fix in libfoo-1.2.6 then it can check that >'latest-1.2.x' points to that version or later, and force a refresh if not.

Why did you write a new kernel module? What's wrong with CODA, UserVFS, etc?

Fully user-space filesystems are really, really slow. Fine for accessing a remote FTP site, but you wouldn't want to run all your applications that way. Every file read involves a context switch to another process and back!

CODA is better (and was used for prototyping), but it's still slower than lazyfs (double context switch on every open/close) and buggy. Also, if the user-space helper crashes, all your applications stop working and you probably have to reboot. If the user-space helper in Zero Install crashes, you just can't download any new stuff until you restart it, but everything else continues to work.

Why is it written in C?

Actually, this isn't a FAQ, but it should be. Zero Install itself is fairly security-critical (it doesn't run as root or accept incoming connections, but an exploit would allow a local attacker to trojan other users' software). It isn't speed critical, however; it only gets invoked when something isn't in the cache, in which case it has to do a network fetch anyway. Given C's lack of buffer-overflow checking, it seems a poor choice of language.

I actually looked at quite a few languages. The problem is that I wanted it to be runnable from a boot floppy, which means the binary has to be small. And, incredibly, there seems to be no decent language capable of producing small stand-alone binaries. I thought C was bloated when I couldn't get "Hello World" under about 700 bytes (and the naive implementation is closer to 3K), but most languages can't seem to manage under a meg for the same thing. Python's great, of course, but it needs a huge runtime (likewise for Java, etc). The best language I could see for this was the D Programming Language (which still manages a ridiculous 60K for a program that does nothing), but expecting people to install a D compiler isn't going to help adoption, and it's not portable (or rather, D code is, but the compiler isn't yet).

The solution may be to have two implementations of zero-install; one written in C to be small for boot-strapping, and one written in Python/D/scheme/whatever for larger systems.

What was the inspiration for Zero Install?

Several things. CODA and wwwoffle for showing that caching network filesystems can still work when off-line. The W3C for using URIs for namespaces. Not Java Web Start, Konvalo or D. J. Bernstein's slashpackage though, because I had never heard of them when I started the project.