This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

Zero Install: An executable critique of native package systems

By Bruce Byfield on February 15, 2007 (8:00:00 AM)

Share    Print    Comments   

Zero Install is one of the more promising alternatives to native package systems for Linux distributions, such as RPM and Debian's dpkg. Originally developed by Thomas Leonard, who works in the Department of Electronics and Computing at the University of Southampton, it begins with a criticism of existing package systems the difficulties of using them, and is built to provide an answer to the problems raised by the critique. However, like other alternative package systems, it faces the problems of winning acceptance from the major distributions and fine-tuning its features.

Zero Install is an offshoot of the ROX Desktop project. Leonard says users were reluctant to try ROX unless it was packaged for their distro, but packaging took time away from development.

Moreover, maintainers could be hard to find, and their work was not always consistent, complete, or high-quality. At any rate, Leonard says, "the distributions had enough to do supporting GNOME and KDE, and mostly ignored us."

ROX's woes lead to the start of Zero Install in 2003. According to Leonard, Zero Install has been downloaded about 26,000 times, and at least 112 programs can currently be installed with it. Traffic on the developer list is light but steady, since, as Leonard points out, the program "is simple, and the important part is the content that people provide using it."

Working with Zero Install

Zero Install functionality is available from the ROX Desktop. However, most users will probably use a small Python program called the Dependency Injector to install software. You can download the Injector from the project site in a variety of package formats. In addition, functionality is integrated into the ROX Desktop if you have it installed.

Once the Injector is installed, you can install software by running the command 0launch <URL> .

A list of known URLs for use with Zero Install is available on the project Website. During installation, the digital signature and a list of dependencies are displayed, and programs are installed to the ./cache directory in the user's home directory.

When installation is complete, the program starts automatically. In fact, if you choose, you can run the Injector to install and start the program. More practically, you can run 0launch --gui and click the Cache button to start it from the right-click menu on a list of installed programs, or create a desktop icon in the usual way. Note that if you start a program from the list, the URL from which the program was installed is displayed first, and you have to open the tree of listings to see the name of the program. Programs installed with Zero Install are not added automatically to GNOME or KDE desktops.

From the Injector window, you can set how often installed packages are updated, or select the Refresh all now to update manually. Deleting a program is similar to running it: Click the cache button, highlight the program in the list of installed programs, then click the Delete button.

The Zero Install critique

Like Autopackage, part of the motivation for Zero Install comes from dissatisfaction with the existing native systems.

The first problem that Leonard brings up with native package systems is a lack of freedom. "Users are effectively confined to the software their distribution packages," Leonard says. "Some distributions don't want their users running 'unauthorized' software, because it increases their support costs if users report bugs to them by mistake." While Leonard acknowledges that this attitude is "understandable," he also characterizes it as "worryingly similar to hardware manufacturers wanting to reduce costs by using Trusted Computing."

Another issue is security. Using his own workstation as an example, Leonard says, "I currently have 2,100 Debian packages installed. Every time I update my computer, the authors of every one of these packages get to run a shell script of their choice as root on my machine -- even the maintainers of documentation packages, or of packages I installed months ago and never ran again. Even if I trust the packagers to this extent, what about the risk that one of them has their machine compromised?"

For Leonard, this arrangement violates the basic security of least privilege, which "demands that a desktop application shouldn't have permission to destroy the system." Efforts to allow sandboxing -- contained testing of programs -- exist, but Leonard asks, "What policy can you possibly write for apt-get?" The same comment, of course, applies to YUM or any other package management utility.

Finally, Leonard complains about the lack of flexibility. "I'm forced to have only a single version of each package on my machine," he says. "I can't compile a program against the GTK 2.4 header files because I have GTK 2.8 installed. I can't install a security update to gnupg because it will uninstall user-mode-linux due to a conflict with libreadline5. I can't run a program that's ten years old, because the libraries it needs have changed." Yet such problems are not inevitable. Rather, Leonard points out, "they are arbitrary limitations imposed by current installation systems.

Zero Install is designed to overcome all these problems. Rather than relying on a list of repositories than must be manually edited, it allows Web pages that contain programs in a number of formats, ranging from Debian packages and RPMs through tarballs and zip files that are digitally signed and work with any distribution, to be entered on-the-fly. Since software is not installed by the root user, installation or updates of desktop applications cannot damage the entire system, and software can be easily sandboxed by maintaining a user account solely for the purposes of experimentation. Similarly, Zero Install tracks different versions of a program separately.

The main drawback to Zero Install is that software must be installed separately for each user. However, this problem is relatively minor, since Leonard sees Zero Install as a supplement to native package systems, not as a complete replacement.

