Zero Install and the Web of Software
 by Thomas Leonard, in Editorials - Sat, Dec 13th 2003 00:00 UTC

The GnuCash installation instructions warn non-programmers against even trying to install it. The word "nightmare" is used. Ideally, the process should be quite simple. If the project were distributed using Zero Install, users could safely fetch and run it, with all its required dependencies, using a single command.

Zero Install is a fundamentally different way to access software. Instead of copying software from the Web onto our computers, we cache it. It's a faster, easier to understand, and safer way to get software, suitable for both broadband and dialup users. In this editorial, we will see how software is accessed via Zero Install and how we can distribute our own programs through it.

Introduction

So how would GnuCash be run with Zero Install? A commandline user would run it like this:

$ /uri/0install/gnucash.org/gnucash

GnuCash would then run. GUI users would open the directory /uri/0install/gnucash.org in their favorite filemanager and click on gnucash. They might also bookmark it, or drag it to their panel to make it easier to get to in future. Shell users might symlink it into their bin directory or create an alias. Note that no password is needed, since this doesn't effect other users of the system, and that the method for running the program is the same whether it is "installed" or not.

Of course, GnuCash needs many, many libraries to work, such as GTK and Glade. That's OK; instead of trying to load libgtk.so and having the linker report that it can't find it, GnuCash will load /uri/0install/gtk.org/libgtk.so and Zero Install will cache it if it hasn't already done so.

Every dependency that a piece of software has is referred to by its location on the Internet, allowing it to be fetched as needed. There is no need to record what software is installed; all software is available at all times.

What about APT?

By now, most people are probably thinking "Doesn't Debian's APT system make software installation easy, too?". But APT, like other traditional package managers, has a number of fundamental design problems. I'll only talk about APT here; this is not to be mean to Debian, but rather because APT is the best example of a traditional package manager.

The main problem is security. When APT is installing a program, it gives it complete access to the machine, running a script provided by the program as the root user. This means that you can't let users install any packages they please, since even something as apparently harmless as a documentation package could wipe the system. This has the immediate effects of requiring a password from the user, limiting the range of software that can be installed, and making system administrators nervous about adding additional APT repositories to the system.

Other problems include:

Scalability

The more software Debian provides, the longer it takes to update the packages list.

Speed

Doing a "dist-upgrade" to keep up with the latest security fixes and features downloads the full contents of every updated package instead of just updating the index files and refetching the software on demand.

Bugs in the install and uninstall scripts can prevent the system from working or even damage important data.

When disk space is low, it is difficult to know what can be safely uninstalled.

Many packages include data you never need...

Such as translations for other languages.

... or dependencies on packages you don't care about.

Such as LaTeX requiring Perl whether you need that particular feature or not.

And the system can't be shared easily with another distribution

You can't use Debian-packaged software on a Red Hat system, for example.

See Zero Install: What's wrong with APT? for a more complete comparison.

A real example

GnuCash isn't available through Zero Install yet, but some other software is. Here is an example walk-through, showing how the ROX desktop may be run with Zero Install.

If you wish, you can install Zero Install now (something that future Linux distributions will hopefully do for you) and follow along with these instructions. However, I'll try to write so you can still see what's going on even without having it installed, as the system is still somewhat experimental.

We could use an already-installed file manager for these examples, but I'll assume we haven't got one yet and show the process using the commandline.

Initially, the /uri/0install directory is empty:

$ ls /uri/0install
$

However, when we try to access a subdirectory (an Internet site), Zero Install will fetch and cache the whole directory structure for that site. A progress indicator utility is available, which will pop up during longer downloads; depending on the speed of your network connection, you may or may not see it.

$ cd /uri/0install/rox.sourceforge.net
$ ls
apps  lib  rox@

We can run the rox script here to start the filer, opening the apps directory:

$ ./rox apps

When we do this, the apps directory opens in a filer window (again, the progress indicator may pop up while ROX-Filer is fetched):

This directory shows a number of applications. These are application directories (described by me in a previous freshmeat editorial), so each is just a directory with an icon and a program inside it. Clicking on the icon will run the program. So if we click on the Edit icon, Edit runs:

Edit needed the ROX-Lib library to run, and it simply ran it from the rox.sourceforge.net/lib directory. In turn, ROX-Lib required pygtk, which it got from a different site (zero-install.sourceforge.net). If we now check the 0install directory, we can see the new entries:

$ ls /uri/0install
rox.sourceforge.net  zero-install.sourceforge.net

Edit also requires Python and GTK. In a full Zero Install system, we would see that gtk.org and python.org had been cached too. Currently, however, these must be installed in the traditional manner.

If we close Edit's window and run it again, it will start instantly, because everything it needs is now cached on disc. Likewise, if we run Memo (which also requires ROX-Lib and pygtk), only Memo itself will be fetched, since its dependencies are already present. Running cached software is just as fast as running traditionally-installed software.

To save having to navigate to the applications each time they are used, users could drag them to a Start menu or to the desktop background, bookmark the apps directory, symlink programs into a bin directory, create a shell alias or keyboard shortcut, or use any other way of making software easier to get to. Here, the user has dragged some of the applications to the panel:

Upgrading software

