I watched the video, but I still don't understand how convergence is better than putting the certificates in DNS with DNSSEC. He says that DNS registrars are not reliable enough, but from the video it looks like convergence ultimately relies on them anyway. e.g.

If I control the DNS entry for paypal.com then I just change its IP address to point at my server. People using convergence will find my server in DNS, get its (self-signed) certificate and send it to the notaries. The notaries will see that it is different from their cached copy, which will trigger them to check for updates. They'll all go to the (compromised) DNS system, get the new IP address, get the fake certificate and return "OK" to the user. What am I missing?

You raise an excellent set of points. So how does 0install fix this?

Firstly, you don't need to find packagers for each distribution. You create one XML file, which allows everyone to run the program.

When the new GCC comes out and breaks your program, you just change the version restriction in your XML:

<requires interface='.../gcc'>
  <version before='4.6'/>

Likewise with the new libpng, and bdb. Other programs will start using the newer versions, but your program will stay with the version that works. You can then work on fixing the bugs and getting a new release out in your own time, without having to rush.

For example, I distribute a lot of Python programs using 0install. They all started "#!/usr/bin/env python". When ArchLinux decided that "python" would now be Python 3, they all broke. But by adding a few lines to my 0install feed, I got them working again:

  <runner interface='http://repo.roscidus.com/python/python'>
    <version before='3'/>
  </runner>

I'm not quite sure what you're asking here, but to be clear:

0install always shares libraries and other dependencies. For example, if your program depends on Java then 0install will use the distribution's version of Java (if installed), or 0install may download a 0install package of Java, or it may get Java from your distribution (using PackageKit). A 0install package should never need to bundle libraries.

On a multi-user system you can enable system-wide sharing. This is off by default because it requires adding a new sudo rule, and adding one automatically would be rude (the admin should be in charge of the sudoers file).

In the case of 0install, the command name (if any) is chosen by the user, not the package. So you might do something like this for shell use:

$ 0alias convert-img http://image-editor.org/convert
$ 0alias convert-text http://text-converter.com/convert

If a package depended on one of these, it would express that in its dependencies. e.g.

Make example.com/convert >= 1.3 available to me as 'convert'

0install would ensure that example.com's convert command was in $PATH, but just for the program that needed it.

It's similar with libraries. A library's files are only in scope for programs that depend on that library.

0install does not touch any files outside of ~/.config/0install.net/ and ~/.cache/0install.net/ by default, and it won't let packages change things at install time either. This is necessary so that it can be used with sandboxes.

The only exceptions are that it will make a configuration change that you request explicitly. For example, if you ask it to add Firefox 4 to your Network menu then it will do that, or if you ask it to add a "firefox4" shell command to run it then it will create a "firefox4" script in your $PATH.

You might be interested in the EBox sandboxing demo (the challenge is to create a package that accesses a user's files without the user's permission).

RISC OS application directories and Apple bundles have the nice property that you can install from anywhere, can have multiple versions and there are no conflicts between packages (e.g. both installing a "/usr/bin/convert"). But shared libraries are a pain because you have to install them manually, and upgrading a library needed to install program B can make program A stop working.

Debian packages have the nice property that you get dependency handling and automatic updates, and shared libraries work better. The system automatically installs a library version that works with A and B, if possible, or refuses to install B if there is no such version.

0install combines the best of both systems: you can get software from anywhere, have multiple versions at once and there are no conflicts. But you also get dependency handling, updates and shared libraries. It automatically installs a library version that works with A and B, if possible, or installs two different versions of the library in parallel if not.

It's perhaps more like Java Web Start in concept, but it works with any language (including Java). There is the 0export tool to create self-extracting bundles, but yes in the normal case it assumes that 0install will already be on the machine.

Yes, some platforms are so locked down that they won't let you run 0install. But it has been ported to all the common platforms that allow it (Linux, Unix, Mac OS X, Windows).

I've put up a Zero Install feed here, for those looking for an easy way to install it:

http://0install.net/tests/Chromium.xml

Tested on Ubuntu/Jaunty so far, but let me know if it doesn't work on other distributions.

Python source is generally compatible (go another level deeper and you'll find that the .py files are mostly symlinks to a single copy, at least on Debian-type systems).

However, the compiled .pyc files need to be regenerated for each version, which explains the separate directories. The symlinks are a messy hack, resulting from the fact that Python requires the .pyc files to go in the same directory as the corresponding .py files, even though you need multiple .pyc files for each .py file. If Python could cache the .pyc files somewhere else, the mess could go away.

The main problem with Python compatibility is with the C ABI, which varies across different packages, making it impractical to use Python to add scripting to a C program, for example:

http://www.mail-archive.com/python-3000@python.org/msg09051.html

I know binaries. I've worked with binaries. You sir, are no binaries.