Slashdot Mirror

What kind of fantasy land are you living in? Sure, if you are willing to dick about all day with apt pinning and use outdated software, maybe you can avoid it. It's a bit of a mission.

But if you want to use the latest versions of things, even if you use Debian you'll have to compile sometimes. Check out the users on the Ubuntu lists bitching about how Inkscape 0.41 just missing the upstream version freeze. Check out Fyre, a cool app for generating images from de Jong maps - note the lack of a Debian package. On Fedora far more software is not in the repositories than is.

Blind fanboyism won't get us anywhere. Even if the best case scenario, which right now probably means Ubuntu, there are serious problems with desktop software installation on Linux.

There is a lot of interest in solutions from users, developers and commercial ISVs (eg LSB/OSDL member companies). There are a few projects experimenting with new approaches, check out my own: autopackage, or Thomas Leonards Zero-Install.

In particular if you want to test Fyre, try the autopackage I made of it: Fyre 0.10svn. Both Fyre and autopackage aren't quite version 1.0 yet, but both are very close.

That build needs GTK 2.4. I have a build locally I will upload soon that adapts to the GTK features available at runtime (using relaytool) and therefore only needs GTK 2.2, but can still use the new file selectors and other features if they're available at runtime.

I think what people really mean, is for Linux distros to incorporate the few strengths of windows. I run both Linux and Windows, and after about a year of screwing around in Linux I'm finally getting to the point where I can use it more than Windows...and this is just the problem. Windows is not better because it works better....just about anyone will give you that. It's that it's easy to use. But, hopefully things like the linux desktop summit, freedesktop.org and LSB will bring us to the point where just about anyone can use Linux without having to find someone to help them get started ;)

The other big issue people complain about is driver/hardware issues...but this is a chicken and the egg argument. You have to have enough users for hardware people to make proper drivers, but most users don't want to deal with the current state of linux do to lack of drivers. It's getting progressively better, but it's still much slower than it should be...

Maybe if distros start becoming more standards based and something like Autopackage takes off, things will speed up even more.

#2 needs solved fast. apt-get/synaptic 'do it' but have major flaws, in that it is centralized, and therefore resources are lacking (you will have some things that are 2/3 major revisions behind because noone has packaged them for the apt-get repo you have). Plus it's no good for commercial software, which like it or not is not going to vanish.

Yup, apt/Synaptic work great for the base distribution, but if you want anything n ot in the distribution you'e in trouble. Fortunately this problem was noted a while ago by some people, and solutions have been in the works for some time. Autopackage is not quite finished yet, but is API stable now, and provides a great way for application developers (including commercial developers) to create distribution neutral easy install binary packages. If you haven't seen it then it's worth a look. Expect to see support for Autopackage increase dramatically over the next year or two as more projects take it up as a packaging system.

Jedidiah.

Have a common to all distro's install tool that is very easy to use (perhaps a RPM front end).

Well Synaptic is a fairly universal install frontend for all distro based software - it runs on Debian (and all debian based distros), Fedora, SuSE, Connectiva. All you have to do is install the damn thing (it comes by default with several of those distro options). As for third party packages, try Autopackage. Yes they're still finishing things off, and yes, it's going to take developers bothering to package their software with it, but the promise it offers is, I think, enough that we can expect to see it become fairly standard over the next couple of years.

KDE vs Gnome wars: put an end to it.

Um, it is. Or are you going to say all the GNOME developers have to go and work on KDE (or vice versa)? So who says who "wins"? And who really cares if there are 2 seperate desktops if they integrate increasingly well via FD.o standards?

Jedidiah

That is not where the problem lies. The additional problems in ascending order of size are --

1 -- (for the non-geek mum/dad user) getting used to the CLI

2 -- (for quite a lot of others too) figuring out what to do if
apt-get install programx
coughs over a dependency issue and shows up with screeds of error messages.

This is nowhere near as hard as you seem to think.

(1) Install Synaptic to do the package management (you know, like Ubuntu and Connectiva do by default), and they'll never have to look at a command line.

(2) They'll do the same thing they do when a Windows Setup.exe barfs with an error message. What's the problem? Neither happens very often at all (unless you go mixing your repositories... which will only happen if you know what you're doing... which will mean you can resolve the dependencies yourself).

For third party (non-distro provided) packages there's things like Autopackage, which while still in development will hopefully become the standard way for any non-distro packagers to package things up.

Jedidiah.

http://www.autopackage.org/

Lots of GUIs to install packages exist. For example Porthole, Synaptic. (There are more than these, but I don't remember the names right now).

See also Autopackage for a nice attempt at easy installation across different distributions.

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.

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.

Why not use autopackage ? It just reached API stable phase. Inkscape and The Gimp already have .package files.

For those that didn't hear about this before: autopackage is a cross-distro binary package with builtin dependency solving. Make the .package file executable, and just run the CLI or GUI installer. Should be better than Loki Installer, or even the one that aMSN uses.

I'm starting to get tired of OSS projects-games releasing only sources to Linux systems. Stellarium and Vega Strike are other examples of "oh, you run Linux, you should be able to spend a couple hours manually solving dependencies and compiling (and praying that it works afterwards)!"

Autopackage could solve that. It comes with an easy uninstaller, too, and soon it will even integrate with the distro's package management.

Autopackage seems to tackle no 2 there.

App developers can use binreloc to make their apps binary relocatable (ie can install to any location). This is mandatory for autopackages and is easy to add in. binreloc is designed for minimal source disruption.

App developers can use binreloc to make their apps binary relocatable (ie can install to any location). This is mandatory for autopackages and is easy to add in. binreloc is designed for minimal source disruption.

What we'd need would be something as easily managed as #define _HAVE_SDL, only at runtime. There is no way to ensure its adoption if you don't make it as efficient to use as possible.

Ask and you shall receive

2) Agree on a common set of libraries -- think DirectX, only system-wide, not just for games

Ding ding ding! This man wins a prize, he has exactly nailed the problems in a way most people in this thread have not. It took me a long time to reach this level of insight into the issue. Go read the NOTES file to get some more ideas for such a Linux desktop platform. Nothing solid has been started yet, there are other tasks that need to be done first. But this is one of the most important ones.

That file also touches on the security updates problem, at least peripherally. The idea is to use the PAL to allow for generic upgrade scripts/plugins to be run. You'd have one for apt, one for autopackages, others for custom installers etc all abstracted by the PAL.

Actually fixing Linux software installation is going to be very tricky indeed. I wrote some notes on it. That document also talks about what's wrong with apt et al and why "Just use Debian!" is not a suitable answer to peoples criticisms.

autopackage is a good start but it's only one component of many that will be needed. OpenPKG has rather different goals and it's not quite fair to compare them.

Package managers are ok for system libraries, etc. and those are provided by the distributions themselves. For third party software (games, bug tracking, etc.) that needs to work in many different distributions, it is better to just distribute a tarball or use standalone installers such as autopackage or BitRock

Reinvening Autopackage and OpenPKG once again?

Autopackage

What's so terrible about RPM? Anyways, Autopackage is really what the future is. RPM or DEB are fine for packageing the distro, but Autopackage for 3rd party applications.. -- Taj

Have you ever tried to distribute a program in binary from for Linux? You are directly in distribution hell, because every distribution (and different versions as well) contain incompatible library versions. Static linking used to be a resolution, but since glibc 2.3.3 it does not work anymore (even worse, it prints out warning, then works on your computer, but crashes on a computer with a different glibc version).

Check out Autopackage. It's not finished yet, but it is designed specifically to handle the sorts of cross distribution packaging issues you're talking about.

The current package formats are not broken, and are not badly designed. They work brilliantly for what they were designed to do: provide a way for a distribution to package up binaries so as to modularise and make maintainable a large system with lots and lots of optional packages. Using rpm/deb with yum/apt-rpm/apt is an excellent way to maintain your distribution. It doesn't help you with third party packages.

If you want third party packages that anyone can make, you need another way. Autopackage is making excellent inroads into making that other way a reality. Really, check it out.

Jedidiah.

That's what Autopackage is for. Packges are mostly static, relocateable, and have a nice GUI.

Have fun!
--
Taj

We need a way to track down what we install, modify or remove. In other words, something like apt but more global. This again I'm refering to the last point I made. Maybe if we had a universal format, maybe then we'd see various package managers available to almost all distributions to make the user's life easier.

Apt is fantastic for managing a core set of distribution provided packages. Throw a nice frontend like Synaptic on it and it's user friendly too. Apt works fine for both deb and rpm packages, so you really have the majority of distribution provided packages covered. Those that aren't covered are source distributions like Gentoo, or other fairly hands on distributions like Slackware.

The problem comes when users want to install something outside of their ditribution provided set. Sure, Debian has a very large repository, but it'll never have commercial software. Meanwhile Fedora has a very small repository (comparatively). For non-distribution provided packages I'd suggest you check out Autopackage. You download a packages, run it, and it will check dependencies, resolve them if at all possible, and install itself - it's like installshield but nicer and with dependency resolution. Autopackage isn't done yet, but it already has working packages - its just lacking nice to have features like integration with rpm and deb package databases etc.

Given a combination of Synaptic and Autopackage for base and third party software I think Linux has a very bright future for installing and managing software.

Jedidiah.

Given that I maintain autopackage, which is devoted to distribution-neutral binary packages, and work on CrossOver which has to operate on many different distributions, probably more than you have.

When I was talking about differences between them, I was talking about the actual software that makes them up. If you look at desktop distros (ie ignore issues like corporate support for servers and specialist router distros), the biggest differences from a software vendors perspective are:

• The package manager/dep resolver in use
• The packages/versions that are actually installed
• The custom patches applied

The other differences like config tools aren't really relevant, and are slowly being reduced as more and more software is pushed upstream.

From the users perspective then, the biggest differences are packages + how much work they make you do. I'd object to your characterisation of SuSE (and I guess similar distros like Fedora or Mandrake, or indeed Ubuntu) as being a "real pain in the ass" if you "know what you're doing". I like to think I know what I'm doing, I've certainly written enough software to prove it, and I use Fedora. Likewise, some of the best hackers I know are using SuSE or Fedora.

The differences from a users perspective don't concern me so much as differences from a software vendors perspective. A 'vendor' in this case can easily be an open source project on SourceForge as well as a proprietary developer. These manifest in the packages installed in a base profile, and the patches applied to key components. I'd much rather that distros didn't patch things at all to be frank - experimentation is fine but there's far too much custom patching going on in distros that could just as easily be done upstream, but working with upstream is hard because they might want things done in a particular way or style, so the end result is you get lots of distros that hardly vary at all with no real standardisation or consistency. This is harmful.

Requiring the root password for certain tasks does not increase security, IMHO. Most users (a) don't want to be constantly typing in passwords and (b) would type it in whenever it was asked for without thinking too hard about it.

If anything you don't want the typical personal-PC one-user setup to ask for the root password very often because the more often you ask when it's not really needed, the greater "password fatigue" gets and the less likely people are to think critically when they get asked.

Really, if you spend a lot of time thinking about it as I have, you come to the realisation that malware which relies on social engineering doesn't have any useful technical solutions. You can get some way there with things like distributed whitelists but pretty quickly you end up in the realm of civil liberties (who really owns that machine you paid for?).

In short: making tasks hard doesn't increase security, it just annoys the user. If the user has decided they want to do something, they'll do it. So good security in the face of a dangerous net is about advising the user well whilst not getting in their way.

Now, I know you're coming from the viewpoint of a server admin which is fine. Most people aren't server admins. It's wrong to try and apply the tools used to admin servers to home machines.

That's one reason why autopackage can install to home directories. (see the third screenshot), though it's not really something that's encouraged (and it can be disabled by administrators). Another is because it's really useful if you want to use a newer/older version of the software installed on a multi-user machine without interfering with other users. Another is because some shell accounts do let you run programs and it's nice to be able to use binaries.

In fact, in all my production systems, home is ALWAYS mounted as noexec. You want a program on the server, fine, you let me know which one and why, and I'll think about it.

That doesn't help very much, you can still run programs on a no-exec mount if you really want to.

The second biggest problem is that of binary portability.

Where files and such are put isn't actually that big a problem. I know that's what it looks like at first, I thought the same thing. But in practice, it's really not a problem.

How do I know these things? Because for the last two years I've been working on a distribution neutral packaging format, that installs anywhere and is easy to use. Go check out the screenshots! There are demo packages you can use as well, like the Inkscape CVS nightly builds. Be warned, I think the Zile package isn't working quite right yet.

Autopackage really needs more people working on it. Right now all the 3 main developers are in a time crunch and it's slowed right down to a crawl. If you want to see easy 1 click installs on Linux (easier than apt-get even for newbies ...) why not come on over and help out?

Configuring XP is quite frankly miles ahead of Linux. Mainly because nearly everything is in a centralized place!. Yes, I click control panel and I can change nearly anything I have to day to day.

I still think that the points that the OP said are very, very valid. They are the 3 points which infuriate me more than anything.

Oh also, apt-get is useless - you need to know the repositries, and commerical software is not going to be delivered that way. Installshield/Microsoft installer does a far better job. Personally, I think OSX does the best job at this, a very, very clean installer that is web aware.However, the autopackage folks are doing a damn great job, and we need to really help projects like this, and the freedesktop initive get off the ground.

The fundamental dilemma is simple.

The only distros on which apt-get and friends actually works reliably are the least user friendly distros.

Debian and Gentoo have serious usability problems in many areas for non-technical users. There's only one distro I'd give to my friends/family today, and that's Fedora Core. Why? Because it has a slick Gnome desktop and I don't think I should be giving non-technical users a desktop which has menu items labelled "smbUmount" and a preference in the file manager called "Minimize memory usage". Sorry. Just MHO. So that leaves Fedora or some customized install of Debian. Compiling from source is right out if only because it takes so long to upgrade the system (think security updates).

Unfortunately Fedora doesn't have many packages, and those packages it does have are often out of date. The moment a new Fedora is released, you have to upgrade too because all the packagers are now targetting the newest release. This is a pain. Often packages are broken, out of date, missing, or only in conflicting repositories. These issues are hard-wired into the system and cannot be solved by throwing manpower at it, despite what some think.

Grandparent is exactly right, we need decentralised packaging. That does not exclude apt type "one command installs", that can easily be layered on top once the fundamental infrastructure is in place. But you've got to get the basics right: build a binary once, install it anywhere.

Go read the autopackage ui vision to see what end users might one day use, then check out the screenshots gallery. Try it for yourself if you like.

Be warned though. On very recent distros (fc2, debian sid etc) the Inkscape package installs but the binaries crash very quickly. It seems some library broke ABI and didn't bump the soname.

Hey, nobody said it'd be easy ....

You mean like this?

There is something that's supposed to work like InstallShield -- autopackage. I haven't looked at it in detail, but it's very promising. It needs to be stable and distributed widely, though. That's not happened yet, but if it did, I think we'd see a greater move to Linux on the desktop. After all, once you have a system and can add and remove parts of it easily, you can really use the system :)

"If you aren't a paid up Microsoft stormtrooper, please do try to some research before making such blatantly erroneous statements."

If they were tools which were more widesrpead, there wouldn't be a problem. We need a solution which is distribution agnostic and available to all, not just Mandrake or SuSE users. The proper setup would allow install on any OS, and provider their own uninstall wrappers. No need for distribution specific support!

Autopackage has been suggested to me, and it looks cool. It's just that it's not 1) stable and 2) wide spread.

