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

I wonder if it works on laptops

[mattbatten]

I wonder if it will work on laptops?

Re:I wonder if it works on laptops

[christopherfinke]

I wonder if it will work on laptops?

Why wouldn't it?

Re:I wonder if it works on laptops

[mattbatten]

I wonder if it will work on laptops?

Why wouldn't it?

It was a joke, dude.

Nice, but...

[Krankheit]

Can Klik install Gentoo Linux?

Re:Nice, but...

[Anonymous Coward]

can anybody do so?

Re:Nice, but...

[Anonymous Coward]

Yeah; you just have to have an IQ above 75.

HTH

Re:Nice, but...

[Anonymous Coward]

This is not funny you insensative clod.

Re:Nice, but...

[Ziviyr]

All you need is portage.

Re:Nice, but...

[Anonymous Coward]

Actually one of the major steps of installing Gentoo is simply untarring linux onto a blank partition. It's not too dissimilar a concept.

Re:Nice, but...

[mattyrobinson69]

oo oo! is that good? woo! my IQ is >75

Re:Nice, but...

[Cid Highwind]

Yeah, but you have to use the secret beta text-mode only klik client (codenamed "xterm"). Open xterm and type "emerge " (the trailing space is important!) Open the klik! web site and highlight the name of the app you want to install with your mouse pointer. Then middle-klik on xterm, and press enter. Presto!

Re:Nice, but...

[koreaman]

That is one of the funnier things I have read in a long time. Mod parent up (insightful or interesting, funny mods are a waste of time)

Re:Nice, but...

[Anonymous Coward]

Can you tell a Gentoo user to click though an installation without offending his intelligence?

Re:As a Gentoo user

[Man in Spandex]

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.

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...

As someone who isn't 3133t

[Anonymous Coward]

I am morally opposed to Gentoo users

Re:As someone who isn't 3133t

[Anonymous Coward]

I for one welcome our new Gentoo using overlords.

Re:As someone who isn't 3133t

[Botty]

As your new overlord my first proclamation is!

BigBrother@gentoo >emerge -deep -p new-world-order

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild R ] world/governments-2.0
[ebuild R ] world/undesirables-0.9
[ebuild N ] instituion/Ministry-of-Truth-1.0
[ebuild N ] instituion/Ministry-of-Love-1.0
[ebuild N ] instituion/Ministry-of-Peace-1.0
[ebuild N ] instituion/Ministry-of-Plenty-1.0
[ebuild N ] lang/newspeak-fonts-1.0
[ebuild N ] lang/newspeak-dictionary-1.0

BBrother@gentoo >emerge -deep new-world-order
--snip--
BBrother@gentoo >gvmnt-update

Re:As someone who isn't 3133t

[Anonymous Coward]

You are out of date, sir! Use the -a option so you do not have to scan for dependencies twice.

I wonder if it works on PDAs

[Anonymous Coward]

I wonder if it will work on PDAs?

Re:I wonder if it works on PDAs

[Anonymous Coward]

It's works on my abacus if that helps.

Re:I wonder if it works on PDAs

[aichpvee]

Does that work on any abacus? Because I saw this Giraffe abacus at Toys R Us and was going to buy it, but needed to check that it could run Linux first.

Re:This Is What I Get At The Site Using Windows Op

[Solder Fumes]

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?

Re:This Is What I Get At The Site Using Windows Op

[Anonymous Coward]

I get the same thing, consistently, using Firefox .8 on Mepis Linux. Lousy advertising for Klik.

K-naming jokes follow

[Anonymous Coward]

In 5, 4, 3...

Oh, wait. This isn't related to KDE.

Re:K-naming jokes follow

[mabhatter654]

but it runs under KDE and Knoppix and Konquer... hence the Klik name!!!

Re:This Is What I Get At The Site Using Windows Op

[FlipmodePlaya]

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.

portage

[Anonymous Coward]

Gentoo's portage has multiple guis, some of which are very very nice. Of course, the only way to install these guis is to install gentoo and use portage from the command line.

User Agent String

[Krankheit]

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.

Re:User Agent String

[Anonymous Coward]

To save bandwidth? That's stupid, more like censorship to me. What happens when someone wants to see the site and is not skilled enough to change his UA string? We hate IE-800x600 optimized web sites, but they apply the same methods. I don't want a browser/OS war like this.

Re:User Agent String

[Anonymous Coward]

I'm using Firefox on Slackware and I hate Bill Gates as much as everyone here, but we know what will happen if we mimic Microsoft's behaviour of detecting and preventing based on some ID.

Re:User Agent String

[Master of Transhuman]

That's true, but the same thing happens if you run Opera and spoof your agent id, which is the problem here.

Re:User Agent String

[Taladar]

That is because they are KDE people: Mimicing MS's behaviour is their job...

KDE-centric worldview?

[Taladar]

Is it me or do the k-folks have a totally kde-centric world-view? I mean who but them would develop a software installation system that has kde as a dependency and ensure that way that no distribution that doesn't want to lose all non-kde users (not only gnome, but users of all other window-managers and users that don't need X on their machine) can use their system?

Re:KDE-centric worldview?

[Jameth]

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?

Most likely, they just didn't bother to make it work with anything until it was good enough that this fact even mattered.

Re:KDE-centric worldview?

[l3v1]

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.

Re:KDE-centric worldview?

[Krankheit]

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.

Re:KDE-centric worldview?

[odioalsoco]

Are you stupid??
Can't you read?

I think so..

Re:KDE-centric worldview?

[Taladar]

I am neither Gnome nor KDE-User and both groups just get on my nerves with their "our program only runs with three dozen libraries that are bigger than the rest of your system together"-attitude. A recent example is K3b which is a nice CD-Burning App but it would be the only thing on my system needing the KDE-Libraries and doesn't really gain much from using them. The better way would be to make one using plain old GTK or QT and allowing non-kde users to use it too without loading all the libraries. I might not need the KDE Desktop to use them but I have to install and load all the libraries which has almost all the disadvantages of using kde itself. If you use one app from gnome and one from kde you even have to have both library sets loaded as double bloat bonus.

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.

Re:KDE-centric worldview?

[Anonymous Coward]

K3B would be twice as big and need twice as much work if it would be a non-KDE app. the KDE libs make developing a great application easy, and if you run KDE, you don't mind the need for the libraries. well, if you don't run KDE, you should use an app build for whatever it is you run, cuz thats simply the most efficient.

I don't complain that Microsoft Office needs Crossover office to run under linux, so don't complain about this.

Re:KDE-centric worldview?

[Curtman]

A recent example is K3b which is a nice CD-Burning App but it would be the only thing on my system needing the KDE-Libraries and doesn't really gain much from using them.

It looks nice, but is among the most frustrating software I've ever tried to use. Gourmet garbage is what it is.

Re:KDE-centric worldview?

[Sunspire]

I for one am sick of these "oh but it requires libgnome/kdelibs". Just fucking install both desktop environments, that way you can run any app you want. Forget selecting libararies, you're doing yourself a disservice. You're likely spending more on toiletpaper any given day than what it costs in disk space to just install everything.

Seriously, if takes a hundred megabytes, a gigabyte, whatever, so what. If it takes you even five minutes to troubleshoot an application you're never going to recuperate your effort. Welcome to 2005, where time is expensive and diskspace is cheap. Fuck custom installations.

Re:KDE-centric worldview?

[bit01]

time is expensive

Yes, it is. Adding extra libraries not only increases resource usage (agreed, not particularly important) but also fragments the code and slows load and execute times. That is important.

Both gnome and KDE take far more time than they should to do simple operations. It needs to be fixed.

---

DRM - Democracy Restriction & Manipulation

Re:KDE-centric worldview?

[BenjyD]

"Premature optimisation is the root of all evil" as somebody once said.

Both the desktops are putting more effort into optimisation now they have most of the functionality required.

Re:KDE-centric worldview?

[bit01]

"Premature optimisation is the root of all evil" as somebody once said.

True for code/peephole optimisation but less true for functional/design optimisation.

Too many software projects assume that any functional design will be fast enough. For instance, they often don't appear to understand the difference between an O(n^2) algorithm and an O(nlogn) algorithm, nor the major timing differences between a polled interface and a callback/callforward interface, nor the way many small delays accumulate into a large delay.

If a project makes bad organisational decisions at the start it can be hard to fix later without breaking backwards compatibility.

Both the desktops are putting more effort into optimisation now they have most of the functionality required.

Glad to hear it. :)

---

Are you a programmer-bureaucrat?

Re:KDE-centric worldview?

[BenjyD]

True enough. I think that there would be a huge benefit to the Free Software community if somebody wrote a simple text book descibing issues like that (big-O, unit testing, asserts, basic software design). The knowledge is out there, it's just spread between a lot of sources and harder to find than it could be.

I get the feeling that a lot of Free software developers are like me: people who can program well enough, but have little formal education in development techniques.

It's been a difficult learning curve for me (current version of my software is 10 times faster than the first version and vastly improved testing), certainly.

WTF?

[Anonymous Coward]

What the fuck? I can't even get to this website with Internet Exploder. What is all this whiny shit I read on here about being free to visit any site you wish with any browser, or open standards?!

Re:WTF?

[mabhatter654]

Still using MSIE... GO AWAY!!!

But seriously, this is a highly specific site, designed primarily for Knoppix/LiveCD users. Complaining about it is like Windows update not working for BeOS... DUH!

Re:This Is What I Get At The Site Using Windows Op

[big tex]

Loads fine with Safari on OSX, despite the fact that I probably can't "install thousands of applications simply with a klik.".

Heh. Go Figure.

Clarification...

[Krankheit]

