Slashdot Mirror

I believe the people behind autopackage will disagree with you. Nonetheless, I don't see how universal binaries would get rid of those non-issues. So, besides universal binaries being a solution looking for a problem, exactly what problems do they actually solve?

Isn't that was http://autopackage.org/ is trying to do to?
I find it a benefit of Linux if there is only one instance of a XML library in my memory, though.

Package management is wonderful, but we need to standardize the damn things. I vote for Apt-RPM. Choice is good and wonderful, but not when it is considering package formats. Just pick one so we can finally just post a "Linux" binary on the web that works with every package management system seamlessly. How kick ass would that be?

These two can be fixed now, and if anyone's awake at Red Hat, Debian or Canonical I suspect they will be.

No, it's not that simple. There are two major formats (deb,rpm), yes, but the actual packages across distributions are different. Mandrake and Red Hat both use rpm, for example, but their packages are completely incompatible with each other. There's a lot of info on the autopackage site about this stuff. The project is attempting to fix these sorts of cross-distribution problems. I think they've got a good start, but it remains to be seen whether they will be successful.

So, something like Autopackage only "borrowing" the name from Apple's marketing dept? No, thanks.

Actually you CAN double click to install applications on Linux. See Applications -> Add/Remove software. It's actually easier to use than Windows, since you can just search for what you want, click on it, and it's done, no need to schlep to a store, enter a product key, insert a USB dongle or whatever.

For applications that are not part of a distro, there is Autopackage - http://autopackage.org/ . We use it for Oolite. Our Oolite autopackage installer is a simple double click on pretty much any Linux install that came out in the last 5 or 6 years. Autopackage is better than Windows installer as it includes dependency resolution (yes, Windows packages often have dependency hell, especially Windows server software).

Understanding the OS innards is valuable but overrated here. It is having a platform (which Linux isn't) where the supplied APIs and UI are predictable and serve as a supportable common ground for ISVs and users.

"Linux" (or more accurately: the typical Linux-based distro) doesn't provide that support of personal computing culture. As a result, you tend to get app developers who are primarily interested in the workings of the OS, and interested in applications second or third or mainly as a way of showing-off to their hacker friends.

Another big problem is that the community wants control of driver development, but doesn't want to take responsibility when the system software doesn't fit the hardware properly and causes big problems as a result. It puts hardware developers in a backseat role when it comes to writing and especially distributing drivers. They know that an end-user will typically blame the entity that distributed the software that made their hardware run poorly... so the OEM's incentive to avoid bugs and slipshod default configurations is diminished.

Yes, there be bugs in hardware and firmware. BUT that highlights one of the value-adding properties of software: Work-arounds. The Windows and OS X ecosystems have their methods and incentives for getting workarounds applied in a timely and effective manner.

There is only one solution to these problems: Stabilize the core of "Desktop Linux" upto and including the desktop environment level, and stop trying to provide a comprehensive selection of drivers and applications-- they aren't properly a part of the OS and should be someone else's responsibility. It is the only way to make "Linux" friendly to independent hardware and application developers alike.

If you want an idea of what a proper platform (standardized UI, APIs, SDK, etc.) in FOSS looks like then Android would be a good place to start looking IMO.

an install.pl

Bad idea. Not everyone has Perl installed. Your best bet is probably Autopackage. My only concern would be permissions, since it of course needs to be executed (with /bin/bash). Are CD-ROMs usually mounted with +x? Or can you use ISO9660/Rock Ridge to set permissions?

When software moves between each seamlessly requiring the same steps and instructions exactly on each distro that uses that package format, with no extra effort from end users or developers, then what you say will be true

One word: Autopackage.

http://www.autopackage.org/ . We've been using it for Oolite since 2005. The game installs in exactly the same way on every distro that we've tested.

Have you considered using a distribution-neutral package format like autopackage? There are solutions written specifically for developers in your situation. Not everyone needs to build packages in native formats; really those are mostly for central repositories. If you're not distributing your app through a central repository, there's no reason not to use something like autopackage.

Admittedly, it doesn't yet have a UI for updating packages automatically from their sources, but the infrastructure for it seems to be in place (and is used to fetch dependencies), so I'd be surprised if that functionality isn't added soon enough.

Yes, simple;

RPM. Most users can download an RPM, double click on it, and it'll get installed properly.

I'm 99% sure that Ubuntu or Debian people can do similar things with DEBs. Of course, the downside with the package approach is you have to have one package per distro (take a look at Skype; skype isn't in any linux repositories, but it supplies 4-5 RPMs and a binary tarball).

If you prefer something that is more like a Windows installer, use autopackage. Autopackages are distro neutral. Here's the quote from their website:
# What is autopackage?
For users: it makes software installation on Linux easier. If a project provides an autopackage, you know it can work on your distribution. You know it'll integrate nicely with your desktop and you know it'll be up to date, because it's provided by the software developers themselves. You don't have to choose which distro you run based on how many packages are available.
For developers: it's software that lets you create binary packages for Linux that will install on any distribution, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface. It lets you get your software to your users quicker, easier and more reliably. It immediately increases your user base by allowing people with no native package to run your software within seconds.