"For now, we're mainly focused on programs (or versions of programs) and libraries that aren't widely installed by default," he says. "So we don't provide GTK through Zero Install, for example, because everyone has it already." However, if a program needs an earlier or bleeding edge version of a basic library, he suggests, Zero Install might still be an option.

Barriers to adoption

Leonard suggests a number of reasons that Zero Install is not more widely used. For one thing, "explaining it to people seems difficult, as it's rather different to what they're used to." Too often, he says, people read only some of the documentation, and form their opinion based on some imagined similarity with another system.

Often, too, Leonard says, people go off on a tangent about security, "even though their current system usually has the same or greater risks, but just hidden. For example, some Ubuntu people complained that our GPG key confirmation dialog didn't do enough to warn users of the risks of unknown software authors. Yet by default Ubuntu will install an unsigned .deb from the Web without mentioning security at all."

Another possible obstacle, which Leonard does not discuss, is a GUI that, while adequate for a few programs, is likely to be inadequate for hundreds, since it would require users to scroll through a list of originating Web sites.

However, the greatest obstacle seems to be getting Zero Install accepted by distributions. Unlike Autopackage, Zero Install has not attracted any degree of hostility from distributions. The reason for the difference may be that, while the Autopackage team makes sweeping criticisms of many of the fundamental aspects of GNU/Linux, Leonard's critique is more restrained and chiefly addresses more basic, less controversial, issues.

All the same, Leonard cites "apathy" from distributions as a major problem for Zero Install's acceptance. To date, only Fedora includes a Zero Install package in its repositories. The project site includes packages for Debian and Ubuntu, Mandriva, Slackware, and SUSE, but these packages have not been accepted yet into the distributions for which they are designed.

However, Leonard suggests that acceptance from the distributions is only a matter of time. "Having some kind of structured system for third party software," he says, "is clearly more manageable than having these programs each come with a custom installation script," as the native systems do now. "So the distributions will either have to accept a system like Zero Install, or else try to lock out third party software entirely (which would certainly be against the spirit of free software that many of them support."

Future plans

Leonard describes Zero Install as "mostly complete." However, the project roadmap includes a list of enhancements that are currently being considered. In addition to system-wide installs -- or, at least, the ability to share installs with other uses -- Leonard would also like to see integration with native package systems, so that Zero Install can use existing dependencies instead of installing duplicates. He is also considering functionality to clean out the cache of installed programs, to include recommended as well as required programs in the dependencies, and to display messages about what has been installed.

Most of all, Leonard would like support for mirrors, which he describes as "pretty critical. You should be able to install new software even if the main Web site is down, without having to find a mirror manually."

Some of these features raise critical issues. In particular, installs for more than single users raise security issues that Leonard is only too aware of. Yet, on the whole, Leonard is satisfied that solutions can be found. Most of these future features, he says, "just make [Zero Install] faster or more efficient or reliable. These are minor technical problems, so it's more a matter of choosing from many possible solutions."

Bruce Byfield is a computer journalist who writes regularly for NewsForge, Linux.com, and IT Manager's Journal.

Bruce Byfield is a computer journalist who writes regularly for Linux.com.

Share    Print    Comments   

Comments

on Zero Install: An executable critique of native package systems

Note: Comments are owned by the poster. We are not responsible for their content.

A few corrections/clarifications...

Posted by: Anonymous Coward on February 16, 2007 08:06 AM
I (Thomas Leonard) have a PhD from the University of Southampton, and I currently work there, but I'm certainly not a professor!

Also, the issues with sharing packages between users are quite minor. You'd need a Set-UID helper that runs the '0store copy' command. The only difficult part is the usual issues involved in writing any Set-UID programs: cleaning the environment, sanity checking the input, etc.

Finally, the preferred way to run applications isn't by browsing the cache. The idea is that each desktop environment should provide its own way to add program launchers to the interface.
ROX and Xfce both provide drag-and-drop interfaces for this, while the 0alias command provides an interface suitable for shell users. GNOME and KDE users would probably want a utility that created<nobr> <wbr></nobr>.desktop files, but noone has written one yet.

#

Re:A few corrections/clarifications...

Posted by: nanday on February 16, 2007 09:32 AM
Thanks for the corrections.

I've corrected the biographical information in the text, but I thought the clarifications belong in the comments.

As you can probably figure out, the comments about running applications from the cache reflects the fact that, for KDE and GNOME users, there currently isn't -- as you say -- an interface.

- Bruce Byfield (nanday)

#

The problem with zero-install

Posted by: Anonymous Coward on February 16, 2007 03:48 PM
The main problem with zero-install is that it's over decentralised. If you're program depends on gtk it will get it from www.gtk.org.