Saying that it's the users' fault they all don't use SuSE or Mandrake is like saying it's the users' fault that Microsoft products are insecure. Fix the product, and you notice the problems disapear.

Until there is a real method of packaging and installing/removing software for Linux, the operating system will never move past where Windows was circa version 3.1. RPM has dependancy issues, and apt-get is something past most people.

I suggest you look at synaptic. Unfortunately they haven't updated their screenshots recently, the interface is now much cleaner and simpler than that presented in the screenshots (which was still quite nice).

With Windows, you just download a binary installer and run it as either the admin or not. If it's admin, it'll install it system-wide; if not, it'll install per user. If'll bring any extra libraries in needs for its private use.

I suggest you check out autopackage. Any parties that package with autopackage instead of rpm or deb create a downloadable binary installer that asks for the root password. If you give it it will install systemwide, if you pass, you can install it just for you. Of course it goes one better and checks for dependencies and resolves them, just like apt (though dependency checking is more in the style of the configure stage of a compilation rather than looking for installed packages, so it is much more robust).

No current Linux technology immitates this. There is no way I can currently download a self-executing shellscript wrapper or otherwise binary program that will install either system-wide or to ~/bin/$appname, with care taken to provide its own libraries, and giving me an easy link so I can remove the application folder, the installed support libraries, and any config files separately.