You can use Google's cache if you don't want to mess with your user agent string to see the site:
http://64.233.161.104/search?q=cache:DcXkKzGdgk8J: klik.atekon.de/+&hl=en
In Opera, even on *nix, the site will refuse to display unless you set your agent string to Mozilla. Opera or MSIE user agent strings (which is usually default in Opera) will make the site think you are using Windows/MSIE.

Re:Clarification...

[JonLatane]

Using Opera 8 Beta, I'm able to access the site by identifying the browser as Opera, but not as MSIE (which is the default). Of course, the layout is all broken on their site. Apparently, while they prohibit non-"standards compliant operating system[s] and browser[s]," they do not adhere to web standards themselves.

Sounds good to me

[Anonymous Coward]

Disclaimer: I haven't tried klik, so I can't really comment upon the application itself. However, I think that something like this is really needed on linux.

Don't get me wrong, I'm not saying that the current way to install programs in linux, especially in debian, isn't great, on the contrary, I'll take apt over the way programs are installed on OSX every day and don't even get me started on windows.

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. More often then not you are then forced to compile the app by hand, which doesn't pose a great problem for someone knowing it's way around linux, but it sure wouldn't pass the aunt Tilly test.
Further, even if distribution independent installers are provided, for example by opera, these installers often leave much to be desired in terms of ease of use. (Which isn't of course a linux fault per se, but if there was some kind of distribution independent, easy to use installer, companies that want to package their software could and probably would use it)

To sum it up, this looks really promising.

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.

Re:Sounds good to me

[Anonymous Coward]

Thats all fine and dandy but they have all of eight "packages" to install.

Is there a seperate package repoisitory somewhere?

Re:Sounds good to me

[Yaztromo]

Don't get me wrong, I'm not saying that the current way to install programs in linux, especially in debian, isn't great, on the contrary, I'll take apt over the way programs are installed on OSX every day and don't even get me started on windows.

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.

Re:Sounds good to me

[Anonymous Coward]

As I already said, I agree with you for the most part. Your example about the card games is exactly the problem I was talking about and it's exactly the area where linux still has a major problem.

However I totally disagree with you about installing packages OSX style. Sometimes using OSX myself I know that it is indeed easy, but it has some great shortcoming compared to a central installation tool like apt, yum, emerge. First of all it is really unefficient compared to apt, etc. as several versions of the same files will be installed on your machine.
Now you'll probably say that you mum couldn't care less about that and you are totally right, but having different versions of the same library strewn around the filesystem can also be a huge security problem as could be see with the recent windows gdi vulnerability.

Further, I really think that a system that allows you to easily update and maintain _all_ of your programs with one command, or graphical interface is vastly superior and in fact userfriendlier compared to for example the OSX approach.

However, as I already stated, you are totaly right imho that there really needs to be a solution that allows to easily install (and for the developers package) software that is not provided by the distribution.

Re:Sounds good to me

[Coryoth]

Thats all fine and dandy but they have all of eight "packages" to install.

Is there a seperate package repoisitory somewhere?

They have so few packages because they are still in development on the packaging system. As I said, an application (or library) developer does need to make some changes to the code to make it autopackage ready. The changes are small, and are very little work, but they do need to be made.

As to other repositories - anyone can set up their own autopackage repositiory, so a third party software developer can simply set one up when they package their software. The end result is meant to be akin to the Windows way of downloading and running a package, but with the added bonus that it resolves dependencies too.

For now Autopackage is something for developers, not users - anybody writing code that they want to package up themselves for people to download ought to be looking at autopackage and using that for their packaging needs instead of RPM, or DEB. Once that starts happening you'll find a lot more applications available as autopackages, and it will start being very useful for users too.

Jedidiah.

Re:Sounds good to me

[Taladar]

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.

Re:Sounds good to me

[Coryoth]

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

Re:Sounds good to me

[Anonymous Coward]

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 [...]

completely missed the point. The file format only matters so far as the policies it allows. 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. They do not use file dependencies but idea / service dependencies. Any collection of files can provide one idea or service. If that service is bound to a particular filename, then the Debian alternatives system allows for multiple alternatives (but only one for an entire system). If it's bound to a network port, then the packaging system disallows multiple, conflicting packages (even if you could re-configure them to attach to different ports). And so on. It's not the size that counts, it's how it's used.

And you've missed a different point. klik-style packages ideally are to be installed by end users, not administrators. Autopackage is just another file format. Attempts like klik and nsbd try to enable users. Those of us who work on massively multi-user systems (think departmental compute servers) would really appreciate being able to use the latest and greatest software without placing a support burden on the tech staff. Something like klik could be a huge help (although the current implementation isn't useful).

Re:Sounds good to me

[drinkypoo]

I'd like to see a version of the package directory (or tarball, or filesystem image, or whatever you end up with) that included the sources and instructions for building them so that it might work on architectures the initial package does not provide for. It would be pretty well trivial to implement the basic underpinnings of all this stuff if it weren't for dependencies...

Re:Sounds good to me

[Spy Hunter]

You have not given any reason why autopackage is better than klik. I think klik is better. Firstly, klik has *no* installer. Packages just work the instant you download them. That beats an installer any day of the week. Klik does lots of dependency checking and resolution also, but it works behind the scenes before the package is downloaded, completely invisible to the end user. Furthermore, klik is useful today, with lots of packages that are autogenerated from Debian packages. Autopackage might have a couple of packages now, but nothing near the selection klik has.

Re:Sounds good to me

[Coryoth]

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.

Re:Sounds good to me

[Coryoth]

Let's be clear then: Klik is fantastic if you are installing a package from Debian. Klik is completely useless to you if you are running SuSE, Fedora, Mandrake, Gentoo, or any other non Debian based distribution. Klik makes installing Debian packages easy, but so does apt and Synaptic (in a different way). It does not solve what is the real difficulty with installing Linux software: Installing something that has been prepackaged for you by your distribution. Installing new software on Debian is trivial, and Klik adds a convenient new layer to that by making it accessible to users who don't have root access. It doesn't address the problem that is always brought up when people claim about hard to install software on Linux. Read some of the complaints about Linux from Windows and Mac users. Once your want something not prepacked by your distribution for you, you're pretty much back to compiling it yourself. It is this that Autopackage hopes to solve, while at the same time making user installs of software easy.

Jedidiah.

Re:Sounds good to me

[Coryoth]

Sorry, typo:

It does not solve what is the real difficulty with installing Linux software: Installing something that has not been prepackaged for you by your distribution.

Re:Sounds good to me

[Yaztromo]

Overall, good comment. Some things I'd like to respond to:

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.

I'm sure you know this, but just for those who may not (and interpret your message incorrectly), Mac OS X does indeed have a shared library mechanism.

With that out of the way, as you've noted yourself, in those cases where an application does need to make use of shared libraries you can have something closer to a traditional installer to install Mac OS X applications. In many cases, however, this installer can be much simpler than what one usually sees in the Windows world, as you can just copy in the shared libraries you need into the correct locations, and then copy the rest of the application package to its target folder.

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.

Let's not all forget, however, how having a central library repository can wreak havoc on ones system. Anyone who has ever used Windows can tell you about "DLL Hell". Remember what it was like back in the days of Windows 3.1? Every application shared common libraries under the same name, and if you installed a new application it might decide to "upgrade" that library to a newer version, causing all sorts of problems with other applications also relying on that library (due to changes in functionality, new bugs, or whatever).

Now granted the Linux way of handling libraries is significantly better than the Windows way of doing things. However, allowing applications to have their own versions of common libraries does have its benefits. If developer A writes "Widget Set 2005" using "doodadlib v4.0 rev B", it isn't going to start to exhibit oddities just because you installed developer B's "Widget-O-Rama 2004" which uses "doodadlib v4.0 rev A". Library versioning issues disappear in this scenario.

And there are ways to mitigate the extra RAM usage. I don't know OS X's innards well enough to know whether they use a system like this, but there have been operating systems which keep an internal lookup table based on the library name/version (and perhaps even some form of signature) to identify libraries. When a call to an unloaded library is made, the OS typically catches an exception, forcing a lookup against the loaded-library table. If the library requested by its name/version/signature is present, a new copy isn't loaded, even if the application has its own copy in a different location on disk. Later versions of IBM'S OS/2 operating system have a system something like this (which can be disabled using the LIBPATHSTRICT option IIRC). Again, I don't know enough about OS X's internals (yet) to know how it handles library loading, but if this is indeed the case RAM wouuldn't be an issue (you merely wind up wasting more disk space keeping multiple copies of the library around). And if OS X isn't doing this -- well, it should :).

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.

Indeed, I've been using Linux in one form or another since 1994, long before there was a Gnome or a KDE. This issue pre-dates both of them. However, it has been particularily within the last 5 years that there has been an explosion of Open Source runtime environments and libraries that accomplish the same goals, causing all sorts of duplication. This in and of itself results in far more wasted memory

Re:Sounds good to me

[Stevyn]

I've seen enough gentoo users make comments on this topic and piss people off, so I'll be brief.

I've done this by ssh'ing into a computer from many miles away, emerging the app, waiting for it to compile, and it will appear in the gnome or kde menu. This is why command line package systems are nice, you can easily use them using ssh without having to worry about X forwarding. And portage will put the little icons in the menu which is very nice.

Re:Sounds good to me

[Spy Hunter]

You misunderstand. It does not require a debian-based distribution. The current implementation assumes that some software (mainly KDE) is preinstalled on a user's machine, but it doesn't necessarily need to have been installed from debian packages.

Re:Sounds good to me

[Coryoth]

The why are all the "supported distributions" Debian based ones, and the documentation page on "Using with Other Distributions" only lists SuSE as non Debian based, says it is "harder to support" and then has a long set of instructions for what you need to do to make it work? That does not sound like easy installation to me... it sounds like rather painfully difficult installation for any non Debian based distributions.

