<?xml version='1.0' encoding='utf-8'?>
<html>
<h2>Compared with other systems</h2>
<toc level='h3'/>
<h3>Matrix</h3>
<p>
This matrix shows some desirable features in a packaging system, and shows which
systems provide them. Obviously, these things tend to be a bit biased (both in
terms of what features are chosen for comparison, and of what is considered to
be a 'pass') but it should give the general idea.
</p>
<table class='matrix'>
<tr><th>Feature</th> <th>Source tarball</th> <th><a href='http://www.debian.org/doc/manuals/apt-howto/index.en.html'>APT</a></th>
<th><a href='http://listaller.tenstral.net/'>Listaller</a></th>
<th><a href='http://java.sun.com/products/javawebstart/'>Java WS</a></th>
<th><a href='injector.html'>Zero Install</a></th></tr>
<tr><th>Users can install software</th> <yes/> <no/> <yes/> <yes/> <yes/></tr>
<tr><th>Dependencies handled automatically</th> <no/> <yes/> <td>Distro only</td> <yes/> <yes/></tr>
<tr><th>Automatic upgrading</th> <no/> <yes/> <yes/> <yes/> <yes/></tr>
<tr><th>Libraries shared between programs</th> <yes/> <yes/> <td>Distro only</td> <yes/> <yes/></tr>
<tr><th>Downloads shared between users</th> <no/> <td>No user downloads</td><no/> <no/> <yes><a href='sharing.html'>Yes</a></yes></tr>
<tr><th>Multiple versions coexist</th> <yes/> <no/> <no/> <no/> <yes/></tr>
<tr><th>Uninstall</th> <td>Sometimes</td> <yes/> <yes/> <yes>(cache)</yes> <yes>(cache)</yes></tr>
<tr><th>Digital signatures</th> <no/> <yes/> <yes/> <td>Only one</td> <yes/></tr>
<tr><th>Conflict-free</th> <no/> <no/> <yes/> <yes/> <yes/></tr>
<tr><th>Decentralised</th> <yes/> <no/> <yes/> <yes/> <yes/></tr>
<tr><th>Non-root install of system</th> <yes/> <no/> <yes/> <yes/> <yes/></tr>
<tr><th>All programming languages</th> <yes/> <yes/> <yes/> <no>Only Java</no> <yes/></tr>
<tr><th>Supports sandboxing</th> <no/> <no/> <yes/> <yes/> <yes/></tr>
<tr><th>Usable when off-line</th> <yes/> <yes/> <yes/> <yes/> <yes/></tr>
<tr><th>Thousands of packages available</th> <yes/> <yes/> <no/> <td>Unknown</td> <no>~1500</no></tr>
</table>
<h4>Explanation of features</h4>
<dl>
<dt>Users can install software</dt>
<dd>A normal user without special privileges can install software using this system (without unreasonable extra effort).</dd>
<dt>Dependencies handled automatically</dt>
<dd>If a program requires some library to function, the system will locate, download and install the library too.<br/>
Listaller packages can depend on distribution-provided packages but not on other Listaller packages.</dd>
<dt>Automatic upgrading</dt>
<dd>The system can check for and install upgrades automatically or at the operator's request. User does not have to
perform a full install operation manually on each package.</dd>
<dt>Libraries shared between programs</dt>
<dd>If two programs use the same library, the library is only downloaded and stored once. Upgrading a library will
benefit all programs that use it.</dd>
<dt>Downloads shared between users</dt>
<dd>If two users install/use the same program, it is only downloaded once and stored once.<br/>
See <a href='sharing.html'>Sharing</a> for how to set this up with Zero Install.
</dd>
<dt>Multiple versions coexist</dt>
<dd>Two versions of a program or library can be installed at the same time, and the user can choose which one to run.</dd>
<dt>Uninstall</dt>
<dd>Programs can be cleanly removed from the system easily (reversing the effects of the install).</dd>
<dt>Signatures</dt>
<dd>Software comes with a digital signature, which is checked automatically by the system.<br/>
Note: Java Web-Start requires all components to be signed with the same key.
</dd>
<dt>Conflict-free</dt>
<dd>If program A requires an old version of a library, and program B requires a new version, A and B can both be installed and
used at the same time. The system will never refuse to install one program because some other program is installed.
Listaller and 0install can both depend on native distribution packages, which may conflict, but their own packages do not.
0install will avoid such problems as long as a suitable version of the dependency is also available as a 0install package.
</dd>
<dt>Decentralised</dt>
<dd>A program packaged for this system can be installed easily, without having to be in some special centralised repository.<br/>
Notes: Debian allows extra repositories to be added, but this is a manual
step, requires root access, and is a considerable security risk.</dd>
<dt>Non-root install of system</dt>
<dd>The packaging system itself can be easily installed without administrator privileges, and the normal selection of
software will be available.</dd>
<dt>All programming languages</dt>
<dd>All types of program can be accessed using this system.</dd>
<dt>Supports sandboxing</dt>
<dd>If you have a way of running an application in a sandboxed environment (e.g., a Java virtual machine), then the
installation system will let you install and run the program without forcing you to run any of the downloaded
code outside of the sandbox.<br/>
See the <a href='ebox.html'>EBox sandboxing demo</a> for an example of using 0install in this way.
</dd>
<dt>Usable when off-line</dt>
<dd>Once a program has been installed, the program can be run again while disconnected.</dd>
<dt>Thousands of packages available</dt>
<dd>The system is widely adopted.</dd>
</dl>
<h3>By project</h3>
<toc level='dt'/>
<dl class='spaced'>
<dt id='JWS'>Java Web Start</dt>
<dd>
<p>
Sun have developed a similar system to Zero Install,
<a href="http://java.sun.com/products/javawebstart">Java Web Start</a>,
although this only works for Java applications. Microsoft have an
equivalent called <a href='http://msdn2.microsoft.com/en-us/library/t71a733d(VS.80).aspx'>ClickOnce</a>.
</p>
</dd>
<dt id='Konvalo'>Konvalo</dt>
<dd>
<p>
Konvalo was a very similar idea to the old Zero Install filesystem, but
implemented using CODA rather than with a custom kernel module.</p>
<p>
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.
</p>
<p>
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.
</p>
</dd>
<dt id='Klik'>Klik</dt>
<dd>
<p>
<a href='http://en.wikipedia.org/wiki/Klik_%28packaging_method%29'>Klik</a> 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.
</p>
<p>
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 <a
href='http://rox.sourceforge.net/desktop/node/290'>article about Zero Install
and Klik</a> for more details.
</p>
<p>Differences between Klik and Zero Install include:</p>
<ul>
<li>The recipes Zero Install downloads are XML files, not shell scripts (this is similar
to the difference between tar and shar files).</li>
<li>Zero Install downloads are GPG signed.</li>
<li>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.</li>
<li>Zero Install can check for updates automatically (by default once a month,
but configurable). Klik requires you to check for updates yourself.</li>
<li>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
<a href='http://rox.sourceforge.net/desktop/Zero2Bundle'>supports</a> this mode
of operation if desired).</li>
<li>Zero Install can <a href='sharing.html'>share downloads</a> between users
safely, using cryptographic digests.</li>
<li>Zero Install supports compiling from source if you want, though not all
packages support this yet.</li>
<li>Zero Install lets you download older versions of programs or libraries.
Klik only provides a single version for download, although you can keep using
older versions once you've got them.</li>
<li>Zero Install is fully <acronym title='Open Source Software'>OSS</acronym>. Only the Klik client is.</li>
<li>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.</li>
<li>Klik has many more packages available right now.</li>
<li>Zero Install is platform independent. Klik only runs on Linux.</li>
</ul>
<p>
The above refers to Klik 1, which is no longer available. Klik 2 was never released.
The successor to Klik 2, <a href='http://portablelinuxapps.org'>portablelinuxapps.org</a> is not
working (as of 2011-08-22).
</p>
</dd>
<dt id='Maven'>Maven</dt>
<dd>
<p>
<a href='http://maven.apache.org/'>Maven</a> is a build tool (like make or ant)
for Java programs. Although not an installation system, it is similar to
0install in that each product has a <b>pom.xml</b> 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 2.0 and 0install:
</p>
<ul>
<li>
The <b>pom.xml</b> files are not signed. An attacker can therefore cause modified
POM files to be downloaded.
</li>
<li>
There is no digest of the downloads in the POM file, so no security checks
are performed to confirm that the download is OK, and downloads cannot be
shared safely between users.
</li>
<li>
Only Java is supported (everything is added to CLASSPATH, nowhere else).
</li>
<li>
Dependencies are named using a simple two-layer system (e.g., axis/axis-jaxrpc).
Therefore, a central repository is required to avoid naming conflicts.
</li>
</ul>
<p>
Note that you can use Zero Install in a maven-like way for compiling programs.
See <a href='http://rox.sourceforge.net/desktop/node/289'>Easy GTK binary compatibility</a>
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.
</p>
</dd>
<dt id='Autopackage'>Autopackage / Listaller</dt>
<dd>
<p>
Like Zero Install, <a href='http://autopackage.org/'>Autopackage</a> 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 Zero Install too. Some differences between this and
Zero Install:
</p>
<ul>
<li>A script inside each package installs the files, making sandboxing
difficult. It also <a href='http://www.kitenet.net/~joey/blog/entry/autopackage_designed_by_monkeys-2005-03-28-14-20.html'>makes conversion to other
packaging formats troublesome</a>.</li>
<li>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.</li>
<li>Downloads cannot be safely shared between users.</li>
<li>No checking for updates or support for multiple versions.</li>
<li>Being closer to traditional installation, it's easier to package existing
applications with Autopackage.</li>
</ul>
<p>
Note that it is quite possible to list autopackages in a Zero Install feed, as
described in <a href='http://thread.gmane.org/gmane.comp.autopackage.devel/5733/focus=5733'>this
post on the Autopackage mailing list</a>. 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.
</p>
<p>Autopackage is no longer maintained, but has merged with the <a href='http://listaller.tenstral.net/'>Listaller project</a>. The Listaller
project has also taken over the <a href='http://listaller.tenstral.net/docs/doc/app-development.html'>tools for making relocatable applications</a>, which
may be useful for making 0install packages too.</p>
</dd>
<dt id='EDOS'>EDOS / Mancoosi</dt>
<dd>
<p>
The <a href='http://www.edos-project.org/xwiki/bin/Main/'>EDOS</a> (<i>Environment
for the development and Distribution of Open Source software</i>) project was a research
project looking at dependency management, QA, and efficient distribution of
large software systems.
</p>
<p>
<a href='http://www.mancoosi.org/'>Mancoosi</a> is a follow-on project
("Managing the Complexity of the Open Source Infrastructure"). The
group invited me to give a talk (March 2009); here are
<a href='http://thread.gmane.org/gmane.comp.file-systems.zero-install.devel/2322'>my notes</a>
from the event.
</p>
</dd>
<dt id='Nix'>Nix</dt>
<dd>
<p>
<a href='http://nixos.org/'>Nix</a> is a purely functional package
manager. 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.
</p>
<p>
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.
</p>
<p>
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).
</p>
<p>
An important difference between the two is that the Nix hash is a hash of the
<i>inputs</i> used to build the package, whereas the Zero Install hash is a
hash of the <i>resulting binary</i>.
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.
</p>
<p>Update: Nix is planning to use binary hashes everywhere in future (zeroing out
self-references for the purposes of calculating the hashes). The same thing was proposed
a few years ago for Zero Install (the
<a href='http://thread.gmane.org/gmane.comp.file-systems.zero-install.devel/882/focus=882'>relocation table</a>).
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.</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
In Nix, mutually untrusting users cannot share packages. The manual says <q>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</q>. 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 <a href='sharing.html'>sharing</a>.
</p>
</dd>
<dt id='OSTree'>OSTree</dt>
<dd>
<a href='https://live.gnome.org/OSTree'>OSTree</a> describes itself as "git
for operating system binaries". It shares many goals with 0install (multiple
versions of libraries can coexist on one system and you can roll-back easily).
While 0install focuses on applications and their libraries, OSTree focuses on
the OS itself. However, there is quite a bit of overlap. For example, OSTree
considers GTK+ to be an OS library, while 0install might consider it to be an
application dependency (which can optionally, of course, be provided by the OS).
</dd>
<dt id='Glick'>Glick 2</dt>
<dd>
<a href='http://people.gnome.org/~alexl/glick2/'>Glick 2</a> has essentially the same
goals as 0install, but includes all dependencies in a single bundle rather
than linking libraries dynamically at run-time (for example, when a library
is updated, every program using that library must be updated individually).
It has support for non-relocatable applications, using some Linux-specific
tricks. It might be worth using these in 0install to implement the <mount-point>
binding, but few applications are non-relocatable these days.
</dd>
<dt id='DOAP'>DOAP: Description of a Project</dt>
<dd><p>
<a href='http://usefulinc.com/doap/'>DOAP</a> 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.
</p>
</dd>
<dt>Environment modules</dt>
<dd><p>
The <a href='http://modules.sourceforge.net/'>Environment Modules</a> package provides
for the dynamic modification of a user's environment via modulefiles. Each modulefile
contains the information needed to configure the shell for an application. Typically
modulefiles instruct the module command to alter or set shell environment variables
such as PATH, MANPATH, etc. To be able to load ("install") software, it must first be
installed under the $MODULESHOME directory which is in <tt>/usr/local/Modules</tt> or
a shared network filesystem. It is also possible to install it in <tt>~/.local</tt>
without root permissions, but then the modules can't be shared (due to different $HOME).
</p>
<p>
The module(1) command doesn't provide a method to share or distribute the applications,
so modulefiles typically take advantage of transparent remote network
filesystem access such as NFS and AFS. 0install can also be used in this way,
with <a href='local-feeds.html'>local feeds</a> taking the place of the
modulefiles and giving the path of the software on the network file-system
rather than a URL from which it can be downloaded.
</p>
</dd>
</dl>
<p>
If you believe that any of the information above is inaccurate or out-of-date, please
write to <a href='support.html#lists'>the mailing list</a> to let us know. Thanks!
</p>
</html>
