"Klik is unique among software installation systems for Linux, in that each package installed through klik is self-contained, isolated from the rest of the operating system. Klik isn't a package management system; rather it's an application that lets you download and run software without installing it."
To read all comments associated with this story, please click here.
Member since:2005-07-02
a) Isin't that more or less what OSX does with foo.app?
Yes.
b) Why don't we have this built into more distros?
Some distros (such as Kanotix) have Klik pre-installed, but it's trivial to install the Klik client on other distros. From the Klik Wiki FAQ:
What do I need to use klik?
A Linux distribution with the klik client pre-installed. Or one where you install the klik-client on your own.
Are there other requirements?
Yes. Your Kernel must support the "cramfs" file system. Your /etc/fstab needs entries which allow users without root privileges to loopmount cramfs image files.
klik also expects some other utilities to be present:
* one of Xdialog, kdialog or zenity
* rpm2cpio (part of package "rpm") [missing f.e. on Arch Linux - install rpmunpack, and symlink it to rpm2cpio - and not installed by default on (K)Ubuntu and Freespire
* wget
* bunzip2
* ar (part of binutils package)
* the libstdc++5 or the appropriate compatibility library
klik checks for the presence of these tools and gives a warning if they are not installed. These tools come with your distribution (base system). Please install them using your distribution's tools.
For best klik experience you should have KDE 3.3+ libs installed (our klik-able KDE apps don't include the kdelibs).
Note that Klik is *not* a replacement for package managers - this is stated clearly on their Wiki. Rather, it can be used in addition to your distro's package manager.
Member since:2006-11-02
I know it's not a full blown package manager. That's what makes it so nice. Right now, if you want to make an app for Linux that's not going to be in the repos of major distros, you have two choices.
1) Source only. While this may work for some people, building source is still a tedious affair. Not to mention you have to have the correct libraries (the -dev versions of course), and whatnot. Not something most humans want to do often. And, it is simply not an option for commercial apps.
2) Make packages beforehand. Okay. Sounds nice, until you notice you have to build RPMs to run on RH, SuSE, and Mandriva, DEBs to run on Ubuntu, Debian, Linspire, and TGZs for those pesky Slackware people. And then you have to test it on every distro because they all have their own versions of the libraries, FS structure, etc. This can be really time consuming unless you are a big operation like IBM, Google Microsoft, etc.
So now we have klik. It's a disk image that you can double-click and run regardless of what distro you're on. Make klik ship in the top five distros on DistroWatch, and include a right-click option for "permanent install" (converts the klikapp to your system's package format, and installs it) and shipping an app to Linux suddenly looks much more viable.
Member since:2005-07-07
a) Isin't that more or less what OSX does with foo.app?
Yes.
No!
Approach is completely different.
On Apple .app is a folder not file. On klik it is really just one file.
Apple just hides everything under .app and shows it as it would be one file only (if you don't believe just start terminal and go into app folder your self), while klik mounts application file as loop device on execution and then executes contents.
Apple approach has been used in ROX for ages.
p.s. I'm not sayng that Apple approach is bad, it is just not possible on linux. There is just too many different vfs-fm approaches and one can't expect that every last one would support it. Klik goes around that, because it provides common execution and also provides support for a lot of fm out there.
Member since:
2006-11-02
If I'm understanding this right, klik lets you run a single file, that contains everything needed to run the app?
a) Isin't that more or less what OSX does with foo.app?
b) Why don't we have this built into more distros? This would make distributing 3rd party apps (both closed and open) much easier on both ends.