Slashdot Mirror

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.

Did I say that? Each distro vendor will package the best, most useful packages to its target userbase. It can be seen, however, that the most popular distros (e.g. RH-alikes, Debian, SuSE, Mandriva, Gentoo) also have the largest selection of packages. Most of those do so inside the main tree, Fedora is trying to take a new approach of building a core and letting a close-knit community take care of the rest. It's working out better than I expected only a few years ago.

This is *not* a hypothetical problem. One project I follow is Battle for Wesnoth, a cool GPL-ed turn based strategy game. They release new versions, in source tarball form, quite frequenty. Typically, the Windows and MacOS X binaries come out within a day or two of release. And the GNU/Linux binaries? The most recent user submitted version might be several versions out of date. The distribution packaged versions are even more out of date that the user submitted ones. For a fast paced project like Wesnoth, being out of date is bad. (I resort to building from source, because I know exactly which libraries I need, but some distros don't package libSDL-dev, ugh)

Pick distros that you're prepared to support and prepare an official package for each, along with any dependencies that don't exist in the standard distro, in the same way as the Windows versions use Installshield or whatever. I can't speak for dpkgs and ebuilds, but once you've done the first RPM spec file, it hardly needs modification from one revision to the next. Packaging doesn't even require much in the way of technical skill to do. If the package has limited requirements, it could even be portable across distros.

Also, I'm not holding FOSS to a "higher" standard. Every other operating system out there besides GNU/Linux *has* a definative baseline you can build applications against, without requiring every application to be integrated into the OS. GNU/Linux is unique in that it has multiple incompatible baselines. If I wanted to release a cool new GPLed application right now I'd have no way of releasing a common binary package that would work for all of my users. There are too many incompatible build environments.

Firstly, it's probably best if you think of FC, Mandriva, SuSE, etc each as separate OSs, even though they share a kernel and many components. Secondly, if you must, build a statically-linked binary. That's often what the commercial vendors do for their 'officially supported' binaries. Alternatively, there are various distro-neutral packaging solutions that might be werth looking into, e.g. AutoPackage.

What he'd really like to see, is for the popular Linux distros to converge on a common core platform, according to the article.

Ultimately, all mainstream Linux distributions could derive from the same basic base (with the exception of those which try to fit Linux in tight places, for example). There is no reason that RedHat, SuSE, Debian, et al have to have so many differences beneath user-space software. (Consider the wildly different boot-time initialization scripts in each of those distributions. Ironically, there is a modular system in place.) Consolidate the similarities and expand by extensions which do not eliminate cross “distro” compatibility. There are already efforts to this effect. This is no magic bullet for any particular problem, but it will help eliminate the throat-cutting within the community and encourage computer manufacturers like Dell to offer Linux solutions.

I've been reading Mr.Linspire's post about it. It's Click N Run software installation. It's like a frontend to apt/emerge/pacman, but more polished at both ends.

Windows are able to make cross-version binary compatible apps, why not linux?

Windows are able to make cross-version binary compatible apps, why not linux?

For third party stuff, Autopackage (http://autopackage.org/ works really well. I use it for Oolite-Linux.

Nice. Why don't you go "inform" yourself? In the past I've written an entire software installation framework on Linux, a binary portability environment, modifications to the dynamic linker, patches for Wine, ALSA, GNOME and a bunch of other projects I forget, and me and my team pretty much wrote the book on Linux binary compatibility.

NViDEA provides binary drivers and has an installer to do the compiling if it can't find a compatable kernel. Their installer is GPL. Slap a graphical front end on it and then you no longer have a problem.

No longer have a problem? This is insane ... you realise that the kernel developers make a sport out of breaking the nVidia drivers right? Having a source wrapper doesn't protect them from everything, nowhere near. For instance the 4k stacks fiasco.

Not to mention that this solution is light-years behind Windows 95 in terms of usability. What happens when you put the driver CD containing this magic source code wrapper in the CD drive? Nothing. What happens if you don't have developer tools and the kernel headers installed? Errors. What happens if the driver is more than 12 months old and the kernel API changed? Errors.

And finally what if you're a little company and Mr Kroah-Hartman smells blood? You get sued. This is about the most uninviting landscape for hardware developers imaginable.

C++ support Then get apps from the vendor or compile them on the system with glibc ... or fix glibc yourself if you don't like it.

Michael Meeks has already attempted to "fix" glibc, and his work was ignored. This is the modus operandi of the glibc people, and as a result a generic patch he wrote to solve many of the symbol fixup and performance problems that plague Linux (eg OpenOffice startup time) is now a SuSE specific file format extension. Yay standards.

And for what it's worth many of the C++ problems are GCC related, not glibc. But Michaels work would have alleviated the symtoms.

As opposed to what? Windows XP?

As opposed to every other program in the world that users don't already have but might want to try.

Linus says he doesn't mind having it. So develop it. Some people don't care because we don't all want it.

Explain to me how to build a DRM system for an operating system in which you have no guarantees about the way it works. Now, you can't built a 100% perfect DRM system ever, but you can get close enough that it's worth doing and Windows is pretty good at it these days (and will get better as hardware support starts appearing for it). But Linux can't mount credible competition in this area. If there was a Red Hat music store or something then it wouldn't matter so much - the iTunes DRM is fairly weak, but it doesn't matter because Apple are simultaneosuly platform and media provider. But Linux is just a platform, so it doesn't have that luxury.

Each Linux distribution has its own form of package management, thus gaim can't exactly offer ready made packages for each distribution.

It is easy to offer a package compatibile with any normal Linux desktop.

There's work under way to replace the Linux standalone installer with autopackage for Firefox 2. Only time will tell if that works is completed or not, but it has the support of Mozillians.

The packaging system already exists for Linux - it's called Autopackage (http://www.autopackage.org/) and it works very well for producing distro-neutral installers. For Oolite-Linux, we do the same as most Windows developers - bundle up the dependencies. For the end user, an Autopackage is just as easy as a Windows installer. Unlike Windows Installer though, Autopackage can resolve dependencies if there are any.

Basically, and this is coming from somebody who has a lot of experience of dealing with binary software on Linux:

• Yes, it's entirely believable that a glibc upgrade was required, because when you compile a program that binary is usually locked to the version of glibc it was compiled with. Newer versions are OK, older versions aren't.
• This locking process is automatic and independent of what the source code actually does. Most of the time the developer isn't even aware it's happened.
• RPM understands it and will refuse to let you install a binary that requires a newer glibc, even though recompiling the software would allow it to be installed on your existing system just fine.
• There is typically zero benefit to be had from this scheme, it's a badly thought out backwards compatibility system, and systems designed explicitly with binary distribution in mind like autopackage work around it automatically.

We can blame the admins, or the people who set the conditions of the test, or whatever, but the real problem is that Linux is crap at handling binaries. It requires an extremely precise knowledge of a million things that don't actually matter.

autopackage is probably the current best tool for this. It makes a single, easily installable (and removable) package while coercing my system's GCC and libs into versions that are suitable for other distributions.

I use it currently for schism tracker (particularly the CVS builds that I do).

It works very well for me: Debian, Ubuntu, SUSE, Fedora, Gentoo, and Mandrake users have reported success with these binaries built with (gasp) a lone FC4 machine.

One day, I'll actually do a proper release and six years later it'll show up in the next Debian release. Then your fancy apt-get tools will work.

And to kneejerk jackasses that say "just release the source"- you must realize that the source is good for you and me (well me anyway, I cannot speak for you, obviously), the people who USE these programs have absolutely NO INTEREST in doing the work that I have just done for my own purposes.

Plus, having them use a single binary means that it's very easy to debug with nothing more than a core file.

Oh, and I suppose I am giving the submitter the benefit of the doubt that we are indeed talking about Free Software, aren't we? :)

Your answer: http://autopackage.org/

I subscribe to the notion of a binary installation. However, until the Linux world can harmonize on a SINGLE package that runs on ALL Linux distros they will be far behind the Windows world in this regard.

...and in those cases, there is Autopackage.

The difficulty in installing some software is not the fault of Linux - it's just that maybe the developers haven't got around to making a decent distro-agnostic installer. Oolite-Linux is *not* distributed with any Linux distro, but it is very easy to install - download the autopackage, and run it. An Autopackage is basically an archive wrapped in a shell script that bootstraps the entire process - including getting the autopackage management infrastructure if your distro doesn't have it, and resolving dependencies if there are any to be resolved. Autopackages can either be installed in a GUI or in a terminal window. Superficially, it looks similar to the InstallShield-style Windows installers (but it does quite a bit more, such as dependency resolution, and can install programs quite happily as a non-administrative user where this makes sense, for example, you can choose to install Oolite-Linux system wide or in your home directory).

Autopackage is fairly new, but it's picking up popularity:
http://www.autopackage.org/

"I mean, it's not the lack of a kparts equivalent, being programmed in a 70's language - c++ is a bad OO language, but C is much worse as "OO language" still gnome went with C (and you have to admit those even if you're a gnome zealot)"

Yes, but back when it was developed, it made sense to use C. C++ compilers back then sucked. Especially today, rewriting everything in another language for the sake of using another language is nuts. Furthermore, even today C++ has ABI issues (see this page for details) while C does not, making it easier for developers to distribute C binaries.

KDE is nice though. It's a good move to at least ship kdelibs, so that KDE binaries can work out-of-the-box (more or less).

Autopackage?

If only SuSe, Red Hat, Debian and Mandrake could just agree on some STANDARDS !!! For crying out loud, everyone is bashing microsoft for not adopting an "open" standard (actually plenty of them) but the key distros cannot even agree on a common way to distribute and install an application. How can anyone blame Microsoft when the exact same idiocy is happenning in their supposedly "perfect" open-source world?

People should realize it's the same thing in the Linux world. Instead of trying to unify all distros into becoming the same operating system (which would just be pointless -- they are different for a reason), how about trying to standardize on a certain distro instead? I propose Red Hat/Fedora Core, but only because it already is the most common (I use Gentoo personally). By that, I don't mean that everyone should be running RC/FC, but rather that all non-expert users or other people interested in psuedo-standars compliance should be running it. Expert users can still choose their distro of choice.

Anyhow, even as the situation is right now, hasn't anyone heard of Autopackage? It is a distro-neutral packaging format, that can install programs in a user's home directory, which already exists and is working extremely well. Far better, in terms of both flexibility, ease of creation, and user-friendlyness, than any Windows MSI-like installer if you ask me. I recommend developers (and end users) to check it out.

Perhaps you're interested in autopackage? We're working very hard on multi-distribution compatibility.

They don't need to do this.

All they need to do is create an Autopackage, or, better yet, and Autopackage and a klik:// image.

Autopackage kicks ass.
http://autopackage.org/

Autopackage

Good comment. Thanks.

Software install is definitely an issue still. When the software you want is included in the distribution, then the install is easier than on windows. Open up whatever package manager you have, and chose the programs you want, and install them. As a bonus, you seamless updates to new versions for all those programs. But installing something that's not in the repository is a pain in the ass.

I know how to compile stuff, but that doesn't make it any less of a pain. Do I have all the required dependencies? There's no easy way to check, just trial and error. ./configure, look at the error, try to guess what package it's missing, install that package, ./configure again. It sucks. Luckily this problem is being approached from a few angles now. Autopackage (http://autopackage.org/), klik (http://dot.kde.org/1126867980/), and zero-install (http://0install.net/) all look really promising. I've tried klik, and it really rocks. Give it a go if you have a chance.

RedHat dealt with RPM hell years ago (up2date and yum both work very nicely thank you).
For everything else, there is Autopackage (http://autopackage.org/)

the answer is: http://www.autopackage.org/

Autopackage isn't quite integrated with the default package manager yet (per their website, http://autopackage.org/) Once that happens I can see that being very likely. ;)

You want autopackage. I suggest you read the materials on that site, these guys not only have the skills but they actually care.

I've been using Linux for many years, and the problem of obtaining software packages drives me to the end of my nerves.

Hmmm, what packages are you trying to install? I usually only have that problem if the software is still in CVS or something. But even then, Gentoo still usually packages it. I do have problems when I use Fedora. Not sure why they don't have a lot of packages, but it is hard to find stuff sometimes. With Debian, though, almost never a problem. In any case, Autopackage is supposed to solve this problem. It actually looks pretty neat, but I am waiting for local packaging system integration. Then it will just be a matter of convincing developers to use it. Some projects, like Abiword, already are.

Then the program is broken. Report the bug. The autoconf/automake scripts should take care of all that.

It sounds as if you'd like autopackage.

This is why most newer distros are using other package managers these days. Debian's apt and Gentoo's Portage do alot more dependency checking and just seem to work much better in general. I've heard good things about Pacman too, but never used it. RPM is slowly but surely going to die out unless they completely revamp how it works. If you can, I'd suggest just looking for a .package as they generally work with almost any distro with very little effort. ;)

There is Autopackage. Never used it but it looks like it'd suite your needs.

From Wikipedia:
Autopackage is a relatively new package management system for GNU/Linux, intended to be usable under all distributions. Unlike the RPM and Deb package formats, Autopackage checks for the presence of dependencies on the actual system, rather than querying a database of package information. Although this reduces compatibility issues with different package naming conventions, it does mean that Autopackage is slower than distributions' native formats. Autopackage packages are actually executable bash scripts, so that they can be installed simply by running them. Autopackage is intended to be used for installing non-core applications such as word processors, web browsers, and games, rather than core libraries and applications such as shells. For core applications and libraries, the distribution's native package manager is recommended for speed and compatibility reasons. Non-core libraries are something of a thorny issue, on the one hand packaging them allows installation on a greater range of systems, on the other hand there can be issues with conflicts when native packages are installed that depends on libraries that have been installed by autopackage. Autopackage differs from other executable installer systems for GNU/Linux such as Oblisk and the Loki installer in that Autopackage is specially designed to be compatible with as many distributions as possible. Autopackage uses APbuild to strip bogus dependencies, "cross-compile" to make C++ programs compatible with different versions of g++, and fix GLIBC version symbols, among other things. Programs must also be relocatable, meaning they can be installed into any location without needing to be recompiled.

With the rich resources of the OSS community, one wonders why rpm dependency hell has no adopted solution.

Autopackage http://www.autopackage.org/ would be a good start but all major distros are not even giving it support!

Next thing is multimedia and multimedia applications. Totem in the GNOME world and Amarok in the KDE world will not play mp3s out of the box, yet there are no licensing restrictions on these formats! These are so many other examples in the multimedia field.

There is a bug/feature I found in Linux that needs attention in relation to how devices are mounted. Remember that we in the Linux world are aiming at domination. So we should attract as many users as we can. The bug is here: http://bugs.kde.org/show_bug.cgi?id=111173. I was surprised that there was a wontfix mentioned. So how are we to attract users if there will always be confusion in how devices are mounted?

With the rich resources of the OSS community, one wonders why rpm dependency hell has no adopted solution.

Autopackage http://www.autopackage.org/ would be a good start but all major distros are not even giving it support!

Next thing is multimedia and multimedia applications. Totem in the GNOME world and Amarok in the KDE world will not play mp3s out of the box, yet there are no licensing restrictions on these formats! These are so many other examples in the multimedia field.

There is a bug/feature I found in Linux that needs attention in relation to how devices are mounted. Remember that we in the Linux world are aiming at domination. So we should attract as many users as we can. The bug is here: http://bugs.kde.org/show_bug.cgi?id=111173. I was surprised that there was a wontfix mentioned. So how are we to attract users if there will always be confusion in how devices are mounted?

The other thing Desktop Linux needs is good fonts. I am yet to find a desktop Linux installation that is beautiful out of the box. Often times, one has to download M$ fonts or could use the script found here: http://vigna.dsi.unimi.it/webFonts4Linux/webFonts. sh to get good fonts for the web.

Next thing is multimedia and multimedia applications. Totem in the GNOME world and Amarok in the KDE world will not play mp3s out of the box, yet there are no licensing restrictions on these formats! These are so many other examples in the multimedia field.

There is a bug/feature I found in Linux that needs attention in relation to how devices are mounted. Remember that we in the Linux world are aiming at domination. So we should attract as many users as we can. The bug is here: http://bugs.kde.org/show_bug.cgi?id=111173. I was surprised that there was a wontfix mentioned. So how are we to attract users if there will always be confusion in how devices are mounted?

Last but not least, we need publicity - good publicity. Right now, Linux is being touted as very good or good enough for the average user. What happens is that folks then have to understand that Linux is just a KERNEL and that there are many implementations associated with this kernel. To many, understanding this is a challenge. So one says "I use Linux at home, it's freely available on the net...try it out..." (and they leave it at that)! What follows is confusion as newbies find tons of distros and incompatible packages. Folks what do you think?

A distro agnostic packaging format like autopackage might help. It doesn't replace your distro's package system, it's in addition to it. Lets third party software writers not have to worry about distro specific crap, and gives the end users a consistant way to install packages that don't come with their distro.

As the GP mentioned, any-distro, painless install is the dream and reality of autopackage.

• 1 CD (less than 250 MiB)
• Gobo linux style file system hierarchy (mac style)
• YaST
• Only base KDE/base gnome
• base system (system binaries)
• No other applications (exactly, don't need 10 text editors, 5 databases, 20 audio players, etc.)
• All programs are provided by their developers directly via Autopackage or BitRock, and other windows-like installers sice no one in the linux community seems to like app folders

I teach game development and do alot of 3D modelling. Alot of what you say above is false out of the box.

The state of 3D on Linux is far from sucking. Proprietary Nvidia drivers on Linux cannot be beaten, out-doing their Win32 counterparts alot of the time, even where frame rate (Q3a, Doom3, UT2004, AA) is concerned. Nvidia on Linux is an industry standard 3D animation platform in the feature film industry, for good reason. When teaching game development, if my students are sitting at machines running Nvidia binary drivers on a Linux OS, I'm having a very good day. Naturally, I'd love it if an open alternative could compete - you seem only aware of the open-source drivers, which are essentially blind to the rich talents of the Nvidia GPU. ATI's fglrx drivers are now (finally) on par with Win32 where pixel/vertex shaders (GLSL ) are concerned and close to a performance equal generally. The installation process is slightly more annoying, that is all. Many non-free distro's handle this for the user automagically (Mepis Linux comes to mind)

Secondly, binary compatibility is no more troublesome these days than it is between versions of Windows, eg running a game made for Win95 on XP - occassionally an issue. Installation of binaries can be done easily using a system like Autopackage if one doesn't want to find and or become an *.rpm/*.deb package maintainer.

Where devices are concerned, the trouble you speak of is many years in the past - udev works in userspace, and uses hotplug calls that the kernel signals whenever a device is added or removed from the kernel. Permissions, naming and control is all done in userspace.

Finally where sales of Linux games are concerned, I tend to agree that it is perhaps a little harder to market to Linux users, though from experience I am the first to buy a game that comes out for Linux. You will find though that due to existance of compatibility layers like Wine, publishers simply don't know how many Linux users are buying their games. I can account for around 14 windows games I've bought with the pure intention of playing them on Linux (for instance). Linux desktop market share is widely considered to be above or equal to that of the Apple OS. Whatever kind of market it is, it's growing.

Lastly, for the grandfather, Ryan, of Icculus is your best bet for a Linux port.

PS. Game development, as a culture, needs free software if a) small to medium sized developers are to survive and b) if micro-markets (like that of the indie-film industry) are to burgeon. Tools are increasingly expensive and publishers offset this cost with IP tradeoffs (buy outs). If I were you I'd ship the engine as free software (binary checksum for login, cheat protection and validation) and sell the data and/or subscription time. More on why here.

Oh, sorry.
I really hope you insist on autopackage! URL: http://autopackage.org/

Technical binary compatibility is an irrelevance if Mr.Average User can't get his application to install.

Quite true.

Maybe it is possible to convert an RPM to a DEB and install it with Apt-get or one of its front-ends but again that's further than most users want to go just to get a pre-compiled app running.

If you want to install an application that isn't provided by your distribution then you really want to be using an autopackage. Binary compatability becomes clear - a single autopackage can install and run on most major distributions (providing you've got the same architecture of course). If the people providing you the software haven't packaged it as an autopackage... perhaps you should be asking them to do so. Autopackage is new, but it's great for packaging up your software project - no more "RPM for Redhat, RPM for SuSE, RPM for Mandrake, DEB for Debian..." just make one autopackage binary for the lot.

