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
Is there a way to convert a "klik://" into an ordinary URL, so I can download it on another machine (with a better or cheaper network connection)? That machine may even run Windows, but it has wget.
No, since most cmg files are dynamically created on-the-fly on the client using existing ftp archives. (One could probably use klik on Windows for creating cmg files...)
But once you have a cmg, you can ftp/mail/... it.
The site does not work for me.
Indeed, it worked just fine for me yesterday. I had a good look around and tried it out on OpenSuse10 RC1. Today it is not available at all :(
There is a DNS issue of our provider. Please visit #klik for a workaround in the meantime.
klik.atekon.de has IP 134.169.172.48
I remember earlier today name resolution didnt work. But now it does again.
What about virus, worms etc and destruction of ~/ and so on?
Can this can be a new super-tool to make Linux as virus infested as Windows is now?
Please tell me I am wrong (and why)!
klik does not run stuff from random places.
Other then installing software on Windows by clicking random links in Internet Explorer, Klik behaves like other package systems like YaST, APT, click-n-run, urpmi and yum: you tell it what you want to run, and it downloads and installs the necessary packages for you from predefined centralized servers, not from random locations.
you are wrong
i can see where you're coming from. imagine that you've already installed 20 packages using klik, all of which are in your home-directory somewhere, and then you install a package with a nasty script in it wiping the the home-directory clean. that would be a very bad-hair-day.
there must be a simple way around this. maybe one shouldn't give the klik script the write to delete anything without the user OKing it. maybe you should be warned, if the klik package isn't kosher.
whatever, it does make things a bit more complex.
The website is offline, any alternative?
http://134.169.172.48
They are having a dns problem.
Goto http://134.169.172.48/ in the meantime.
the komplete KLIK thing does not work for me because the DOMAIN does not resolve. this is very very sag because everybody who tries this klik thing will stop to use it because it wont work... :-( :-(
:-(
:-(
Oh, come on. Click the flatforty link and only two entries below your comment is the answer to your problem.
no it does not work !!! perhaps you try first and post then ?
the domain name ist encoded in some of the scripts (most of them) so i only get errors when using klik because it wants to get things from klik.atekon.....
i just wantet to say it suck that the dns goes off when you announce it on kdenews with 150 comments !....
chris
It's a real pitty that there is no single mirror.
Here's the solution
Add '134.169.172.48 klik.atekon.de' to your /etc/hosts file.
Remember to remove it once the dns problem is solved.
Unfortunately /etc/hosts is irrelevant if you are to use a transparent proxy, right?
### "/etc/hosts is irrelevant if you are to use a transparent proxy"
----
You can circumvent proxy problems by using "transconnect". I've to do it to get past my proxy too.
transconnect is a small library, tconn.so, that can be used with the "LD_PRELOAD" mechanism to intercept all CONNECT calls of libc programs and replace these with an explicit proxy connection, including proxy authentication where this required. tconn.so reads from a tconn.conf configuration file in each user's home the exact details how it should behave. Make sure you do "unset http_proxy" at the same time you use tconn.so pre-loaded.
See http://transconnect.sf.net/ for details.
This looks mildly interesting but is hardly something to get too excited about. The same functionality (and then some) has been available in the Tcl/Tk community literally for *years* -- check out »starkits« on the Tcl/Tk Wiki at http://wiki.tcl.tk . A starkit is a Tcl/Tk program, including any required extensions, in a single file, and can be platform-independent (i.e., the same, identical starkit runs on Linux, Windows and the Mac), store its own configuration settings, and self-update from the Internet.
And how does that work with KDE apps? GTK apps? Plain old X apps?
Well, the article you commented on was about "the potential uses of this technology [klik] for helping the non-coding contributors to KDE".
These starkits don't help a bit regarding development, translating, usability testing, functional testing of KDE or creating artwork for KDE. Klik is one possible solution for some common problems in the KDE development community. AFAICS Tcl/Tk and starkits are completely unrelated.
Starkits may have nice features but they solve a different problem.
How does starkits relate to C++ programs like KDE apps?