That would be autopackage. Okay, it's still at 0.5, and isn't completely API stable yet, but it is progressign quickly, and already has several applications (inkscape for instance) which you can fully install via autopackage.

Jedidiah.

So linux isn't ready because if you choose to use software distributed as source you have to use the commandline? It's not even a terribly hard sequence of commands, and they are almost always described in the INSTALL document.

That aside though, the main issue with source installs is that you end up with a mess - files all over the place. You can't remove what you just installed unless the Makefile happened to include an "uninstall".

Up until now I've been very happily avoiding this issue by using stow, but recently I found checkinstall which you run instead of make install. Checkinstall creates a package (.deb, or .rpm based on your system) containing all the files getting installed by the make install step, and installs that for you. That means that everything, source installs included, can be conveniently managed from whatever package management application you use (I prefer synaptic myself, it works for anything that supports apt, which includes rpm).

"That's still too hard!" you say? Yes, quite possibly - but then the only real reason to be installing from source is if you have very particular needs (special configure options) or a need to be on the bleeding edge. Pretty much anyone who thinks compiling is too hard should be happy with binary installs. With things like synaptic, redcarpet, up2date, etc. around installing distro provided packages is a breeze. If you have to go outside your distro try autopackage. Yes, autopackage isn't finished yet, but they're at the stage where they have some test packages (install the latest version of inkscape via autopackage for instance), and what they do have is fantastic - think of it as installshield with advanced dependency checking resolution. All those third parties currently supplying distro specific rpms ought to shift their project to supplying autopackages, and certainly autopackage looks to be the way to go for any commercial vendor who wants to create a linux installer for their software.