Jedidiah.

The main reason you don't see it advertised for more distros is because you have to pay for certification. A lot of the distros will try to follow most of the LSB guidelines, but don't have the funding to spend on certification.

I'd love it if Autopackage support became part of the LSB one day ;)

I have no freaking idea where this thing is actually stored.

The ~/.local directory is quite a wise addition, and is a user-specific directory equivalent to /usr (with bin, lib, share, etc.). Autopackage uses it to install per-user programs, and Freedesktop uses it to install per-user MIME-settings (in ~/.local/share/mime and ~/.local/share/applications).

Now, if Linspire could adapt autopackage http://autopackage.org/, the better since Linspire packages would be able to install on any distro.

Autopackage is an InstallShield style installer that lets users optionally install without knowing the root password. (it installs under their home directory, naturally in such a case)

Take a look:
http://www.autopackage.org/flash-demo-install.html

If I were to want to distribute commercial apps under linux, this is what I'd use.

You should try giving the .package file a whirl. It's built using autopackage which is a distro neutral linux based installer that also resolves dependencies. Even if you don't have autopackage installed, you just download the .package file and it handles everything. IMHO, it's best thing for Linux software development.

Autopackage is not a packaging system to build a distro, their own FAQ says so: http://www.autopackage.org/faq.html#1_2