This dose mean that zero-install programs share dependencies but its not so good if you want to install something in 10 years time.

Really what is needed is some way of createing a<nobr> <wbr></nobr>.tar.gz that includes all dependencies, save those provides by the LSB, and installing that via an install-shield like program. Such a system will be worse than apt or yum in most respects but its sheer simplisity would make it easy to do securely and allow developers to publish their own packages.

#

Re:The problem with zero-install

Posted by: Anonymous Coward on February 16, 2007 07:25 PM
Get a Gentoo. Install (or compile) all needed software. Pipe list of files to tar. Done.

#

Re:The problem with zero-install

Posted by: Anonymous Coward on February 16, 2007 08:40 PM
The main problem with zero-install is that it's over decentralised. If your program depends on gtk it will get it from www.gtk.org.

By default, yes. You (the user) can specify somewhere else, though if you want (double-click on GTK, then click on 'Add Remote Feed' and type in its URL).

Note that the packages don't normally contain the URIs of the libraries they use. Instead, the XML description of the package gives the dependencies. So, if in 2017 the gtk.org stuff has moved to <a href="http://archive.org/2007" title="archive.org">http://archive.org/2007</a archive.org> then the author of the program using GTK would just edit the XML to give the new location (or someone else could publish the updated XML, if the original author had disappeared).

This dose mean that zero-install programs share
dependencies but its not so good if you want to install something in 10 years time.


Well, this is covered by support for mirrors. As long as someone kept a copy of GTK you can use that. Presumably whoever archived the 10 year old program would have archived its dependencies too.

Really what is needed is some way of createing a<nobr> <wbr></nobr>.tar.gz that includes all dependencies

Like this?

<a href="http://rox.sourceforge.net/desktop/Zero2Bundle" title="sourceforge.net">http://rox.sourceforge.net/desktop/Zero2Bundle</a sourceforge.net>

#

He makes a very good point

Posted by: Anonymous Coward on February 16, 2007 04:44 PM

"I currently have 2,100 Debian packages installed. Every time I update my computer, the authors of every one of these packages get to run a shell script of their choice as root on my machine -- even the maintainers of documentation packages, or of packages I installed months ago and never ran again. Even if I trust the packagers to this extent, what about the risk that one of them has their machine compromised?"


And he goes on to remark that Ubuntu will install an unsigned<nobr> <wbr></nobr>.deb from the web without mentioning security at all. This is a security disaster waiting to happen. As soon as any GNU/Linux distro gets a significant share of the total desktop market, look out for the bad guys to start exploiting this. Steve Ballmer will have a field day pointing out that "Linux" is less secure than Windows. Of course Linux is pretty secure and GNU is pretty secure; but the packaging systems used by nearly all distros make the user bypass all security, so his message will be believed.

#

So they were dissatisfied, that is.

Posted by: Anonymous Coward on February 16, 2007 09:39 PM
Well let me drop my $0.02 into this mess.

> Zero Install is one of the more promising alternatives<nobr> <wbr></nobr>...is _not_.

> it faces the problems of winning acceptance
Indeed.

> users were reluctant to try ROX unless it was packaged for their distro
Sure! It's not exactly trivial.

> maintainers could be hard to find
Now, when you are high quality upstream which is a piece of cake to package and work with, we're not *that* hard to find.

When you're promising at first but then frustrating upstream, you sure have the best way to distract from developing the project by developing the scaffolding for lazy users to install it!

I've recently commented on ROX-Filer here, and on LWN, arguing that while it has a bunch of nice features, overall it's not something you want to give your parents or your customers: it's quirky and will make losing your files "on the desktop" as easy as removing symlink target is, too.

So, maybe it would be better to *first* care about critical usability bugs in the project itself, then popularize it via articles and reviews -- there is considerable demand for lightweight desktop, I tell that as one who does this for living! -- and then talk to people inside Debian/Ubuntu and Fedora/openSUSE (maybe FreshRPMS , OpenPKG or Dag would do that -- if these were archived, we could share a bunch of RPM specs for ROX, drop me a note if anyone interested).

Don't even bother to care for slackwarists and the rest of those who would groan how hideous those dependencies and packages are, just not worth the trouble: they'll find another point to exercise their usual gross incompetence with. (heck, even Guido is an enemy of software deployment with his stance of recommending to install python and modules "just in your $HOME"!)