Zero Install uses a very aggressive caching scheme. If it has already fetched something, it won't try to fetch it again. This is because software is typically used in a different way than Web pages (which are also often cached). When I open a Web page in my browser, I don't want to see yesterday's version. When I run the Gimp, I'd probably rather use a month-old version than wait for the new version to be fetched.

However, we can force an upgrade very easily. Click on the Refresh button in the filer's toolbar, and the cache (for the whole rox.sourceforge.net site) is updated.

If nothing has changed, this requires downloading approximately 1K of data. If the site has changed, about 30K will be downloaded (the new index). Unchanged files on the site do not need to be re-downloaded, but anything that has changed will be refetched next time it is accessed. Also, only the initial 1K (with the index's digital signature) needs to come from the named site; the rest may then be safely fetched using closer mirrors or peer-to-peer systems.

In fact, sites normally make multiple versions of each package available (whether using Zero Install or not). If you instruct your filer to open Edit as a directory (rather than run it), you'll see that it actually contains all the different versions (use the right-button popup menu and Look Inside if you're using ROX-Filer):

You can thus run any previous version of Edit too, and the main application actually just runs the latest version (identified by the latest symlink).

This illustrates a rather interesting feature of Zero Install. Programmers often have to decide when to drop an old feature, such as support for a version 1 file format, to avoid programs becoming too large. With Zero Install, old code is still easily available, but is not fetched until it is accessed. Thus, support for old formats need never be dropped, since the new version can just call an older version if required.

Zero Install removes this size/features trade-off in other areas, too. For example, programs sometimes include debugging symbols. These make the programs considerably larger, but allow users to send much more helpful bug reports. Normal binary packages don't include them, to save space, but with Zero Install, they can be placed in separate .debug files, and will only be fetched if the user tries to fire up the debugger, getting the best of both worlds.

Distributing your own programs

Not only is Zero Install easier for users, it's much easier for programmers. One of the big savings is that, since everything is always available, you'll never be tempted to add a hacked-up XML parser or the like to your application to save users from having to install one. Another is that the process of making software available is just that much easier. Here's how you do it:

Start by creating the directory structure you want to export. Most simply, you can just copy the binary in, but you could also provide a directory structure with different versions and binaries for different platforms, etc. You should think about this early, because you must expect other people to link to your programs. Try not to keep moving things around! Here, for simplicity, we have a directory called MySite containing a single executable called MyProg:

The next step is to run the 0build program. This will build the index file and tar each directory. The output files need to go in a directory exported by your Web server. If you're running Apache, this just means copying to your /var/www directory (or wherever your installation is set to look). You also need to specify the server's hostname. If you're using another computer as the Web server, you can just put the files in a local directory and use rsync or the like to copy them across.

Haven't got 0build? Don't worry, it's in Zero Install:

$ alias 0build=/uri/0install/zero-install.sourceforge.net/bin/0build
$ cd ~/MySite
$ 0build /var/www example.org

When you do this, you'll be prompted to create a GPG key. This adds a small amount of security; anyone who has accessed your site at least once before will have her system automatically check, when upgrading, that the upgrade is authorized. If you're new to GPG, just select the offered defaults for key type, size, and expiry. The "Real name" can be anything, but the "email" address must be 0install@example.org (replacing example.org with the server name, of course).

You only have to do the GPG work the first time. In the future, just run 0build in ~/MySite to rebuild the index with the same settings as last time (0build will check which files have changed and only create new archives where necessary). You can now see if it worked (possibly from a different computer):

$ cd /uri/0install/example.org
$ ls
MyProg

And that's it! Your program can, of course, link against, run, or otherwise use any other software in the Zero Install system just by using its full pathname starting with /uri/0install.

There is one caveat, however: Because Zero Install always uses its cached copy of the index, the cached version of a site may be too old. You do, therefore, need to check the version of the resource you are using and force a refresh if it is too old. This isn't actually anything new, since even traditionally-installed software needs to check for versions; the difference is that instead of reporting an error, you update the cache.

Often, the library you are using will provide some way to do this. ROX-Lib, for example, is located (even in a traditional system) using the "findrox" module. This takes a version number and checks that the installed version is recent enough:

import findrox; findrox.version(1, 9, 11)
import rox

When used without Zero Install, the "version" function reports an error in a dialog box, telling the user where to download ROX-Lib. With Zero Install, it simply updates the cache (using the 0refresh command).

You can also check the state of the cache in other ways. For example, Python programs normally use the /usr/bin/env program to search for the Python interpreter in PATH:

#!/usr/bin/env python2.3
print "Hello world!"

Under Zero Install, /bin/0run can be used to check the cache and run Python through it:

#!/bin/0run python.org/python2.3 2003-01-01
print "Hello world!"

This checks that /uri/0install/python.org/python2.3 exists and is at least as recent as the given date. If not, the cache is updated using 0refresh.

For more information about packaging software for Zero Install (such as the recommended directory layout), see the Documentation for packagers.

Current status

Zero Install currently works on Linux 2.4 and 2.6 systems. Hopefully, developers on other systems will port it to their platforms. Up-to-date RPM and Deb packages will be needed to make installation of the system itself as painless as possible. While the implementation is still experimental, the interface seen by users and programs using the system (i.e., the /uri/0install filesystem) should remain stable. At worst (if the index format changes, for example), site maintainers will only need to rerun 0build to update.

