Point-and-klik Linux Software Installation?

bfree writes "While you may have come across klik before, you might not be aware of some of the major changes which have been taking place over the last few months. If you visit the old klik site you will see a link to the Next Generation klik, which aims to provide a web interface to install the entire collection of Debian packages, letting you grab any package from sid (and its dependencies) and 'install' it into its own location, similar to the system outlined in this recent slashdot story." See below for more on klik.

bfree continues: This is not the only change in klik recently however, now applications are built into compressed image (cmg) files rather then stored as application directories. This means that you can store the application on any filesystem and move it around at will. Klik no longer totally depends on kde. Where previously klik could only be used with konqueror, now you can also use firefox and elinks, and where previously kdialog was required, now any of dialog|Xdialog|kdialog should work.

Klik now also supports more distributions fully. The officially supported list of distributions is now Knoppix (3.7), Kanotix (BHX), Linspire 5.0 and Simply Mepis (2004.04). Klik assumes that you will have installed at least the lowest version of any package which is present in all supported distributions and build the applications as such. If a package you want klik to install depends on a package in this base system it will not be included in the cmg so you must have it installed or add it to the cmg by hand afterwards. If you want to try using klik on another distribution, your results will primarily depend on whether or not your distribution has the packages the cmg depends on and assumes are present. So you will certainly fail to install kde applications on a distribution with no kde (as all the supported distributions have kde), but programs with simpler, or less common and therefore missing from some supported distributions, dependencies can work just fine.

One of the best ways to demonstrate the power of klik's techiniques is with the Christmas present from probono, an OpenOffice.org cmg for version 1.9.65. With this cmg (which runs on far more distributions then klik's supported list, especially as it uses Linux transparent iso compression rather then cramfs) you can download one 100M file to try out the preview release of Ooo, no need to upgrade any parts of your system and if the system has been setup by root to use cmg files there is also no need to even be root. I think this demonstrates the very best feature of bundled applications, you can try a potentially reckless preview release of software without having to upgrade your system.

Comments

Nice, but...

[Krankheit]

Can Klik install Gentoo Linux?

This Is What I Get At The Site Using Windows Opera

[Master of Transhuman]

"Unsupported Operating System

If you were visiting this site with Linux, you could install thousands of applications simply with a klik. You can download a free copy of Linux here. Please come back with a standards compliant operating system and browser.

This site is optimized for Konqueror and Firefox."

I don't like this shit when it happens with IE and I don't like it when it happens with Linux.

Fortunately I use Red Hat, so it doesn't matter...

Re:Sounds good to me

[Coryoth]

There is just one area where linux does have a problem when it comes to installing programs and that's when the program is not provided by the distribution.

Unfortunately I don't think klik, as nice as it is, is quite the solution to this. I would suggest, instead, that Autopackage is a far better solution for providing a means for installing third party packages. The people writing autopackage have spent much time carefully considering the difficulties involved, and have some very cunning solutions to some of the problems.

What does Autopackage do well? For starters it does the basic things that you'd expect well - it's got a nice GUI installer, it can fall back to a console installer, and it nicely wraps up a binary package in a "download and run it to install it" system. It has other bonuses that are more subtle, but for third party packages, suprisingly necessary. For starters it is distribution neutral, but at the same time does dependency checking and resolution. That's not so easy if you actually think about what it requires.

Autopackage is, of course, still in development. The really nice features (integrating in with rpm and dpkg databases etc.) aren't coming for a very long time yet. For now though it does work, and can install packages. If you're writing software it may be worth your while to look at what Autopackage asks of developers (you do need to do a little work to make code autopackageable) and keep it in mind as you go.

Jedidiah.

Finally maybe someone gets it

[Com2Kid]

Windows has had this for ages,

we call them EXEs. ....

Seriously though, just being able to click on a link, save to a directory, and run a program, is such a nice thing. I don't care how it is bundled up, just make the darn thing run!

Re:Finally maybe someone gets it

[Coryoth]

Seriously though, just being able to click on a link, save to a directory, and run a program, is such a nice thing. I don't care how it is bundled up, just make the darn thing run!

This is actually a much harder problem that you might think. There are a few different solutions. The Windows solution has been a combination of trying to bolt down a core set of libraries that everyone can be expected to have, and generally completely ignoring dependencies/shared libraries and letting the installers either trample each other, or install multiple versions of the same thing in different places. It kind of works, but does have drawbacks.

On Linux you could effectively do this by just having all packages statically linked, or have each package bundle up its own versions of all the libraries it will ever need. Neither is a very efficient solution for either disk space, or more importantly RAM (which is where shared libraries really start to earn their keep). The problem is partly that open source has a release early, release often approach, which means the base set of libraries (which Microsoft simply bolts down) tends to be an ever moving target (Microsoft simply does everything in huge upgrade jumps every now and then instead... except for a few things like DirectX). The other half of the problem is that with all that source code out there being shared freely there's an awful lot more code reuse and a much broader range of shared libraries and hence dependencies. This is a good thing most of the time, but causes issues for installing software.