Installs are still a little tricky, but the issues have been spotted, and are being worked on - and the solutions look better than anything Windows provides.

Jedidiah

There are already a lot of replies to this post saying "no definitely not, OSS developers are all elitest ignoramuses" because it's easy to sound insightful when criticising, but really what they're saying doesn't stack up. It might have been right 3 years ago but the improvements made since then have been staggering.

A lot of software has been rewritten or redesigned with usability being core. Example: grip was deemed a lost cause as far as UI went, so Sound Juicer was written instead. XMMS was deemed fundamentally flawed so Muine and RhythmBox were written. Gnome has adopted a pervasive HIG and while it may have a few rough edges still it's arguably more consistent than both Windows (hands up if you read the Windows HIG - thought not) and even Apples (brushed metal or aqua - what mood is Steven in today?).

Today, if you want, you can get software that's had well thought through usability. That doesn't mean everybody uses it, but it's certainly available to those who want it.

Now, there are some big remaining usability issues in free software but these tend to be structural/architectural. For instance Linux software installation is frequently very difficult and it's not easy to solve without a great deal of engineering.

On Windows the GIMP user interface isn't anywhere near as good as on Linux, despite the GIMP 2 itself making great strides over the 1.2 release in absolute terms, the different (arguably worse) Windows WM model and UI paradigms aren't accounted for and there aren't enough Win32 Gimp developers to give Gimp/Win32 an excellently integrated UI. Or at least, not rapidly.