Conclusions

By using a filesystem layout following the Internet DNS system, a Zero Install system is able to namespace and directly locate all of its resources. This removes the need for installers to move files to well-known locations (such as /usr/bin), since all files are already in their "standard location". It also allows Zero Install software to be used alongside packages such as Debs and RPMs. Because every resource in Zero Install is namespaced in this way, it is possible to share a single cache between distributions (imagine dual-booting Debian and Red Hat, but sharing the /usr partition). Wherever the same resource is used, only one copy is needed; where different resources are used, both copies are present (python.org/python2.3 vs. redhat.com/python2.3, if Red Hat wanted to use a non-standard build of Python, for example).

Because no install or uninstall scripts need to be run, users can run any software they please without risking the system or other users' security. This enables a truly distributed "web of software" to which anyone can contribute and removes the need for software to be packaged specially for multiple distributions. Disk space can be recovered by deleting parts of the cache (either manually by the system administrator or by a cron job looking for unused files). If anything deleted is needed again, it will be refetched.

While Zero Install doesn't solve the problem of security for individual users (a malicious program "Foo" can still delete the files of a user who runs it), it does simplify the problem considerably, paving the way for better user security systems in the future (clearly, there is no point in users not trusting Foo in a traditional system; if it's installed, it has already had the chance to do any damage it wants). See the Zero Install Security Documentation for more information on these topics.

Zero Install is already being used to distribute the ROX desktop's applications, and I hope that this article will inspire more people to make their software available this way. Future work will include polishing the core system and working toward better binary compatibility in the Linux world generally (the autopackage.org people share this goal with us, and we are using some of their software already to make our binaries more portable).

Author's bio:

Thomas Leonard is currently working as a research assistant at the University of Southampton while he finishes his PhD in computer science. He is the project administrator for the ROX desktop and for Zero Install, and is also involved in various freedesktop.org activities, including drag-and-drop compatibility and the Shared MIME database.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: System :: Archiving :: Packaging Topic :: System :: Software Distribution Tools

Referenced projects autopackage - A framework for producing powerful, distribution-neutral packages. Debian GNU/Linux - The Universal Operating System. dpkg - A package maintenance system for Debian GNU/Linux. GnuCash - A program to keep track of your finances ROX-Filer - Drag-and-drop based filemanager. Shared MIME database - The freedesktop.org shared MIME database. Zero Install - A system for running software without needing to install it.

 Comments

[»] It's not a solution
by nx12 - Jan 27th 2004 20:54:05

As far as I see, it doesn't resolve the main problem of today's installation:distribution's specific dir's and config's files. So you still have write distro-specific installation scripts or whatever you do install anything. I don't see any improvements comparing with apt-get or portage-system. Either it will build absolutely separated app/lib directory in userspace or anywhere else, either it will have the same distro-specific incompatibility problems.
I see it just as something closed to dynamic linking. Nothing exceptional.

--
53 49 47 4E 41 54 55 52|45 20 53 55 43 4B 53 21

[reply] [top]

[»] Two Holes and complex builds?
by Bob Glamm - Jan 12th 2004 13:42:50

1) Setuid()/setgid() binaries? Certainly root isn't running any installation scripts written by unknown parties, but a non-trivial class of applications exist (email) that tend to rely on setuid()/setgid(). I took a quick look at my system here and Mutt and KDE are the standout setuid()/setgid() offenders. A normal user can't install a setuid()/setgid() application, so this means that 0install needs to run as root (at least during the chown() call). Not an unfixable problem, though.

2) Hacked originating sites = comprimised 0install clients. GPG keys are nice and all, but how many people actually walk around with their GPG private keys on a floppy disk or USB keychain drive? IIRC a few months ago there was a site/source comprimise where the MD5 signatures matched the tar but the binaries had a trojan inserted. Mode 600 doesn't protect GPG keys on a rooted machine.

For that matter, the 0install system can be used as a kind of Denial of Service engine in a "dumb-user" environment: all one has to do is set up a teaser website where the list of dependencies includes huge lists of large files; if left unattended at home/small/medium size sites it can saturate the Internet access pipe until the disk is filled.

3) Complex builds can strike the system down. Ex: PHP4 with all its extensions. Say extension #1 in PHP4 depends on liba; extension #2 in PHP4 depends on libc, which in turn depends on libb and liba, and for whatever reason two different versions of liba are specified between the two extensions. Boom. It's difficult enough for a person to properly configure a PHP4 installation with the myriad library/sublibrary dependencies and the interaction with Apache.

Granted, it's unlikely that the end user is going to be installing PHP4, but it's not impossible that other reasonably complex applications have similar problems.

[reply] [top]

[»] Re: Two Holes and complex builds?
by Thomas Leonard - Jan 16th 2004 08:08:29


