Severs are a completely different thing. OK?

No, not OK… trying to maintain a different ELF binary system and a different library system for “desktop” as opposed to “server” is a completely brain-dead idea. The system for binary format and library linkage should be generally applicable on desktops, laptops, small business, big business and supercomputers and everything in between. And there’s absolutely no reason why that cannot be achieved.

Yet, these pundits are wrong–every year.

Linux seems to be making steady growth in both the server space and the desktop space and the embedded space too. What are these mystery pundits so wrong about exactly? Linux is a bit like global warming… you can keep saying it isn’t happening (and many people still do), but that doesn’t matter because it happens anyway.

As for stability… the world changes, deal with it. Really.

The current objectives of most of the Open Source world are development and growth. These objectives are being achieved. Your objectives might be different, by all means put your effort into building a distribution that is more stable than the others if you think that will be useful. It’s pretty annoying to hear people tell me that they know what I want better than I do, then explaining to me what I “must” do.

ELF links exactly as I would expect and how I’ve always expected. The last thing I want is multiple versions of the same code running in the same memory image — that’s just a nightmare to program around because every program needs to store global state in some form or other and now you end up with multiple copies of the same global state or worse you end up with incompatible code manipulating a single piece of global state memory. Trying to debug such a situation is hopeless. It’s the last place anyone would want to go… but if you want to go there then go and write your own dynamic linker, Linux lets you do that.

Not much of the Open Source world is deeply concerned with the distribution issues of proprietary vendors. However, proprietary vendors continue to exist and some of them (e.g. Oracle) have decided to become Linux vendors as well. Here’s one: http://www.cadsoft.de/ and they support MS-Windows and Mac too so obviously they have figured out how to compile multiple versions of their code in a reasonably robust manner.

Finally, there’s no such thing as “Joe Average” user, just like there’s no such thing as a one-size-fits-all running shoe. Every user is different, they all have different needs. If you push them all into being “average” then they will all be unhappy. That’s why system diversity is a good thing.

Just because you find it convenient to try to categorise the world into nice, simple distinct units does not imply that anyone else should bother to respect your stereotypes.

Having standards is also a good thing, but not the sort of standards that are too inflexible and get in the way of progress. Even the posix standard is continuing to evolve — expect ppoll() and pselect() to join posix before long. The world moves, it takes all the running you can do just to stand in the same place. If that requires a recompile now and then, well big deal.

I’ve never noticed that Firefox had a problem getting out fresh versions to a wide variety of platforms on a regular basis. The official firefox release binaries and/or the various distro archive binaries are enough for about 95% of users — the ones who want to be more bleading edge are usually also the ones who can figure out how to compile from source, and that’s a good thing because the less knowledgable users automatically end up with more mature packages that have been through the testing of the more adept users. It’s a self-regulating system.

There is nothing wrong with adding new functions to an API. GTK+ does this all the time and still (mostly) maintains both API and ABI backward compatibility as long as you don’t use these new symbols. Your ppoll and pselect examples would fall into this category as well.

Both Apple and Microsoft has been able to maintain backwards compatibility, so it’s not an impossible task. Granted, they both spend huge amounts of resources on it - resources not always available in open source projects - but that doesn’t mean that we (F/OSS world) should ignore the issue completely. Also, sometimes it’s required to do a fresh start (MacOS 9 vs OS X, GTK 1.x vs GTK 2.x etc.) and it’s perfectly legal to do so. Just make sure to provide a migration route (parallel installable libs, emulating older system etc.).

Also, don’t be so hasty criticizing someone for dividing the world into distinct units when you do the exact same thing. (Regarding which type of users who wants to run the latest firefox). There are many reasons for wanting to use the latest version of something. I’ve been hit several times by this issue, and I’m using Ubuntu which is doing fairly frequent releases. Last time I was bit by this was when I wanted a newer version of Banshee. Sure, I can wait until the next ubuntu is released, but is it *really* needed that I upgrade my entire OS just because I want a newer version of a music player? You can’t just shake this issue away by saying that only tech people needs a newer version than the one in the repository.

