Author: Bruce Byfield
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 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 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.