> 1) Setuid()/setgid() binaries?
> Certainly root isn't running any installation scripts written by unknown
> parties, but a non-trivial class of applications exist (email) that tend to
> rely on setuid()/setgid(). I took a quick look at my system here and Mutt
> and KDE are the standout setuid()/setgid() offenders.
Mutt isn't setuid here (Debian/unstable). Any idea why it would be? For KDE, the only thing I can think of is kpppd. The solution is for such programs to go through sudo, giving the admin a central point to configure all root access. Of course, sudo itself can't be in Zero Install (we don't allow setuid binaries under /uri/0install, for obvious reasons).

As an admin, this means you don't have to worry about packages installing setuid binaries behind your back, of course.


> 2) Hacked originating sites =
> comprimised 0install clients. GPG keys are nice and all, but how many people
> actually walk around with their GPG private keys on a floppy disk or USB
> keychain drive? IIRC a few months ago there was a site/source comprimise where
> the MD5 signatures matched the tar but the binaries had a trojan inserted.
Modifying MD5 sums to match binaries is trivial if you have access to the site (to be secure, you need some way to verify the MD5 sums themselves are correct, which zero install does with GPG).

As for breaking the GPG: yes, you could find out who admins the site, find their personal machine, get through the firewall/NAT, break into their machine (assuming they're running sshd on their laptop), install a keystroke logger, get the GPG passphrase and private key, break into the server and upload your trojaned build.

But it's a lot of work. Consider that most software doesn't come with a digital signature at all, and most people don't check them even if they do, and zero install will usually be more secure.


> For that matter, the 0install system can be used as a kind of Denial of Service
> engine in a "dumb-user" environment: all one has to do is set up
> a teaser website where the list of dependencies includes huge lists of
> large files; if left unattended at home/small/medium size sites it can
> saturate the Internet access pipe until the disk is filled.
That's true of your web cache, too, of course. Note that the user has to run the software (and leave it running while it downloads everything), the daemon process doesn't follow dependancies itself. For most home machines, you could achieve the same thing by telling a user to run 'wget -r' on a big site.

(you could also put per-user quota limits in the fetching daemon, but the system isn't big enough that we've had a problem yet)


> 3) Complex builds can strike the system
> down. Ex: PHP4 with all its extensions.
> Say extension #1 in PHP4 depends on
> liba; extension #2 in PHP4 depends on
> libc, which in turn depends on libb and
> liba, and for whatever reason two
> different versions of liba are specified
> between the two extensions. Boom.
However, it would be 'Boom' for everyone, not just your system, so it would get fixed ;-)

Mike Hearn (autopackage.org) is working on implementing the solaris linker behaviour, which allows this situation without problems.


[reply] [top]

---

[»] 0install will make a difference!
by Ian M. Trotter - Dec 16th 2003 13:18:57

I'm very fascinated by 0install. Now that I've found it, I know what's been missing in my life ;) This project might just be the one that proves the worthiness of Linux to the masses? In any case, I am convinced this software will grow up and make a difference in the world.

However, how does one envision the use of this in larger environments? Imagine being responsible for ~100 computers in a corporarte environment, and you want to limit the strain on the line due to people on workstations caching the same software. Now, there are probably (nay, certainly) many ways to do this, but a neat way would be to have some sort of zero-install proxy-server that caches software requested by the workstations the first time and (transparently) serves it to any additional workstations, running zero install, wanting to start the same program. Programs would then be cached on the proxy, and on the workstations themselves.

Anyway, I digress. My original thought was: does it let any user run any program? In many administered environments, there are certain programs you do not want regular users to be able to run, be it games during work hours or other things that upper management or stern administrators consider counterproductive or destructive. As such, it may not be a bad idea to have some mechanism which lets someone control what programs can and what cannot be run.

Well, I don't suppose it's worth concentrating on this sort of issues at an early stage of development. Tools like that will probably pop up all over the place with time...

[reply] [top]

[»] Re: 0install will make a difference!
by Thomas Leonard - Dec 17th 2003 11:23:47


> I'm very fascinated by 0install. Now
> that I've found it, I know what's been
> missing in my life ;) This project might
> just be the one that proves the
> worthiness of Linux to the masses? In
> any case, I am convinced this software
> will grow up and make a difference in
> the world.
>
> However, how does one envision the use
> of this in larger environments? Imagine
> being responsible for ~100 computers in
> a corporarte environment, and you want
> to limit the strain on the line due to
> people on workstations caching the same
> software. Now, there are probably (nay,
> certainly) many ways to do this, but a
> neat way would be to have some sort of
> zero-install proxy-server that caches
> software requested by the workstations
> the first time and (transparently)
> serves it to any additional
> workstations, running zero install,
> wanting to start the same program.
> Programs would then be cached on the
> proxy, and on the workstations
> themselves.
By default, it fetches stuff using HTTP, so your regular web-cache (eg, squid) will do what you want.

The mirrors list for each site (about 1K) is fetched with caching disabled, but the rest of the data can come through the cache, and all the archives are uniquely named with a timestamp to ensure that the same URI always refers to the same version of an archive.

[reply] [top]

---

[»] Why great things like this will advance slowly...
by svuori - Dec 15th 2003 02:16:30

is because of people who, without trying it out and without better knowledge, jump in with their "facts" about binaries not being compatible, library inconsistencies, directory structures and whatever.
This system is in an early development stage and still so many things work. Right now I'm writing this using Mozilla Firebird through Zeroinstall. People who want to know things before trying (like me), go to the zero-install website and read documentation there. Try it out anyway, you'll be surprised. Oh, you should try RoX too, at least its filer, you'll like it too :-)