This is more a side-effect of the Gimp being most popular on Linux and the core developers all using Linux though, rather than any fundamental insight into the nature of open source. I've seen some pretty crap ports to Windows UI from commercial companies as well - for instance, the laughable QuickTime 4 which not only made zero effort to integrate with the host operating systems UI but also committed quite a few usability sins like the thumbwheel.

Well, I disagree. I'm working on making it easy. So far it's not doing badly, though for more robust installs we want to be able to delegate to apt/yum/urpmi/whatever when there are no distro-neutral packages available.

I am the Debian zealot I am because many people complain that something does not work in "Linux", even though it does on Debian.

There are plenty of things that work in Fedora/Mandrake/SuSE that don't work (out of the box) in Debian, so I don't really see your point. Every distro has strong points and weak points.

Even though it's not that hard, nobody should *have* to fall back on tarballs and ./configure / make / make install. DUMB

Very true. I made the mistake of selecting a "desktop" install instead of a "workstation" install when (finally) setting up my wife's pc with FC2 -- (she's off Win, yeah). I didn't realize that desktop installations did NOT install gcc! Then I wanted to install Scribus, and I was nixed right there. I sighed, shuddered to think what else might be missing from a desktop install, an proceeded to re-install, working with a "workstation" setup the second time around.

I hope AutoPackage can address these types of issues, looks promising .

Are you getting these packages from the servers of the distribution you are using? You should only download rpms which are specifically built for the linux system you are using. For example, if you are using Mandrake linux 10.0 Official Edition, you should only download packages which are built for Mandrake linux 10.0 Official Edition.

As nice as this is, you just can't expect a single vendor to package everything you could ever want. At some point you're going to have to provide something packaged by someone else. That's the point where the trouble starts. Right now the only really distribution agnostic packaging system is source. Source is nice, and when well managed (say, with stow), it works very well for handling those few extra packages you want to install, but source does take a little more nouse than perhaps it should. ./configure; make; make install is great when it works, but working through any issues that arise when it doesn't (while still not that hard) is starting to get a little sticky. The fact is, there are still points at which software installation for Linux can become cumbersome and annoying for desktop users that don't want to have to fiddle. Fortunately things are being done about this. There are projects like autopackage which are looking to provide a nice clean simple to use distribution agnostic packaging format. It is worth recognising the weaknesses, and embracing the (still in development, but looking better all the time) solutions.

Jedidiah

"Often, the open source community has a very narrow and selfish view when it comes to certain things. Like, why make software easy to install, like OS X? No need- any Linux user (present or future) is smart enough to compile his own software, resolve dependencies, etc."

Sigh... don't give me stupid stereotypes like that. I've been working for more than 2 years on the autopackage project, which is exactly trying to make Linux software installation easier. I've put many man hours into the project and you come up with a dumb stereotype!? I'm very insulted! I'm sure all the people who put a lot of efford into GNOME and KDE would feel the same way too.

I swear, if Linux ever fails on the desktop, it'll be because people like you keep insulting developers with dumb stereotypes.

"A person has to ask- could the OSS community ever have produced a gem like OS X? Could it have produced Java? OSS has the skillset, some of the sharpest folks on the planet."