One thing I do agree with you is that this should be solved for all systems - not just the desktop. But what I think that Taj meant is that desktop systems are typically more targeted by these kind of issues, since a typical server environment has dedicated admins that handles the compatibility issues (only install from repo, compile from source where needed, test test test)

ELF links exactly as I would expect and how I’ve always expected. The last thing I want is multiple versions of the same code running in the same memory image — that’s just a nightmare to program around because every program needs to store global state in some form or other and now you end up with multiple copies of the same global state or worse you end up with incompatible code manipulating a single piece of global state memory. Trying to debug such a situation is hopeless. It’s the last place anyone would want to go… but if you want to go there then go and write your own dynamic linker, Linux lets you do that.

I fail to understand your point here. You argue that the current ELF linker is doing exactly what you want and then complain that the results (global state corruption due to incompatible code) of its behavior is a nightmare. I agree. It *is* a nightmare. A better linker would keep the two loaded libs as completely separate entities, each with their own “global” state. It would also make sure that if MyApp is linked against v1 of libfoo and libbar [which is linked in by MyApp] is linked against v2 of libfoo, they would only access symbols from their respective version of libfoo.
No symbol collisions, no incompatible code accessing a super-shared global state. No hard bugs to debug in gdb. Everybody’s happy

However, I think we are talking to the wrong people. Nobody in the Linux developer world cares about this.

There are a lot of users that complain about this but gets highly criticized because they are questioning the distro / repository model.

The biggest benefit of the distro model is the easy way of finding software and updating the software that is installed. If Autopackage or Zeroinstall could provide that, it would be great - but right now, they simply don’t can’t (look at the amount of software in Debian compared to Autopackage / Zeroinstall).

The problem is that only the Linux distros are mature enough to compete against Windows (I think, please correct me if I am wrong) and that’s why people are using them.

We need a competing alternative: could it be BSD or Haiku?

For #2 under repos:
The kind of people who are implied when people talk about “making it to the desktop” (something which it has already done in my family due to Ubuntu being a lot easier to use than Windows) are not the kind to be beta-testing. The kind of people who beta-test are the kind who probably know a bit about coding themselves–enough to type ./configure && make && sudo checkinstall. The “checkinstall” makes it into an easy to “apt-get remove” deb. The kind of people who are afraid to compile (the kind assumed in this kind of discussion) are probably not equipped to deal with the problems that result when using beta releases, so this really doesn’t matter.

#7 in repos:
Three letters: CNR. Linspire/Freespire’s Click N Run is now merging into the Ubuntu line. This lets commercial vendors charge their fees instead of trusting their stuff to regular repos.

You are not addressing the kernel stuff.

Also, regarding backports: can I get F-Spot 0.3.5 for dapper?

I will answer myself: no, I can’t.

Also, regarding beta-testing: beta-testers don’t necessarily want to compile. They have better things to do.

There is stable interfaces in Linux, in the form of portable APIs like Java, or API-independant protocols like X11 and DBus - these can be used from multiple programming languages, on many versions of many distros, right now. As an example, libhal’s API is unstable, but if you connect to hald straight from DBus, you can skip using libhal completely.

If you want a stable C API, either ditch ELF and make another object file format, or force his highness Ulrich Drepper to accept the -Bdirect patch and make gcc generate Bdirect ELF sections by default (ie. without the need for some special switch that nobody will know or use); I’m sure if Red Hat’s management got involved in the decision, the patch would be accepted very quickly.

Centralized repositories are evil and I hate them - but what else do you offer people? It is bitterly ironic that autopackage, which is a far superior solution, has less than 1% of the packages in Ubuntu’s repos. The way to win here, is to build autopackages of software which is almost never packaged or really difficult to install: MythTV (a mission to install, entire distro - MythKnoppix - just to get it working), asterisk (entire distros: Trixbox, AsteriskNow are built around it), mplayer (many people including me run the Windows version under wine, it’s easier than compiling the Linux version), and so on. Get this kind of software autopackaged and watch autopackage really take off.

I just wanted to share my expirence with you. My site is http://www.viralpatel.net and http://geocities.com/taj_os