--
-- C++/Java frustration? Try D http://www.digitalmars.com/d/

[reply] [top]

[»] Old features
by Fredrik Arnerup - Dec 14th 2003 13:37:34

"Programmers often have to decide when to drop an old feature, such as support for a version 1 file format, to avoid programs becoming too large. With Zero Install, old code is still easily available, but is not fetched until it is accessed. Thus, support for old formats need never be dropped, since the new version can just call an older version if required."

Does the author really think that size is the reason features are dropped? I would say that in the overwhelming majority of cases, old features are dropped in order to reduce code complexity or because maintaining old code to make it work with the new code is a pain in the butt.

--
/far

[reply] [top]

[»] How to make it more secure
by DataMoist - Dec 14th 2003 09:42:58

You should look into YURLs. http://www.waterken.com/dev/YURL/ The idea is to form a network of trust via introductions. Lets say the Rox site has a link to the GTK site. But the Rox site includes a hash of the GTK site's public key in the link. That way, if the GTK site is hacked or re-directed, the (browser) client will refuse to load it. Under the current scheme, you will only detect a problem if you had been to the GTK site before.

Given all the attempts at back-dooring the Linux kernel, etc, it's not too paranoid to be thinking two steps ahead.

In regards to 0install: I like it, but it needs managment tools. Each user should be able to "freeze" the application versions they like, so some other user doesn't "upgrade" them to a version they are unfamiliar with. At my university we had an application called SWSELECT that would allow you to set which version of each application you wanted to run. It just exported ENV vars like this:

PERL_VERSION=5.0.3
EMACS_VERSION=20

Applications not listed would get the 'recommended version', which only changed once a term. But geeks could set their version forward or backwards to their heart's content. (based on what the university continued to support, of course).

--
-- DataMoist -- The revolution will be packetized

[reply] [top]

[»] Re: How to make it more secure
by Wayne Scott - Dec 6th 2004 18:37:50

Basically the same as the SFS (Self-certifying File System).

A very good way for a site to include system links to other software collections that are trusted. This would complete the chain and nothing can be forged.

[reply] [top]

---

[»] Let me see if I understand this properly . . .
by RunNHide - Dec 13th 2003 22:24:57

Okay - the idea behind Zero Install is what it's name portends: that there is actually no installation performed and that all libraries/binaries are actually somewhere on the internet? Let me throw this in the mix - I live in Central Florida, known as "The Lightning Capital of the World" - we average 14 lightning strikes per acre each year. I am on DSL due to non-availability of cable. We have LOTS of electrical storms, and every time (or pretty close to every time) there's a lightning flash, I lose internet connectivity. Does this mean that, if I was using a program thru Zero Install, that program would crash?

[reply] [top]

[»] Re: Let me see if I understand this properly . . .
by LukeyBoy - Dec 13th 2003 23:11:28

No; the 0install program has a local cache of anything you decide to use. I haven't used the system personally, but I assume that if you set the size of the cache to something reasonably large like 500 megabytes you'll seldomly run into any problems like this.

[reply] [top]

---

[»] Not convinced
by Richard Clark - Dec 13th 2003 20:46:10

I've been watching Zero Install for a while now, and I like many aspects of the concept, but there are grey areas that I'm not so keen on.

In theory, it all works beautifully. but in theory, so does APT. In reality, APT works very well, I've never lost data and I've only rarely ended up with a screwed up system. But the fact of the matter is that sometimes, I have ended up with a dependency mess. Currently in sid for example, "gnome" depends on a pile of things which end up depending on "planner", which doesn't exist in the tree, thus you can't install the "gnome" package.

The fact of the matter is that this information is entered by humans, Zero Install or APT or YUM or whatever. And thus, it can break, and it can break spectacularly.

With APT, I know that unless I've done an apt-get upgrade, my packages haven't changed. They're right there, like they were yesterday, and they'll work just the same way they did yesterday. With Zero Install, its much more volatile. At any time, I could start an application only to have it load a new version from the 'net. One dependency screwup by a human on libc or some other vaguely critical package and you're in some serious trouble, all of a sudden nothing works and you've had no opportunity to look at the upgrade list, note that libc is in that list, and make yourself a rescue disk or equivalent in case things go to shit.

This is not to say that the Zero Install concept is a bad one overall, but I'm not sure people (or at least, people like me who like to *know* what state their system is in) are really ready for the idea of a caching application system. I think it *is* is the kind of thing a centralised authority could get away with, but the decentralised internet breaks all too often to make me feel happy that it could be relied upon to keep my system in good shape all the time.

