Submitted by “It’s the year 2006, and installing applications in GNU/Linux can still be a nightmare (especially if they are not available in your distribution’s repository). Simon Peter is the developer of Klik, a piece of software that tries to resolve this problem. Simon kindly accepted to answer a few questions for FSM.”
Note to self, work on apt://
Please don’t. IMO, one of the worst parts of Klik is that it uses it’s own pseudo protocol. There’s no real reason for that, since Klik doesn’t actually use it’s own protocol — it’s simply HTTP. One problem with this is that you have to add custom URL handlers to every web browser etc in order for them to understand klik URLs, and you can’t use standard tools like wget or curl to fetch klik files, and you can’t use other delivery methods like FTP, mail a klik file to a friend etc.
Things would have been a lot better if instead they’ed only created their own MIME type. IOW, something like http://myserver.com/someapp.klik instead of klik://someapp . MIME databases are a lot more centralized and easier to handle. It would mean that you could use standard tools to handle and process those files. It would also mean that the whole system wouldn’t depend on one central server. If you’re worried about security, you could restrict the client to only accept files from trusted servers. Better yet, require the files to be cryptographically signed with a trusted key.
So, apt:// == bad, application/x-apt == good.
Request denied. Their is an entire world of difference between a file and a protocol. Your requirements can be met with a simple file handler, excellent, you already have that capability, now consider why that’s not quite enough.
I understand that klik urls are secure because klik:// will always get the package from one site. But what if a site doesn’t use that url but just a regular, for insstance http://dangeroussite.com/coolprogram.klik
If you download it and put it on the Desktop will it run? In the interview he says that it will work if you take it form a usb stick so probably it will. Or do they use some kind of pgp signing?
If you download it and put it on the Desktop will it run? In the interview he says that it will work if you take it form a usb stick so probably it will. Or do they use some kind of pgp signing?
Yes, you could probably run a non-official Klik recipe. The wiki mentions they are looking at some sort of signing method, and are open to suggestions.
Klik wasn’t originally intended as a mainstream alternative package manager; I believe it was originally pushed as a way for non-developers to test alpha/cvs software without having to compile or risk de-stablizing their system.
There are two cool things I like about Klik: a) Doesn’t require root privileges, unlike every other package management solution, which aside from security, should do much to inherently protect your core system config and b) Mounts and runs in a virtual sandbox without bunging existing apps up (although when trying beta or alpha software, you may want to backup any local profile information in your home directory)
I’ve used it a few times, mostly for software that wasn’t in the repo or was alpha-quality and I didn’t want to have to risk stability problems. For instance, once in Suse I needed to use QCad but couldn’t find a Suse version and didn’t feel like compiling and installing and tracking down the necessary dependencies. Klik was able to build a package for me from .debs, pull down required dependencies (.debs again) and it ran flawlessly. Even with a tool like alien it would have been tricky installing .debs into Suse with the proper dependencies if I tried to do it from downloads with traditional package managent.
I don’t know that Klik will replace proper package-management, but then again who knows how it will evolve. It certainly has a place alongside standard package managers though.
So as to your original question about downloading potentially malicious packages, well, general rules of common sense apply, I think that at the end of the day if Klik becomes more widely adopted, there’s only so much they’ll be able to do to protect users. I don’t ultimately think it’s any different than adding untrusted third-party repos to obtain non-official packages.
so this app is able to rip apart other package formats to locate the files it needs and use that to create the app archive? color me impressed.
If this genius guy could solve this disadvantage of linux installation problems, then linux will be the model to follow in ease of use.
I like this “Klik is intentionally designed in a way that doesn’t “register” applications with the base system.”
because this means redesigning or re-engineering linux installation daunting routine.
I prefer apple approach rather than windows when solving this problem, i.e, take a folder drop it to a folder say /usr then run your application; and if you don’t want the application take the application folder to trash.
By the way, as we all know OSX is make on top of a unix base so why all linux distros didn’t attempt to mimic apple’s genius method of installation simplicity.
“I don’t ultimately think it’s any different than adding untrusted third-party repos to obtain non-official packages.”
Thanks for your explenation.
I think there is a difference, currently linux is save because you can’t mail someone a chmod +x file. (or download one), you always have to implicitely make it chmod +x yourself. Therefore users who don’t know anything about computers can’t run a virus. With klik it will be very easy, I can mail someone a klik package which will erase his homedir when he “kliks” on it. The difference with an extra repo is that only experience users will add an extra repo while unexperience users will have klik on their system without knowing it. I hope distro don’t have klik in the default install until they implemented signing.
“I think there is a difference, currently linux is save because you can’t mail someone a chmod +x file. (or download one), you always have to implicitely make it chmod +x yourself.”
Just mail them a .tgz containing the executable inside.
For another way to trick users into executing untrusted software, look at the start of klik’s homepage (http://klik.atekon.de/), where it tells you to type:
wget klik.atekon.de/client/install -O -|sh
Alternatives to klik may require you to state that you trust a GPG key before running the software, but how can users decide whether the author can be trusted?
For example, Zero Install (http://0install.net) consults a central database to see if the software is signed with a known key, but users can still override this if they want, and so far the only key database just states when and where a key was first announced; there is no warranty or statement that the key is actually trust-worthy (I guess you’d need to pay someone money if you wanted them to check).
I know that PowerPC Linux and Intel Linux can run most of the same software but need a recompile in between. Would it be possible to make a packager that would use an intermediate bytecode like LLVM and then statically compile it at install time without requiring all of the source?
its really not that hard to compile things on ubuntu.
download the package build-essential, which gives you the programming stuff to get started compiling things.
then just download a source tree and run ./configure from the command line from that directory. it will tell you whats missing, go and get that from synaptics. and run configure again, till it runs and says “run make”.
then just type make, and it will compile the program, and then you can run it.
They seem to have some pretty interesting ideas: http://klik.atekon.de/wiki/index.php/Klik2
Icons, .desktop integration etc is just the thing that is missing with klik. If they fix these problems, I’d gladly replace apt with klik. The whole repository business is great for corporations/servers, but for desktops the OSX .app-approach is clearly superior. Just think about it. All the time that distributors would save from not having to package thousands of applications every time they release a new version. How the entire “dist X doesn’t have mp3-support”-point would become moot, as installing kliks with this software would be extremely easy.
How ISV’s finally would have an easy way of making their apps run on multiple distros.
I really hope we will start to see this technology in mayor distributions soon!
> If they fix these problems, I’d gladly replace apt with klik.
Apt and klik are focused on two different things. Klik is focused on quick delivery of single packages that can be removed by just removing a single CMG file/directory and installed without admin privileges. There is no dependency management in Klik. If you have two apps that depend on GNOME, your two apps will package the all the GNOME libraries. This can lead to some pretty big downloads, but that’s the price you pay for not having to worry about dependency management. If you tried to build an enter OS out of Klik, you’d end up with something that was extremely bloated. Kanotix might support Klik natively, but APT-GET does most of the heavy lifting (as it should).
Apt OTOH is worried about package management. It downloads the minimum you need to run your software. If two apps depend on GNOME, GNOME is only downloaded once.
If use APT-GET for packages that are available with your distro and you’re willing to pay the price and only download from trustworthy sources, Klik is pretty good. Unlike Autopackage, i also doesn’t go messing with the system directory so deleting a CMG won’t mess up your system or updating your distro’s version of the app you’ve just installed with Klik won’t mess up your system.
Klik isn’t the only choice. On Debian or Ubuntu at least, there is a natively supported way for ISVs to package their software outside the main Debian/Ubuntu repositories. It’s called GDEBI:
. . http://www.whiprush.org/2005/11/gdebi_arrives.html
. . http://packages.debian.org/unstable/admin/gdebi
With GDEBI, you can double-click on a regular third party DEB file (e.g. most things already on sourceforge) and GDEBI will determine which dependencies are required and install those before installing your 3rd party DEBs. To uninstall your app, just use Synaptic or apt-get as you’d normally do to uninstall regular DEB files.
> All the time that distributors would save from not
> having to package thousands of applications every
> time they release a new version.
Actually, distros *want* to package these packages. It’s now they maintain quality control. GDEBI and Klik might be needed for some projects, but overall most packages will likely still come from your distro.
> How the entire “dist X doesn’t have
> mp3-support”-point would become moot
Actually this isn’t much of an issue for most modern distros. You just need to add the appropriate repositories and you’re good to go. The only thing Klik buys you is the ability to purchase legal MP3 support, but you could also do that with DEBs (through GDEBI), so this isn’t much of a gain.
Edited 2006-04-09 21:31
!!!
Anyone using “Klik” and “AutoPackage” (a multi-distribution binary packaging framework for Linux) regularly, or any other similar application can share it’s experiences here, please…
What are the ‘pros’ and ‘cons’of “Klik” and “AutoPackage”, problems of each one, comparisons etc…
!!!
Edited 2006-04-09 10:03
There’s a (possibly biased 😉 comparison of the features of Klik and Autopackage here:
http://0install.net/matrix.html
A proper review from someone who’s tried all the different systems would be very useful, though.
And here is the comparison from the klik point of view:
http://klik.atekon.de/wiki/index.php/Comparison