Klik is a very nice system, and it works admirably for Debian based systems, but ostensibly its just providing Debian packages the same as the Debian repository. Any packages it provides that aren't already in the Debian repository have been packaged for Debian. Therefore it isn't really a solution to third party packaging issues (which was the original point I was replying to).

Jedidiah.

Re:Sounds good to me

[Yaztromo]

I've done this by ssh'ing into a computer from many miles away, emerging the app, waiting for it to compile, and it will appear in the gnome or kde menu. This is why command line package systems are nice, you can easily use them using ssh without having to worry about X forwarding. And portage will put the little icons in the menu which is very nice.

The Mac OS X application packages can also be "installed" via the command line by mounting the disk image (if any), cd'ing over to it, and then using "cp" to copy the application to its destination directory.

Where Linux systems currently have a benefit is that they often have package retreival systems atop the packaging system itself. Apple's packaging system is akin to RPM -- it's a package format. This wouks fine if you have the package in the first place. Where systems like yum or apt-get or emerge are benefitial is in being able to get packages in the first place, and to ensure that all pre-reqs are met (and if not, to retreive and install them as well). Still, these tools typically don't specify the package format themselves, but are designed to work with another (usually specific) packaging format. As such, they aren't directly comparable.

I do see how these package management/download systems are of benefit to systems administrators and power users -- they are powerful -- but they are also beyond what most end-users would tolerate for software installation. And AFAIK, most of them are directed towards retreiving code from networked repositories, and don't really do you much good if you're buying software on CD-ROM as your typical consumer is apt to do (no pun intended ;) ).

Yaz.

Re:Sounds good to me

[Anonymous Coward]

The autopackage stuff also will know nothing of Debian policy. Hence, it will suffer from exactly the same problems. The policies define the packaging environment, not the files or the tools. Third-party installation on Debian is also simple. Just use epkg, stow, whatever in /usr/local. No, it won't know about Debian dependency policies. Neither does autopackage.

From the NSBD experience, relocating binaries is the easy part. Many bind configuration paths pretty tightly. Many cannot be told to search for configuration or core data files outside their installation roots for dependencies. The paths embedded in binaries are deadly. The autopackage folks are not the only ones who have approached this, but I'm not sure they realize it. They're following the same approaches and will hit the same walls.

The best bet on "modern" systems is to use a library wrapper or trace system that redirects particular file paths to the installation locations. Another trick would be to use process-specific namespaces, but that's limited to Linux and Plan 9. No one seems to want to do the work, so they're all stuck with the same, half-broken, "but if all developers would just do XXX" mechanisms.

Re:Sounds good to me

[Spy Hunter]