There are ways and ways of getting around the various disadvantages, and I think to a degree the system proposed *is* the future, but at the moment we are not short on disk space for applications, and we are short on bandwidth (always :), so its solving the wrong problem I think, thus little motivation to solve the issues with it until the situation reverses itself (As I'm sure it has for some people with non-hd systems on gigabit lans or something).

[reply] [top]

[»] Re: Not convinced
by FNORD - Dec 13th 2003 22:32:48


> With APT, I know that unless I've done
> an apt-get upgrade, my packages haven't
> changed. They're right there, like they
> were yesterday, and they'll work just
> the same way they did yesterday. With
> Zero Install, its much more volatile. At
> any time, I could start an application
> only to have it load a new version from
> the 'net.

Wow, did you even read the whole article? Let me quote:


#Zero Install uses a very aggressive caching
#scheme. If it has already fetched something, it
#won't try to fetch it again.


Hmm, so explain to me how 'at any time' it will load the new version from the net? Oh, wait, if you keep reading:


#However, we can force an upgrade very easily.


What? You mean we have to 'force' an upgrade just like in APT? No way!


Please read the whole article before you go bashing it.


Is 0install the right/best way to do it? Who knows but it's better than not doing anything. Not all progress is fast, even in the computer age. My guess is that in 10 years no one will be using 0install in it's current form, but I wouldn't be suprised if the system that is being used isn't genetically related.

[reply] [top]

---

[»] Re: Not convinced
by Richard Clark - Dec 21st 2003 09:47:53


>
> % With APT, I know that unless I've
> done
> % an apt-get upgrade, my packages
> haven't
> % changed. They're right there, like
> they
> % were yesterday, and they'll work just
> % the same way they did yesterday. With
> % Zero Install, its much more volatile.
> At
> % any time, I could start an
> application
> % only to have it load a new version
> from
> % the 'net.
>
>
> Wow, did you even read the whole
> article?
You are correct, I was wrong regarding the auto-update mechanism, my apologies for that. I did read the article but I must have mentally skipped over that part. Sorry :/ After reading that I went to the site again because I go pretty much every time I see it pop up on freshmeat just to see whats changed, and sure enough, right at the top of the FAQ it says they don't upgrade automagically. My bad.


[reply] [top]

---

[»] Internet Required
by Sean Middleditch - Dec 13th 2003 15:45:44

So, since a very large number of users can't use the Internet for software distribution, what about them? There's a reason people buy CDs of software versus doing network installs, even for single, small apps. A good number of apps would be hell to download, too, such as OpenOffice.org, or any real game (I don't mean those little toys like TuxRacer or whatnot - I'm talking the 4CD install of things like Baldur's Gate and so on).

Unless 0install has a clean, easy, simple way of handling these cases as well as the network, it's going to force and require multiple ways of distributing software.

--
-- What?

[reply] [top]

[»] Re: Internet Required
by Thomas Leonard - Dec 17th 2003 11:43:49


> So, since a very large number of users
> can't use the Internet for software
> distribution, what about them? There's
> a reason people buy CDs of software
> versus doing network installs, even for
> single, small apps.
>
> Unless 0install has a clean, easy,
> simple way of handling these cases as
> well as the network, it's going to force
> and require multiple ways of
> distributing software.
The layout of the cache directory (/var/cache/zero-inst) is fairly simple, with one directory per site. So, I upgrade the cache on my (non-networked) laptop by copying the /var/cache/zero-inst/rox.sourceforge.net directory across on a zip disk.

A CD based installer can easily do something similar.
You need to be root for this, of course, but that's no worse than RPM, etc.


[reply] [top]

---

[»] Allowing non root users to install
by John C. McCabe-Dansted - Dec 25th 2003 07:50:58


> You need to be root for this, of course,
Actually, couldn't you have a suid program that installs the package if it is signed by the owner of the DNS?

For example, if a user wanted to install a package into adobe.com/acroread-6.0, the suid program would install it if it was signed with adobe.com/public.key.

Alternatively we could have a private cache directory for each user that they can write to.


[reply] [top]

---

[»] Mac OS X
by Vroem - Dec 13th 2003 14:53:53

I prefer the Mac way of installing software. Everything
except what is included in the operating system is
statically linked, OK I know, you don't like that. But It's
SOO easy to install!

Most Mac OS X programs consist of ONE file -- actually
a folder that looks like a file. Downloaded software is
always in the form of an auto-mounting image with that
one program "file" in it. Installing MS Office is just a
matter of copying a folder to your desired destination.

Almost no programs need root access (that's why there
is no root on default installations). But of course, there
can be a need for dynamic linking, therefore there is in
OS X, too, a package format that needs the password of
an administrator to be installed.

Sorry if this may not seem a *nix philosophy. But
remember that even tough OS X is less *nix-ish than
others, it is the most widely adopted *nix vendor. And
that of course because of it's user friendlyness

[reply] [top]

[»] Re: Mac OS X
by Marek Janukowicz - Dec 15th 2003 00:08:46


> I prefer the Mac way of installing
> software. Everything
> except what is included in the operating
> system is
> statically linked, OK I know, you don't
> like that. But It's
> SOO easy to install!
Yes, and SOOOO big :)


> Most Mac OS X programs consist of ONE
> file -- actually
> a folder that looks like a file.
> Downloaded software is
> always in the form of an auto-mounting
> image with that
> one program "file" in it.
Most of the time, yes. Always, no.


> Installing MS Office is just a
> matter of copying a folder to your
> desired destination.
I don't think it's easy. In my Gentoo Linux I only need to type "emerge openoffice" to have OO installed. In OSX (theoretically) I need to know a location where I should put the application.


> Sorry if this may not seem a *nix
> philosophy. But
> remember that even tough OS X is less
> *nix-ish than
> others, it is the most widely adopted
> *nix vendor. And
> that of course because of it's user
> friendlyness
Yes, especially uninstalling is very user-friendly :). You can't get a list of installed packages and you can't uninstall them (you have to delete package files manually).

