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


One-click installation with Klik

By Nathan Willis on November 07, 2005 (8:00:00 AM)

Share    Print    Comments   

Simplifying software installation is a popular pastime for Linux developers. It has given us useful tools like Synaptic, YUM, checkinstall, and autopackage. A new kid on the block, Klik, approaches the problem differently, by avoiding the installation altogether.

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.

Share    Print    Comments   


on One-click installation with Klik

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

klik client is GPL actually

Posted by: Anonymous Coward on November 08, 2005 12:54 AM
Just as a clarification, the klik client is under GPL (even if the article suggests otherwise). klik follows an open development model, with most of the action taking place on #klik in and via the "klik maintainers" interface.


Re:klik client is GPL actually

Posted by: Nathan Willis on November 08, 2005 02:00 AM
Huh? I don't think that I did suggest otherwise.

Although I should point out that the klik client is distributed with no license attached and there is no license statement on the project's Web site. If it is intended to be GPL'ed, then it needs to say so and the GPL needs to accompany it.

Both those things are easily fixed of course; it's just that too often people simply assume that all Linux software is under GPL, when in fact there is no license (leaving the software in a state of limbo and un-included with commercial distros who have to take such matters seriously) or a distinctly non-free, non-open-source license (as is the case with <a href="" title="">Gizmo Project</a>).

I have no doubts about Simon Peter's commitment to open development, but as of right now it is quite definitely incorrect to say that klik is under GPL. Software's not under a license because people feel like it is; it's under a license when the license is attached to it and released with it.


Re:klik client is GPL actually

Posted by: Anonymous Coward on November 08, 2005 04:09 AM
"the klik client is distributed with no license attached"
You didn't look at the source code of the klik client, did you? If you did, you can surely tell me which language it is written in, yes?


Re:klik client is GPL actually

Posted by: Nathan Willis on November 08, 2005 04:26 AM
Indeed I did, and indeed I can, but I am not continuing this discussion with an anonymous troll. If you want to have a real conversation, you know how to contact me.



Posted by: Anonymous Coward on November 08, 2005 04:31 AM

I am truly amazed how well some of the klik packages work. I'm a klik user ever since Kurt Pfeifle started to regularly <a href="" title="">blog about it</a>, 2 months ago. My current favorite is

  • <a href="klik:amarok-svn-nightly" title="klik">klik://amarok-svn-nightly</a klik>

It bundles a Xine sound engine with it, and it is based on the current amaroK development code, re-built each night from the Subversion repository. Only 9 MByte for the complete bundle -- that is not more than the SUSE RPM package for amaroK (Is that the effect of the compression that is applied to the<nobr> <wbr></nobr>.cmg? Whatever...). My other favourite kliks are:

<a href="klik:scribus-latest" title="klik">klik://scribus-latest</a klik>

<a href="klik:kimdaba-latest" title="klik">klik://kimdaba-latest</a klik>

<a href="klik:wesnoth-latest" title="klik">klik://wesnoth-latest</a klik>

<a href="klik:kdissert" title="klik">klik://kdissert</a klik>

<a href="klik:kflickr" title="klik">klik://kflickr</a klik>

<a href="klik:kitty" title="klik">klik://kitty</a klik>

<a href="klik:klamav" title="klik">klik://klamav</a klik>

<a href="klik:xara" title="klik">klik://xara</a klik>

<a href="klik:luma" title="klik">klik://luma</a klik>

<a href="klik:opera9" title="klik">klik://opera9</a klik>

<a href="klik:skype" title="klik">klik://skype</a klik>

<a href="klik:smb4k" title="klik">klik://smb4k</a klik>

<a href="klik:yakuake" title="klik">klik://yakuake</a klik>

<a href="klik:ooo2" title="klik">klik://ooo2</a klik>

<a href="klik:nvu" title="klik">klik://nvu</a klik>

(Damn, the links above do not work! They are displayed with the required "//", but these are actually not in the links. You'll have to insert the double-slashes manually!)



Posted by: Anonymous Coward on November 08, 2005 06:14 PM
It looks too limited to be useful. The distribution system is not distributed!!!!!!



Posted by: Anonymous Coward on November 09, 2005 01:39 AM
surely this sort of url would be trivial to implement?


a default server could be controlled by<nobr> <wbr></nobr>/etc/klik.conf so individual distributions could use different repositories



Posted by: Anonymous Coward on November 09, 2005 07:37 AM
Actually, for most klik bundles the "recipe" is found on the klik server, but the "meat" of the package (i.e. the binaries that make it up) are simply downloaded from existing debian repositories and mirrors. Except for the small (few Kb) recipes, it's just as distributed as apt-get.



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

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya