Not only has IRC channel #klik on Freenode.net seen quite some influx in recent days. We now also run two new mailing lists hosted by KDE, both related to klik. Dirk was so nice to create them on very short notice for us:
- klik@kde.org is meant for end-user support; subscribe here: https://mail.kde.org/mailman/listinfo/klik
- klik-devel@kde.org is for discussions about future innovations for klik; subscribe here: https://mail.kde.org/mailman/listinfo/klik-devel
Here the description of the (user-oriented) klik@kde.org list:
-
klik is an innovative approach to (and a new implementation of) the old idea to make software runnable, "installed", by just copying it over to a system.The concept of "AppDir" bundles is realizing that idea for Mac OS X (and did so already in NeXT), where everything an application needs is supplied in the application's self-contained sub-directory.
What klik adds to this idea is to melt the AppDir into a compressed zisofs or cramfs file system image. Result: instead of "1 program == 1 AppDir directory" klik advanced to a "1 program == 1 file" paradigm.
Another innovative approach of klik is to just supply few-kiloByte sized "recipes" to klik clients requesting a certain software re-packaged into an AppDir compressed filesystem image, and letting the client himself automatically fetch the correct binary files (.rpm, .deb, .tar.gz packages) from distro and third party repositories and create his own bundle.
This makes klik very scalable, and the klik server will not be overloaded by the need to distribute complete multi-MegaByte sized binary bundles.
Currently klik bundles need to be "mounted" with the help of the "loop" device, and the mountpoints need to be pre-defined once (by the root user) in /etc/fstab. In the future, we hope that the FUSE (Filesystem in UserSpacE) extension of the 2.6.14 Kernel, can help to remove these (and more) limitations which currently still hinder klik's full blossoming.
This list is for end user questions and discussions of the current klik technology, its supplied bundles, and the "recipes" it uses. It is for feedback of users having problems getting certain klik bundles to run, or wanting to relate their own klik success stories to the user community. It is *not* to discuss development issues of the current klik implementation or design suggestions for a future klik2 design: for development discussions please join the list "klik-devel@kde.org" at https://mail.kde.org/mailman/listinfo/klik-devel.
Here the description of the (developer-oriented) klik-devel@kde.org list:
-
1. This list is mainly meant for *development* discussions of current klik technology and all discussions around "klik2" (hey, this is just the working title for now), the next generation of klik. It is meant for people who intend to contribute code and ideas to klik2. Also, it is the forum of people who are maintainers of current klik recipes, and who exchange ideas with co-maintainers of other packages or with the klik developers.
2. This list is *NOT* for end user questions and discussions around the current klik technology, its supplied bundles, and the "recipes" it uses. For the "end user support list" of klik, subscribe to "klik@kde.org" at https://mail.kde.org/mailman/listinfo/klik.
A few words about KDE + klik + other environments:
- The klik-devel@kde.org and the klik@kde.org lists are (obviously) hosted by KDE and we are grateful for that.
- It is true, klik originally started into its (so far short) live as the "KDE-based Live Installer for Knoppix+Kanotix".
- It is also true, that klik originally supported mainly KDE apps being klik-ified because KDE uses no absolute paths and its applications are more easily relocatable.
- But klik in the meantime has outgrown this initial scope.
- There are now a lot of non-KDE programs working well with klik.
- There is a growing number of Gnome apps which are in the klik server's repository.
- The "fake" URL of "klik://name-of-app" now works also with Firefox, Mozilla and even elinks (!!).
- klik is not an "only KDE apps"-supporting project, but open to all.
Syndicate Blogs
*BSD?
Is support for *BSD (FreeBSD or PC-BSD in paticular) planned? That would be cool.
Support for FreeBSD?
Yes.
There were 2 people in channel #klik in the last couple of days who are interested to work on FreeBSD support for klik-ified application packages.
Come and join #klik to find out more.
mount problem
You state that "Currently klik bundles need to be "mounted" with the help of the "loop" device, and the mountpoints need to be pre-defined once (by the root user) in /etc/fstab.". So what needs to be mounted where? I'm getting the error message: "unable to mount /tmp/app/1". I guess this has something to do with what you mean. How can I solve the problem?
Cheers
mount problem
To allow a user to mount a .cmg image, the Kernel needs be enabled with the "loop" device (either compiled in, or as a loadable module). Also, cramfs needs to be one of the supported file systems.
Try
ls -l /dev/loop*to check for the presence of loop devices.
Try
lsmod|grep loopto see if the loop module is loaded in your case.
Try
cat /proc/filesystems |grep cramfsto check for cramfs support.
Most of the popular Distros have these utilities available by default. Gentoo users often need to compile a new Kernel, or at least the additional module.
re-locatable
How does klik deal with KDE plugins? They aren't relocatable at least not easily (meaning, I don't know how
). Like because of the sound engines, amaroK has to be installed into the same prefix as KDE itself.
Edit: Well, running the Krita .cmg I see it runs kbuildsycoca. I suppose this adds a new kdedir which would allow plugins to be used outside of the KDE prefix?
klik+ relocateable KDE plugins?
eean,
sorry, I do not know the answer (yet).
Being not a coder myself, this kind of topic certainly isn't part of my home turf. I am engaging on the klik front precisely because we (the non-techie contributors to KDE) need an easier way to access bleeding edge code that *runs*, and because we have not been supported by the coding contributors very well so far.
Having said that, I probably will find out soon. Currently I am building a KDE 3.3 environment (which also includes older glib, gcc and what-not), so that I later can build KDE 3.5 applications inside that environment in the hope that the resulting klik-able *.cmg images will be more widely usable.
Help and advice is welcome.