The Zero Install system

Similar or related systems

Java Web Start

Sun have developed a similar system to Zero Install, Java Web Start, although this only works for Java applications. Microsoft have an equivalent called ClickOnce.

Konvalo

Konvalo was a very similar idea to the old Zero Install filesystem, but implemented using CODA rather than with a custom kernel module.

One disadvantage of Konvalo was that you needed to run a public CODA server to distribute software, whereas both Zero Install implementations only require a web-server serving static pages.

The project did not attract support from the community and the author abandoned the effort in April 2006, asking for links to it from this site to be removed.

Klik

Klik allows users to install software by clicking on links in web-pages (or even just by looking at a web page). Like Zero Install, it stores each package in its own directory and sets environment variables to let it run. There is a central server which sends shell scripts to clients; executing the script causes the software to be downloaded and installed. This process is started automatically by your web browser.

Klik is mainly focused on having a large selection of packages working now, but pays little attention to security. Klik packages can be automatically converted to Zero Install ones. See my article about Zero Install and Klik for more details.

Differences between Klik and Zero Install include:

• The recipes Zero Install downloads are XML files, not shell scripts (this is similar to the difference between tar and shar files).
• Zero Install downloads are GPG signed.
• Zero Install is decentralised: you need permission from the Klik maintainers to distribute a Klik package. You don't need anyone's permission to distribute with Zero Install.
• Zero Install can check for updates automatically (by default once a month, but configurable). Klik requires you to check for updates yourself.
• Zero Install handles dynamic linking. This allows upgrading a library to benefit multiple applications, and saves space and bandwidth. It also lets you use a different version of a library if you want. Klik bundles all dependencies into the package (Zero Install also supports this mode of operation if desired).
• Zero Install can share downloads between users safely, using cryptographic digests.
• Zero Install supports compiling from source if you want, though not all packages support this yet.
• Zero Install lets you download older versions or programs or libraries. Klik only provides a single version for download, although you can keep using older versions once you've got them.
• Zero Install is fully OSS. Only the Klik client is.
• Klik runs the 'intellipatch' script on downloads, which does a search-and-replace for filename paths in binaries (simple text matching) and changes them. This allows some programs which aren't built to be binary relocatable to work. Zero Install doesn't support this, and requires binaries to be relocatable in the first place.
• Klik has many more packages available right now.
• Zero Install is platform independent. Klik only runs on Linux.

The above refers to Klik 1 (the current version). Klik 2, which is under development, uses a slightly modified version of the Zero Install feed format for its recipes. Note: link is to a fixed version, as the Wiki page is frequently vandalised.

Maven

Maven is a build tool (like make or ant) for Java programs. Although not an installation system, it is similar to the injector in that each product has a project.xml file with a list of dependencies. When building a product, maven downloads the specified version of each dependency and stores it in a cache directory. Some differences between maven 1.0 (I have not yet tested version 2.0) and the injector:

• Only exact versions of dependencies are given. Maven cannot select the best version from a set. In an installation system, this would lead to a lot of extra downloads as programs used different library versions unnecessarily. It also makes it harder to get security fixes.
• Dependencies are not fetched recursively. If A requires B, and B requires C, then maven will not fetch C unless A requests it explicitly.
• The project.xml files are not signed, as they are not fetched by maven. Only implementations are downloaded.
• There is no digest of the downloads in the project file, so no security checks are performed to confirm that the download is OK, and downloads cannot be shared safely between users.
• Only Java is supported (everything is added to CLASSPATH, nowhere else).
• Dependencies are named using a simple two-layer system (e.g., axis/axis-jaxrpc). Therefore, a central repository is required to avoid naming conflicts.

Note that you can use Zero Install in a maven-like way for compiling programs. See Easy GTK binary compatibility for an example of using Zero Install to compile a C program against an older version of a library's header files to ensure greater compatibility.

Autopackage

Like Zero Install, Autopackage aims to let users install software and to make software distribution decentralised. The work done by the Autopackage developers to make packages relocatable is necessary for the Zero Install injector too. Some differences between this and Zero Install:

• A script inside each package installs the files, making sandboxing difficult. It also makes conversion to other packaging formats troublesome.
• Security features such as GPG signatures have not been implemented. Given that packages are executable files, the design doesn't seem to allow this to be fixed.
• Downloads cannot be safely shared between users.
• No checking for updates or support for multiple versions.
• Being closer to traditional installation, it's easier to package existing applications with Autopackage.

Note that it is quite possible to list autopackages in a Zero Install feed, as described in this post on the Autopackage mailing list. In this case, no scripts are run during installation (the package is treated as a normal archive), so not all packages will work, but many do.

