To view parent comment, click here.
To read all comments associated with this story, please click here.
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.
Well, you have another option (in addition to source, which ideally will be packaged by the distro maintainers): use on the many "standalone" installers available.
Personally, I think that Klik is a more interesting solution, however you *do* have to install the Klik client first (if it's not preinstalled on your distro).
Make klik ship in the top five distros on DistroWatch
That would be a good thing, yes.
and include a right-click option for "permanent install" (converts the klikapp to your system's package format, and installs it)
That would be much more difficult...remember that Klik pacakges (unless I'm mistaken) use static libraries, so it would be difficult to "convert" the Kliked apps into packages. That's why it's not there to replace package managers, but rather to offer a way to ship additional apps for Linux PCs that have the Klik client installed.
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.
Well, I wouldn't say it's completely different...Klik's cmg may be seen as a file, but it's really a compressed image that is mounted with cramfs, at which point it is treated as a folder.
Remember, in *nix everything is a file. A folder is a file, and a compressed image is a file that becomes a folder once mounted.
So, yeah, I wasn't being really accurate when I said it was "more or less" what they did in OSX, but I wasn't totally off either. The principle is the same, even though it's handled differently. I have to say I do prefer the Klik way, myself.






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.