Author: Nathan Willis
Klik is a service that delivers Linux applications as self-contained Application Directories in mountable, compressed filesystems. To the end user, each package looks like a single file with the extension .cmg that can be moved anywhere on the system and run in place (assuming the permissions are correct). Inside each AppDir is a bare-bones filesystem with the application and library dependencies.
Many people get that far in the How to use Klik page and think, “That’s crazy; I’ll have dozens of copies of every library on your system, needlessly wasting space.”
But that’s the wrong idea entirely; Klik is not designed to replace a full-blown package manager like rpm or dpkg. Instead, it is for individual applications. Recently, I chatted with Klik creator Simon Peter about that very misconception.
“Klik is just an additional way of using add-on software on top of your existing base system, without touching it. For managing the base system (everything you need to boot and run KDE, GNOME, or your preferred desktop), you will continue to use your distribution’s infrastructure just like always,” says Peter. “But if you want to test the shiny, new app you just read about, you can do so with Klik — without the need to wait for your distribution to package it, without the need to change anything in your base system, and without the risk of damaging anything.”
Klik grew out of Peter’s fondness for running Knoppix live CDs. “Personally, I like to use a read-only base system that I never touch…. The separation of the base system (for which integrity must be ensured at all times) and userland applications (which can come and go) is an important concept.” The AppDir concept, inspired by Apple’s Mac OS X application directories, fit the bill perfectly.
The Klik client registers a handler for klik:// URLs. To install any application in the Klik library, users click on a klik://firefox (or similar) link to request a package from the Klik Web site. The server returns a “recipe” instructing the client what packages to download and how to build the appropriate AppDir and compressed filesystem on the user’s machine. Most Klik recipes are auto-generated from Debian packages, though some require manual fixes before they are added to the library.
This implementation makes it simple to download and run an application. The library, which opened in late 2004, currently contains 4,000 to 6,000 packages and boasts more than 100,000 installs.
Klik has some limitations, however, including the fact that all klik:// requests are hard-coded to search only the official Klik library, which makes for a single point-of-failure for the entire system. You can’t start and maintain your own library, as the Klik client won’t support it. Peter says that the Klik team is looking at support for different servers, but it is designated as “step two.”
Also under discussion for the future are a command-line client, digital package signing, and a “Klik maintainers” interface to allow programmers to easily add Klik recipes for their own programs and maintain them at the central Klik library.
A note to application developers on the Klik site instructs them on how to provide easily “klikable” packages. Those interested in helping with Klik development must work with the Klik team and request access to the source code on IRC. Peter says that they won’t be making a public source code release in order to discourage people from forking the code base, thus making Klik more difficult to use.
A more serious limitation is, of course, that each AppDir is a filesystem that must be mounted to run. Since Klik mounts AppDirs with loop, it limits you to eight simultaneously running Klik applications under the default Linux kernel configuration. There are ways around the limitation, but Peter reports that future upgrades will take advantage of FUSE to avoid this problem and leave /etc/fstab untouched. Here, again, he is quick to point out that Klik is not intended to provide every application on the system.
The Klik library currently provides only i386 recipes, and Peter says they will stick to i386 alone for now. But Peter is intrigued by another Apple tactic: universal binaries. Perhaps, just as Apple supplies multiple-architecture packages whenever they switch processors, Klik can package multiple images in one file. Peter promised to start working on it as soon as someone bestows a G5 on him.
Despite its current limitations, Klik’s driving principle — maintaining a clean installation — makes it a welcome utility. Only a few applications are unavailable through my distribution’s official repository, but those few invariably cause the most headaches with their bleeding-edge dependencies. Getting a self-contained executable via Klik can help you sidestep this issue altogether.