EDOS

The EDOS (Environment for the development and Distribution of Open Source software) project is a research project looking at dependency management, QA, and efficient distribution of large software systems.

Nix

Nix is another "purely functional" package manager. It is purely functional in the sense that each version of a package has its own directory. As with Zero Install, "upgrading" creates a new directory for the new version, rather than modifying the existing one. Unlike Zero Install, however, whether a package is installed affects the behaviour of the system. For example, running "firefox" when Firefox isn't installed produces an error in Nix, whereas in Zero Install it will install Firefox first if missing and then continue. In other words, installation has side-effects in Nix.

Additional feeds (e.g. for pre-built binaries) can be registered using "nix-channel --add", which appears to work much like "0launch --feed", although each channel can contain binaries for multiple packages. The channel "MANIFEST" file doesn't appear to have a digital signature. Presumably this will be added at some point.

Each version of a package has a digest (hash), which includes all build dependencies (e.g. the version of the compiler used), just as it does in Zero Install (for packages built using 0compile, at least).

An important difference between the two is that the Nix hash is a hash of the inputs used to build the package, whereas the Zero Install hash is a hash of the resulting binary. Nix does this to support binaries that hard code their own paths, since the final hash needs to be known at compile time. For source (non-compiled) packages, the Nix hash is a hash of the contents, as with Zero Install. The Zero Install hash often happens to include the inputs, since it covers the "build-environment.xml" file which 0compile places in each binary package. Zero Install doesn't allow binaries to include hard-coded paths.

Update: Nix is planning to use binary hashes everywhere in future (zeroing out self-references for the purposes of calcuating the hashes). The same thing was proposed a few years ago for Zero Install (the relocation table). It relies on the cache directory being at a fixed location, whereas people often have Zero Install set up to use their home directory, but it's basically a good idea.

Another difference between Nix and Zero Install is that Nix treats configurations as packages. Changing your configuration is like "upgrading" your configuration package to a new version. Rolling back a change is like reverting to a previous version. Zero Install doesn't generally handle configuration settings, preferring to let the user use subversion (or similar) for that, but it's an interesting idea.

Building a Nix package involves creating a "Nix expression" in a (custom) functional language. The expression fills the same role as a Zero Install source feed: it says where to download the source, what its digest is, what the build dependencies are, and how to build it.

While Zero Install is mainly targeted at adding additional packages to an existing system, Nix aims to manage the whole system (although it installs cleanly alongside your existing package manager). Nix packages have short names (like "perl") not full URIs, and thus it appears to assume a centrally-controlled repository.

In Nix, mutually untrusting users cannot share packages. The manual says A setuid installation should only by used if the users in the Nix group are mutually trusted, since any user in that group has the ability to change anything in the Nix store. Because the Nix hash is a hash of the inputs, it is not possible for the system to verify that a package is valid (it would have to download the sources and compile the program itself; Nix can share binaries in this case). Because Zero Install hashes are always hashes of the package contents, it does support sharing.

DOAP: Description of a Project

DOAP is a project to create an XML/RDF vocabulary to describe open source projects. We should investigate whether any of these elements would be useful in Zero Install feed files.

See the matrix for a comparison of Zero Install's features with those of other installation systems.

Articles about Zero Install

Here are some discussions about Zero Install I've found on the web (Google, emails, etc). Let me know if you find any more!

• Zero Install: An executable critique of native package systems linux.com review and interview
• Decentralised Installation Systems essay on OSNews.com
• Neue Zero Install-Implementation article on pro-linux.de (in German)
• My slides from the 2004 Desktop Developers' Conference (in Ottawa, Canada, July 19-20, 2004; these slides include the questions asked during the talk)
• Zero Install System: instalar programas se va a acabar (in Spanish)
• Zero Install: Software-Installation der Zukunft? (in German)
• Zero Install : si t’installes, t’es un Zéro! (in French)
• Introduction to the Zero Install System (OSnews article and comments)
• Zero Install: The Future of Linux on the Desktop? (Slashdot article)
• Zero Install and the Web of Software (my freshmeat editorial and comments)
• Zero Install and the Web of Software (OSnews article and comments)
• Package Management in the ultimate operating system
• Ed Heil's Weblog
• Blue Sky Platform discussion
• Gentoo forums discussion
• Using Zero Install for sandboxing

Tim Berners-Lee's "Installation, Catalogs, and Caches" (DRAFT version) mentions Zero Install, too! (though the comment about needing a constant connection is wrong)