Klik2 – a new Linux installer for the masses?

Tux
The klik development team has recently released a screencast of the currently developed software system klik2. While currently in development klik2 is supposed too solve quite some problems regarding software usage and Linux once it is released. And indeed the current available information are very promising.

The first test version of klik2 was released in August and introduced several important advantages over the current klik version 1. But the newest information do sound even better: klik2 will not any more build more or less upon Debian based systems but will run on any LSB system! This is very exciting since the LSB is the only real standard available today – and it totally makes sense to build upon.
Also it is now known that the client will be able to use non-modified rpm or deb files. There is no more need to patch anything which is certainly helpful. And as already mentioned the new mount system will not inherit the limitations of klik1 but will use a fuse based method to mount as many apps as the user likes.

There is also a screencast of the new klik2 available showing the new interface:

I must admit that I’m really looking forward to this new release. If everything works out and klik2 will be really strictly LSB dependent only and if klik2 will be able to run command line applications and other stuff without problems (think of server apps here) than it might be a realistic answer to the Linux software installation problem – that there is no easy way to install/provide software on Linux systems in general.

Of course I would prefer a system which could integrate with the local package management, but I’m afraid something like that is nothing more like a dream yet. I also must admit that I had/have quite some concerns regarding klik. The design and technology of klik1 is sub-optimal and is well described with “hackish”. Also, the developers sometimes have a bit too strong sense of mission. But if the klik2 client lives up to the promises these concerns might become history and it could become a real alternative. I might even start contributing packages/recipes.

About these ads

6 thoughts on “Klik2 – a new Linux installer for the masses?

  1. Klik is one of the options we have discussed before and you dismissed it then. I’m not sure why you would want it to be integrated with the package management system with the exception of updates which I’m sure would be easily extended on to them (so no real problem?), imagine though a system that would never complain of broken dependencies when you do an update!!!! The thing I don’t understand is how/why debs and rpm’s fit in to this – Scenario: you have just created your revolutionary new application and you want it to be independent of distribution so you want it to be run from a klik file, do you have to create a deb/rpm then you have to create a package repository on the web and then you have to create a klik from the deb/rpm file that you have just created, why can’t you just create a klik from source and cut out the complication? What used to happen was that the Klik was created on the fly after the deb’s were downloaded from multiple locations but the trouble was if the deb’s needed to come from multiple locations then if any of those locations were down then you couldn’t have the app! Surely downloading a single file would be much better then if the deb’s were ever madealtered in a recipe incompatible way it wouldn’t matter as you could still only had to get the Klik that was premade and tested as working.

  2. Dave Taylor:
    The integration with the package management system would enable klik to become dependency aware and use the dependencies available on the system.
    In the current form klik2 will only depend on the LSB dependencies and nothing else – of course an update would be easier in this way but the necessary files have to be statically linked in afaik. That’s not a good idea security-wise.

    And: integration with native package management does not mean to provide debs or rpms – imagine a system where you could simply register the files with the native package management. Imagine the klik2 file could tell the rpm/deb database: “I have these files available” or, and that’s the interesting point “I need these libraries, please take care of it”.
    But such a situation is unlikely at the moment, and from that point of view klik2 (not klik1) will be a very good solution.

    But about the question where the deb/rpm files come in (I’m not sure if I get your point/question here, correct me if I’m wrong): klik2 will not be a binary format but still a recipe. So you need a binary to create the klik package from.

  3. The point of Klik is that it wont need to be dependency aware as it is self contained. This way you can have as many versions of a library as is needed so you’ll never see any unresolved dependencies (at the increasingly less important expense of some disk space). Package management would then be of no use (except keeping the LSB files updated and possibly server related applications as I’m not sure how they intend Klik2 to interact with upstart/init).

    My point about deb/rpm is flexibility, of course at the moment making Klik files from deb/rpm files in invaluable because they are widely available and converting all of Linux’s software catalogue will be very easy but would it be possible to make a Klik from the binary files that the source makes otherwise if some one wanted to make his application available as a Klik2 file then they would have to create deb’s/rpm’s then would have to create a recipe which seems like a lot of unnecessary work where inadvertent errors could be made just to package binaries that you already have.

  4. Dave, you’re right, klik packages have everything what they need inside. But that also means that you have to update the package as soon as one single part of it has a security problem. Given that you would have several packages with the one component inside you would have to update quite a lot of packages. That’s the advantage of dependencies, in that case you only have to update one thing.

    But the same problem is true for LSB-RPMs, so again: klik2 seems (from my point of view) a sub-optimal solution, but it seems to be the best one.

    And about the binary thing: it is definitely an extra step which is unnecessary, but if klik2 becomes more wide spread this issue might be solved in the next klik version.

  5. Wow, I didn’t even consider the one beauty that today’s package management delivers. Not just automatic updating but the fact that the seperation means that only one file needs to be updated rather than multiple instances of one. I guess absolute control will always be complicated, but for sakes of ease of use Klik2 wins.

  6. I did agree with you right from the beginning. Let’s hope that klik2 will be there quite soon – and will deliver everything which was promised.

Comments are closed.