There's nothing wrong with urpmi (and its GUI equivalent in the Mandrake Control Centre) - they work just as good as apt for me. I've been using MDK since 9.2.

Is it a new Windows distribution, when an OEM installs extra tools, such as IBM's laptop utilities? I think there's a tendancy to see division above and beyond where there actually is any, when it comes to Linux.

Changes in policy alone can made a distro seperate from its parent.

Personally, what I would like to see is a "standard source library", where versions of packages known to work together are collected together. That would simplify the work of binary package maintainers and provide a level of unification on the baseline WITHOUT imposing unification in the installation or the experience.

Agreed. I think a combination of Componentized Linux and AutoPackage would bring us several steps closer to that goal. Also, it's too bad that Fedora "Core" doesn't join in the effort.

I have long thought that we need a package and repository system for FOSS on windows also. Wouldn't it be great if you could just install apt-get for Windows and get all of the OSS goodness in one shot with automatic updates? :)

I would ALSO like to see package maintainers work together a bit better. I use a number of the RPM distros that make up the RPMForge collaboration, yet I do run into lots of incompatibility issues. This is not necessary and definitely not desirable.

I'm not familiar with RPMForge, I agree that there should be more consolidation when possible. Why do there need to be several incompatible repositories for Fedora Core? Why can not everyone converge around an at-rpms multi-step testing style instead of pushing out the current version as soon as the latest is released? I'm not even endorsing at-rpms itself, just that style and consolidating the repositories.

