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 one huge difference between zero install and klik. Klik is dead simple to install. Zero install needs a kernel module and a bunch of other garbage, klik is one command. I've always wanted to try zero install but the install is too much hassle. Klik rocks!
If you don't like 0install you can try Injector (http://0install.net/injector.html) from the same author as 0install.
Bye
Piero
i like the zero install concept tooo !
i hope it will be integrated with FUSE , if it goes in 2.6.14
and i hope too , that one system will be selected , not that we have 10 new , zero install systems ....
i would like to have one where i could install the complete kde 4 svn , to start developing right away....
like klik:/kde4svn , oder 0install klick on kde4svn.--
klick on kdevelop , new project -> open directory where you want to kontribute , and start coding ....
ch
Heh, why stop there??!!
What you really need is something along the lines of:
'klik:/code_cool_new_kde4_feature_and_call_it_my_own_and_make_patch_and_email_to_kde_core_devel_and_collect_fame_and_glory'
Now, _THAT'D_ be a really useful app...!
The old version of Zero Install needed a kernel module and a daemon process loaded at startup. The new version requires neither; it's pure Python and you don't even need to be root to install it (unlike Klik). Tarballs and packages are here:
http://0install.net/injector.html
Please give it a go if you found the previous version too difficult, as we've made it a lot easier now.
Ah.. Thank's for the heads up! I will definitely try it out now.. As so often, one tries some software, forms an opinion, and then neglects to try the newer versions.
Now if only more kde stuff was available under it :-) I tried it,
it looks to work very smoothly.
If I got it right, when clicking on a lick link, you will download the apps, and it will be saved in your desktop and you will be able to run it without installing, right?
If that's the case, it's a good idea to integrate a p2p network on it, such as bittorrent, so that once it's popular, the servers aren't down because of too much people downloading, or you start getting problems of connection. It would be nive to kind of force people using p2p in this case.
The idea is good. But I don't get why you need to mount an image to run an app, it could work just as well with a normal directory, say a MyApp.app directory which would be automatically recognized as an application, and no overhead of mounting an image file.
Having AppDir support in KDE would be nice, actually I have asked for it quite some time ago on http://bugs.kde.org/show_bug.cgi?id=81772
Having said this, cmg still has some advantages over AppDirs:
* You can simply e-mail a file, but not a folder.
* A cmg file is compressed, thus saving ~50% disk space.
Btw, a cmg file is nothing but an AppDir packaged in a cramfs file.
You can easily unpack it with /sbin/cramfsck -x which gives you a ROX-compliant AppDir.
when you look at the autopackage vision, the "vision" is almost the same, the implementation was bullied by several persons. Klik makes only sense when it is available and working on all major distributions.
http://autopackage.org/ui-vision.html
friend Kurt Pfeifle, you have really made some good point. klik is the answer to the Linux Package Hell!!! Linux Standard Base must include klik for package management. (we need to improve klik for Global and local (user) software installation).
Also if klik could do installation from source like in BSD then it would be the standard package management tool for GNU/Linux OS! Thank you.
I'm tired of running kdesvn-build to get one or more errors to beta test kde 3.5.
it takes around 2 days to compile the whole KDE 3.5 svn, and most of the time kdenetwork, kdelibs, kdebase, or extragear stuff get errors.
Now, with klik life of kde users like me who would like to test and enjoy latest kde 3.5 (or kde 4.x) would become easy.
Please consider klik://kde_3.5_latest, so that it becomes easier.
non-kde packages get installed in slackware nicely.
ktorrent shows libqt-mt.so.3 is not found. (but i have my custom compiled qt-copy with kde 3.5svn).
libqt-mt.so.3 error should be fixed.
with kde 3.4.1 and qt 3.3.4 of klax, ktorrent works file with klik. I love klik :)
Can you imagine that this is what I'm doing on windows since, what?, 10 years. The installation of application under Linux is probably the only thing that refrains me from using it. I really wish success for that king of approch.
You must have a secret version of Windows... ;-) Mine puts stuff everywhere in random locations and a monster file called the "registry" - everything gets intermingled so that you can't take an installed application and move it over to another computer.
Witk klik, every application is one single file that you can easily move, mail, or delete.
But this sounds like the autopackage vision. So I hope klik is not KDE-only
### "Can you imagine that this is what I'm doing on windows"
----
Honestly, I can't.
Have you got a URL/link? Where can I get and test this Wonder Windows? I want to buy a license (rather, let my boss buy one), even if it is double as expensive to the ones MS sold us so far.
*Our* Windows doesn't follow the simple "1 file == 1 application" principle that klik implements. Our Windows cannot remove any application by removing just 1 file. Our Windows does not allow us to copy 1 file to a different Windows computer and then have the application run there. Our Windows does not allow us to mail the application (remember, 1 file!) to a friend so he can run it. Our Windows does ask for money for most applications we want to install on top of it. Our Windows does not give us the freedom to modify most of the applications that are installed on it. Our Windows has an "installer" that writes many, many files to multiple places when installing an application, and a fat "Registry" with many secret keys that keeps growing with each installation as well as with each de-installation.
Our Windows is too dumb for klik.
Our Windows does not have anything that even comes close to klik.
Okay,
but could you update us on registry issues. It was considered to use Elektra as a KDE4 registry. The common consensus was: not a registry is bad per se, but win reguistry is a pain.
What's the difference between klik and the autopackage vision?
autopackage does an install. klik does not.
> Our Windows does not allow us to copy 1 file to a different Windows computer
> and then have the application run there. Our Windows does not allow us to
> mail the application (remember, 1 file!) to a friend so he can run it.
Actually it does! That file is called a "worm" and it is exactly why klik will never be installed in my Linux workstations.
Really, people, are we still trying to let end-users execute applications from e-mail messages or floppies/flashcards coming by untrusted PCs???? No lessons taken from YEARS of viruses, worms and trojans? Very, very sad...
By me
Do not take my post too "seriously". When I am saying on windows it's easy to install an application, I mean how to get the application, and how to install it.
What the installer is doing behind you back and what it is necessarely to be able to run the fresh installed app is one another thing. This too often brings problems. I agree with you.
Having said this, it is possible to write good applications on win. I'm using Python and wxPython for coding, I create exe with py2exe and eventually, but not necessarely, a setup.exe with Inno Setup. Once installed, all the files are in a directory (the app + Python + wxPython lib). No entries in the registry. The application can be removed just by deleting the dir containing the app. If the app has been installed with a tool like InnoSetup, the app can be removed with the windows add/remove win utility.
My (GPLed) applications are available in two forms, as Python scripts and as exe. Believe me or not, the exe's are more downloaded than the script versions.
I'm still convinced, what an end user wishes is something that it easy to install. They do not care if the libs are statically linked (as explained above) or dynamically linked.
BTW, wxPython is the kind of app, I *never* succeed to install on any Linux distro. Of course, it is doable. But this is simply too much for me. On windows,
I install it with wxPython-setup.exe :-).
You see, I really wish a brilliant success for you klik installer. I think this is the way to go.
Just a question at the end, what do you think about the "pbi way " of the PCBSD project?
Regards
"BTW, wxPython is the kind of app, I *never* succeed to install on any Linux distro. Of course, it is doable. But this is simply too much for me. On windows,
I install it with wxPython-setup.exe :-)."
Have you tried Gentoo? "emerge wxpython" does the trick.
/ceel
>Once installed, all the files are in a directory (the app + Python + wxPython >lib). No entries in the registry. The application can be removed just by deleting >the dir containing the app. If the app has been installed with a tool like >InnoSetup, the app can be removed with the windows add/remove win utility.
...can you do the same things with MS Office? I'm wotking with kliked ooo2....
Thank you... *sigh* I think I'm going to cry...
Are the repositories x86 specific? If I'm on an amd64 system, can I reasonably except many of the links to work? I'm assuming that a 64bit cmg file would work fine once compiled into the cmg, however I cannot tell what architecture the cmg file contains at first glance...
Currently it's all x86, but there is no limitation in the architecture that would prevent us from doing the same for 64bit as well. One could even think of "universal binary" cmg files that would run natively on both architectures, just like Apple does now.
I didn't even think about that.. I'm running Suse 10 RC1 for amd64 and so far all the klik packages work awesome. So at least Suse10 has no issues running the i386 klik cmgs on an amd64 OS.
Unlike Mac OSX, you have to use specific protocol klik://
which checks for libs on your computer and creates files.
I might be wrong, though.
Since I cant go on internet in Linux it is useless for me.
But if someone finds this great, then well... great.
the klik:// protocol is only for when you do not already have a .cmg file -- anyone can post a cmg file on their website and it can process over http, etc.
And how can you get cmg file?
USB, cdrom, automatically from repository, download by hand, you name it...
If Linux is "useless" for you, what are you doing here? And if you can't get on the net, how can you post here?
>If Linux is "useless" for you, what are you doing here?
"...Since I cant go on internet in Linux _it_ is useless for me."
I didnt' say Linux is useless for me.
>And if you can't get on the net, how can you post here?
Not all people connect on the internet from Linux.
If I can download package from windows, please someone
post link to the web page. For example Firefox package on klik site.
(When it gets back.)
http://opensuse.linux.co.nz/klik/10.0/firefox_1.6a1.cmg
Thanks.
If you don't support Slackware and other popular distros like fedora core, Mandriva, then you are doing great unjustice to them.
You have added support for OpenSUSE, why? Is openSuSe a debian based distro? I guess not.
btw, many applications work with slackware, so you can (and you must) support non-debian distro alike.
when installing some software, klik can get libraries from slackware ftp mirrors.
Also how do I make a .cmg file for say slackware (i would compile with ./configure --enable-static) so that it would work on other systems too?
### If you don't support Slackware and other popular distros like
### fedora core, Mandriva, then you are doing great unjustice to them.
.......
Dude -- this is Free Software. This doesn't mean it grows on trees, just hanging there for you to harvest. Creating Free Software also involves hard work before it can be shipped to your convenience. And have you ever thought that the developers can only start with support for those systems they run themselves? Have you ever thought, that a student developer may not own dozens of boxen, running dozen of distros, in dozen of sub-versions, and has the time to maintain them all?
Dude -- this is Free Software. This means *also* that the developers are free to do what *they* like. -- Who are you to play the guy trying to boss them around? Who are you to be so impolite and demanding things from developers who are working on this in their own time, on their own money??
Dude -- this is Free Software. This means *also* that *you* are free to add what is missing for *your* needs. Or pay someone to add it for you, if you lack the skills yourself. And if you can't do it, can't pay for it, be at least polite. This very often helps, and you *may* still get it in the end...
Dude -- you're an obnoxious, impolite egoist polluting this forum. Go away.
----------------
### You have added support for OpenSUSE, why? Is openSuSe a debian
### based distro? I guess not.
So?
Dude -- if you were a bit intelligent, you'd have discovered that openSUSE support was added only recently. You would see this as a sign of klik development now going into its next stage, starting to support non .deb based distros. You would be thankful for that, and celebrate it. You would probably apply a bit of politeness to your question about when one could expect support for even more non .deb based distros.
-----------------
### so you can (and you must) support non-debian distro alike.
Dude -- the developers "must" nothing. Not even when an impolite non-Gentleman calling himself fast_rizwaan starts demanding things.
Calm down.. He was just asking.
But yes, it's probably a manpower issue, not an idealogical one.
funny, that you got annoyed by my opinion.
klik is a nice concept (and a reality now), and it MUST be available to all GNU/Linux distros, klik can bring ease of use to all GNU/Linux users! that's why it is a MUST!!!
I can help create .cmg but there's no howto for that!
>Dude -- you're an obnoxious, impolite egoist polluting this forum. Go away.
You (ac) are welcoming, polite, humble, cleaning this forum . welcome to KDE ;)
and you know opposite attracts ;)
We'll try our best... please come to #klik on irc.freenode.net if you would like to help (testing).
The klik seems very similar to WebStart, insn´t it ?
Really - what we dont need is another Windows-Thingy.
All those thoughtless users that install anything they can do with a single click is the real problem of Windows itself.
Be i paranoid? I mount all my rw-partitions with noexec (and would even disallow source script.sh but dont know how for myself at my own box).
Reason: all the buffer overruns discovered in the last months.
It is just a matter of time that a virus is distributed that erases your home-partion, with a single klick...
Thats why i say: those apps should be run in a sandbox with read-only-rights at least.
klik operates under the rights of the local user, unlike rpm and apt which require root. klik does nothing that wouldn't be possible without it - every time you install software from the web you run the same risk. And remember, klik:// doesn't run stuff from random places, an attacker cannot set up his own klik:// links. That being said, I am open for improvement suggestions.
> klik operates under the rights of the local user,
Which is already enough to destroy valuable data or to create an email worm that works by tricking the user into executing it. There are many examples of this in the Windows world. And the more non-geek users the Linux desktop gets the easier this will be.
> klik does nothing that wouldn't be possible without it - every time you
> install software from the web you run the same risk.
I agree. But klik makes it easier to shoot oneself in the foot. :)
That's the downside of being user-friendly.
> That being said, I am open for improvement suggestions.
I think (embedded?) gpg signatures for the images and a configurable list of trusted keys would be a good idea. That way for example a translator would be able to define "I trust klik images from " but no one else's.
Klik and HotNewStuff (amarok uses this feature for downloading of Python scripts already, for example) are places where it's appropriate to be extra paranoid, IMHO.
I agree that the fact that the download location for this stuff is restricted already helps a lot. But signing of the packages would add an indicator that packages have been tampered with, should the download server ever be compromised (which happened to the Debian project at least once), or if the images are distributed by Email or other means. Of course this would only help if the images are signed offline by the author and in their final state. This could be a problem when the images are created on-the-fly, I guess.
>> klik does nothing that wouldn't be possible without it - every time you
>> install software from the web you run the same risk.
> I agree. But klik makes it easier to shoot oneself in the foot. :)
> That's the downside of being user-friendly.
...so we use complicate installation/run method, so we got reduced security risk...
it would be really good to be able to run a klik program as nobody
Is there a way to make klik work on Debian stable (sarge)? This would be The Thing for stable on the desktop; just klik-install bleeding edge desktop stuff, and remove it if it breaks things, while the core system remains rock solid. But if it depends on new stuff in ubuntu etc, then it won't work...
Anyway, how does klik handle the dependency issue? Does every app include its libraries? Or is there a predefined set of versions which klikified apps are compiled against?
The problem with debian is that you can never know what is in the "base system". That is why klik officially supports only debian-derived distributions, where the set of packages that come with the "base system" is known.
But of course, there is nothing in klik that prevents it from being used on sarge. You just have to make sure that you have a reasonable set of base system libraries installed (easy with apt-get).
The problem with debian is that you can never know what is in the "base system".
???
All the packages with priority = base?
Could you please elaborate on this? O was I punk'd?