Because they haven't yet done the work necessary to support installation on non-Debian-based distros. However, the concept is sound and the implementation is straightforward. All that is needed is to compile a list of common base software that should be available on every distro. Then when you install the klik client it can check to make sure you have that software and install it if you don't (using a simple script that runs your distro's package manager or simply downloads the necessary files from klik itself). After that klik would work the same way it does on Debian. It's much simpler and more straightforward than developing an alternate meta-packaging system that does on-the-fly dependency resolution using any of 10 different package management systems; and therefore much more likely to work correctly and much less work to implement and maintain. That's why it's better than Autopackage. Less complexity = better software.

Re:Sounds good to me

[ColMustard]

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.

Actually this is only partly true. Programs can include every single library they use inside the application "bundle," but it certainly isn't a requirement to duplicate. This is only usually an issue with drag-n-drop installed apps. Programs which are installed using a helper installer program usually install libraries in a global place. And either way, the installation is "easy."

Re:Sounds good to me

[Coryoth]

The autopackage stuff also will know nothing of Debian policy. Hence, it will suffer from exactly the same problems. The policies define the packaging environment, not the files or the tools. Third-party installation on Debian is also simple. Just use epkg, stow, whatever in /usr/local. No, it won't know about Debian dependency policies. Neither does autopackage.

So the easy way of installing third party packages on Debian is to compile it from source? That being what stow (which I use), and from the look of it epkg, require you to do. You my as well use checkinstall instead, it'll provide more useful results (it adds a source compiled program into the dpkg database). No, that oesn't sound like the easy solution to let Grandma install third party packages that the original poster I replied to was looking for.

Let me quote the original again:

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.

The issue is when the program is not provided by the distribution: right now that's not easy, or so the OP claimed. Your solution is: compile it from source and use stow or epkg to put it somewhere nice. That's not a solution, that's what we've had for the past 5 or more years on any distribution. If that was a solution why do you think people keep raising the issue as a problem?

To be honest I have no idea quite what you're ranting about any more. The question was: "Will this make installing non-distro provided packages easy at last?", my answer was "no, as good as klik is, it only really works with Debian based distros, so is just more Debian packaging really. Try autopackage if you want to install 3rd party apps."

You seem to have taken great offense, but I'm not sure to what.

Jedidiah.

Re:Sounds good to me

[Coryoth]

Because they haven't yet done the work necessary to support installation on non-Debian-based distros. However, the concept is sound and the implementation is straightforward. All that is needed is to compile a list of common base software that should be available on every distro.

Welcome to "The Problem". How do you know what's installed, and which version it is? If it's Debian it's easy because it's all standardised, if its any distribution then it gets very hard very fast (particularly on version of library etc). You have to figure out whether the library is there even though the location, name, and version may all be different. Drawing up a huge table for every distribution out there is going to be very tedious indeed. Especially when you need a seperate table for each library dependency. The instructions for making klik work on SuSE get around this by literally making you copy over the libraries from a working Debian distribution. It's quite a list to copy over to make everything work.

So you're down to 2 choices - have an unbelievably complex bunch of logic to check what distribution it is, what version of the distribution that is, determine what the corresponding locations and names of the required libraries are, checking if they're installed and what version they are etc. or simply packaging up all the required shared libraries into the package - which is to say, ignoring dependencies entirely... which raises all sorts of other issues like RAM use, and security.

Making this portable across distributions is incredibly hard. It's not the easy last step. If you want portable across distributions try Zero Install or something. I doubt it'll happen all that soon with klik.

Jedidiah.

Re:Sounds good to me

[Spy Hunter]

You misunderstand again. The beauty of the klik approach is you *don't* need incredibly complex logic. You simply need *one* script for each distro version supported. This script installs the base libraries and doesn't need to be complex at all.

The script goes through the list of base libraries (which is much much smaller than the entire list of possible packages for each distro). For each library it has a location to check and a location to obtain the file if it is not there. It simply downloads the files you are missing and that's it. Very simple. If you want to be fancy it can use the distro's package manager to install the files if possible, but that is not even necessary. In fact, if you don't use a specific distro package manager, this script could probably be portable across several distros. After this simple script finishes you are ready to run any klik package.

There are of course tradeoffs with the klik approach. However I think that it is the most sensible packaging solution to come along yet. It provides a middle ground between "huge self-contained packages with everything included" and "completely modular packages, but you need to download 10 dependencies to install any software". I'll list some of the potential problems I see:

1. Any library not included with the base must be downloaded in each klik package that uses it.

   I believe a sensible base library set can be found such that most applications will be a reasonably-sized download, yet the base library set is still manageable. Yes some libraries will be downloaded twice, but it's not the end of the world.

2. The base libraries don't change, what if one is upgraded?

   If a particular program requires an updated version it can be included in the klik package. I think the longer-term solution, however, is to provide a new version of the base library set every few months. Since it hopefully is kept small, this is still doable.

Re:Sounds good to me

[Anonymous Coward]

You can install binaries just fine with epkg, stow, depot, and the like. Some for epkg are distributed by UIUC. UFL distributes depot binaries for a few platforms. There's a widely used depot-like archive for AIX somewhere (UCLA?). CERN uses a similar tool for packaging binaries for their users. Binaries are sold to large installations using the very similar modules system. These tools work just fine for binaries.

I take offense at the duplication of essentially the same tools over and over again with no real advance. It's an utter waste of time. There are and have been many depot-epkg-etc tools. There are and have been many autopackage-epm-etc tools. None of them work enough to be interesting to a larger community, and none of the "new" ones have substantially improved any of the existing ones. Hell, very few of them bother even to discuss the advances and shortcomings due to tools that came before them.

There are new directions available, but people keep wasting time on the old ones. (And the area doesn't relate to the work I'm paid to do, and I haven't found sysadmin work fun for about a decade.)

Re:Sounds good to me

[Anonymous Coward]

Distribution neutral? I tried installing it on my Ubuntu box the other day, it detected I was running Ubuntu though (nice touch) but then it needed a file to run and suggested I apt-get it from my package maintainer, only, my package maintainer didn't have that needed file in any repository, and why should I have to go apt-get anything when autopackage is meant to make things simple?

Long way to go.

Re:Sounds good to me

[TrancePhreak]

"Now granted the Linux way of handling libraries is significantly better than the Windows way of doing things."

Please explain how this is true today. COM itself can solve this, as well as other methods such as having local copies just like OSX, or with shared libraries.

Re:Sounds good to me

[Anonymous Coward]

I didn't mean for that to be bold... Ah well.

Re:Sounds good to me

[IamTheRealMike]

The paths embedded in binaries are deadly. The autopackage folks are not the only ones who have approached this, but I'm not sure they realize it. They're following the same approaches and will hit the same walls.

The right way to solve this is by providing binary relocatability support in core libraries and small utilility files that can be statically linked. This is what binreloc is, you can find out more at the autopackage homepage, and it's designed to be trivial to drop into pre-existing software. It requires patching the code, but it takes all of half an hour to do even complex apps like Gaim and Inkscape. The fact that it requires patching isn't a problem, as autopackage is designed to be used by upstream developers with their full knowledge and consent.

Re:Sounds good to me

[IamTheRealMike]

autopackage bears no resemblence to epm, or any other "package manager" we're aware of. I suggest you read about it more carefully, as otherwise you'll jump to incorrect conclusions. It is not "just another file format" either, in fact the contents of .package files are implementation-defined and subject to change without notice.

It is best described as a hybrid between NSIS/Loki Setup type installers, and package managers such as dpkg and RPM. Autopackages are programs that understand the quirks of various distributions, and which contain binaries compiled in such a manner that they are binary-portable across a wide range of Linux systems. When run they will integrate that software with the users system in the tightest way possible. They understand dependencies and dependency checking, and can resolve missing dependencies. They understand 4 or 5 different menu systems and can place items in the menus for all of them. It allows you to install that software to your home directory. It provides both GTK and Qt based uninstallation tools. It has been designed with end-user usability in mind from the ground up.

It is a real, useful piece of software that exists today and is not a theoretical program that works perfectly in a theoretical world. It does not require you to use it for all your software. It does not require special setup. It does not require distributions to support it. It does not need you to be using the "right" Linux system to work. Naturally, it is not a magic pill that works 100% of the time either, but that was a conscious design tradeoff we made at the time.

In other words, it's a program designed specifically for the situation the Linux community currently finds itself in. Please show me another program that meets these design criteria. The closest I'm aware of is ZeroInstall which is nonetheless very different.

Re:Sounds good to me

[IamTheRealMike]

You were probably installing Gaim and had the wrong version of GnuTLS. Yes? That's a known problem, the Gaim developers are aware of it, and will probably be autopackaging GnuTLS themselves at some point and/or changing Gaim so it can use multiple major versions of GnuTLS. SSL in general is just a big pain and Gaim has an entire FAQ devoted to it.

Also in future we want autopackage to know how to use apt to install things it needs, as well as being able to resolve dependencies from other autopackages.

Autopackage is not a magic pill that makes everything better. It is a tool that combined with changes to software and new methods of community development can significantly ease the pain of installing unsupported software into a distribution.

Re:Sounds good to me

[Anonymous Coward]

Thanks for posting.

To be honest I didn't take that harder a look, I thought I'd try out the .package then when I needed GnuTLS and couldn't find it I instantly gave up (I only tried it because the .deb from my repos. of Gaim was borked for a couple hours, but eventually it was fixed) I'll give it another look, though.

Re:Sounds good to me

[Makarakalax]

Unfortunately you don't know what you're talking about. Mac OSX installation is very nifty but you can't do it with Linux, just try.

Re:Sounds good to me

[Yaztromo]

Unfortunately you don't know what you're talking about. Mac OSX installation is very nifty but you can't do it with Linux, just try.

I'm both a daily Mac OS X and Linux user. I've been using Linux in various forms since 1994 -- long before 99% of the people posting here even heard of it. So forgive me if your words carry no weight with me.

I'm not claiming that Linux has the same install system as Mac OS X -- I'm saying it should strive towards a similar system as what OS X uses. It would obviously need to have some tweaks and modifications to fit better with some of the assumptions built into the core OS, and would require modifications to the program loader(s), but other than that there is little reason why it couldn't be done. It merely requires someone to develop the necessary code to do it.

Yaz.

Re:Sounds good to me

[bbtom]

Why? I absolutely HATE the OS X system. urpmi was one of the most pleasant surprises I had when installing Mandrake.

Re:As a Gentoo user

[incom]

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.

Re:SuSE 9.2

[Anonymous Coward]

While I agree with you I'm asking myself what exactly your praise of Suse does have to do with the story at hand?
I just don't get it.

Re:As a Gentoo developer

[Anonymous Coward]

You apparently can't take a joke. Maybe I should submit a patch to support humor?

Err RTFA ....

[taniwha]

It sais: "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."

Gnome-centric worldview?

[Kurrelgyre]

Two wrongs still won't make it right.

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

[Simon Lyngshede]

Just to bad you can't upgrade all your Windows applications with a command or two.

Point and Click installation, like exe og msi in Windows is actually amazingly stupid because they can tie it all into one update function.

Re:Finally maybe someone gets it

[Anonymous Coward]

It's pretty hard to do, really. I've tried to use apt-get in a chrooted rxvt on a running Knoppix system to add something like Firefox to my build directory, so the next time I run mkisofs, I get Firefox. Only problem is that firefox wouldn't start, needed a particular library that couldn't be found in the Original Knoppix 3.4 I started with.
apt-get did install a bunch of new libraries, but one, at least one, was missing, so no Firefox for me. As an alternative way, I usually add on a "firefox-installer" directory in /home/knoppix, and all of firefox's stuff is there, so that's where I hook my icewm menu, to /home/knoppix/firefox-installer/firefox
and off she goes! No problem. But, with apt-get, I get close, but no cigar.

Re:Finally maybe someone gets it

[JDevers]

Only very simple programs don't need an installer to copy over all the OTHER parts of the program that AREN'T in the .exe. I haven't used this, but it seems quite a bit different than you describe. It is more akin to being able to download a major program and it just running right out of the box without an installer at all, no matter the program nor the need to have "permission" to install software (either be root in a *nix or have admin privs in Windows).

Re:Finally maybe someone gets it

[be-fan]

In what alternate reality can you run a program without using the installer? Aside from a few tiny utilities (putty.exe), nearly all Windows programs require an installer. You can do the same thing in Linux too if your program doesn't have any external dependencies. The catch is that nearly all significantly-sized programs do.

Re:Finally maybe someone gets it

[jdhutchins]

Linux has had RPM's for ages. They don't always work perfectly, but neither do EXE's. And there are graphical interfaces to most common package managers; Debian has Synaptic that works with apt-get and dpkg quite nicely.

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]

• Just to bad you can't upgrade all your Windows applications with a command or two.

Why would I want to? Most software I own is not updated that often (surprise surprise!) and often times I do not want the latest greatest themable UI that sucks up another 4 or 5 megs of memory.

As a rule I only download a new version when security issues appear.

Also, Windows people are a bit more paranoid about updaters, they tend to get disabled VERY quickly. What ensures your trust of a one click update that downloads from multiple sources? Sure you may trust most of the sources, but I would not want to download an update from a company such as, say, RealNetworks, without hand inspecting every last little bit of it first.

Re:Finally maybe someone gets it

[Com2Kid]

• Re:Finally maybe someone gets it (Score:1)
• 
  by be-fan (61476) on Saturday January 15, @02:03PM (#11375444)
  In what alternate reality can you run a program without using the installer? Aside from a few tiny utilities (putty.exe), nearly all Windows programs require an installer.

Depends upon the competency level of the programmer.

Older versions of Photoshop (5.5 and maybe 6.0) did not require an install to run, and neither does Firefox!

Whatever version of SmartFTP I am running does not, and neither do a good deal of my games or other applications.

A well written app either does not use the Windows Registry, or simply checks for needed registry entries upon first run and adds in any that are missing.

Pissy written applications crash and complain if any registry entries are missing.

Many Windows programs either do not use shared libraries, or keep a copy of any shared libraries around in their local program directory in case someone or something else decides to mess with the system32 directory.

I just got done reinstalling Windows 2003, without reformatting the HD, some apps work, others don't.

Heck Nero works without complaint (reenter CD key tis all!)

Hey, my fractal applications still work!

Seriously, the only issue I typically have is applications that either:

1. Hard code their own directory into the registry and then get stupid when they cannot find themselves.
   
2. Applications that use some stupid form of copy protection (that is why the newer versions of Photoshop have issues).
   
3. Applications programmed by dunderheads.
   

As I said, shared libs are not an issue, since most apps just package in their own preferred library version.

Yes I know that this is not "proper" practice, but darnit, it makes life SO much easier!

Re:Finally maybe someone gets it

[Brandybuck]

I've got a piece of software I release for Unix, Mac and Windows. When I originally created the Windows version I simply put all the files into one directory, zipped that up, and distributed it. To install, merely unzip to the location of your choice. Finished.

I had complaints with this simple scheme. So I had to make the a self extracting archive. Sigh.

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.

Re:Finally maybe someone gets it

[be-fan]

Depends upon the competency level of the programmer.
It has nothing to do with comptency. Indeed, if you package everything into a static executable, it is at least bad practice, if not incompetent. It makes a program suck up 10x as much memory as it needs to.

neither does Firefox!

Firefox certainly requires installation.

neither do a good deal of my games

What games don't require running an installer? No mainstream game I've used since the early 1990s comes without an installer!

Re:Finally maybe someone gets it

[i_should_be_working]

I have tried it and it is more like you say. click the application you want and it downloads a folder to your home directory. I don't know if the executable was actually in there. Must have been. But what I clicked on to run the program wasn't actally the binary.

It's pretty neat and for the most part worked. Sometimes (rarely) it asked me for permission to put something onto my system outside of the application's folder.

So I think it's great, and something like this will probably be the future of application installers for those who prefer it. I guess most of us are satisfied with the package management that our distro came with. Besides, obviously things like libraries can't be installed like this. But for end product applications, this thing seems great. Now they need to get it to support more distros. It seems they started with the KDE based Debian distros and will spread out to other Debian derivatives from there.

Re:Finally maybe someone gets it

[CTho9305]

You can download ZIPs of firefox releases (and nightly builds) with no installer. The installer just registers it as the default web browser, and creates shortcuts. It runs just fine without installation.

Re:Finally maybe someone gets it

[Anonymous Coward]

isn't uncompressing itself into a directory and registering as a default browser an installation?

Re:Finally maybe someone gets it

[OneDeeTenTee]

Just to bad you can't upgrade all your Windows applications with a command or two.

Re:Finally maybe someone gets it

[say]

When I originally created the Windows version I simply put all the files into one directory, zipped that up [...] I had complaints with this simple scheme.

No wonder, considering the fact that Windows did not ship with any kind of unzip until Windows XP. I too hated zip installs - mainly when I was reinstalling Windows or helping someone else install stuff - and most of all when the machine wasn't on the Internet. And WinZip is like 3MB, which takes a while on a 28.8 modem.

It is really quite funny that Windows didn't ship with unzip, but maybe it was because they were afraid of being accused of monopoly abuse?

Re:Finally maybe someone gets it

[OneDeeTenTee]

Crud. I should have used the preview button.

Let's try that again.

Just to bad you can't upgrade all your Windows applications with a command or two.

I want to see a single klik way to transparantly upgrade my parent's WinME box to Linux. Not because they have lots of trouble with it, it's just because it's WinME.

Re:Finally maybe someone gets it

[certsoft]

That's what we like about generating Windoze executables with Delphi. It has a smart linker so it only links in the library routines it actually uses and produces one EXE file for the program. This EXE will run correctly on anything from '98 to XP without change. When the Linux community finally decides on ONE executable format that will run on just about any Linux installation, then they might have something.

Re:Finally maybe someone gets it

[Anonymous Coward]

"Also, Windows people are a bit more paranoid about updaters, they tend to get disabled VERY quickly."

Hence most windows installations being quite out of date, and vulnerable to exploit.

"What ensures your trust of a one click update that downloads from multiple sources? Sure you may trust most of the sources, but I would not want to download an update from a company such as, say, RealNetworks, without hand inspecting every last little bit of it first."

For most major distros all updates done like this are normally from an official repository, where every last little bit has *already* been hand inspected, and had to be given the green light to be put into the repository. Obviously this applies to the stable branch of your distro.

Re:Finally maybe someone gets it

[Anonymous Coward]

Actually, for the most part, it's the USERS that require the installer, because they don't know how to unzip an archive and place the contents into a directory elsewhere. This is actually the largest part of the work an installer does. Then the bells and whistles (creating icons, and then - shudder - registering the software into your registry.. for whatever reason the company chooses to do that). You can test this for yourself by using a pc that has not had said software installed on it before and simply copying the software from one system to another and running the appropriate exe to see if it will run. I have seen very few programs that will not run this way. You will see the occasional error about a missing file, but that should be easy to fix (and if you can't figure that out you shouldn't be doing this anyway).

Re:Finally maybe someone gets it

[DarkTempes]

that is by far the most ignorant thing i've ever read... you think there arn't executable binaries in linux? boy, you are seriously deranged. i dunno how that became to be 'insightful' as it seems more flamebait anyway, more on subject alot of popular linux applications have binary installers (mozilla for example), but it's not that hard to do "./configure; make all; make install;" anyway if you were compiling from source though having a centralized web-interface for this sorta thing is nice...but the real question is, how easy is it to UNINSTALL applications. (which is also a problem windows has had for years...)

Re:Finally maybe someone gets it

[Com2Kid]

• It is really quite funny that Windows didn't ship with unzip

I'd gather either stupidity, or they just didn't want to bother licencing the algorithm.

Who knows, there is likely some software industry politics behind it, or maybe MS was just being stupid. Heck MS has always tried to push one of their own inane compression systems during each release of Windows (to almost zero success), but I doubt they ever considered these apps to be real competition to mainstream compression utilities.

Quite frankly XPs built in zip support absolutely bits, and I wish there was some way for me to disable it from the OS itself.

Re:Finally maybe someone gets it

[Com2Kid]

• that is by far the most ignorant thing i've ever read... you think there arn't executable binaries in linux?

Stand alone executables, read the comment right above yours.

I have a slew of applications that are either just a stand alone executable, or a stand alone executable with some supporting data files in the directory.

So

Damn

Simple.

I go to the directory name (which is also the program's name! Hey how about that!) and I type in the program's name.

The program runs.

Or I use a GUI to go to the directory the program is in, I click on the program's executable.

The program runs.

Seriously, I don't have to know anything about any particular system, I can sit down at any Windows box and in a matter of minutes have mapped out exactly what is on that particular system just by browsing around a bit.

• but it's not that hard to do "./configure; make all; make install;

Two questions:

Why should my Grandmother have to compile her own programs;

Why the hell should I have to compile my own programs! I don't GIVE A RATS ASS ABOUT COMPILING MY OWN PROGRAMS THAT TAKES TIME

Half the shit I get off of the web I just open right from the website, hell some convienent utilities that are small (under 100k or so) I just type in the damn URL to when ever I need to use them! Yah its not safe, but I trust the app vender, so I don't care!

Fundemental principle:

INSTALLING AN APPLICATION SHOULD TAKE LESS THAN TEN SECONDS OF MY TIME AND THE FIRST 8 OF THOSE SHOULD BE SPEND ON DOWNLOADING.

If I am trying to find a new audio editing app, within an hour I want to have tested out at least eight or nine different applications.

Or more.

Click, Run, Done.

98% of everything is crap, open source or not, I want to sift through the crap as fast as possible.

Re:Finally maybe someone gets it

[Anonymous Coward]

It HAS an installer, but doesn't NEED one.

Re:Finally maybe someone gets it

[Coryoth]

I have a slew of applications that are either just a stand alone executable, or a stand alone executable with some supporting data files in the directory.

Yup, it's called static linking, and it's actually not all that good. Linux could do it, but made a chocie not to go that route - open source went the hard way and ended up with lots of dependencies. That has meant solutions have been slower (we're still waiting on solutions for third party apps, but they're coming), but it will be worth the effort.

Statically linking so that your binary is self contained means:

(a) You are wasting RAM as each binary loads its own version of all the commonly used libraries.

(b) Your security is poor. If some commonly used library gets compromised you have to update every single application that linked against it - which could be a large number indeed. If it's all dynamically linked (with dependencies) you update the library, and all the apps just automtically use the patched version.

You're not going to get statically linked binaries, as it's just a dumb idea all around. What you will get is solutions like RPM, dpkg, apt, apt-rpm, yum, portage, zero-intstall and autopackage which will make installation as easy as you seem to want it to be - you'e just going to have to wait another year or three for the final few pieces to slot into place and the user friendliness to fully kick in.

Jedidiah.

Re:Finally maybe someone gets it

[Alioth]

Umm...there *is* only one executable format for Linux, it's called ELF, and it's been the format since at least 1996.

Re:Finally maybe someone gets it

[andrew71]

I believe that the concept of software package is fundamentally flawed. As you correctly point out, even today's most polished implementations (which are IMO the overall best you can get) have endemic problems.

It may end up that package managers are workarounds, not solutions.

IMO, what's needed is:

• Working, efficient versioning system for shared code;
  
• Execution and Dynamic linking mechanism that is not bound to dumb file system hierarchy. May we add, in year 2005: a secure and network transparent one;
  
• Organized, multiuser, network-aware management for software preferences
  

I think that is not too much to ask for today. But maybe Rob Pike is right.

Re:Finally maybe someone gets it

[IamTheRealMike]

OK, any modern OS uses shared libraries and this is a good thing. Let's take that as axiomatic. There are a few people around who believe that shared libraries are inherantly evil and should go, but they apparently don't know anything about operating system engineering. Clearly if they did, they would not say that.

So like any powerful tool, there is a tendency to overuse it, or use it where it's not appropriate. Without shared libraries we could not have systems like Windows XP, Linux or MacOS X because no machine today would have enough resources to do it at an acceptable speed. But nonetheless, it's undeniable that managing them correctly turned out to be significantly harder than expected for all operating system developers.

Linux treats software as a set of nodes on a graph, with each node representing one small piece of software. Dependency resolvers like apt treat every node as of equal importance, there is no distinction between system level packages and third party packages. They work by doing a topological sort on the dependency graph (amongst other things). This works well as long as the software has representation in the graph. If it does not then things start to break.

Windows treats software as falling into two camps: system level software and third party software. However the line is often blurred, because Microsoft distribute upgrades like DCOM98 and DirectX 9 as installers that can be distributed with third party software. These updates then appear in the Add/Remove Programs window. The advantage is that people get insane value for money out of a Windows purchase: you're still able to play games like Pirates! which needs DX9 on Windows 98, an OS that is now seven years old. The disadvantage is that this process was never thought through or managed and the inevitable result was "DLL Hell".

MacOS X is simply a more extreme version of Windows. There's a clear cut distinction between system level software and third party software. While third parties can ship newer frameworks inside themselves (Windows/Linux devs can do this too but generally don't ...) this facility is hardly used. Instead Mac users have to put up with a crazily fast release cycle: try finding MacOS X apps that still work on the original 10.0 release - it's not actually that old, but there are almost none. In fact many programs require the very latest release in order to function correctly. Remember that each major version upgrade is $120!

So all these platforms suffer "dependency hell" though it comes in different forms and is known by different names. Should Linux change?

Yes ... yes I think it should. The situation where non distro-provided software requires Herculean efforts to install is simply ludicrous, as distributor packaging has been empirically shown to have serious scalability problems. Right now projects like autopackage simply attack the problem with code - the idea being that by providing a new system that closely integrates with the host system (apt/yum/emerge/etc) but is nonetheless specifically designed for third party software, we can begin separating the graphs and so provide a stable platform on which Linux developers can build. It's only one part of the puzzle and is currently woefully incomplete (for instance, it can't resolve dependencies from Debians apt yet).

But long term the direction we must go in is a hybrid - a stable, well specified base platform which is documented and predictable, with powerful dep resolver technologies to allow us the flexibility to quickly deploy new code without compromising system efficiency. With it must come a realisation that sometimes static linking is OK, even necessary if we are to achieve that goal. If dependencies are causing your users more pain than gain, don't use them

Re:Finally maybe someone gets it

[dodobh]

For me, definitely. I run a few GTK+ applications, a couple of Xlib apps so I definitely see large savings in memory use.

Note that I don't use GNOME or KDE, so the actual savings are quite high. The top two memory hogs are Mozilla and X at the moment. My GTK+ apps are using about 4 Mb of RAM each, but 3 MB of that is shared memory, so the effective use is about 8 MB or so.

Re:Finally maybe someone gets it

[Com2Kid]

• Firefox certainly requires installation.

No it does not. I just got done reinstalling Windows 2003, and my Firefox installation still works fine.

Re:Finally maybe someone gets it

[Com2Kid]

• (a) You are wasting RAM as each binary loads its own version of all the commonly used libraries.

To a limited extent, but, a lot of programs do not need all of those libraries. Rememeber Windows does not have the "million and one small tools to complete a task" mentality that *nix has. The disadvantage is, tons of things that can be done at a *nix command line may need to be done by hand, advantage is, small crap is just included in with code!

Seriously, many of the applications I use do not use external statically linked libraries, and those that do tend to use the different sets of libraries anyways, so having 5 shared libraries in memory would just mean having one application using each shared library and netting me zero efficency gain.

Seriously, about the most common library is Zlib, and umm, not too often do I run multiple applications that handle zip files at the same time.

Actually I don't think I ever do.

MS provides the GUI shared libraries, OpenGL and DirectX are shared, I fail to see what other shared libraries I could possibly use.

Re:Finally maybe someone gets it

[be-fan]

That doesn't change the fact that Firefox requires you to run an installer first, to put all the files in place. That is something different from still working after an OS upgrade. Nearly all Linux apps are like Firefox: there is no registry, regular apps don't put anything in /etc, and they auto-create their dot-files under ~ the first time they run. So as long as you've got all the binaries and libraries (ie: you copy your /usr to a new drive), they will still work. But, like nearly all Windows programs, they require something like APT to get all the pieces laid out in the first place.

Re:Finally maybe someone gets it

[Com2Kid]

• That doesn't change the fact that Firefox requires you to run an installer first, to put all the files in place. That is something different from still working after an OS upgrade. Nearly all Linux apps are like Firefox: there is no registry, regular apps don't put anything in /etc, and they auto-create their dot-files under ~ the first time they run. So as long as you've got all the binaries and libraries (ie: you copy your /usr to a new drive), they will still work. But, like nearly all Windows programs, they require something like APT to get all the pieces laid out in the first place.

I could zip up my Firefox directory, move it to a separate computer that has never had Firefox installed on it before, and Firefox would still work just fine.

This isn't an OS upgrade, this is called I nuked the entire Windows directory and installed a fresh new copy, all shared libraries etc are gone.

Re:Finally maybe someone gets it

[Anonymous Coward]

Maybe you ought to tell firefox about this unknown amazing capability. Hell, maybe your zip file will also work in Unix and OpenVMS.

this is wierd, totally

[l3v1]

It says 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.

Somebody mentioned earlier this is like apt with web access. Well, reading that, it's more like brain-extracted rpm with web access. You want it, take it.

Re:this is wierd, totally

[Billy the Mountain]

I don't think that dependencies are handled very well in apt-get, rpm, etc. All too often, by installing one 100K package, you wind up installing 1GB of dependencies. As far as I can tell, there's no alternative except for the override in rpm. I think the next generation installer is going to present a graphic dependency map showing you why the dependencies might be needed and let you determine which ones you are going to install.

BTM

Re:this is wierd, totally

[sirReal.83.]

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.

Re:this is wierd, totally

[Anonymous Coward]

Firstly, that is an extrodinary exaggeration. I have never needed to install a whole gigabyte of dependencies (in many instances, only a few megabytes on my working Debian system).

Secondly, you need those dependencies. The code won't run otherwise. If you're going to call a function, it needs to exist. And its packaged into a dependency.

Thirdly, apt-get does something similiar. It will install only the absolutely required dependenices, and then tell you what packages are recommended/suggested to get other features from a program.

Re:this is wierd, totally

[say]

Uh. Why would you want to install a package without the other packages which DEPEND on it? Apt (at least) does install a conservative number of dependencies, and presents you with a list of recommended packages (if any are optional).

Re:this is wierd, totally

[Billy the Mountain]

I'm talking about the scenario where package a uses icons from package b, so you go ahead and install package b but package b has a dependancy chain, etc. Yes, strickty speaking you would need all that to install the original package, but what if you had the opportunity to substitute the icons with something else?

BTM

Re:this is wierd, totally

[bfree]

I was just trying to get across how dependencies are handled by klik. If you are on a supported distro they should not be a problem, if you are not on a supported distro then you may not have required libraries. As one of the major complaints in the previous slashdot story on bundled applications was about how many copies of libc or other common libraries may be around I wanted to get across that there is a slight solution to this in klik.

Re:this is wierd, totally

[zerblat]

I'm talking about the scenario where package a uses icons from package b

What package does that? If package b includes some files that are commonly used by other packages, those files should be packaged separately in, say b-common. Debian has lots of *-common packages.

If it's just a few icons, another alternative would be to simply ask the person who packages a to include those icons in a (renamed or in another directory, so a doesn't conflict with b).