As you can see from the screenshots, autopackage is pretty dead-easy for end users.

There are also next-generation packaging utilities that are overtaking Windows MSI-type things, including openSuSE's one-click-install, and KDE's klik://, but neither of these has taken hold with enough Linux distros yet (you have to be using SuSE 10.3, or install a package on older SuSEs, and klik:// requires a kio-slave).

Yes, simple;

RPM. Most users can download an RPM, double click on it, and it'll get installed properly.

I'm 99% sure that Ubuntu or Debian people can do similar things with DEBs. Of course, the downside with the package approach is you have to have one package per distro (take a look at Skype; skype isn't in any linux repositories, but it supplies 4-5 RPMs and a binary tarball).

If you prefer something that is more like a Windows installer, use autopackage. Autopackages are distro neutral. Here's the quote from their website:
# What is autopackage?
For users: it makes software installation on Linux easier. If a project provides an autopackage, you know it can work on your distribution. You know it'll integrate nicely with your desktop and you know it'll be up to date, because it's provided by the software developers themselves. You don't have to choose which distro you run based on how many packages are available.
For developers: it's software that lets you create binary packages for Linux that will install on any distribution, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface. It lets you get your software to your users quicker, easier and more reliably. It immediately increases your user base by allowing people with no native package to run your software within seconds.

As you can see from the screenshots, autopackage is pretty dead-easy for end users.

There are also next-generation packaging utilities that are overtaking Windows MSI-type things, including openSuSE's one-click-install, and KDE's klik://, but neither of these has taken hold with enough Linux distros yet (you have to be using SuSE 10.3, or install a package on older SuSEs, and klik:// requires a kio-slave).

I visited your Autopackage web site. I was quite impressed by the way you were able to figure out a set of simple instructions, understandable by grandma, that would work for most distros.

Once you can get the user to run a given application, the app itself can take over and be as user-friendly as you want, but the tricky part is to get them to run the app in the first place, using instructions that don't involve compromising the security of their Linux system. Your 4-step instructions, which don't involve any command line, was suitably impressive. You've figured out how to formulate the instructions so that it is consistent across the KDE and GNOME interfaces. (Having two possible desktop environments is a bit of hassle, isn't it, when it comes to giving user instructions?) And, even if the user fumbles around a lot and just happens to randomly succeed in getting Autopackage installed, from then on Autopackage is installed and s/he won't need to do it again.

In doing research for writing this reply, I learned about Zero Install from Wikipedia. This is also a distro-independent way to install software. Reading through the instructions, I see that it looks like you have to install the Zero Install launcher first, and then from then on you can install software. I think this is not as good as Autopackage, in which (apparently) the software installer comes with each and every package itself, so that grandma user doesn't need to do a separate step; just download TheSoftwarePackageIWant, and it will already set up Autopackage. (Presumably it's a stub that downloads the full Autopackage installer only if necessary, to save space?) Nevertheless, Zero Install is also a worthwhile system for allowing users to install software without waiting for the distro maintainers to do it.

Now, Klik is slightly different; as I understand it, it actually downloads and runs the program from a RAM disk, almost Knoppix-style (the last K in K.L.I.K used to stand for Knoppix). Very handy, from the developer standpoint, in establishing a way to temporarily install software in a consistent environment. That doesn't really matter to grandma users, though, and the main disadvantage I see for Klik is the complex first step that will turn lay users off: you have to get to a terminal (already a big hurdle) and then type in:

wget klik.atekon.de/client/install -O -|sh

But wait! If you run k/Ubuntu, first you have to type

sudo apt-get install binutils libstdc++5 rpm gnome-about

Not very user-friendly at all. (Granted, I don't think the goal of Klik is necessarily to be user-friendly.)

So, for the three systems, Autopackage, Zero Install, and Klik, I think Autopackage comes out the winner in terms of ease of posting instructions on the software author's web site. In other words, suppose I wrote a SuperDuper program that I want to give/sell to non-geek users of all sorts of Linux distros. Autopackage would best let my users download and run my software, without needing to send them to the actual web site for Autopackage / Zero Install / Klik itself.

Also, Autopackage and Zero Install have very friendly web pages, for when people do need to check them out. Klik has a very busy web page that's intimidating to new users, and, much as I hate to say this as a KDE fan, typical of how KDE is more for the technically minded people who want the dazzling array of switches and blinking lights, and not for the lay user who just wants to get things done.

But I'm impressed with the way packages can be basically distro independent now. I no longer think that having different packages is so much of an issue, and the software author who writes The Killer App (e.g. some cool game) no longer needs to wait for the distro maintainers in order to distribute the software.

All we need now is to spread th

I visited your Autopackage web site. I was quite impressed by the way you were able to figure out a set of simple instructions, understandable by grandma, that would work for most distros.

Once you can get the user to run a given application, the app itself can take over and be as user-friendly as you want, but the tricky part is to get them to run the app in the first place, using instructions that don't involve compromising the security of their Linux system. Your 4-step instructions, which don't involve any command line, was suitably impressive. You've figured out how to formulate the instructions so that it is consistent across the KDE and GNOME interfaces. (Having two possible desktop environments is a bit of hassle, isn't it, when it comes to giving user instructions?) And, even if the user fumbles around a lot and just happens to randomly succeed in getting Autopackage installed, from then on Autopackage is installed and s/he won't need to do it again.

