Klik is a system which creates self-contained packages of programmes installable over the web with a single click. In the article below Kurt Pfeifle discusses the potential uses of this technology for helping the non-coding contributors to KDE. He also looks at how the system works and the obvious security issues involved.
- Can you imagine you just copy one single file onto your system, wherever you possess "rw" privileges (no need for being root) and this file represents a complex, runnable application?
- Can you imagine that with a simple click on a website you could "copy-install" and run such an application?
- Can you imagine that this simple "installation" did not affect in any way the stability of your base system?
- Can you imagine that this file could even run from a USB pen drive? And you just stick it to a different computer to run the application there?
- Can you imagine that you could run the latest official Krita release side by side with Boudewijn's code from last night, without the two versions interfering with each other?
- Can you imagine you revert to your old system again by just deleting one file?
And why would this be relevant or useful?
- It would provide a way to KDE developers for making binary packages of bleeding-edge code directly available to be run by usability experts for early feedback...
- It would let KDE developers give out their bleeding-edge packages to beta-testers well before Release Day...
- It would let translators see (in their actual, lively GUI context) the strings they are working on...
- It would enable art designers to actually *run* a program they are contributing icons and other artwork for...
- It would give a full preview of what will go out to our users at Release Day, to all the different groups of our non-technical KDE contributors (who are not typically compiling KDE every night from the latest checked-out sources)...
- It could happen at any time, completely independent of releases, practically 5 minutes after the code was written and compiled, and long before there are official packages created by everyone's favorite distro...
One can dream, no?
At aKademy I discussed this question with various people. By now everyone in the KDE community is aware of one of my proposed solutions (or that's what I like to think): use a NX or FreeNX driven KDE Application Server, and provide remote access to the programs in question.
However you are wrong if you imagine that my only occupation is NX. I have another, complementing proposal about how to tackle this same problem. One that is an especially nice fit in cases where testers and users do not have network connections.
One that works for Live CD distributions (Knoppix, Kanotix) as well as for Debian, Linspire, Ubuntu, Kubuntu and openSUSE/SUSE Linux 10.0. (No, it's really got nothing to do with NX. Nor with FreeNX. Other than the fact that Fabian, the main developer of FreeNX, has also been a contributor to this klik thingie...)
Take note! It's not a dream. It is reality. It is reality for Linux. It is reality for KDE. It is called klik.
It works on most Debian systems, and on Knoppix (torrent) and Kanotix (torrent) Live CDs.openSUSE/SUSE-10.0 is has recently been added to the list too. Here's how you can test it:
- Install the klik client: press [Alt]+[F2] and paste: wget klik.atekon.de/client/install -O - | sh (this step is not required on Kanotix -- it has the klik client already installed).
- Follow the instructions that pop up on your screen.
- Start Konqueror (it may have opened automatically), and click on one of the links offered in the online klik store.
You could also just type klik://xvier into the Konqueror address field. I actually do recommend to you to start with xvier: it is a simple game that fits into a less than 400 kByte download, so you can have a quick success with klik and see what potential it has...
Neat, isn't it?
klik has been developed by Simon Peter (a.k.a. "probono" in IRC), with the support of Niall Walsh ("bfree"), Jörg Schirottke ("Kano") and FreeNX's Fabian Franz ("fabianx"). You can meet them in the IRC channel #klik on Freenode.
If you are bit security concerned, you may want to know what klik does to your system. Here's the pitch:
- Its .cmg files are self-contained AppDirs (applications directories), compressed into a cramfs or zisofs file system.
- To run the contained app, klik mounts the bundle file underneath /tmp/app/1/ and runs it from there; if mounted, the bundle looks like it is a subdirectory expanded into the real directory structure of the host.
It's very much similar to how applications on Mac OS X works....
If you are even more cautious, or paranoid, you surely want to investigate more closely and see how klik operates on your system. Follow these steps to find out more details:
- wget klik.atekon.de/client/install (this downloads the install file without executing it).
- less install (this lets you look at the installer code: fear not -- it's pure shell).
- less $HOME/.klik (this lets you look at the "commandline client+klik protocol handler" code, of course only after running the klik client install).
- less $HOME/.zAppRun (this lets you look at the commandline starter for klik-ified AppDir bundles, also executed if you just click on one of the .cmg files).
- less {$KDEHOME,$HOME/.kde}/share/services/klik.protocol (the secret behind the klik://my_cool_app links, part 1).
- less {$KDEHOME,$HOME/.kde}/share/applnk/klik/klik.desktop (the secret behind the klik://my_cool_app links, part 2).
- less {$KDEHOME,$HOME/.kde}/share/applnk/klik/.directory (why there is now a klik icon and a klik entry in the K Menu).
- less {$KDEHOME,$HOME/.kde}/share/mimelnk/all/cmg.desktop (why klik is now responsible for handling clicks on files that happen to have a .cmg suffix, part 1).
- less {$KDEHOME,$HOME/.kde}/share/applnk/.hidden/AppRun.desktop (why klik is now responsible for handling clicks on files that happen to have a .cmg suffix, part 1).
- less /etc/fstab (why klik can now find mountpoints in the file system to mount the .cmg AppDirs on execution).
- ls -lR /tmp/app/{7,6,5,4,3,2,1} (list the directories underneath the mountpoints while one of the .cmg AppDirs is executed).
klik's smartness is all contained in a few shell scripts and typical KDE config files, as you can easily see...
For most of the 4000+ packages available from the klik warehouse, the "download" consists of a "recipe". The recipe tells the klik client where to fetch the binaries from (in most cases .deb packages from the official Debian repositories), how to unpack them, and how to re-package and compress them into the final .cmg image. So the klik client does most of the work and builds its own .cmg file in most cases.
If you want to look at one such recipe, here is the klik recipe for Scribus.
There are other packages which have been built on the server (and hand-tuned and tested) so that they work with non-Debian distros too ("serverside apt"). In this case the klik://some-app link will fetch the ready-made .cmg from the URL the klik server names in his recipe. The special "klik apps for SUSE 10.0" repository is filling up by the day. Warning: currently this will only work for openSUSE/SUSE Linux 10.0, not for other Distros!
You may be interested in trying the following links, if you have more bandwidth (note: they'll not work for you unless you install the klik client). They work on openSUSE/SUSE-Linux 10 RC1 very well, and also support Knoppix, Kanotix, Debian, Linspire and Kubuntu (other distros are untested):
- klik://apollon (downloads 2.2 MByte)
- klik://firefox (downloads 10.0 MByte)
- klik://skype (downloads 10.2 MByte)
- klik://frozen-bubble (downloads 14.0 MByte)
- klik://ooo2 (downloads 114 MByte) - Martijn can use this to read .odt files easily!
I found the ooo2 bundle (representing the OpenOffice.org 2 beta release, build 125 by Novell) on par (or even better) in speed and responsiveness as the "real" RPM package that I installed from the RC1 iso images for SUSE Linux 10.0.
If you are a type of person who likes to startup apps from the commandline, use the klik commandline client like this:
- $HOME/.klik klik://ktorrent (installs the cool KTorrent BitTorrent client).
This will prepare the .cmg AppDir bundle and run it once ready. Once .cmg file is on your system, the commandline to run it (without a repeated download) is this:
- $HOME/.zAppRun /path/to/app123.cmg (runs the application named app123).
I have already browsed the web with Alpha version 1.6a1 of Firefox to see if the hype around it is justified. To do so, I tried the old-fashioned manual installation of the klik-ified Firefox:
- mkdir $HOME/klik-downloads
- cd $HOME/klik-downloads
- wget http://opensuse.linux.co.nz/klik/10.0/firefox_1.6a1.cmg
- $HOME/.zAppRun firefox_1.6a1.cmg
I am pretty sure, that at least some of our beloved KDE-PIM hackers will like this new way to take a quick look at their valued competition, without needing to install it:
- klik://thunderbird -- the Beta 1 of upcoming Thunderbird 1.5, the Mozilla mail client (klik bundle, direct link)
- klik://sunbird -- Development version of Mozilla calendar application (klik bundle, direct link )
Now, developers, what do you think of a tool that lets you easily create binary snapshots of your own development versions in the form of those nifty "Don't Install, Just Copy!"- .cmg files? -- Which of you will be the first five to step forward and receive the service of getting their SVN weekly builds packaged as .cmg AppDir bundles, for the next 3 months?
I know Boudewijn has been struggling in the past to provide Krita snapshots to a dozen beta testers and non-technical contributors, and to help them compile the code, or to support them installing binaries he had built.
I also know that I definitely would love to get quick access to kpdf, KWord, amaroK, Quanta and Kommander snapshots which I can run on my stable system with the reassuring feeling that the most that can go wrong is that the test app doesnt run at all, and all I had to do is just delete it again, to have my system reverted to its original state.
What about our friends from OpenUsability.org? Would they appreciate such a service too? Have they ever looked at the added value klik:// can offer to our common development workflow?
Comments
There's a problem with the online klik store link, atekon has been replaced by artekon ;)
Hope a dot editor sees that.
Fixed
And it's down to, perhaps due to too many hits ...
Yes, your friends from OpenUsability.org really appreciate that service! We usability people sometimes have problems installing the latest developers version of an application, so we welcome smart workarounds like klik.
I've tried klik for Skype and I was amazed how easy it is to install a fully functional application - and especially how easy it is to deinstall it later: You simply delete the skype icon from your desktop. It's magic!
For single applications, klik is a real alternative to the NX technology as keyboard shortcuts, clipboard etc. work as usual. For evaluating the whole desktop, however, NX is superiour (plus klik is not yet able to deliver the whole DE, I think).
From an OpenUsability point of view, it would be cool to have klik for non-KDE applications, too :)
Thanks guys and go on developing such cool tools!
/el
aahh!
I didn't fully read the article (as I knew the technology before)
-> there ARE many kliks for non-KDE apps
wonderful :)
This is an awesome thing that for me will help a lot porting commercial apps without bothering of package building (or hating rpm-only distribution made by some vendor) but to have success this must be supported by other DEs like Gnome and xfce (and also enlightenment) ROX already supports AppDirs, so if AppDirs (or compressed AppDirs) become standard they could help a lot distributing software under linux (or BSD) especially commercial ones (which most of the times are staically linked so there are no dependencies problems)
Great work!
Wow, this looks great. What I missed in the description is if this also works for kpart plugins, ie. does it register mimetypes/servicetypes?
### "kpart plugins" ?
----
waitaminutewaitaminutewaitaminute!
You can't have all at once. But development certainly is not yet finished! New developers are welcome. Come by and visit us in #klik on Freenode.net.
klik can set them up for the application contained in the cmg, but it does not touch the world outside the cmg (this is by design).
If it works for KDE applications it is very likely expanding KDEDIRS as the KDE application rely on KStandardDirs to find their own resources.
If an application installs a MIME type into "its own" KDEDIR equivalent it should be visible to the rest of KDE as well
It would be great also if instead of putting the application .config files into my homedir, they would be put into their own little space, maybe in the installation file itself. I really don't like having tons of .something into my homedir for every app I try.
Right now, it seems like gentoo isn't supported. Is there any change for gentoo to get supported?
yep i am using gentoo too
I'm running Gentoo and the example app worked perfectly for me. I also tried smb4k though that didn't work... :-/
I get "/tmp/apps/1/wrapper" no such file or directory on gentoo, but on my debian-PC it works great. :)
Please open konsole and run manually:
~/.zAppRun ~/Desktop/xxxxxx.cmg
Then watch for error messages, that might give you a hint. Please join #klik if you need further support ;-)
Try another one. I get that error with freedoom and some others, but like frozen bubbles works perfectly along with bzflag and some others. Right now its about 50% of them work flawlessly for me.
You need cramfs installed as a kernel module (and cloop to?)
yes, it's part of most distros
It work for me, but you have to had cramfs installed.
This kind of thing is exactly what Linux needs. Every application should be installed this way.
nice idea, but this is just not the scope of Klik. it would be inefficient if every application would have a certain amount of dependencies (amount getting larger, the lower you get into the 'chain' of applications - if you say only base apps are installed, every 'klik' would need lots of basic libraries, and be very large on disk and memory). the native packagemanagement software or autopackage should cover this.
as said before, the scope of this is limited, but cool :D
Personally, I don't care about a reasonable amount of inefficiency. My computer is more powerful than I really need; it's time to put that power to work doing *something* useful. I would accept double the memory consumption and disk space usage in all my applications if it would enable something as cool and useful as this. If a little inefficiency is the price to pay for the complete elimination of all packaging and installation problems across all distros, I say go for it! Of course the old way of packaging will always still be available for those who can't stand a single wasted resource.
I personally would definitely _not_ want every application installed this way. This would lead to a system with dozens of different versions of libraries stored in dozens of different application directories, wasting space, computer resources with unoptimized builds and unnecessarily large waste of disk space (I don't care how cheap the disks are, I wouldn't want to waste my money even if I were a billionaire).
I could go on listing situations where a system built fully based on klik would not be desireable. The point is, of course there are situations where klik can simply RULE, it's nice, I love it, really. Still, I wouldn't use it to install anything on my machines, I'd use it for quick-testing alpha/beta software then quick removal, but nothing more.
The situation is different of course when you want to provide a very easy and quick setup of applications for 6packjoes, for whom some waste of bandwidth, space and efficiency is not a big pay for having a simple installation method.
Cutting this short, klik is great, but one should not loose the focus and apply a seemingly nice solution to all problems, even for some which don't even exist yet.
It would be nice if there was some way you could manage what things you have install (maybe though klik:/config or something?). Also I think 'klik:/' should take you to the klik page with all the downloads.
I am afraid I am not up to date with klik but when I discovered it about a year ago it was bound to the URI scheme and did't yet offer a MIME type for the recipes.
The drawback of the situation back than was that the server, or more generic the source, of the package couldn't be transported along with the recipe as the part of the klik URI where the hostname would usually be is occupied by the package name.
Being bound to the URI had also the drawback of being only accessible to browser that can be configured for additional protocols.
Its definitely a nice thing to have this easy to remember URIs additionally, though
Does it work if I want to install Plasma with a klik://plasma link? (Cannot test now myself, sitting in front of a WinXP box visiting my brother...)
And if there is not yet a klik package for Plasma, will Aaron "Jack-Of-All-Trades" Seigo provide one?
Will there be a CMG package of Zack Rusin's EXA drivers/X extension so I can do a simple klik://exa ?
Will klik become an integrated part of KDE 4?
Are there plans to make klik:// a full KDE KIO slave (coded in C++ instead of Shell) and with more configuration options?
As Plasma still is in it's infancy I don't think there are anything really interesting to install yet, unless you are one of its developers:-)
And from what I read of Klik I don't think it's intentional use are those fundamental system parts/libraries like Plasma and even more EXA. It's more targeted for use with higher level stuff, like applications. But maybe it perhaps could be used for Plasma extentions, what I think they call plasmoids.
most plasmoids are scripts, based on java, python or ruby, thus easilly installable. but for the c++ plasmoids, autopackage or klik would be nice.
I know you speak from experience with the packaging mess that NoMachine has for different versions of Linux. This is a perennial problem that *does* need to be solved.
klik://nxclient
I already knew about klik, and I am really excited about this way to get (not so) simple packages with one click :)
I have one question: How does this relate to the freshly announced DCC?*
I read Knoppix, Linspire, Xandros and many others have joined the DCC, so it should be easier to simply target one ..."common core" indeed. Is this correct?
If this is the case, well I'm simply amazed, think about what klick could become for the entire OSS community in the next months...
... i want klik URL's on kde-apps.org! :)
Kudos
* That's Debian Common Core, but don't tell the debian dev's ;)
DCC should indeed help. I don't know whether they will specify a set of "base packages" that will be installed on every DCC-compliant system, but that would help even more.
It's more like a common set of libraries taken from sarge + 2 or 3 packages to make it LSB compliant.
The "core" is already downloadable and "weighs" about 350MB:
http://archive.progeny.com/progeny/linux/iso-i386/
announcement:
http://lists.dccalliance.org/pipermail/dcc-devel/2005-September/000116.html
This is a start, but where is KDE?
heh, i guess somwhere in the repositories...
I don't know if the common core is or will be extended to KDE or other non-system librarier, but this is their very first step, and it's a step in the right direction IMHO.
My big attraction to this is that with a single click, i could run last night's konsole (e.g.,) build every morning, and if there's a problem, I can file the bug *and move back to the known working version of konsole* immediately. This would close the loop on the qa process, tighten it to a single day, and make it nonintrusive to getting my work done.
This lets me 'slipstream' QA into my normal work routine -- and when I run into a serious bug, I can resume with only a minor interruption to file a bug and restart my working version of the app.
I currently run MacOSX Firefox nightlies this way. It's valuable knowing that the bugs I file are timely and relevant to the current state of development.
I am blown away by ease of use of klik://scribus-latest
It give me Scribus-1.3.1cvs up and running on Kubuntu within 2 minute, with one click only! After I close Scribus again (I successfull printd Scribus tutorial found on kde-files.org), I am ask for feedback, but stupid I cancel the dialog, without filling it. So here is my feedback to klik inventors:
This is so revolutionary for everyone: developer, user, developer-helpers (beta-tester, translator, documentor, artist).
Didnt know about klik, but I am Knoppix user since 2 years. Great stuff!
I look around the klik website to see if they publish their feedback somehow. Discoverd it: they feed it even *live* into this page (50 latest comment):
. --> http://klik.atekon.de/comments.php
It is amazing t watch the various comments coming in now. Dunno if it was this article. Seems like a *lot* of people try it klik now.
Thank you very much for klik.
while I'm entusiast about this, I think that cmg images and AppDirs should be natively supported by kde, klik it's great, but I don't want to depend on it, I want to download a .cmg image mount it and drop my app (AppDir) where I want, like in MacOS.
Again dependencies are a problem, but it could be simple to create a way to install needed libs with AppDirs (ROX already does it)
klik also does include the required libs in the cmg. In fact, a cmg is nothing but a ROX AppDir inside a cramfs image.
What a fantastic implementation of a very interesting idea! Works well here on my Gentoo system.
It might be nice if later on the disconnect between a systems' own package manager and klik could be bridged over, so the user could choose at some point to properly install the application.
If you run a Debian based system you could just install the .deb that the cmg image is generated from (and any others that it depends on that you don't already have that is).
"If you run a Debian based system you could just install the .deb
that the cmg image is generated from (and any others that it depends
on that you don't already have that is)."
------
You didn't get the point of klik then....
*Of course* you could install the .deb. But what would it do? It would change your base system. The .deb would install its files into your /usr, /bin, /sbin,... whatever directories, additionally drawing in possibly many dependencies (installing more), and on the way replace the previous version of that application(s). You couldn't revert easily to the previous state of your system.
The .cmgs are self-contained. They don't touch your /usr & /bin & /sbin... They do not replace your system's applications. Never. The cmg AppDir files are designed to be run side-by-side with your existing apps (which are under the reign of some package manager). And they are designed to also get rid of them, easily: just delete one file. Your package manager will not be affected in any way.
No thats not what I meant. I was replying to:
" It might be nice if later on the disconnect between a systems' own package manager and klik could be bridged over, so the user could choose at some point to properly install the application."
I didn't meant for it to sound like I was saying 'so what?' to klik, I think klik is awesome (I have an icon on my desktop that launches the klik .cmg image of Frozen Bubble). I run Gentoo so I find being able to just 'klik' and run a program (like a little games like Frozen Bubble) very good to see if I want to actually install the application later (since compiling takes a long time). The primary advantage of installing it using the distribution's package system would be that it would be automatically updated whenever you update the system. *hint hint: feature request for klik*
hi,
just to say klik is an extremely interesting technology -- just what i have wanted already a long time ago!
the klik website has an interesting statistic showing how popular each of the applications offered are (download numbers), and how successfull the users where in installation.
it is here:
http://klik.atekon.de/popular.php
Aurelio
I don't really like the idea of modifiying /etc/fstab, so I'm looking forward to see an implementation working with FUSE (actually merged in what will become the 2.6.14 linux kernel).
That way no root access will be needed, and every app will be mountable under ~/.kde or ~/pub etc...
Anyway, klik is a very useful piece of software, congrats !
There's this old one: "Anyone who doesn't know Unix is doomed to re-invent it, badly."
Same can be said for Zero Install. I've see quite a few idea on that path (AppDirs, fat binaries, auto package, auto installers) and none can hold a candle to Zero Install (http://zero-install.sourceforge.net).
It basically offers everything that "klik" offers above and also includes:
* Bundling libraries (so you don't have to worry about supported distros)
* Managing library versions (avoids DLL hell)
* Auto-updates software versions as required
* cross desktop support as no special "handlers" are required
* Downloads are cached across the system (multiple users don't need to download the same program multiple times)
It also offers some interesting security features. I do suggest that people start to do some research before duplicating efforts.
klik follows the "1 application = 1 file" paradigm, 0install does not.
Like a lot of technologists, you completely missed the point.
The issue isn't how it does its magic but how it presents it to the user. The idea of using the file manager/web browser paradigm that the user is familiar with to also (easily) manage software installations is the main issue here, not the technological nitty-gritty details of how you do it.
Klik also cheats a bit by hacking on support for its "one file = one application" paradigm into Konqueror. The fact that its very easy to do not withstanding. How does it intergrate for users who run ROX on their K desktop, or even - god forbid - nautilus ? Currently it doesn't and as I read it there aren't any plans on making it so or even providing a framework that would work for new and unlisted file managers. This is the major down side of Klik - it does not fix the fact that the OS itself does not support internally the neat idea described above, instead it bolts on support on a per file manager implementation.
0install has one better - its integrated into the kernel. You don't need to support each individual file manager, you can use whatever you are most comfortable with and get away with it. Heck, you can even use the command line if you so prefer.
0install of course supports the file management based software install/uninstall, it just have its own way of doing it (which IMHO is better). As a fringe benefit to the nitty-gritty details of how 0install implements the paradigm (vs. how Klik does it), that with 0install you can install and run a software on your computer just by clicking a special link on a web page (its not that special, it simply a link to a local 0install powered file path that doesn't exist yet) - with all the required warning dialogs of course.
With the important limitation that the 0install kernel hack is just for one particular kernel, afaik there aren't port to kernels of other OS (and undoable for OS which have a closed source kernel).