Linux got around these dependency issues by having distributions which package up all the dependencies for you. This works very well, especially with apt, apt-rpm, yum, portage, and all the other fun dependency resolving tools, but has one drawback: If you aren't installing a distribution provided package the system has a lot more trouble tracking (and especially resolving) your dependencies. That means installing and maintaining a Linux system is easy, but adding new software from third parties can be a pain in the ass. Debian and Gentoo attempt to solve this dilemma by havign so many packages available from the distribution that you don't want for anything. As well as this works, it again isn't quite a complete solution.

Which finally brings us around to the open source attempts to try and provide systems to allow third parties to package software. The principle now is: You let the distribution do the hard yards of installing and maintaining the syste with their packaging and dependency resolving systems, and simply provide some distribution neutral package format that can still slot in amongst all of this. There are several solutions, each taking a slightly different approach such as ZeroInstall and Autopackage. They are still in the works, but look to have some surprisingly good solutions. They are definitely worth a look.

So, in summary, Windows manages to have their system by:
(1) Locking you down on base libraries, and having a slow upgrade cycle on those.
(2) Windows developers not sharing as much code, and not caring about actually sharing libraries even when they do.

That is a perfectly valid solution, and it does work, but its never going to fit with open source, which has a pretty fast developing set of base libraries (which is a good thing), a lot more emphasis on code sharing, and an eye for efficiency. That doesn't mean open source can't have easy to install software (it already does for anything distribution packaged, and various solutions for third party software are well on the way), merely that, because of some fundamental philosophic tenets of open source, it is a harder problem than on Windows, and requires more cunning solutions.

Jedidiah.

Re:Finally maybe someone gets it

[Com2Kid]

• (1) Locking you down on base libraries, and having a slow upgrade cycle on those.

Actually it is more like a base API, the various libraries constantly go through upgrades and such, more of a feature lock.

On one hand this is a bad thing, Windows did not even have a (decent!) built in dearchiver until Windows XP, but on the other hand it is also a good thing, as the free market allowed a number of competing (and ultimately superior) archival formats to come forth and not have to fight against any one single OS-supported format.

• Neither is a very efficient solution for either disk space, or more importantly RAM (which is where shared libraries really start to earn their keep).

A key question becomes, on client workstations, are shared libraries REALLY all that much more efficient, a good trade off for the hassle that they cause?

Honestly, a good HTML renderer, sure, Windows software has found a million and one ways to make use of that (A good portion of Visual Studio.NET's UI is basically a fancy IE window from what I can figure out, at least it behaves like one!), and other things like built in sound and video acceleration are (of course) handy to have around, but honestly, how often is some huge shared library really going to be used?

Lets see, if I have a 3D modeling app open, Winamp playing tunes in the background, and my browser of choice (Firefox or IE which ever) up and running, what use are shared libraries to me?

The UI, sure, but Windows has that, granted the options kind of blow, Win32 or .NET (suck up programmer time or suck up system resources), HTML renderer? Got that, my 3D program in the least is going to be using it for its help system and likely also for parts of its UI.

A standard image manipulation library? If I install a new image manipulation program I want something revolutionary, something different, from it. Heck, $400+ painting programs sell specifically because the programmers have developed some kick'in libraries that are limited just to that program. Besides, I don't want a shared library that specializes in doing a Physics Simulation of paint on paper!

Games? Sure, to some extent I guess, but how many games am I going to be having running at once? Honestly? 2 tops, even that is rare, most likely, just, well, 1.

On server and application server environments, shared libraries are a blessing, but for a client environment, flexibility and the capability to rapidly deploy applications to the end user seems to be higher priority.

OO is NOT "the best way to demonstrate klik power"

[imr]

From that sentence One of the best ways to demonstrate the power of klik's techiniques is with the Christmas present from probono, an OpenOffice.org cmg for version 1.9.65..

OpenOffice is one of those huge projects which come in preinstalled preconfigured and self sufficient package which have to be decompressed in one directory.
So having a "klik" package is not a proof of technical achivement, as it would be trivial to have a, say, loki setup or even a script which untar the package and put the missing entry in PATH.
No, give me a klik package of some kde or gnome program wich installs and works with every distro, aka fit nicely in every distro and rely on dynamic and present librairies. THAT would be a true demonstration.

Re:KDE-centric worldview? Or parent is trolling?

[UnderScan]

1.) klik is about a year old & is not new software.
2.) klik was first developed to install applications on in Knoppix (which uses KDE). Since Knoppix is on a read-only medium (CD-Rs) the dependecy on KDE was a real one.
3.) klik on longer depends on KDE. Just RTFA for once please.
4.) As far as I know, probono the developer of klik is not a official KDE developer.
Try googling or reading instead of posting First forum post by probono about klik back in Jan of 2004

Re:KDE-centric worldview?

[Nasarius]

For that matter, why would anyone make an installation system that had GTK as a dependency? Then, it would never look nice under KDE, so why even bother?

Actually, the latest version of gtk-qt is pretty damn good. I think it has the potential to become a "standard" for KDE users once all the little bugs are worked out.