In doing research for writing this reply, I learned about Zero Install from Wikipedia. This is also a distro-independent way to install software. Reading through the instructions, I see that it looks like you have to install the Zero Install launcher first, and then from then on you can install software. I think this is not as good as Autopackage, in which (apparently) the software installer comes with each and every package itself, so that grandma user doesn't need to do a separate step; just download TheSoftwarePackageIWant, and it will already set up Autopackage. (Presumably it's a stub that downloads the full Autopackage installer only if necessary, to save space?) Nevertheless, Zero Install is also a worthwhile system for allowing users to install software without waiting for the distro maintainers to do it.

Now, Klik is slightly different; as I understand it, it actually downloads and runs the program from a RAM disk, almost Knoppix-style (the last K in K.L.I.K used to stand for Knoppix). Very handy, from the developer standpoint, in establishing a way to temporarily install software in a consistent environment. That doesn't really matter to grandma users, though, and the main disadvantage I see for Klik is the complex first step that will turn lay users off: you have to get to a terminal (already a big hurdle) and then type in:

wget klik.atekon.de/client/install -O -|sh

But wait! If you run k/Ubuntu, first you have to type

sudo apt-get install binutils libstdc++5 rpm gnome-about

Not very user-friendly at all. (Granted, I don't think the goal of Klik is necessarily to be user-friendly.)

So, for the three systems, Autopackage, Zero Install, and Klik, I think Autopackage comes out the winner in terms of ease of posting instructions on the software author's web site. In other words, suppose I wrote a SuperDuper program that I want to give/sell to non-geek users of all sorts of Linux distros. Autopackage would best let my users download and run my software, without needing to send them to the actual web site for Autopackage / Zero Install / Klik itself.

Also, Autopackage and Zero Install have very friendly web pages, for when people do need to check them out. Klik has a very busy web page that's intimidating to new users, and, much as I hate to say this as a KDE fan, typical of how KDE is more for the technically minded people who want the dazzling array of switches and blinking lights, and not for the lay user who just wants to get things done.

But I'm impressed with the way packages can be basically distro independent now. I no longer think that having different packages is so much of an issue, and the software author who writes The Killer App (e.g. some cool game) no longer needs to wait for the distro maintainers in order to distribute the software.

All we need now is to spread th

...how long are we going to have to wait...?

Well, it's something I've been thinking a lot over the last years, and I'd like to share my thinking with you lot:

At this point, I don't think we're going to have a major breakthrough until Linux becomes third-party friendly.

Let me explain.

At the moment, the whole experience of using a Linux distribution is balanced between two parties: the user, and the developers of the distro. Linux distributions in general have come a LONG way in minding the user's convenience, but I am still not sure this will suffice.

Because the success of other platforms (well, Windows, alright) doesn't boil down to user friendliness, I think that much is clear by now. No, what made its success is that it fosters a rich environment of third parties -- entities that are neither the OS maker nor the user, yet benefits both.

Something that is still a long way from penetrating the Linux culture, I think.

At this point, let's imagine you're a third party (and as such, not particularly involved in the Linux world as such -- to you it's just a platform among others) and you wish to ship your software for Linux. What are your options? Well, and that's assuming you're even going to bother trying to figure out the whole mess, you can: try to ship various packages (.rpm and .deb, really) in the hope of covering a sufficient user base, while hoping it won't completely break next time some distro upgrades to libwhatever.so.52; or you can try to get your software into the package repositories of all the major distributions (and thus become entirely dependant on the goodwill of each distro for access to your software); or you can try to package the software your own way and hope for the best (that's what Loki did for their games, for instance), which is still vastly suboptimal because it's a lot of additional work for you and you still have no guarantee it'll work well, due to countless issues, the least of which not being that ELF has real, real issues where it comes to binary compatibility. Oh, and yeah, you can also just ship the sources in a tarball, hereby reducing your user base to the demographic of Linux geeks.

Compare with Windows: just put the binaries in a ZIP file or an installer. Done.

And let us not mention the issue of drivers. At this point, shipping a driver for Linux, when you're a neutral hardware maker third party, involves either sending the kernel maintainers your code and hope they'll consent to include it in the main kernel tree at some unknown point in the future, or ship some manner of hack that will try to compile your driver against the installed kernel, which will simply not work if the compiler, or even the right kernel headers, aren't already installed. (To be fair, the initiative that was recently spoken of on Slashdot, about some company developing Linux drivers for third parties for free, is interesting and might improve the situation lots.)

In short: when you're a third party, supporting Linux is generally not worth the pain.

This is a very bad situation for us, because we need hardware makers to support our platform, so there isn't an ongoing gap of weeks or months between the release of bleeding edge hardware and its support on Linux, and there is just plain not enough of us to reproduce the functionality of all the software third parties are making for other platforms

Admittedly, projects like Klik and Autopackage are a step in the right direction, but isn't it too little and perhaps even too late? I don't know.

Because the main, the core issue here is not technical.

The core issue is that when you discuss something like Autopackage, the response typically amounts to "Why don't you use .debs | use .rpms | fork your own distro?"

And this, my friends, is why I've lost hopes of seeing the Linux desktop go mainstream.

Hopefully the future will prove me wrong, though.

...how long are we going to have to wait...?

Well, it's something I've been thinking a lot over the last years, and I'd like to share my thinking with you lot:

At this point, I don't think we're going to have a major breakthrough until Linux becomes third-party friendly.

Let me explain.

At the moment, the whole experience of using a Linux distribution is balanced between two parties: the user, and the developers of the distro. Linux distributions in general have come a LONG way in minding the user's convenience, but I am still not sure this will suffice.

Because the success of other platforms (well, Windows, alright) doesn't boil down to user friendliness, I think that much is clear by now. No, what made its success is that it fosters a rich environment of third parties -- entities that are neither the OS maker nor the user, yet benefits both.

Something that is still a long way from penetrating the Linux culture, I think.

At this point, let's imagine you're a third party (and as such, not particularly involved in the Linux world as such -- to you it's just a platform among others) and you wish to ship your software for Linux. What are your options? Well, and that's assuming you're even going to bother trying to figure out the whole mess, you can: try to ship various packages (.rpm and .deb, really) in the hope of covering a sufficient user base, while hoping it won't completely break next time some distro upgrades to libwhatever.so.52; or you can try to get your software into the package repositories of all the major distributions (and thus become entirely dependant on the goodwill of each distro for access to your software); or you can try to package the software your own way and hope for the best (that's what Loki did for their games, for instance), which is still vastly suboptimal because it's a lot of additional work for you and you still have no guarantee it'll work well, due to countless issues, the least of which not being that ELF has real, real issues where it comes to binary compatibility. Oh, and yeah, you can also just ship the sources in a tarball, hereby reducing your user base to the demographic of Linux geeks.

Compare with Windows: just put the binaries in a ZIP file or an installer. Done.

And let us not mention the issue of drivers. At this point, shipping a driver for Linux, when you're a neutral hardware maker third party, involves either sending the kernel maintainers your code and hope they'll consent to include it in the main kernel tree at some unknown point in the future, or ship some manner of hack that will try to compile your driver against the installed kernel, which will simply not work if the compiler, or even the right kernel headers, aren't already installed. (To be fair, the initiative that was recently spoken of on Slashdot, about some company developing Linux drivers for third parties for free, is interesting and might improve the situation lots.)

In short: when you're a third party, supporting Linux is generally not worth the pain.

This is a very bad situation for us, because we need hardware makers to support our platform, so there isn't an ongoing gap of weeks or months between the release of bleeding edge hardware and its support on Linux, and there is just plain not enough of us to reproduce the functionality of all the software third parties are making for other platforms

Admittedly, projects like Klik and Autopackage are a step in the right direction, but isn't it too little and perhaps even too late? I don't know.

Because the main, the core issue here is not technical.

The core issue is that when you discuss something like Autopackage, the response typically amounts to "Why don't you use .debs | use .rpms | fork your own distro?"

And this, my friends, is why I've lost hopes of seeing the Linux desktop go mainstream.

Hopefully the future will prove me wrong, though.

You mean something like .. i dunno .. like this?

Oooor... like this?

Or maybe like this?

Note that all three have their use cases.
First is programs from repositories (default shipped with ubuntu contains a lot of programs, but you can add your own), and all software installed from this will be automatically updated.
The second is for single programs packaged for ubuntu, which contains a compressed file with all the software (similar to windows, except the package manager keeps VERY good control over the files the program adds, and is much more painless to remove).
And the last one, if you target multiple distros with one installer.

There's also the traditional source code packages, and some more .. special systems, like this.

All in all, there is no reason why an ubuntu user should not find it just as easy or even easier to install/manage programs than a windows user.
And we all know the standard windows installer. Trust us, we know what we're doing! Really!

Wouldn't it be great to go grab a package from freshmeat or sourceforge and...oh look that's the package type I need....

Auto package for happy pinguin .... http://autopackage.org/ The fact is that installing from source is a really bad thing. Not that it don't work or it's difficult. But but having file spreaded everywhere is not a good thing. So then package is really great... One of the thing that would be great is... having the source archive and open it with let say synaptic. then synaptic would find the needed dependencies so it should work and make the sources in a temp directory. Then when it's done, synpatic do something like make install to install the file in a directory so he would be able to create a package for it. and install it cleanly. And finally putting every sources to trash except the archive. Then you have something that in drag and drop would build/install a package from source and having autopackage file for commercial binaries is a damn great idea. It's better than using the ugly .sh script....

And one of those strengths is that you can still install WINE after you buy the computer despite the decisions made by a large company or single individual.

Only if you are squinting so hard you're blind. Linux is the only desktop operating system in which if your distributor decides to not include software, getting it anyway is extremely difficult. If a package isn't included in Ubuntu, your only option is either to compile it from source (good luck with that if you aren't technical) or using something like an autopackage. Neither Windows nor MacOS X practice this kind of software censorship.

I have to admit, this news really pisses me off. Shuttleworth can't seem to decide what he wants here. For background, I am the creator of autopackage, a framework for writing cross-distro binary installers for Linux. It's kinda like Loki Setup except it's designed for open source software, so it handles dependencies, has GTK, Qt and console frontends, etc. Now I haven't really been involved with this project for some time for various reasons, but back when I was, this whole idea that open source projects might distribute their own binaries was terribly controversial. People wondered what the point was.

Now, I did a presentation at LUGRadio Live last year, in which I laid out the case for autopackage (and klik and zeroinstall), and also talked about a bunch of other issues like malware. One of the issues I raised is that every distribution is a political entity that excludes software for reasons that are, to the non-Linux enthusiast, more or less random. Whether it's to do with the license, or lack of manpower, or because a program isn't UNIXy enough, or simply because the maintainers don't like it, a distribution uses its monopoly on easy software installation to eliminate software from the users world.

At the time I warned that this situation couldn't work long term as Linux scaled up. It makes the distro responsible for all the software that is shipped. More to the point, it harms users, because it forces one groups choice on everybody else, restricting the free market. I warned that while people might find discrimination on the basis of license acceptable, and on the basis of manpower understandable, distros would at some point start discriminating against software for bad reasons. And then what do the authors of the affected software do? They can't tell their users to compile it themselves, because that's too hard and fragile. They can't make their own repositories for every distro out there, that's too much work, and besides users are told not to trust 3rd party repositories because they might mess up the distro, break it or be malware. This was very visible to me, because when an enthusiastic user requested an Ubuntu package of the autopackage runtime (first time installs are awkward without that), it got shot down because an Ubuntu developer didn't think it was useful. A bunch of users did, but he didn't, so tough cookies.

I'm pretty pissed off, because not only was I an autopackage developer but also a Wine developer, and now it's happening again. Once more, both users who want a program and the developers who write it are being screwed over due to the opinions of one guy combined with a bad system. About the best option Wine has now is for the developers to maintain an Ubuntu repository, and for users to be given clear instructions on how to add it, and be told to ignore any warnings about that being a bad idea. If N other distros decide to join in the fun, multiply the effort by N.

Even Microsoft, at the height of their monopolistic practices, never made installing software they didn't like so difficult. This is a big shame for Linux, and as it slowly gets more popular these issues will return again and again.

Oh and you seriously think accusing people of being an "elitist" is going to make your point clear?

Do you have any idea how many hours I spent on writing http://www.autopackage.org/docs/howto-install/ [autopackage.org] ? I took the time to launch 2 different desktop environments and to take screenshots from 4 different file managers. I circled the exact buttons that people have to click on. I did my best to write everything without using jargon. I tried my best to use as little text as possible, to describe things as unambiguously as possibly, and to layout things as readably as possible. I took the time to make nice thumbnails with drop shadows. I let non-technical people proofread the guide. At first I even refused to provide commandline instructions and wanted everybody to use the GUI - the only reason why I added it later is because users kept asking for it.

I did all this hard work for the sake of anonymous end users whose face I will never see. Nor will I ever get any reward for it. And now you suddenly jump out of the bushes, calling me an elitist? Seriously, you need to stop applying stereotypes to people.

"Documentation is boring. Nobody wants to do it. Most people try to make writing documentation as easy as possible for themselves, instead of making it as easy as possible for the reader."
Please, can you speak for yourself? Do you have any idea how many hours I spent on writing http://www.autopackage.org/docs/howto-install/ ? I took the time to launch 2 different desktop environments and to take screenshots from 4 different file managers. I circled the exact buttons that people have to click on. I did my best to write everything without using jargon. I tried my best to use as little text as possible, to describe things as unambiguously as possibly, and to layout things as readably as possible. I took the time to make nice thumbnails with drop shadows. At first I even refused to provide commandline instructions and wanted everybody to use the GUI - the only reason why I added it later is because users kept asking for it.

And now you suddenly jump out of the bushes, calling me an elitist? Seriously, you need to stop applying stereotypes to people. Frankly I'm offended. After all the work I've put in ensuring that things are as easy as possible for the end user, you destroy everything and by pasting a stupid stereotype label on me, while ignoring all the hard work that I've done.

There is a method that does that. http://autopackage.org/ . It is designed explicitly for 3rd party software. RPM + yum or .deb + apt is fine for system packages (i.e. stuff directly supported by the distro), but for everything else, Autopackage is what people want.

You may want to check out Autopackage.

- installs new software correctly, in default and custom locations - Check Use --prefix to choose your own location

- uninstalls old software correctly - Check Doesn't everything do this?

- updates old to new software correctly - Sorta It will upgrade properly if you download the new package file. It doesn't yet automatically update, but it's planned.

- is aware of and can work with custom-installed libraries and dependencies (i.e. EVERYTHING doesn't have to be installed using this system, some stuff can be compiled from source or downloaded from third party). - Check Autopackage looks for the actual files (usually, shared libraries) instead of in a database.

- is scriptable through some command-line interface - Check It has text, GTK, and Qt frontends. All installs are non-interactive, and therefore are scriptable.

- isn't a pain in the neck - You'll have to try it to find out...

installs new software correctly, in default and custom locations

uninstalls old software correctly

updates old to new software correctly

is aware of and can work with custom-installed libraries and dependencies (i.e. EVERYTHING doesn't have to be installed using this system, some stuff can be compiled from source or downloaded from third party).

is scriptable through some command-line interface

isn't a pain in the neck

As far as I know, none of the software installation systems out there for any platform meet all of the above requirements.

The difficulty of desktop Linux is really a myth these days. I recently set up Fedora Core 6 on a laptop. Setting up FC6 as a desktop is now trivially easy. It roughly consisted of inserting a CD-ROM, booting it, clicking OK and Next a few times then feeding it disks until it finished.

Installing extra software was equally trivial. There is a GUI to start off the Applications menu for installing more software. It downloads and installs the software all as one step. No need to download it, run a separate installer or scroll through pages of impeneterable EULA.

To add extra applications to this GUI application installer - mainly multimedia applications - all it required was clicking on a link on Livna's web page to add the Livna repository. (Like Mac OS X, you're asked for the administrative password on application install).

Installing Fedora Core and extra applications and extra application repositories is actaully easier than doing the same on Windows, and about the equivalent difficulty of doing the same on Mac OS X.

For third-party applications, there is Autopackage: http://autopackage.org/ - which provides a distro-independent method of installing applications. It's reminiscent of things like the Mac OS X application installer (for apps you can't simply drag to the Applications folder) or the InstallShield types of installers for Windows. Except unlike InstallShield installers, it has the ability to resolve and fetch dependencies (ever tried to install Microsoft BizTalk? Complex and unweildy because you must manually install several dependencies, each with their own dependencies. Autopackage does away with this dependency hell).

Linux needs a universal framework for application development

app installation/uninstallation

user configuration storage

sound and graphics

users won't have to install two entire desktop environments just to run all the apps out there

For system-supported stuff, then apt/yum (with their graphical front ends) is actually much simpler - just choose the package from the list.

For 3rd party stuff (which is what I suspect you gripe about) - there's Autopackage. http://autopackage.org/. Works just like the InstallShield files on Windows, except it's better since it has dependency resolution built in. I package up Oolite-Linux as an autopackage - I've not come across anyone who's had a problem installing it so far.

I would love if, instead of trying to fix RPM people started to use the excellent Autopackage package manager

Question number 2 in their FAQ (and linked to on the front page of autopackage.org:
"Is autopackage meant to replace RPM?

No..."
http://autopackage.org/faq.html?PHPSESSID=71d1abe6 fa721b547177e5f4e1de55b4#1_2

Autopackage is great and is good for frequently updated desktop apps like Firefox, Gaim and OpenOffice but it doesn't replace/do the same thing as RPM.

I would love if, instead of trying to fix RPM people started to use the excellent Autopackage package manager. It has been the only package manager so far, to allow me to install some program /without/ root privileges. Also, it is the only REAL click & play installing program.

For you, that are a software developer, I would really recommend autopackage. The only problem I have (for now) is the need to open the terminal to run the .package script (although that should be fixed by the gnome and kde people).

...the fact is that developers use DirectX because it's easy to make a game with...

Ha. HA. BWAHAHAHAHAHAHAHA!!

I can easily see you have never actually USED DirectX in any serious capacity (or possibly at all). It is a royal PAIN. True, it is better than what it was, but that's not saying much. And SDL + OpenGL is still, far and away, far, far easier to use than any version of the DirectX suite. The only thing DirectX buys you is (as you mentioned) portability to XBox. Which can definitely be killer if the business folks decide they want to have the game run there.

As for development tools, Linux has by far, much better tools than any Windows version.

There are basically three things that are truly hurdles for Linux gaming:

• No critical mass
• Lack of good graphics drivers
• Lack of an easy, hassle-free way to install 3rd party apps.

I need to download an app, double click and click next next next and its done. To uninstall I'd doubleclick something and its gone.

Well, assuming that you have a valid reason for not letting the distro builders package your application for you, it sounds like you need something like AutoPackage.

Are you thinking of Autopackage?

Amen to that. I just wanted to add to this a mention of Autopackage, which has done wonders, not only for amazing ease of installation (did you say "a few clicks"? Autopackage is one-click), but also for wide-spread binary compatibility under GNU/Linux. GNU/Linux certainly is capable of binary compatibility, it's just that most distros don't care anyway (why should they when there's APT/Yum/Portage/whathaveyou?). The Autopackage project has developed some rather sophisticated wrapper scripts around the GNU toolchain to build binaries that link to ABIs that are available on as wide a range of distros as possible.

It's a huge pain to distribute binaries for every different distro, so unless your app becomes popular enough for other people to do that work for you, (or the distros do it themselves) then a significant amount of development time is spent just on packaging and deployment.

In any case, "One Package Manager To Rule Them All" still wouldn't be the panacea people think. Each distro would not only have to use the same package manager, but they would all have to do dependencies in exactly the same way for it to work. This is why many RPMs intended for distro X won't work on distro Y.

RPM and .deb etc. are designed for use with software packaged by the distro maker - not third party stuff. Therefore, there isn't really a need for a standard (and no point, so long as there are different distros with different packages and different dependencies).

For third party stuff, there is Autopackage. When most people go on about the One True Package Manager, generally they are thinking about the ease of installing third party packages. Autopackage does this admirably well - http://autopackage.org/.

• Most package formats are differently merely through being apart. The technical differences between RPM, DEBs, ebuilds etc are not tha large in terms of the fundamental primitives they work with. None has a clear advantage over the other.

• The "diversity" you see is not really diversity for the reason given above, so, we pay the price in terms of poor user experience but we don't get any of the benefits

• The splintering of it discourages innovation in distro design. No distro can get a large userbase without a large repository, because installing anything outside of the repositories is such a gigantic pain in the ass (unless you use autopackage ;) - so "new" distros tend to merely be derivatives of existing distros with very minor changes.

In short, we get all the pain of diversity and none of the gain.

There's growing recognition of this fact in the upper echelons of the community. At LUGRadio Live Mark Shuttleworth talked about the need for standardised package management and the need to move away from the repository model of software distribution towards one where anybody could publish a package that works on any distribution. Of course Ubuntu is the poster child for centralised packaging, so who knows if it'll happen. Probably not.

Unfortunately, package management seems to be the great divide. What are you doing to bring One Package Manager to all Linux?

How about this: posting links to Autopackage (http://autopackage.org/) on Slashdot? :)

OT: about your signature - for easy (i.e. Windows install shield style) installs, Linux already has Autopackage. I use it for Oolite. Works very well. Quite a few projects are now using it for distro-independent installers.

http://autopackage.org/

Not sure if you mean this autopackage page or not, but that doesn't have a button that says "downloads"... In fact, it doesn't say downloads anywhere until you click on Packages, then see "Downloads" as the page title. If the question is truly one of the most asked questions, it's not under the "Most Asked Questions" section. It should at least have one of those big buttons on the right... "Download now" etc.

Again, I don't know if that's the site you're referring to.

If you're referring to the autopackage website I think I know why you're getting those questions.

There's more than a dozen hyperlinks on the main page. None of them say "Download".
Okay. I'll go to the "Help & Support" section. None of the links there say "Download" either.
What's left on the main page that seems vaguely relevant? "Packages; various packages"? I don't want various alternative packages, I want autopackage.
Okay, I'll check the FAQ link on the main page. Do a search for the word "Download"; nothing relevant.
This is stupid, I'll ask in "Forums".

You broke a very common standard when you called your download section "Packages; Various packages". Fix it by changing the word "Packages; Various packages" to "Downloads; autopackage" on the main page so the hyperlink is both standard and has the same name as what it is referring to. People aren't mind readers and they have no way of knowing that a link titled "Packages; Various packages" points to a web page titled "Downloads". You could also make that link more prominent (Different color or top-left corner?) because that's what most people visiting your website for the first time probably want to do.

When you design a web page or a program you need to get into the mind of your intended audiences. Don't assume they know what you do, don't assume they're mind readers and do remember there's a first time for everybody with everything. Standards are one way to to reduce error rates by making sure it's less of a "first time". Also add redundancy so that different members of your intended audience using different thought processes will still get to the right place in the end. e.g. By putting links to the download section in the Help&Support and FAQ sections.

---

Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

It would have been for Google to release Earth and Picasa as .package files. (See http://www.autopackage.org/ This way, the Linux installation would be better than on both Windows XP and Mac OS X. Is anyone at Google reading this? Thanks, Google, for the Linux versions.

That's the whole point of Autopackage (http://autopackage.org/). We release Oolite for Linux as an Autopackage rather than an RPM/deb/whatever. Seems to work fine on all the recent distros out there.

You shouldn't see different binaries for different distros. A Linux app should be an Linux app, period.

Amen! Not only is it frustrating figuring out where all the config files are, but having an app fail to install or work because of dependancy or lib versions is also frustrating. I remember having fits trying to install Oracle 8i (circa 1999-2000) and having the install fail because the linker was choking over libc version incompatabilities and LD_ASSUME_KERNEL settings. Ofcourse, all the problems could be resolved by tinkering and patching, but that turns a 30 minute install into a 2 hour install. Installs should be a clean process, not a tinkerthon.

I saw another post here that mentioned apgcc. This was the first i've heard of it, but from the description at its website, it looks like a good idea. Basically, it looks to enforce lowest common denominator libraries and static linking. I like the idea of a fat binary. I also like the idea of self contained app directories (I've never owned a Mac, but I've been lead to believe that is the way it works). Diskspace is cheap nowdays. I don't see why everything needs to be dynamically linked.

Now let me digress into the config file issue. This seems to be a favorite flame topic, so let me don my asbestos suit and jump in. IIRC, the cannonical UNIX practice is to install everything not part of the core OS into /usr/local, including the config files. Most linux distrubtions seem throw everything including the kitchen sink into /usr/bin and then put the config files in /etc. My own personal feelings on the matter are that nothing but core os components should go into /usr/bin and /etc (and no, GNOME and AFTERSTEP are not core OS componets). Everything else (including config files) into /usr/local or /opt.

If Apple can do universal binaries across architectures, you'd think all us linux whiz kids could get a cross distrubtion (and cross version) system of binaries working. Ofcourse, Apple has unitary leadership and direction, instead of "hearding piss-ants".

All mainstream package formats have the full installation path hard-coded in the archive. LSB does not address this yet. The other problem of RPM, namely binary compatibility between different library versions, is already solved by compiling with apbuild. This works surprisingly easy, and allows my to provide one single package that can be installed everywhere [1].

[1] I can recommend to compile packages at Slackware because Slackware ships most packages without patches. Compiling an app at SuSE for example, made binaries depend on ABI changes caused by SuSE patches.

As a previous poster said, instead of making a new distro, why not make a package that works on all flavors of Linux that will fix one of the problems with moving switchers?

I wanted to migrate away from Windows.
I am sorta tech savvy - I know the different parts of a computer, I can trouble shoot some basic problems, and I can type "getting your printer to work in ubuntu' into google.

My point is, instead of paying 40 dollars for a book, here is what you do:

1.Go download the Ubuntu ISO
http://mirror.mcs.anl.gov/pub/ubuntu-iso/CDs/5.10/ ubuntu-5.10-install-i386.iso

2.Go get some burning software, I had to download a few free ones off downloads.com to find that actually worked burning isos as they claimed to, but you probably have some installed, I'm sure.
http://www.download.com/Click-N-Burn-CD-DVD/3000-2 646_4-10461707.html?tag=lst-0-5
http://www.download.com/3120-20_4-0-2-0.html?qt=bu rning&author=&titlename=&desc=&li=49&os=&swlink=&g filetype=
I installed slackware a few years ago and my friend spent like 5 hours helping me configure it to get everything to work and it still gave me problems.
It was a pain, or else one of us just overcomplicated it.

Once Ubuntu was installed... it just worked wonderfully. I sometimes forget I'm not using windows and any non GPL software. The install went like this: insert CD, boot off cd, go through install process, Ubuntu won't start up, switch to boot of IDE-0 in bios - Everything is perfect

I also installed automatix, and Auto Packages
http://www.ubuntuforums.org/showthread.php?t=13840 5
http://autopackage.org/docs/howto-install/index.ht ml

I don't like computers particularly, I'm not a poweruser or a nerd, and I don't really game. Ubuntu provides me near full functionality for what I need - more than windows ever did.

CentOS provides other options too, but why use Windows if you don't have to?
I feel like such a subversive.
So do what works for you.

And that, right there, is the crux of the issue: Ubuntu, Fedora Core, Mandriva, SuSE, Gentoo, Debian, Slackware, ... (and hundreds more at distrowatch.com) are all seperate operating systems. I'm well aware that that is the state of things now. What I'm trying to say is, it doesn't have to be that way.

Statically linking (or the equivalent: packaging your own dynamically linked libraries and using those) is an acceptable solution, provided it's used on programs without too many dependencies, and only used on a small scale. Otherwise, the system's memory usage will increase dramatically and performance will go down. The downloadable Linux versions of Firefox and OpenOffice.org take this approach. It works for them because they reimplement almost everything (including their UIs) as internal libraries. They're both genetically related to formerly proprietary codebases, and therefore they don't represent typical Linux programs.

I've been following Autopackage for a long time. It's got a lot of potential. I hope they can work out the kinks, and get a larger body of software packaged, so I can get new software releases without worring about someone packaging it for my distribution. Another interesting project along similar lines is Klik.

Incidently, the Autopackage developers have a page that explains the problems with Linux application portability much better than I did. They also talk about why massive distro-specific package repositories aren't a good idea, in the same FAQ.