Short outro: I'm maintaining some hundred and a half packages in ALT Linux, and we've used ROX-Filer in one of desktop Linux deployment projects (alas, XCFE's then-current XFFM was even more of a disaster; Thunar seems much better though). And yes, I'm fed up with this awful lot of not-so-polished wheels just because somebody tried to roll one lying on its side!

PS: I'm talking rough not to offend but rather to give some imagination of the pain involved in attempts to actually use software which wasn't created with deployment in mind. That includes e.g. Python and homegrown stuff like 0install<nobr> <wbr></nobr>:-(

--
Michael Shigorin, M.Sc.
shigorin gmail com

#

Re:So they were dissatisfied, that is.

Posted by: Anonymous Coward on February 17, 2007 02:05 AM
I've recently commented on ROX-Filer here, and on LWN, arguing that while it has a bunch of nice features, overall it's not something you want to give your parents or your customers: it's quirky<nobr> <wbr></nobr>...

Exactly. ROX isn't a drop-in Windows replacement. If we cared about making money from it, and targeting the biggest market, we'd probably change it as you suggest.

But that isn't the goal. This is Free software - we like it this way. I suggested your design on the mailing list as one alternative many years ago when I implemented the feature. No-one wanted it that way.

But as long as we're willing to write ROX, and there are people who want to use it as we build it then we should be able to do that, without any needing to convince dozens of distributions that we've done our market research to justify their efforts.

There's a wider issue here, too, which the Autopackage devs also mention. Upstream often implements features in a very open way, with discussion on the mailing lists between all interested parties. Alternatives are tried; feedback and experiences are collected. The carefully produced package is released... only for a lone packager, only vaguely following what's going on ("maintaining some hundred and a half packages" to use your phrase), to make some unilateral change that undoes it all.

Now it may be that some kind of Windows/ROX hybrid would be useful to some people. You're free to make one, or to pay someone else to make one. And if you distribute it through Zero Install, then anyone on any distribution will be able to use it, if that's what they want.

#

Sharing is now supported

Posted by: Anonymous Coward on February 27, 2007 11:18 PM
<a href="http://0install.net/sharing.html" title="0install.net">http://0install.net/sharing.html</a 0install.net>

#

current packing systems awful

Posted by: Anonymous Coward on March 08, 2007 09:08 AM
I hate the current packaging systems. If Linux distros were owned by proprietry companies I would swear the reason for them is to lock people into the distros.

The operating system and the applications should be seperate - they are different things. I want to get the apps from the authors, not from a distro specefic repo. Why?

Because often the app you want isn't in the repo. What do you do then? Compile from source? Then you become (or have to become) a de-facto software developer, who will need to understand and debug C compile listings. No thanks.

The difficulty with installing software, a process that should be so simple, is the shame of the software industry. It is difficult not because its inherently complex, but because the underlying infrastructure in the operating system has been designed without consideration of installing software. If the native file system software and api's supported a proper naming system and local addressing the problem would not even exist in the first place.

Its like designing a car with the steering wheel in the boot. Of course its hard to steer, but it wouldnt be with the wheel in front of the drivers seat.

But operating systems / file systems are not designed with software installation in mind, but with the assumption that the operating system and applications are a complete whole (which they are not), or that the system will be set up by an skilled IT department (which most arent).

As impressive as zero install is, I still think it is more complex than should be needed, as it is a bolt on solution rather than designed into the low level system infrastructure.

The operating system should support in built meta data which allows for the proper run time identification of shared files and looking for them using local references (e.g. the application directory first, then through other outer layers).

I think all application libraries should be able to be located within the applications directories, and the op sys should look there first. It can later determine if an exact same library is already loaded in memory and elect to use that (possibly under user control). Libraries should be shared in memory, but not necessarily on disk. Disk space is in abundance and very cheap. No one cares about saving space for shared libraries these days.

How about this simple scenario. Application (app) is started from its own directory (~home/app). It then wants to load libproc.so. This library is in the app directory (e.g. ~home/app/libproc.so). Operating system calcualates the hash for this library (or has it stored as metadata from a previous run) and examines list of hashes of currently running shared libraries to see if its already loaded. If it is, use it. If not load the local copy and use that.

Cant it be that simple?

Applications would be available on web sites as tar files containing ALL the required libraries. Installation would involve only de-archiving to a named directory. Executing would involve running the binary executable from within that directory. Everything else would be automatic.

#

Pardon me for wanting a synopsis of a synopsis but

Posted by: Administrator on February 18, 2007 06:26 AM
What does this do better than apt4rpm/smart or apt debian packaging systems?

The weakness I see with our existing systems is that you need to do some kind of relinking, ldconfig, SuSEconfig, etc. to get each package to actually take and be show up ready to use. It would be nice to have a packager that contends with dependencies while making the installation seamless per environment.

In any case, I'm not really sure why we are talking about 0install after reading the article. Cheaper, faster, better--- No offense, but which one is it.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya