Yes I know what you mean. Ubuntu is like a building site in which construction never finishes. I lost faith with 7.10 and then regained it with 8.04. Lets see what the next upgrade breaks. 😉 Incidentally I don't know if you tried Kbuntu 8.04, but that was so broken it was unusable.

I recently had a kernel upgrade for Ubuntu 8.04 which broke my wireless drivers. Luckily it wasn't on my main laptop, but if it had been, I'd be spitting feathers by now.

But you bring up an interesting point. Windows has a release every two or three years. Upgrading from one iteration to another is major pain. Ubuntu on the other hand commits itself to lots of small breaks on every 6 months, but no real major upgrade problems. Not sure at this point which I prefer. Maybe you're right, a release of Ubuntu once a year would be enough. Or maybe they do that already but the .10 release is more akin to a service pack.

Hmmm. Pontificating too much here. I'd better get on with some work.

I'm surprised that an HP box is giving you so much hassle, as HP is a supporter of Linux. However I see from a google search that a lot of people are having problems. It sounds like a hardware issue to me, and frankly Windows has those as well — if you don't have the correct drivers, then your hardware won't work.

First of all I suggest you take a look at the HP page for your server. http://h18004.www1.hp.com/products/servers/linux/ml110g5-drivers-cert.html

It seems that your best choices for running linux would be Redhat Enterprise (so you can also use the OpenSource Centos which has the same code base), and Suse, which is available as an OpenSuse distro.

If you really must use Ubuntu for whatever reason, I'm guessing that playing about with a Live Boot CD and changing the boot options will eventually give you a CD that boots. (eg noapic acpi=off etc). Once you've booted the CD, you can install it from the desktop.

If you don't have direct internet access, then installing any operating system is going to be a challenge, as there is a great deal of help available there, and you'll need to install patches, and perform system updates using the internet as well.

Finally, as a general rule of thumb, if you're asking for help from someone, its usually best if you don't shout obscenities at them!

Maybe this is just impractical as there are too many combinations, but then again I'm nowhere near as expert as you appear to be on the matter.

The distros exist because all these people have different opinions on how a Linux system should work. I'd say this is a real-time experiment, a Darwinian effort to see which approach works best. This is the price of innovation. At the other end is stagnation, and I don't think any of Linux users would like it to stagnate.

Reasons for why it's hard to create universal packages:
1) Improvements/differences in GCC compiler and so called "toolchain".
2) Different init systems and services management.
3) Different config files locations and syntax.
4) Different package formats and package management systems.

Explanations:

1) All binary programs that constitute a working system have to be compiled (translated from human-readable form into a form suitable for CPU to execute). In case of Linux the kernel, basic GNU tools and other useful programs (be it X Window System, GNOME/KDE/XFCE/etc, Firefox, K3B, and so on), this is done by a suite of GCC compilers and a set of tools like: automake, linkers, loaders, binutils and so on.

These tools are not set in stone, they are improved, changed, restructured over time, not to mention the occasional bugfixing. Sometimes these changes are INCOMPATIBLE, like changing the GCC from version 2.95 to 3.x line and then to 4.x series. The same is for accompanying tools. They all change as their requirements change (according to the user's demand).

So when a particular distro or a package developer decide to use a specific set of tools and libraries, with their specific versions and behaviour, these decisions can be a source of incompatibility across distros and package maintainers. So for example, an mplayer package from distro A may *NOT* work at all in distro B, because of so called ABI differences (Application Binary Interface). The compatibility is maintained at the source level instead. So it's the distro maintainers that worry about this, so they just recompile a problematic package and put a new version for use.

2) Even when the package is compatible at the binary level (which is true for most packages and distros), distro creators may have different views on how their systems work internally and how they handle system services. I mean the locations of service scripts (/etc/rc.d versus /etc/rc0.d versus /etc/init.d), their configuration files' locations (/etc/default versus /etc/conf.d) and structure, where they place working directories of services, and so on.

This may not apply to the end-user applications like web browser, multimedia player or CD/DVD burning application. But for things like cups (printing service) or apache (web server) it is a serious concern. Each distro may offer a unique approach here, because people disagreeing on the details. So it may happen that a specific package from distro A would not work in distro B or may even break its installation. That's why users are advised *NOT* to install foreign packages on their own without thinking about consequences.

Compiling a package manually under a given distro typically yields in a working package that's tailored to this distro (and honestly it's not so hard as one can imagine). But since then it is the user that's responsible for maintaining such package and upgrading it when some bugs are found.

3) Sometimes even a basic structure of config files may be radically different. From my experience the network configuration varies wildly between distros (e.g. Debian, Mandriva, RedHat and Gentoo have it completely different). Apache configuration files are also well known to be differently separated and placed in different directories and under different names in distros. Just because people have different opinions and vision on how it should be done.

4) Package formats of DEB, RPM, TGZ, .recipe, .ebuild are different enough to be incompatible. In some packages there are little programs (maintainer scripts) that are run at the beginning of the installation or after a package is installed.

Each package format has a different way of describing dependencies (which other packages need to be installed first before a given package would run correctly). Even RPM or DEB packages from different distros may describe dependencies incompatibly. Even packages from different releases of the same distro may be incompatible!

Package formats also evolve, for example recently Ubuntu and Debian introduced the concept of package triggers, independently of pre-inst or post-inst scripts. Yes, this mechanism is backward compatible, but you get the idea.

Concluding, there are incentives to minimize the differences, like the noble FHS (Linux Filesystem Hierarchy Standard) or LSB (Linux Standard Base). So the problems are worked on, but for now it's really hard to create a package that would run unchanged in a number of distros. I don't say this would not change in the future, but I hope you now understand the problems here.

VM: Sounds like I'll have to give Mandriva a try as well. I only used it once a couple of years ago when it was installed on a client's server, but a lot can happen in two years! Interesting comments on KDE.
I sympathise with your experiences in the PCLOS forum. I understand that they can't support the distibution once you've made changes "outside the box", but they do seem a bit strident about it.

SRhedge: PCLinuxOS is indeed on version 2007. However I used the Gnome edition which is tagged as 2008, (http://www.linuxgator.org/Gnome/gnome_page/gnome.html) Sorry for the confusion. However that does now explain why its using the PCLOS 2007 repositories, which was confusing me!

Lorrain: Looks as though it could be useful to any Turkish users out there …

RM: Thanks for the link. I'll check it out.

Tim: Sounds like this is the problem. You need resources to run a big repository, and while Ubuntu can afford them, PCLOS is a small operation. Anyone know how many people are involved in it? Is it just the one guy? Tex whatsit?

Shocky: Ubuntu definitely has better marketing (thanks to its greater resources, as noted above). And it may well be that Mandriva is way ahead. However one thing we should all be thankful for, is that the halo effect from Ubuntu's marketing efforts has brought _all_ linux distros into the limelight. People are now aware there is an alternative. Manufacturers like Asus, Dell, HP are offering their home PCs with Linux on. Its all going in the right direction. And yes, I'll try Mandriva.

Brian: Great round up of distros there. Thanks for the information. I was wondering if anyone was going to mention Xandros, as it was the distro which featured on the Asus EEE PC.

StolenNomenclature: Your post made me think. The vast number of distros and packaging systems is indeed a problem. Maybe there is a way around this: there are cross compiling systems for software which will automatically build software for eg Linux, Mac, Windows, Windows Mobile, etc. I wonder if those could be adapted to build for all the different versions of Linux as well, or at least the major ones.
I guess this will all resolve itself as a few distros forge ahead and become the most popular. Maybe the other distros will start to fall in line and use the same packaging systems and standardise. However in doing so, we may lose one of the things that Linux is all about — the ability for someone to say "I don't like the way they're doing this. I can do it better myself" and go ahead and make your own distro.

Rambling a bit here. Maybe I should do another blog post on this later …

lefty.crupps Says:
June 3rd, 2008 at 8:50 pm

How are you liking KDE in PCLOS vs the Gnome that Ubuntu uses? I am a big KDE fan, which makes it hard for me to find a truly great distro with a lot of packages and community; eventually I have settled on Debian Testing, which has a good default KDE, a ton of packages, and rolling release updates.

Lefty, just in case you are looking for other distros that use KDE with Debian, here are several: sidux (2008-02 development snapshot released today, 2008-01 is the supported version available. It is a rolling release, and with a broadband network, you can be VERY current with your KDE software.

SimplyMEPIS 7.0: this one is aging, but it is still newer than PCLinuxOS 2007. It is extremely stable and it works very well. A somewhat newer offshoot of this is AntiX M7.2. It uses either Fluxbox or IceWM by default, but you can download a KDE-lite implementation if you prefer. Very light, very fast. SimplyMEPIS is the model of stability and simplicity; AntiX is the model of lightness and speed.

Xandros: Older than PCLinuxOS or SimplyMEPIS in its standard version; seems to be going the OEM route with the EEE PC projects. Extremely easy to set up and use, especially when already included as the OEM OS on small computers. Very good interoperability with Windows. Recommended for people used to using Windows.

Kubuntu 8.04: you can get this either with the latest stable KDE, 3.5.9, or you can get it with a KDE 4.0.3 update or with the latest KDE 4 snapshot. Very easy to install and easy to use.

PCLinuxOS is very similar in operation to these systems. It is most similar to Xandros and SimplyMEPIS in being simple to set up, configure, and use. Does not provide the latest software, it tends to lag in this, but what it provides always works well. PCLinuxOS gets most of its packages downstream from Mandriva, which may partially explain the lag in getting the latest software. It uses Debian-originated apt-get packaging tools retrofitted to work with RPM packages. The synaptic tool is used as the graphical implementation on top of apt-get and this makes for a very easy to manage system.

Before you go back to Ubuntu, give Mandriva 2008 Spring a try (though if you wait another month or two it will be even better – Mandriva releases always need a couple of months to stabilize before they show their true potential).