Yeah. How about Mono? Everybody who has tried .NET is bragging about how great it is. How about GCJ? It can produce native executables from Java source code. Perl and Python are also very nice and powerful languages.

"But who is keeping them coordinated? Who is the CEO with a single, cohesive vision?"

How about the project maintainer? The BSDs has a clear visiion of what it's supposed to be. Inkscape's maintainer has a clear vision of the future. There are good and bad maintainers, but there are also good and bad CEOs. Don't act like corporate control is some kind of bliss.

Mmm... I'd love it for two of my favorite open source projects to come together.

For the article, Xandros looks nice with its slighlty modified KDE and won't disturb much users with MS Windows experience. Nice effort, but I think a full-blown desktop distro- the Deluxe one, should not cost more than any good new video game, 50EUR. - Yes I'm cheap when it comes to software. I won't buy them, but wish them good luck.

I have to wonder if Linux developers have missed the fact that a computer is supposed to run arbitrary programs

Splitting hairs mode : Linux is the One kernel. Kernel developpers didn't miss anything in this regard. The first tier is OK, let's climb higher and look on the distro tier.

If I get what you said correctly, here lies the problem. Most distros are promoting free-as-in-speech softwares, and free-as-in-beer to cut costs. So they basically can't put everything in their repository.

With Gentoo, IIRC you can emerge commercial and/or proprietary softwares - Sun JVM and some games such as Neverwinter Nights comes to my mind. You must however provide the binaries/data in one way or another, since the download is under some restrictions. The primary purpose of these tools is to facilitate integration in the whole system, nothing less, nothing more. The downloading part is a convenience but nothing more, heavily used when it's legal to do so, but not in other

Sun also provides RPM for its JVM. Whether they do for other distros the packaging job or not is up to them .

Whether you provide nice apt/yum/chihuaha repository for your database software people can't obviously live without is up to you too. :-) As for selling software for big $$$ through these tools, well you can't(*). But it would still apply for the 30-day-trial-after-that-foot-the-bill evaluation version.

So go make those .deb, .rpm, and ebuild. Just don't expect voluntary packaging for your proprietary and non-free-as-in-beer tools.

Moreover there are some meta packaging tools that could save your day, such as autopackage. They're not complete yet, but they're worth a look.

Waiting for the rather nasty reply, Batman. ;-)

Just my 0,01EUR.

(*) unless you code a free plugin for these repository that implement a pay-per-download system, that is.

Application installation hell certainly isn't an out of date complaint about Linux. Is somebody going to make a .rpm/.deb/.tgz for EVERY single piece of software out there? Nope. Then, it has to be in a repository to apt-get/urpmi. And finally, you have to have that repository set up. But on top of that, what about commercial software?!

The parent was referring to an installation in Windows where you download a .exe/.msi and its a self contained installation.

Linux can do better (have self contained insallations while keeping some form of dependency checking).

Check out http://ww.autopackage.org

Distribution-neutral packages? Then you are looking for Autopackage. Autopackage is a distribution-neutral installation system for Linux designed for desktop software (mostly). It does automatic dependancy resolution and real dependancy checking (does not rely on a database like RPM).

We've recently changed our plans a little and we are near a feature freeze and 1.0 release now.
1.0 won't be perfect, it will just be a "it works, and works well". The really cool features like RPM/Deb/apt/yum integration is scheduled for post-1.0.

Please lend us your support. You don't have to be a coder to help us - writing documentation or just being a tester is also good.
We're trying to increase our userbase, and therebefore hopefully also gain more developers to help us with writing code, so Linux can get a good cross-distribution installation system.

Maybe you're looking for Autopackage.
Autopackage is a cross-distribution installation system for Linux, mostly designed for desktop apps. With Autopackage it's very easy to create packages that automatically integrate with GNOME and KDE and support non-root installs.