Re:This Is What I Get At The Site Using Windows Op

[Master of Transhuman]

Of course, you never want to tell a site you're using Opera - then they pop up some crap telling you to use IE!

It's bullshit either way.

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:This Is What I Get At The Site Using Windows Op

[marcosdumay]

What do you want to do in a debian repositore using windows? Just slashdot it?

Re:This Is What I Get At The Site Using Windows Op

[Master of Transhuman]

Er, read it while I happen to be using Windows?

Duh...

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

How does it work without root help?

[caseih]

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?

Re:How does it work without root help?

[Anonymous Coward]

Read the install script. A few entries must be present in your fstab. And it looks like you can run at most 7 cms apps at once, system-wide. Relatively clever, but very limited right now. NSBD tried to address similar problems though funky use of installation prefixes. That attempt is pretty much dead, too. (It would go apeshit on Reiser4.)

What you really need for these tricks is process-specific namespaces with bind mounts. Oh, wait, that's available in Linux. hmmm.

Re:How does it work without root help?

[OA]

Yes. Not only that, when installing, I am sure dependancy needs to be met and install scripts need to be run.

You can break your system hard.

Post inst script of rm -rf / will wipe yor system. So I really need some more explanation before I Klik from my Debian PC.

Osamu

Re:How does it work without root help?

