[dot] klik: "Don't Install, Just Copy"
Dot Stories
stories at kdenews.org
Fri Sep 16 12:58:36 CEST 2005
URL: http://dot.kde.org/1126867980/
From: Kurt Pfeifle <pfeifle at kde.org>
Dept: knoppix-to-opensuse
Date: Friday 16/Sep/2005, @05:53
klik: "Don't Install, Just Copy"
==========================================
Klik [http://klik.atekon.de/] is a system which creates
self-contained packages of programmes installable over the web with a
single click. In the article below Kurt Pfeifle
[http://www.kdedevelopers.org/blog/418] 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 [http://conference2005.kde.org/] 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 [http://www.nomachine.com/] or FreeNX
[http://freenx.berlios.de/] 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
[http://www.openSUSE.org/] 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.
[http://klik.atekon.de/]
It works on most Debian systems, and on Knoppix (torrent
[http://debian.tu-bs.de/mirror/kanotix/KANOTIX-2005-03/KANOTIX-2005-03-LITE.iso.torrent])
and Kanotix (torrent
[http://www.solidz.com/torrents/knoppix/KNOPPIX_V3.9-2005-05-27-EN.torrent])
Live CDs.openSUSE/SUSE-10.0 [http://www.openSUSE.org/] 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
[http://klik.artekon.de/] store.
You could also just type klik://xvier [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.
[http://klik.atekon.de/scribus.recipe.example]
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"
[http://opensuse.linux.co.nz/klik/10.0/] repository is filling up by the
day. Warning: currently this will only work for openSUSE/SUSE Linux 10.0
[http://www.opensuse.org/], 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 [klik://apollon] (downloads 2.2 MByte)
* klik://firefox [klik://firefox] (downloads 10.0 MByte)
* klik://skype [klik://skype] (downloads 10.2 MByte)
* klik://frozen-bubble [klik://frozen-bubble] (downloads 14.0 MByte)
* klik://ooo2 [klik://ooo2] (downloads 114 MByte) - Martijn
[http://www.kdedevelopers.org/blog/1192] can use this to read .odt
files easily!
I found the ooo2 bundle
[http://opensuse.linux.co.nz/klik/10.0/ooo2_1.9.125-novell.cmg]
(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.
[http://www.opensuse.org/Download#Development_Build]
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
[http://www.kde-apps.org/content/show.php?content=26353] 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 [klik://thunderbird] -- the Beta 1 of upcoming
Thunderbird 1.5, the Mozilla mail client (klik bundle
[http://opensuse.linux.co.nz/klik/10.0/thunderbird_1.5b1.cmg],
direct link)
* klik://sunbird [klik://sunbird] -- Development version of Mozilla
calendar application (klik bundle
[http://opensuse.linux.co.nz/klik/10.0/sunbird_0.2+.cmg], 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
[http://www.valdyas.org/fading/index.cgi/hacking/krita/] 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 [http://kpdf.kde.org/], KWord [http://www.koffice.org/kword/],
amaroK [http://amarok.kde.org/], Quanta [http://quanta.kdewebdev.org/]
and Kommander [http://kommander.kdewebdev.org/] 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
[http://www.openusability.org/]? Would they appreciate such a service
too? Have they ever looked at the added value klik:// [klik://] can
offer to our common development workflow?
More information about the dot-stories
mailing list