Submitted by “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.”
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.
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.
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.
A much more interesting complement to apt than CNR. Works great and “installs” quickly on many distros and Live-CDs.
I agree, I’d rather see this in upcoming Ubuntu releases than CNR.
I agree, I’d rather see this in upcoming Ubuntu releases than CNR.
Why the binary condition (i.e. “rather than”)? You can already install it on (K)Ubuntu, so you can have *both* CNR and Klik on your Ubuntu system.
That’s the beauty of the Linux model: there are many ways to accomplish the same task, so you can pick the one that suits you best.
A much more interesting complement to apt than CNR.
Why? CNR on Ubuntu should be vastly more seamless than Klik could ever be, because CNR is a frontend for Ubuntu’s APT repositories, whereas Klik doesn’t know anything about how to make a package integrate nicely on Ubuntu (i.e. place its launcher in the right section of the Applications menu).
If by “interesting” you mean “less likely to work well,” then I agree.
I know next to nothing about klik, but from what I understand KDE and QT and whatnot are being ported to Windows. Anyone know how that effects klik? Drag and drop apps on Windows would rock.
Anyone know how that effects klik?
emmmmm, it “might” work, but then, the apps would not.
the apps would have to be ported as well as klik itself.
That’s a very interesting question. Right now the Wiki state they are completely incompatible with Windows, but once the KDE and QT libs are ported…who knows!
Edit: Hmm, raver31 pretty much answered the question.
Edited 2007-02-14 20:45
You would need cramfs support in Windows first.
Before recommending Klik as “the next big thing” replacing deb and rpm please read the User’s FAQ at
http://klik.atekon.de/wiki/
Edited so the link works
Edited 2007-02-14 20:36
I’ve used Klik before when I want to test applications, particularly development versions that might break my existing apps if I tried to install alongside. I’ve also used it when I need a quick shot app for a specific function or requirement that isn’t included in my distro.
I like the fact that it enables apps to be installed with regular user permissions, I like the fact that it doesn’t break anything, and it does a pretty good job of mapping dependencies for Suse despite using debian-based packages and naming conventions.
But I also like shared libraries, and I like a centralized update infrastructure. I find Klik convenient but I personally wouldn’t want to rely on it as a permanent package delivery mechanism.
I realize the developers’ goal is not to supplant existing package management methods etc., but I can’t help thinking there’s more potential here if they opened up the server side piece and encouraged active community/distro involvement.
I don’t think it would be incredibly difficult to integrate klik as a front-end package delivery mechanism still integrated with local package management to ensure that system library dependencies are met, and provide for centralized updating of everything. Or something along those lines anyways. I’m not entirely sure I would use it myself, but I can definitely see an advantage for newer/novice users and it need not be a workaround to existing infrastructures.
But none of that will happen unless the project is opened up; distro maintainers may take the hint and develop something similar (or work via CNR), but it would be nice to see something like .cmg works as a quasi-universal format that integrates natively. I don’t think it would be an awful lot of work to do, and wouldn’t require the same degree of wheel re-invention some other approaches propose.
Anyways, just my 2c…
The klik client is GPLed. It should be a pretty trivial exercise to adapt it in a way that it will first look for a certain application on a distro specific server before going for the distro agnostic version.
It could be an effective way to run a distro. Use the LSB as base system. It offers the shared libraries and the GNOME and KDE frameworks. Then install every single application as a klik package.
Advantages:
-Much easier package management. If you install a new application you no longer install 385 supporting libraries for all eternity (because due to metapackages and naming conventions you’ll never know which libs you actually need).
-Probably others, but the first one is pretty big so I don’t want to water it down.
Problems:
-Performance? How much slower are cramfs or FUSE compared to having a distro where you put every application in its own directory?
-Dependencies. The LSB may be a starting point but there may be half a dozen apps using libsdfwerkr (a database backend) or libliblib (a backend lib for easier integration of other libs). If each app provides its own copy it eases handling but it defeats the shared library approach. The question is where to draw the line.
Didn’t gobolinux do it this way just with dirs instead of images?
Funny that we had a bad review of Autopackage yesterday and today we have a good review of Klik. What makes Klik better aside from the fact that Klik is still alive?
The klik developers don’t hate Linux? Not that the autopackage devs really do, but they rubbed a lot of people the wrong way, criticizing fundamental parts of how Linux works. Right or wrong, they alienated a lot of people, which removed some opportunities they might have had. Basically, klik does what it does without telling Linux and upstream devs to change how they do things. That’s how it looks to me, though I’m not involved with either, so someone could correct me if I’m off.
The autopackage devs tried to challenge the existing ecosystem and failed. Klik plays by the rules already laid out by the distro community.
I think this is a bad sign because the distro community needs to deal with constant change not just have it the same way as it has been for many years.
The autopackage devs tried to challenge the existing ecosystem and failed. Klik plays by the rules already laid out by the distro community.
Well, to be fair the two approaches are completely different. Autopackage was an alternate way to install programs on Linux, while Klik lets you run apps without installing them (apps being a single, self-contained file on your Linux PC).
I think this is a bad sign because the distro community needs to deal with constant change not just have it the same way as it has been for many years.
I’m not sure I understand your argument here…the current ecosystem is there for a reason: for better or worse, it works. It hasn’t been designed, it has evolved…you just don’t try to change it overnight!
Package managers serve their purpose…standalone installers serve their purpose…and so does Klik! That’s the beauty of the open-source model: all of these methods coexist, so you can use the appropriate one (or the one you prefer) for the task at hand.
nice to see klik is still “clicking” along. The niche I’ve often thought Klik can fill is for the one or two programs you really want to work but your stuck in dependency hell, or it just won’t install right, you know there’s a solution but it keeps eluding you.
I tried it many times before and it did not work for me on Ubuntu.
but its pretty good idea.
Did you follow the instructions on the Klik Wiki?
I installed it last night and it worked flawlessly the first time, though admittedly I only installed a simple program to test it (xmountains).
Tonight I’m going to try a large, complex program (Jahshaka, a video editing app) to see how well that works…
The klik folks are just more pragmatic about their role than the autopackage guys.
They may not “hate” Linux, but they certainly agree what’s broken about it:
http://klik.atekon.de/wiki/index.php/ABI_insanity
Note the autopackage link right at the top!