[caseih]

Yes I did discover the the fstab information. It seems quite limited in its present state and does not seem to address any of the software installation problems that we currently face in linux.

As for mounting the compressed file systems, they could use avfs (relative of fuse) to virtually mount the cmg file and intercept all file i/o calls to make it appear as though the cmg was mounted and give transparent access to these files. Such a scheme would not require any root support at all, since it would all be done with a ld_preload.

Re:How does it work without root help?

[bfree]

Nope, you are quite wrong. When installing the dependencies are calculated against a base set of assummed packages (from the supported distros) and no install scripts are run. Config files can be copied to /etc if you so wish and snap with files destined for /var (you are prompted to copy either if they are present). Besides, klik is run as a user, and needs no root privileges (except for the presence of suitable mount points in fstab).

Re:How does it work without root help?

[Anonymous Coward]

I wasn't aware of avfs, thanks. I tend to believe that something like what you suggested is the right thing for ELF-like platforms. AIX is a pain, though, and I need packages to work on that, too. wheeee... (AIX can use ELF, but also uses its own variation on COFF. Such joy.)

Re:This Is What I Get At The Site Using Windows Op

[Trimbo2]

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.

Re:This Is What I Get At The Site Using Windows Op

[omicronish]

Being a Windows user and being interested in Linux are not mutually exclusive things.

I first tried Linux back in high school after hearing about it from friends and even bought a copy of Red Hat Linux 6.2. I've installed Slackware after seeing it mentioned a lot on the Internet, and Gentoo I discovered one day probably through Slashdot, and after reading their installation guide I thought "cool, I'll give it a try." In fact, I'm downloading GoboLinux right now after being reminded of it through the last link in this story.

Exposure is a good thing. You can't gain supporters if you deny potential supporters the chance of learning about you. And yeah, I'm a Windows user.

Re:As a Gentoo user

[ant_slayer]

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.

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 /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.

It just seems to break the foundational philosophy of the distribution to me.

-Ant Slayer-

Re:OO is NOT "the best way to demonstrate klik pow

[Anonymous Coward]

"OpenOffice is one of those huge projects which come in preinstalled preconfigured and self sufficient package which have to be decompressed in one directory."

More to the point, you don't ever want to download OpenOffice twice (it takes a week on a modem or something), which makes the tar.gz feel like a safer option, if you must download it at all.

Download and Run

[Anonymous Coward]

I didn't read much after the first half of the responses, because that's where they ceased to make intelligent points.

Anyway, I don't know how files are installed in OSX, and I don't understand exactly what kilk does. However, Windows has a terrible way of handling programs. Sure, there is a point-and-click installer. Which spews program chunks all over your computer, including in the cryptic registry. At that point, you have to run the uninstaller to remove it, and that doesn't always work perfectly.

What I want, and what klik seems to offer, is the ability to download a single file for a program and run it. Not run an installer and then run the program. Make the program be one file requiring no chunk-spewing installation. Download and run. Move it when you want. Remove the entire program by deleting that one file. Exactly like PuTTy.

Yeah, I realize that it's hard. But you know what? Whoever pulls it off properly is going to have something very good going on.

As a BSD User

[Anonymous Coward]

I'am not sure if i should be here

Re:As a Gentoo user

[Taladar]