--
Marek

[reply] [top]

---

[»] Re: Mac OS X
by rds - Dec 17th 2003 12:09:37


> I prefer the Mac way of installing
> software. Everything
> except what is included in the operating
> system is
> statically linked, OK I know, you don't
> like that. But It's
> SOO easy to install!
It sounds like you want AppDirs, which are a feature of ROX-Filer. Basically, they work by placing all the app's code and what not in a directory, and you launch the program by clicking on it, or running the AppRun sh script. Unless you want to, you never have to see the "guts" of the program, you just click it and it [compiles and] runs.

I agree that it makes thing so much easier, and I honestly wish every piece of software would use it. :)

[reply] [top]

---

[»] Re: Mac OS X
by Sutic - Dec 17th 2003 16:10:14


> I prefer the Mac way of installing
> software. Everything
> except what is included in the operating
> system is statically linked,

http://developer.apple.com/qa/qa2001/qa1118.html:

Q: I'm trying to link my binary statically, but it's failing to link because it can't find 'crt0.o.' Why?

A: Static linking of user binaries is not supported on Mac OS X. (...)

[reply] [top]

---

[»] Nice.
by X - Dec 13th 2003 12:33:03

Ever heard of -static?

Most users would rather download a single executable rather then go around looking for dependancies.

I've trying to come up with a solution for releasing binaries. Even making my own wizard maker.

Sounds good, from a programmer's point of view.

[reply] [top]

[»] Won't gain wide adoption without a distro
by Ian Clarke - Dec 13th 2003 08:06:42

I think 0Install is a great idea, and quite possibly the natural evolution in how software is deployed in the future - it could put Linux ahead of all other widely used Operating Systems when it comes to ease of deployment.

There is a serious problem though, I don't think 0Install will be widely adopted until someone builds a Linux distro which uses 0Install as its primary packaging system. The reason is that people don't want to deal with two or more packaging paradigms.

Building a distro around 0Install wouldn't be hard, but would require laying down standards that people adhere to. This would allow a more distributed approach. For example, a software developer that wanted a dependancy on GTK could reference the GTK website directly such that the latest version of GTK will always come straight from its authors - rather than having to go through a packaging process.

[reply] [top]

[»] Re: Won't gain wide adoption without a distro
by Ben Crowell - Dec 13th 2003 18:44:53


> There is a serious problem though, I
> don't think 0Install will be widely
> adopted until someone builds a Linux
> distro which uses 0Install as its
> primary packaging system. The reason is
> that people don't want to deal with two
> or more packaging paradigms.
There are already too many different software packaging and distribution systems. Some of them are good (e.g., FreeBSD ports and packages, and, from what I hear, apt), and some are not so good (e.g., RPM), but the proliferation is a real problem. As a user, I don't want to worry about whether a particular piece of software has been packaged using the system I use. As a programmer, I don't want to be bothered creating many different packages. I recently googled on the name of a piece of software I wrote, and found out that several people were distributing old versions in RPM format. On the one hand, it's flattering that they went to the trouble, but on the other hand, it's a drag that they're distributing old versions.

Rather than adding one more packaging system to the mix, I'd rather see some of the badly designed ones (RPM especially) go away, so that effort could be better focused on the ones that are well designed.


[reply] [top]

---

[»] Re: Won't gain wide adoption without a distro
by Janne - Dec 13th 2003 20:11:47


>

> There are already too many different
> software packaging and distribution
> systems. Some of them are good (e.g.,
> FreeBSD ports and packages, and, from
> what I hear, apt), and some are not so
> good (e.g., RPM), but the proliferation
> is a real problem. As a user, I don't
> want to worry about whether a particular
> piece of software has been packaged
> using the system I use. As a programmer,
> I don't want to be bothered creating
> many different packages. I recently
> googled on the name of a piece of
> software I wrote, and found out that
> several people were distributing old
> versions in RPM format. On the one hand,
> it's flattering that they went to the
> trouble, but on the other hand, it's a
> drag that they're distributing old
> versions.
>
> Rather than adding one more packaging
> system to the mix, I'd rather see some
> of the badly designed ones (RPM
> especially) go away, so that effort
> could be better focused on the ones that
> are well designed.
>
*sigh* You are confusing very different things here.

RPM != apt

RPM == deb

RPM is a package format, and is neither better or worse than the deb format (which debian uses).

Apt is a package manager, which can use deb, RPM or whatever package format. An alternative to Apt is Yum, which also in principle can work with whatever package format.

Removing RPM as an alternative would do nothing, zero, squat for solving packaging problems. In fact, suggesting that we dump the most commonly used format is counterproductive; if you want to standardize, why dump the one that is used by over 90% of distros already? Debian could in principle switch over to RPM from Deb without its users even noticing; just push an update over apt.

Package problems are really due to differences between distros. If you want to hand out binary packages, they pretty much need to be built separately for every distro you wish to support.


--
This mission will be easy and fun for all. /Janne

[reply] [top]

---

[»] Is there any list of available applications?
by Claudemir Todo Bom - Dec 13th 2003 06:19:21

I'm willing to test it, but I'm unable to find any list of available applications, is there any such thing?

