Author: Nathan Willis
The system consists of two parts: a small client-side application that registers itself with the OS as the protocol handler for klik:// links, and the official klik server that generates and serves build instructions to the client for each requested application. Following the server’s instructions, the client takes an app and turns it into a compressed disk image files (with the extension .cmg) rather than installing it through traditional means.
When the user launches a .cmg file, the disk image is uncompressed, mounted (read-only), and the application within run. By default the current version of klik uses loopmount to mount the disk image, limiting the user to eight simultaneously mounted .cmg apps on recent Linux kernels.
The advantage of running applications from compressed disk images is that they are far less likely to damage or otherwise alter the underlying operating system. The .cmg image encapsulates the directory structure containing all of the files and libraries needed by the application, eliminating package-management hassles like obscure dependencies, version conflicts between apps, and accidental corruption of important files.
There are always pathological exceptions, of course. You can easily launch a .cmg package of Thunderbird, for instance, and from it delete years’ worth of your own email — but that isn’t klik’s fault. For the most part, a .cmg package is sequestered, safe, and simple.
The trade-off for klik’s convenience is the absence of flexibility. The client is hard-wired to retrieve packages only through the klik.atekon.de server. The apps provided through the official klik server must be maintained by a human volunteer who tracks changes to the application and its dependencies and modifies the server-side “recipe” that is returned to klik clients.
Furthermore, the klik server can manage dependency checking for the app, but it does so through its own database, using information calculated based on the official Debian packages. A developer can add an app not in Debian to klik’s system only by contacting the klik developers and convincing them of its worth. That’s not to say that it is an arduous process, and they even provide a set of guidelines on making apps “klikable” — but if they turn down a request, it is game over.
Get klikking
The key to making an app klikable is to avoid the use of hard-coded paths. When uncompressed, each .cmg image contains what the klik documentation calls an AppDir — a sparse Unix directory hierarchy containing the filesystem structure needed by the app, much like a chroot. Similar schemes are used by Mac OS X and the ROX environment.
To make an app function in this hierarchy, it must be compiled with relative filesystem paths. For example, instead of coding an app to look for its plugins in /usr/lib/myapplication/plugins, you could tell it instead to look in $MYAPPLICATION_PLUGINDIR. Under normal compilation and installation, the MYAPPLICATION_PLUGINDIR variable will be correctly set to /usr/lib/myapplication/plugins — but in addition, the klik recipe will catch that reference and set the variable to a location inside the AppDir instead. Thus the app works in both cases.
For further study, the klik documentation recommends looking at BinReloc, a tool from the Autopackage project designed to assist developers in making relocatable apps.
Another ingredient to making a klikkable binary is determining what dependencies need to be included in the AppDir. Since klik is designed to work across a variety of distros, it assumes the existence of some basic tools and libraries. Discovering exactly what those assumptions are requires some digging. The klik project leaders maintain a list of known working Linux distributions on the klik wiki, but unfortunately the exact list of expectations is undocumented. You can, however, see what is currently expected by the klik server.
In general, the klik team advises independent package maintainers to test on slightly-older-than-bleeding-edge systems in order to be as compatible as possible.
Once an app meets the relocatability and compatibility requirements, inclusion in the klik system is a matter of making packages publicly available on the Web (so that klik clients can retrieve them automatically) and finding an official recipe maintainer. The klik project suggests that developers volunteer to maintain recipes for their own apps; to get started you must contact the project via email or IRC.
Future versions of klik will do away with several of the current generation’s shortcomings. The team is evaluating the use of FUSE to sidestep the loopmount limit, and Plash for a full application virtualization approach. Plans are also underway to revise the AppDir format to better handle read/write data, security, and metadata. And the project hopes to simplify the question of what base packages it can assume are installed on a client-side machine by adopting the Linux Standard Base as its benchmark.
The klik client is licensed under the GPL version 2, and undergoes active revision to support new distros, desktop environments, and usability enhancements. The klik server code, however, is proprietary.