The optimizations are not important for lots of gentoo users. What is important is the freedom of choice regarding optional dependencies. With Gentoo you can e.g. remove mysql-support from all packages and ignore (not install) mysql. Since mysql is a popular package most binary distros come with mysql support compiled in their binaries so you have to install it even though you don't use it.

Coooool.... even FreeNX is installable!

[Anonymous Coward]

Cool stuff....

I used klik to install FreeNX and kNX http://www.nomachine.com/ onto a customized SuSE (with lots of self-compiled software that dis-allows now to use SUSE updates) -- and it works like a charm.

Really, really cool. Good job, probono!

Great

[Anonymous Coward]

The officially supported list of distributions is now Knoppix (3.7), Kanotix (BHX), Linspire 5.0 and Simply Mepis (2004.04).

This will be really popular once they support Yggdrasil. Think of the size of the userbase!

KDE-kentrik worldview, sure!

[Anonymous Coward]

## "Is it me or do the k-folks have a totally kde-centric world-view?"
----
Aktually, you are right at first. I am a k-guy, and I have a totally kde-kentrik view. So no, it is not you, initially.... But that changes:

## "who but them would develop a software installation system that has kde as a dependency..."
----
As a matter of fact, klik first was developed to install additional software into a running Knoppix. In case you dont know: Knoppix is a Live-CD system. Which uses KDE as its default GUI. So initially the dependency on KDE was a real one, for various reasons.

## "...and ensure that way that [....] no distribution [....] can use their system?"
----
Actually, you didnt get it right here either. That dependency on KDE is now _removed_. Even _you_ could test klik in all its glory, if you cared.

A step in the right direction

[redmoss]

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).

Mom test

[Anonymous Coward]

besides being stable and damn good looking!

Please, tell us more about your mother.

As a Linspire user

[Mindmatter]

It's nice to see that Linspire customers can use a free alternative to Click n Run, and get out of paying yearly for such a service. The only down fall is the lack of OS updates. But at least its another choice.

Only good for LiveCDs

[DuckofDeath87]

I have been using Knoppix 3.7 from the CD for a couple weeks, and klik is a great way to get software that is not normally availble. However, I would hate to run this on a writable system.

For one thing, as far as I know, you have to run klik in a webbrowser. It is a protocol (klik://). I do not think there is a way to run it from a command line yet, and that would just makes it easier sometimes.

Also, the way it is set up right now, it is very dependant on the central klik site, which was down for a couple days, so I could not run the klik software during that time.

I would like to beable to easily download the .cmg files directly and just run something like AppRun appname.cmg and be done with it. then if i were to save the file to a diskette or another computer, I would not have to worry if the site was down.

But, it does serve its purpose. I can usually run nearly anything from my livecd, which is great.

Similar to .app or .dmg on OSX

[aristotle-dude]

If you look at the architecture http://klik.atekon.de/architecture/, you will see that it was heavily inspired by the .app structure from NeXTStep/OS X and mountable .DMG disk images from OS X.

It's a good start.

Re:As a Gentoo user

[fsterman]

It's a joke, Sarcasm- [don't] get it?

Re:This Is What I Get At The Site Using Windows Op

[themightythor]

What did you expect? It's a system for installing Linux software. You ran it on a non-Linux operating system...which is therefore unsupported. Jebus...

Re:SuSE 9.2

[Anonymous Coward]

While I agree with you, SuSE is near impossible to upgrade from one full release to another without breaking stuff. Last attempt was 8.2 to 9.1, and I was left with a crippled system with no KDM even. This was using their built-in automated upgrade (system-breaking) tool.

god uses Gentoo

[Anonymous Coward]

thats why it took 6 days to put everything together.

guess thats better than him using windows.

maybe the dinosaurs were killed by a BSOD?

Hmm

[t_allardyce]

To be a fully usable system for 'home' users it needs root access so it can install spyware etc. It also needs to be able to hide some file somewhere to implement those 30-day trial counters. Also if it could handle installing absolutely anything, from source, and fix all dependencies in a single click i'd be happy.

Re:This Is What I Get At The Site Using Windows Op

[Anonymous Coward]

I dunno how you got modded +4 informative... maybe +3 intersting ;) but man... first off, you're using a browser from windows, that can tell websites it's any browser it wants to pretend to be. Secondly, they actually have a link to install opera right from them. I'm using firefox, on windows, and it Tries to install but fails to find the required client (much less linux OS) to actually install applications.
From what I've heard other people saying is that
if you were actually in linux, had the client installed, and were running the opera browser, were mimicking firefox for user agent, you could use klik to install software.
if it didn't (install applications) all you'd have to do is muck about with associations so that opera knew how to handle the data stream, and connect it to the client.. But since you can install opera from klik, I'm somewhat certain that it will work, when user agent isn't being 'spoofed' as ie.

Yggdrasil

[nurb432]

Hey, in their day they were really innovative.

One of the first simi-live cds with a truly GUI install. I even bought a copy back then. ( doing my part to support OSSish development )

They were a bit wierd thou.. explains why they dissapeared.

Re:As a Gentoo user

[ColMustard]

Actually, ther real way to install things is probably the Mac OS X way...

Click. Drag. Drop. Done.

poor excuse

[asv108]

Why would I want to? Most software I own is not updated that often (surprise surprise!) and often times I do not want the latest greatest themable UI that sucks up another 4 or 5 megs of memory.

As a rule I only download a new version when security issues appear.

You must spend a lot of time keeping track of security vulernabilities if you plan on keeping all your software up to date manually. How do you even keep track of the updates? Do you visit the web page of every software package installed on your windows system every week? Between security updates and software updates, you must spend 1/2 the week browsing websites.

This is a huge advantage of Linux packaging systems, with distributions like debian and gentoo, I can keep my whole system secure and up to date with a single command.

Re:poor excuse

[Com2Kid]

• You must spend a lot of time keeping track of security vulernabilities if you plan on keeping all your software up to date manually.

Winamp, SmartFTP, AIM, umm, a few others perhaps.

Most of the apps are either large enough that they have a built in check-on-run updater that pops a big "Yo Security Error!" message box on my screen when something is seriously wrong (upon which I then go to the website and check) or that security issues with them get posted to at least a few of the main tech news sites.

Not being in a server enviroment, most of my applications either not hooked up to the net, or not hooked up to the net in a fashion that gets them near executable code (or hopefully any buffer overflows!)

Strangly enough, it isn't an issue.

Seriously. The two pieces of software I have to update the most are Firefox and IE.

Wish I was kidding...

Re:poor excuse

[Anonymous Coward]

There isn't really any point trying to enlighten you. You are an official fuck.

Re:This Is What I Get At The Site Using Windows Op

[marcosdumay]

Sorry, I really expected the comment to be funny. Bad choice.

Re:As a Gentoo user

[Anonymous Coward]

Sounds to me like another distro than Gentoo would be more suitable for you then.

step backwards

[jeif1k]

I think this is a step backwards. Linux installations are already "one click", with an excellent user interface: you go to the software directory ("package manager"), select what you want to have installed, and it just happens. That works in most modern distributions. After you have selected what you want installed, it gets maintained and updated automatically.

Klik seems to take us back to the cumbersome systems that Windows and Macintosh use, where you have to download applications and worry about when they are going to get upgraded and whether the different pieces that are installed are going to be compatible. That is not progress.

Please let's not dumb down the Linux package system to the level of Windows or Macintosh: that would be bad for all users, expert and novice alike.

Re:step backwards

[aristotle-dude]

This was modded as insightful?

Klik seems to take us back to the cumbersome systems that Windows and Macintosh use, where you have to download applications and worry about when they are going to get upgraded and whether the different pieces that are installed are going to be compatible. That is not progress.

The .app packages that OS X use combine the dependencies within the .app directory so you don't have to worry about incompatibilities or causing problems with other apps in case the version of the dependencies an app uses has bugs in it which might become exposed when used with a different app. Since the dependencies are included, they get updated when you upgrade the .app. Difficult huh? Uninstalling is as easy as deleting the .app package.

Instead of spreading FUD, take some time to RTFA, read the info on the project website and learn something about the OSes you would criticize.

Re:step backwards

[jeif1k]

The .app packages that OS X use combine the dependencies within the .app directory so you don't have to worry about incompatibilities or causing problems with other apps in case the version of the dependencies an app uses has bugs in it which might become exposed when used with a different app. Since the dependencies are included, they get updated when you upgrade the .app. Difficult huh?

Not difficult at all, it just doesn't work.

First of all, applications have dependencies on operating system libraries, which are not included in .app directories. Updates to OS X do break applications.

Second, different applications obtained from different sources have dependencies on each other: Mozilla has plugins, word processors and spreadsheets may embed each other, etc.

It would be nice if the solution to the dependency problem was as simple as putting everything into one big directory, but it isn't. It may be good enough for 90% of Macintosh home users, who only run iLife, Safari, and MS Office, but just about anything works for that.

and learn something about the OSes you would criticize.

I know more than enough about OS X, and I know what a pain software installation and maintenance is on it compared to a good Linux distribution.

Maybe you and all the other Macintosh zealots should get your heads out of your asses and learn something about other platforms for a change. Go install a copy of Ubuntu Linux or SuSE and see how easy things can really be.

Re:step backwards

[aristotle-dude]

I happen to use an extensive list of shareware and open source applications without any problems at home.

I have not experienced any problems with open source applications which include the dependencies within the .app package. I don't see it as a "good thing" to have a linux equivalent so/dll hell happening where you have various applications overwriting libraries with newer/less stable ones for the sake of adding additional features.

Rare is the case that an OS update (other than windows) will break a lot of applications. I have not experienced any broken apps from any OS X updates other than gui hacking tools but they were quickly updated by their authors.