[reply] [top]

[»] Re: Is there any list of available applications?
by Thomas Leonard - Dec 13th 2003 06:37:40


> I'm willing to test it, but I'm unable
> to find any list of available
> applications, is there any such
> thing?
>
This directory has some symlinks:

/uri/0install/zero-install.sourceforge.net/links/

Most of the ROX apps are available and well tested.

Some other bits (acrobat, java, mozilla, nedit, openoffice, etc) are also available. However, many of these were from an earlier test version of 0install. In particular, you may need to symlink /uri/0http to /uri/0install (the path changed a few versions ago).

Of course, you could always put some up yourself...

[reply] [top]

---

[»] And compaired to yum?
by X-Nc - Dec 13th 2003 06:11:01

$ yum install gnucash

Do the same caveats for apt apply to yum? I don't know the guts of either, just how to use them, so I really would like to know. I have looked at Zero Install and it doesn't look bad (similar to stowe) but it seems more complex than it needs to be.

But what do I know anyway...

--
If I actually _could_ spell I'd have spelled it right in the first place.

[reply] [top]

[»] I am sorry.
by Tassilo v. Parseval - Dec 13th 2003 01:00:13

While this may sound like a good idea, it is hardly practical for the maintainer of the software. This sounds dreadful:

Typically, you'll want to provide multiple versions of your software, and for multiple platforms.

[reply] [top]

[»] Re: I am sorry.
by Jaap Karssenberg - Dec 13th 2003 03:02:09

The 0install system is intended to work with application directories. A typical application directory will have a AppRun script that checks the platform, if a binary distribution is available it will use that, but if not a compile process can be started. Most of the appdirs currently around actually do that.

[reply] [top]

---

[»] Re: I am sorry.
by Igor Izyumin - Dec 13th 2003 11:05:05

I agree, there is no way this could possibly work. Binary compatibility is all but non-existent, since a binary package usually depends on the exact versions of all libraries and the compiler that it was compiled with. If you expect the maintainers to create and maintain zillions of binaries for different platforms, this will not fly.

In short, this project aims to solve a non-issue (dependencies), while imposing a weird structure for finding things and ignoring the real issue (the fact that a binary for distro X generally will not run on distro Y). If binary compatibility existed on Linux, there would be absolutely no need for any weird package systems. Just look at Windows.

[reply] [top]

---

[»] Re: I am sorry.
by Mike Hearn - Dec 13th 2003 12:00:28

That is simply incorrect. Linux binaries are binary compatible, if they were not, we would not be attempting schemes like ZeroInstall or autopackage.

Believe me. I have spent many months of my life researching these matters. Linux binary compatability, while improvable, is definately good enough to try this. After all, why not ask Loki, or CodeWeavers, or any of the other companies that ship one set of binaries for all distributions and somehow manage.

[reply] [top]

---

[»] Re: I am sorry.
by Dmitry E. Melamud - Dec 13th 2003 14:55:08

They are using statically linked binaries, aren't they?

[reply] [top]

---

[»] Re: I am sorry.
by Michael Torrie - Dec 14th 2003 00:11:04


> They are using statically linked
> binaries, aren't they?

No. They are standard dynamically linked binaries. They usually just have a few requirements, like Glibc >= 2.1, libX11, sometimes libgtk (1.2.x). Really it's not hard to get a binary to run on a wealth of distros if you stick to the lower demoninators of installed software.


Things are a little more dicey for gnucash since they work with newer versions of libraries than are typically available on existing distros (usually due to bugs in the older versions). In the case of Gnucash, many of these dependency libraries actually grew out of the gnucash project, so it's not unreasonable that gnucash would require a newer version that, say, redhat ships. Of course, that does make Gnucash about as hard as gnome to compile.



[reply] [top]

---

[»] We could specify exact versions
by John C. McCabe-Dansted - Dec 25th 2003 04:10:19


> … If binary
> compatibility existed on Linux, there
> would be absolutely no need for any
> weird package systems. Just look at
> Windows.
Even under windows one cannot trust DLL's to be backwards compatible (hence "DLL hell"). IMHO it would be best if each application specified the exact versions of each library that it required, and checked that the MD5 matched. The application would only link against a new library version, if a trusted database reported that it had been thoroughly tested against that new version.

This would cost HDD space, but Windows & Linux installs frequently fail and I would rather waste 4 MB than spend a day fiddling with DLL files. To a "End-User" software that requires fiddling with DLL files would be useless.


[reply] [top]

---

[»] Re: We could specify exact versions
by Damjan - Jan 20th 2004 05:41:31


>
> % … If binary
> % compatibility existed on Linux, there
> % would be absolutely no need for any
> % weird package systems. Just look at
> % Windows.
>
>
> Even under windows one cannot trust
> DLL's to be backwards compatible (hence
> "DLL hell"). IMHO it would be best if
> each application specified the exact
> versions of each library that it
> required, and checked that the MD5
> matched. The application would only
> link against a new library version, if a
> trusted database reported that it had
> been thoroughly tested against that new
> version.
In windows its even worse, there are not different versions of a library like: libpng.so.2, libpng.so.3.
Linux already has this, but the problem is when oyu need to integrate two different software packages (like apache and Python

[reply] [top]

---