We're close to 1.0. We've recently changed our plans a little to reach 1.0 earlier so we can have more users ==> which means more developers.
Autopackage 1.0 will not be perfect, it will just be a "it works, and works well". The really cool features such as RPM/APT/YUM integration is scheduled for post-1.0.

Please lend your hand and support us. The more users/packagers we have, the better, because that means we'll probably also get more developers who can help us with the post-1.0 cool features and make Linux installation even better.

If it's no big deal, then why is it nearly impossible for me to get a standard way for installing softwre on linux? I understand that most distros come with a packaging manager, but if I want to write a program, allow downloads from my site, then (to the best of my knowledge) there's no way for it to easily be installed and have menu shortcuts etc set up....

Follow this and your menu entries will show up for KDE and GNOME. Users of other DEs normally have enough nouse to add menu entries themselves (or their DEs can load GNOME/KDE menus).

As for installers, at wort you can just statically compile into an rpm - no dependency issues then. As long as you provide a source tar ball as well then most everyone will be happy (and if your program is any good, it'll get included in the package repositories of the various distributions).

If that doesn't appeal, you could always support autopackage.

Jedidiah.

For alternatives, checkout:

Bitrock: kind of "Installshield" for linux
Installshield multiplatform: The actual Installshield for Linux (written in Java and a bit ugly)
Autopackage: Kind of universal installer

Actually, we at the Autopackage project recognize this problem and have already made a solution. See apbuild.

Ask and you shall receive.

I used to agree ...but
One format, nice, but then: which one. I don't see us agreeing on this one. And I also doubt whether autopackage will be successfull.

The main problem is not the format I guess, it's the dependencies. The only way you can resolve dependency hell, is by establishing a central repository that all distros use.
That would however indirectly imply that every distro has their stuff compiled the exact same way. But what then , what would be the difference between the several distributions ...?

The only way you could achieve this, one standard format, would be source I guess, but hey, we've got tar.gz ...
Notrace

Lots of these posts have mentioned that different distros use different packaging schemes and that there can also be problems with package names and dependancy locations (e.g. required .so files being in the wrong directory), but I haven't heard anybody mention the problem of binary compatability. Suppose I have program a.out which requires a.so and b.so to run. Now a.so also uses b.so, but a.so was compiled against b.so version 3 while a.out was compiled against b.so version 4. This will lead to problems as the loader will load only ONE version of the library and require both a.out and a.so to use the same version of b.so. This is why rpm's of the same program are not compatible accross different versions of the same distro! We'll never get out of the dependancy hell until somebody fixes this problem (e.g. Windows works the way you'd want). There's more info on this issue in the Autopackage FAQ if you're interested. BTW: suppose I've got a.so version 3 on my machine and I go to install myprog. myprog requires a.so version 5. Upgrading a.so will require upgrading 500 other binaries on my system as they also depend on a.so version 3. As far as I can tell rpm doesn't want to let me install a.so version 5 (e.g. a.so.5) along side a.so.3 without using the --force option even though that would/should work in many instances and make an upgrade much easier. Am I missing something??

So this is a similar effort to Autopackage except that it plans on using the native package formats? Intriguing...

I set up a computer for my wife and installed Redhat 7.2 a while back for her. After using it for 6 months, she swore off linux and went to Windows 2000. Her reason:

She can't install any software on Linux! Every time she wanted to install something, she had to call me over to her computer. I had to locate the redhat rpm's, and if there were no rpms (which was often the case) or there were only rpms for a different distro, I had to compile the software for her!

Asking a non-technical user to compile software is just crazy! With windows, she just downloads the software and run's the installer! She doesn't have to worry about what distro and version number she's running (ie RH 7.0, or RH 7.1 or RH 7.2) she doesn't have to worry about dependancy hell, or any of that other crap...

Now if linux has a standarized installer that worked for all distros, I could probably convince my wife to try it out again.

Autopackage may be the ticket?!?