Me? A Mac zealot without a clue about other platforms? I will have you know that I get "paid" to write in house software on both the Windows and Linux platforms.

Did you know that the .app package evolved on the NextStep/OpenStep platform? Interestingly enough, Sun and HP were originally part of the group OpenStep group and if you look at the directory structure of a Java .jar file (renamed .zip), you will see how similar it is to the .app package directory tree. Also, Java was heavily influenced by Objective C. You could say that both Java and .jar files were the direct result of Sun's involvement with the OpenStep platform.

Read up on NeXT and OpenStep and then perhaps we can have an intelligent exchange of ideas. Learning about that platform will help you understand OS X better.

Please enlighten us as to how it is a "pain" to install, update and uninstall software with drag and drop. Do tell.

Re:This Is What I Get At The Site Using Windows Op

[omicronish]

Oh, no worries then :)

Re:This Is What I Get At The Site Using Windows Op

[strider44]

So you're complaining that the site won't display properly to people who can't use it anyway? It only gives an overview of the product and a location to download it should you want to . . . and that's bad?

This is a piece of software for linux that can only be used on linux. I don't see why not being able to view the software on Windows is a problem.

Very nice, but there are other problems...

[Anonymous Coward]

I installed Knoppix 3.7, which was a breeze, and while visiting the Knoppix forum saw the announcement of a cmg file for OpenOffice 2.0. I browsed over with Konqueror and downloaded and installed the small gui app for Konqueror. Then I downloaded the cmg for OO 2.0

What cmg does is act like an iso running under a mount loop. Very neat. Very fast. Very easy. The sooner it becomes standard install proceedure for apps the better. This putzing around with dependencies is getting long in the tooth and it is time to retire that old dog. With RAM and HD space so plentiful these days I don't care if I have 10 copies of a library, each tied statically to one of 10 different apps.

The problem I have is with the Knoppix distro itself, and clones like Kannotix, SimplyMEPIS, and non-Live distros like Ubantu, Xandros, and Debian itself, all of which I have tried in the last two weeks, is the apt-get feature. Apt-get is both a powerhouse and a bomb that will go off in your face sooner or later.

The first time I installed Knoppix I immediately did:
apt-get update
apt-get upgrade
apt-get autoclean
Around 400MB of upgrades were downloaded, bring Knoppix "up to date". I rebooted the xserver and things seem to work great. I used apt-cache to search and find my favorite apps, and apt-get to install them. My DVD's played beautifully! Adding and removing apps with apt-get is child's play. I thought I was in Linux heaven!

Then, a tongue of fire reached up from below and gave me a hot seat... I asked apt-get to install a particular app and it responded by saying it would update 3 or 4 files and install 1. One of the files it updated required the complete removal of KDE !!! I watched fearfully as file after file was removed. Then the prompt came back. With fear and trepidation I entered "apt-get install kde" and watched the fireworks. About 400MB later I restarted the xserver and was presented with a new 3.3.1 KDE screen! KDE off and on in two easy commands! I was breathless. Within a day or so that scenerio repeated itself again. The third time it happened I wasn't so lucky... KDE was hosed.

So, I tried Kannotix. It's creator says he likes Knoppix but wanted to "improve it". It ran fine as a Live CD but after I installed it and installed a few apps and their dependencies the xserver wouldn't come up. It was then I discovered how ancient Debian's management tools are. Does xf86cfg tickle your admin chin? I finally had to resort to that ancient Unix technology, xf86config, to get the job done. I tried the apt-get update, upgrade, autoclean on it and promply lost my internet connection when the fireworks were finished. It said I didn't have an eth0 card when I tried to reset the dhcp.

I won't go into Ubantu. I had it on for 30 minutes. I downloaded the 15CD Sarge set (twice!) , but the first CD confused my ncr53c810 SCSI card with my via_rhine ethernet chip and wouldn't let me change its mind or configure an internet connection.

I tried two Sarge net install isos, including the most recent but they hung up at the same place. I passed a paramter during boot to skip the ncr check and got through the install routine up to the point where I could select an eth0 card for the internet connection. Sure enough, the only card it would see was the SCSI card. No Debian for me if I have to use the

I tried SimplyMEPIS. It also is an easy install from a Live CD. It also has some better sys admin tools than the K or D distros. And, I was careful to make sure I was using only the Woddy or Sarge mirrors. No Unstable mirrors. But apt-get blew it off my computer too. The best Debian based distro I've tried todate is Xandros 2.5 Business. It has the smoothest install and the best admin tools of any Linux distro I've seen. But, it has apt-get too.

So, Kliks should try to get a gui version for Konqueror regardless of which distro Konqueror runs on, so that any Distro (MDK, FC, SUSE,..) can use the cmg technique.

KDE called.

[Anonymous Coward]

They want their 'K' back.

Re:This Is What I Get At The Site Using Windows Op

[Slack3r78]

You know, some people own more than one computer, and some people also use computers at work where they might not have control over what software is run. I happen to be on an XP box at the moment, but I have 3 machines in this same room running Linux. Somehow, I think this software could potentially be useful for me, even if the machine I'm on at this exact moment couldn't run it.

In short, while the webmaster may have thought they were being cute, this is just plain stupid. W3C standards are good, use them. Don't fall for this "Well, if I can't see your site, you can't see mine" crap. It's exactly the reason why the web was so broken in the NS4/IE4 era.

Re:As a Gentoo user

[incom]

What's wrong with getting a new, non-critical application running this way? I don't want to have to write an ebuild to try out a little game or something trivial like that.

Re:This Is What I Get At The Site Using Windows Op

[SpacePunk]

It's not a matter of a non-Linux operating system being used to view the site. It's this text "Please come back with a standards compliant operating system and browser." Who's standards? What standards? There are no 'standards'. If it said "Please come back with a Linux based operating system and browser" it would be another thing entirely. I get the feeling that the person(s) that put the page together are the same type of person(s) that berate people for asking a question about how to do 'X' in Linux using mixed case lettering and telling them they are n00bz.

It certainly won't bring more people to Linux.

Re:This Is What I Get At The Site Using Windows Op

[Anonymous Coward]

Who's standards? What standards?

Duh! The Klik standards.

More important question

[Anonymous Coward]

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?

It appears that APT (with tons of graphical frontends) already allows the downloading and running of software in a liveCD environments (Knoppix, Morphix, Dynebolix--you name it) with automatic dependency resolution. What is better in klik even in a liveCD environment? Is it just Yet Another Bad Idea(TM)?

Re:This Is What I Get At The Site Using Windows Op

[Anonymous Coward]

W3c standards - IE? You're joking, right? Turnabout is fair play. Screw IE. It is a dead browser that is Microsoft is not doing anything to improve and never will unless it promotes their hegemony. There is no good reason for anyone to run IE any more. Those web sites whose designers were stupid enough to make their site dependent on IE should be boycotted until they get the message that supporting standards compliant browsers like Mozilla is in their best interests. Only then will we be able to take back the Internet from Microsoft and its minions.

Re:This Is What I Get At The Site Using Windows Op

[strider44]

it also allows them to utalize features that every other browser except IE (and perhaps lynx) has like transparant PNGs.

Re:This Is What I Get At The Site Using Windows Op

[Master of Transhuman]

Heh,heh, you must be new here - there ARE NO funny remarks on /.! If you don't offend someone, you get modded down...

Re:This Is What I Get At The Site Using Windows Op

[Master of Transhuman]

I didn't run anything. I went to the site to see what it was about.

Duh...

Re:This Is What I Get At The Site Using Windows Op

[Master of Transhuman]

Look, moron...

I run Linux AND Windows. What part of that don't you comprehend?

I'm NOT trying to RUN anything. I'm visiting a fucking Web site, okay? I don't like it when I use Opera and some fucktard tells me his site won't even be SHOWN to me because I don't use IE, and I equally don't like it when some Linux fucktard tells me I can't even VIEW his site because I "don't run Linux" when IN FACT I DO run Linux.

Get the picture now?

I download TONS of software from Linux sites for Linux using Opera running on Windows 2000. I even store it on a FAT32 partition under Windows 2000 until I can get around to booting Red Hat and moving it over to the Linux ext3 side of the machine.

This asshole is somehow different that I have to be using Linux to even view his site?

Bullshit. His site should be viewable in any half-way modern browser, period.

He's a moron - and if you can't grasp that, you're a moron, too.

Download from work using Windows?

[billstewart]

Some people use Windows machines at work and have faster internet connections there, or CD-burners, or more spare time (:-). Why not allow downloads from there?

Re:Download from work using Windows?

[bfree]

There is nearly nothing in klik which can be downloaded like that. Klik builds the packages on your machine. I'm not denying there are some things which could/can be downloaded/browsed from windows (the openoffice.org cmg can probably be grabbed). Klik isn't just a normal site, it's a web software installer which depends on a klik client running on the target host for the program.

Re:This Is What I Get At The Site Using Windows Op

[Aeiri]

Turrents syndrome for 100, Trebek.

For use with Knoppix 3.7, Simply MEPIS 2004.04, Linspire 5.0 (need to install client first), and Kanotix BH X (client preinstalled).

Here, to appease you I'm going to leak some of the content for you:
klik://ada-mode
klik://ed
klik://ee
klik://ee

Use these links in any way you wish.

Re:This Is What I Get At The Site Using Windows Op

[Aeiri]

Whoops, "turrets"... used to typing "torrents" since we are on /....

Also one of those links should be 'klik://e3'.

Re:This Is What I Get At The Site Using Windows Op

[Anonymous Coward]

"Tourettes"

Re:This Is What I Get At The Site Using Windows Op

[Master of Transhuman]

Yeah, you just gotta love these /. highly educated technical nerd-boys...

Can't even respond to the right post...:-)