Why is there not a common repository project that supports all of the big RPM based distros (at least RHEL, Fedora, SUSE & Mandriva)? If nessisary use one SRPM and compile it against the various target distros, but maybe one rpm could cover them all (I'll let someone else inject the LOTR reference).

I think diversity for Linux is essential, but a software version of the Great Library of Alexandria would definitely help with not only maintaining those distributions efficiently but also make it easier for distros to be much more compatiable with each other.

Debian is already at the center of several distros, why not extend it over to the RPM world? Use Debian source packages and make RPMs out of them. :)

Excuse me, there are many more packages than Gaim available here. Firefox, Abiword and The Gimp stand out as the most popular packages on the list.

Autopackage addresses this issue by allowing the providers of software to roll their own equivalent of an InstallShield package.

The only big piece of software that I know about that distributes an Autopackage is Gaim (here).

Just download and run it, and after some progress bars and some simple questions you have Gaim on pretty much any distro. Sure, it has to provide its own dependencies (so you lose the benefits of sharing libraries with your distro), but it works damnit.

So the problem is being addressed on Linux, it's just a matter of software getting packaged in a way that everyone can use. But that's kind of the idea of distributing source...

I don't know ... user idiocy can really be equated as people using your software outside its intended purpose. To me - what marks a good engineer is one who accounts for such deviation. Calling people idiots doesn't solve the problem. It just puts further barriers between you and the problem at hand.

But on the topic of Windows, I do find it to be an inferior operating system in the sole reason that it is designed like a submarine with one compartment. Get one leak - no matter how small - and the entire ship goes down. With Linux, just seal off the damaged compartment, and keep on keeping on.

I do agree with you in regards of installing software on Linux. That's why I hope this little project takes off.