Slashdot Mirror
Point-and-klik Linux Software Installation?
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.
Can Klik install Gentoo Linux?
Powered by caffeine and sugar; BSD
What's wrong with that?
Sure you can be opposed that's fine but nobody's telling you to go for it or nobody's telling the guys at gentoo "ok, follow the klik's way!"
It's simply more choices and the ones who will prefer this are the migrating users who come from windows. They have to point & click the most possible to get confortable with an o/s environment.
"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...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
I am morally opposed to Gentoo users
Well, I don't get that with Firefox on Windows XP, though if I set the user agent to IE 6, I can see the message you describe. If I set the user agent to Opera, I still don't get the message. Is your user agent set to IE right now?
In 5, 4, 3...
Oh, wait. This isn't related to KDE.
Indeed, using Opera on Debian Sid, I get the 'unsupported operating system' error only when the user agent is set to IE. Opera users: press F12 to change it to Mozilla, for this site.
If you are running a browser under Win32 or MSIE in WINE without spoofing your user agent string, the site will bitch. Solution: Change your user agent string. In Opera this can be done from the Quick Preferences menu. They are most likely doing this to save bandwidth.
Powered by caffeine and sugar; BSD
Actually, as an actual Gentoo user, it sounds pretty good. It'd be nice to have a variety of gentoo compatable binaries on the net, and easily installeable/removeable ones at that.
True genius is grasping a situation like a peice of fruit, and peircing it just right so that it drains dry.
Is it me or do the k-folks have a totally kde-centric world-view?
Surely no Gnome-user would have a gnome-centric world-view ever.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
You don't have to run the KDE window manager to use most KDE apps such as KDevelop. You just need Qt and the KDE libs. There are no dependancies on the window manager itself.
Powered by caffeine and sugar; BSD
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.
Craft Beer Programming T-shirts
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!
Need help treating your acne? Come here!
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.
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
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.
LOAD "SIG",8,1
I have read through the docs, but I can't find any indication of how klik really works. Clearly the cmg file has to be mounted somewhere. I found references to the overlay file system (which linus refuses to integrate). Does the cmg file get mounted somehow (with a root helper) and overlayed on the root file system? cmg files seem to be created from binary deb files, so I don't imagine they are recompiled to look for their files elsewhere (say $HOME/etc or something).
I believe this klik system could have real application across all kinds of distros, even RPM-based. However klik still doesn't truely offer (due to how linux works) apps that are dependency free. For example the galeon.cmg would still require mozilla and a few other things. I suppose they could make each cmg independent, but then we'd have tons of glibc's in memory, plus multiple copies of gtk, etc. How do they get around this issue?
It appears the main target of klik is to allow the downloading and running of software in a liveCD environment. How will this work in a real environment?
Indeed, I use linux and XP on this machine, and I just happened to be on XP when I read that story, enough to put me off ever trying their software.
If Linix is ever going to be a real force on the desktop in general, and not just the corporate desktop, it needs to do some serious work on how programs are installed.
I personally disagree with your above assessment -- the Mac OS X style of program installation and packaging is exactly what Linux should be striving for. In this configuration, a single application package can contain executable forks for multiple operating systems/distributions in a single package, which can be stored in a disk image and "installed" merely by dragging and dropping it into its target directory. Everything that is part of the program is then part of the package itself -- there is no need for an application to pollute the rest of the system by dropping files all over the place. Deletion is as simple as deleting the program icon/directory, and presto -- it's gone.
Indeed, I can see such a system actually working better on Linux than it does on OS X due to the ability for the package to contain executables for multiple OS's. A single package could contain executable code for Linux on x86, x86-64, PPC, S390, Alpha, MIPS, and all other Linux architectures (along with Mac OS X if one wanted to). Have a buddy running a different architecture you want to share an application with? Just copy it to their system as-is: the loader selects the correct executable and libraries within the package to use, with all the architectures sharing common application resources.
Installing applications on Linux is one of the major hurdles for Linux to 100% pass the "Mom test" here (my mothers system is running Fedora Core 3, because it's vastly easier for me to manage and maintain for her remotely than Windows ever could be, and I don't have to worry about her accidentially deleting system files or otherwise munging up the system somehow, besides being stable and damn good looking!). Mom recently wanted me to find and install a bunch of card games and little arcade games for her, and besides having a hard time finding many such games that suit her tastes on Linux (she doesn't want online multi-player, and doesn't need 800 different solitaire games), the ones I was able to find were a PITA to install (as most of them were source-only, build-it-youself, and then go in and manually create the necessary data files to add them to the Gnome menu, the latter of which I continue to believe there is no excuse for anyone to have to do).
On top of this, IMO the Open Source community needs more package maintainers, especially for smaller projects. It's hard enough for a moderately popular project to keep up with development, user requests, bug reports, end-user support, web site maintanence, and documentation as it is, nevermind trying to ensure your project gets packaged for the myriad of different packaging formats out there (and not just for Linux either if your project is portable to other OS's).
Okay, rant mode off. I neeeded to get tthat off my chest :). Linux program install has a long way to go before it's going to be friendly enough for the average non-sys-admin user.
Yaz.
A fellow Gentoo user, I don't see this fitting into the Gentoo paradigm. Gentoo, from its very beginning, is the opposite of packaged binary software. The initial geek factor with Gentoo was that you could throw in all the wacky compiler optimizations you wanted and build your Linux system from scratch -- very attractive to a small percentage of humans.
/opt -- an obvious attempt at some modicum of castigation. I suspect that there will be little impetus at the developer level to move Gentoo in the direction of more precompiled binary applications and away from the "compile everything from source with your own optimizations" model.
What I'm seeing now is that Portage has a couple really cool advantages over other packaging systems, and with those features come a horde of less wacky enthusiasts. Those features are, namely, ease of removal and upgrade and dependancy bliss. Nothing like issuing an "emerge world" and coming back 10 hours later with no hitches.
Even the binary packages you can install through the portage tree are relegated to
It just seems to break the foundational philosophy of the distribution to me.
-Ant Slayer-
Dependencies are dependencies - they exist to say "I NEED these things to even work at all." If you find some package that lists something as a dependency but you have no problems using the package without it, you've just found a bug.
You see it from the user's perspective. Thats fine but to create a new way of installing software you have to see the problems with the existing ways. The major problem with OS X Style program installation (and windows installers most of the time) is that they all contain every library they use. This leads to duplicated (in memory, where this is important) libraries and more important to outdated versions of libraries that might contain old security holes. Linux dependency tracking software installation approach is superior to these two forms but it clearly is much more difficult to do dependency resolution without a central repository (basically the lack of a common way of naming things makes decentralized dependencies difficult). The Installation System on Linux needs work but it shouldn't go in the direction of Windows and/or Mac from the Developer Perspective even though the result might feel similar from the Point of View of a User.
Linux is not Windows
I personally disagree with your above assessment -- the Mac OS X style of program installation and packaging is exactly what Linux should be striving for. In this configuration, a single application package can contain executable forks for multiple operating systems/distributions in a single package, which can be stored in a disk image and "installed" merely by dragging and dropping it into its target directory. Everything that is part of the program is then part of the package itself -- there is no need for an application to pollute the rest of the system by dropping files all over the place. Deletion is as simple as deleting the program icon/directory, and presto -- it's gone.
I think I've already written on tract about different systems for handling installation, and the pros and cons thereof, but that was in comparison to Windows. It looks as if it is time to discuss MacOS X.
Yes the OS X system is beguilingly simple in its ease of use. Drag and drop, multiple architectures in one package, no files strewn across the file system for each package, clean and simple. This does have its drawbacks though. One drawaback is shared libraries. MacOS X largely gets around this issue by having a huge monoloithic, heavily standardised base set of libraries to do, well, most everything. That core set of libraries is religiously controlled by Apple, and no one tinkers or changes it unless they buy the latest upgrade from Apple. That means application developers have a nice fixed set of shared libraries they can link to without having to worry about dependencies. Of course, anything outside that base set of libraries either has to reinvent the wheel each time, or have multiple copies of the same library not being shared between apps. Multiple copies of the same library has a few problems, the biggest being that it tends to hog more RAM than needed, and for security purposes there's no central place to upgrade/fix the library. Still the end result still works pretty well, and as you say, it's a ncie system to use. It is worth noting, however, that Apple themselves are moving away from App Folders and tend to have installer programs for even their own applications now.
So why can't Linux just do like Apple? There is no core set of libraries that everyone can be fully expected to have. Contrary to popular opinion this is less to do with the "Desktop War" between GNOME and KDE, and more to do with the release early, release often philosophy of open source. New versions of widget toolkits, CD backend libraries, and who knows what come out with startling regularity: Core libraries are a moving target. This is, of course, good in that open source software is continuing to advance and improve at a very impressive rate, and everyone can develop against the very latest if they want to. It's bad for installers though, because you don't have a 100% locked down "This Is How It Shall Be" set of shared libraries. This will not change. Open source is always going to be release early, release often, and developers of open source apps are always going to try and develop against the cutting edge of code. At the same time, because there is so much code out there, freely redistributable, there is a lot more shared code, and hence a lot more shared libraries that cover all manner of obscure things. Again, that's good, but again, its an issue for installation. That won't change either though - this is open source, so everything will be open and code reuse will be rampant (that's part of the point really!).
At it's core open source simply has philosophic issues that make App Folders something that just won't fit in with the open source world. Don't despair though, there's no reason a drag and drop front end that makes RPMs or DEBs look like App Folders can't be written - it simply interacts with the package database instead of directly with the filesystem. The visible results for users can be made to look identical.
As to how to actually handle software installation
Craft Beer Programming T-shirts
Looking at the documentation, I'd say this is a step in the right direction for Linux to be appropriate for home users. For the typical user, it is important that they can find an "application link" somewhere on the internet and just click it to use it. Package management systems like apt/urpm/emerge work well and are still necessary for Linux, but klik-style installation will enable average users to be comfortable using software that hasn't already been installed by someone else. As a result, they will probably feel a lot more "at ease and in control" during their Linux experience.
As a bonus, the linked application only runs with the user's privilege level. That means if it's a malicious app, it won't hose the whole system, and security/recovery becomes much easier.
It almost makes me want to try out desktop Linux again (using OS X right now).
completely missed the point.
Then we're talking around each other, because you seem to have missed my point.
Debian's "easy" system isn't easy because of its size (as the autopackage faq suggests) but rather because of their strict adherence to policy standards.
We're talking about installing some software. It is "easy" to install software on Debian if it is in the Debian package repository. If it is not, then how exactly are you planning on installing it? Compile from source? Not "easy". Download a third party provided DEB package? That ought to work, but that's hardly easy for the developer who has to provide a DEB package, a Fedora RPM, a SuSE RPM, a mandrake RPM etc., and then there's the issue that maybe the DEB was for Ubuntu and linked against some libraries in Ubuntu that aren't in Debian stable yet. In short, installing software that is not in Debian's repositories is hard. This mostly doesn't matter because Debian's repositories are BIG so the odds of wanting to install something that isn't there are rather small.
You can discuss policy standards all you like, but in the end if the software isn't in Debian, it isn't likely to be following those standards.
Let's be clear anyway: Autopackage is not a replacement for dpkg, apt, and all the usual Debian goodness. It is complementary to all of that, and is meant to provide an easy way for those "not in the Debian repository" packages to still be easy to install (and at the same time allow developers to package once, instead of "once for each distribution").
And you've missed a different point. klik-style packages ideally are to be installed by end users, not administrators.
Autopackage is about empowering users not just administrators. A user can go to the homepage for [insert random application here], download the autopackage file provided there by the developers, then just double click to run it and up comes a little installer that checks and resolves dependencies. One of the key points of Autopackage is for binaries to be relocatable. That means a non-root user can still install an autopackaged file - it just gets installed to their home directory instead of systemwide. Autopackage is not meant to manage a distribution - Debian and Redhat and SuSE already do that pretty well. It is about providing a way for extra third party application not already in the distribution to be easily installed by users.
Jedidiah.
Craft Beer Programming T-shirts