Fair warning, rant incoming. I’m working on a server development project, which will get deployed to CentOS 3 or possibly 4. Since I don’t currently have a spare machine that’s fast enough and able to blown away, I revived my linux dual boot on my main development workstation (2x opteron 242, tyan thunder k8w). I initially went with Fedora Core 5, since I figured I could easily enough rebuild using mock for centos4 and centos3. Except I’m getting my butt kicked by the ‘udev hangs’ bug. No combination of kernel versions, acpi=off, noapic, udevtimout, selinux=disabled, apm=off or bios changes seems to make the machine boot consistently, let alone assign my ethernet cards consistently.
Since I have work to get done, I went ahead and installed CentOS 4.4, which luckily did install and with the addition of the Nvidia binary drivers is running my dual screens beautifully and stably. Now all I need in order to work happily is music! Unfortunately, most of said music is in mp3 format, and redhat doesn’t supply an mp3 decoding library, due to licensing issues. I understand the nature of the situation and don’t fault redhat for this, but nonetheless its really annoying.
There is no livna repository for rhel/centos, and trying to build the repos for fc3 or fc5 tends to introduce all sorts of dependency problems. And besides, I’m not getting paid to rebuild mp3 players, I have real work to do. I just want to listen to mp3s! Luckily for me theres a guy out there by the name of Dag Wieers who maintains a very nice set of RPMS for fedora AND rhel distributions, and his xmms package compiles cleanly with dependencies I’ve already got, saving me from working in misery for another few days.
However, all of this points to a major problem in the Linux world. As much as we love to hate it, Microsoft absolutely understands binary application compatibility. For a given version of windows, application developers know exactly what library versions are guaranteed to be available, and how to include the rest of their dependencies in a safe way. Standard practice is to include the libraries that are needed inline with the application. Windows provides reasonably standard interfaces allowing the application register itself as a type handler and to add desktop shortcuts, quicklaunch icons or start menu entries. Every windows application developer writes one or perhaps two versions of application foo and makes up a nice little installer, and after a few iterations has an installer that works on windows, period. Sure it makes the average download kinda big, but honestly in the days of free after rebate spindles of CD-ROM’s, broadband for $15/mo, and 250gb hard drives for under $100, who cares? My time is worth a WHOLE lot more than a few extra megs used up on my drive.
Compare that to linux. Say I found out about this great new mp3 player. I go to their website, and see a source tarball. I try to build the source tarball and if I’m lucky the’ll have a competent ./configure script which will find out what dependencies I’m missing and tell me about them. At that point I’m looking at a significant period of time trying to find prebuilt versions of those build dependencies, or rebuilding my entire system from scratch. If I’m lucky, they’ll have an pre-built rpm package. However, 9/10 times that rpm is going to have a whole slew of unmet dependencies and I’ll have to spend several ours ferreting them out and downloading them. If I’m really unlucky, the application will depend on a whole slew of CPAN libraries, some of which will come with my OS, and some of which will require a perl version not included with my distro. I can understand needing to integrate directly with the OS when we’re talking about truly system level stuff, but 99% of the time thats not what I’m talking about. An mp3 player does NOT need to know what kernel version you have, nor does it generally need to know much of anything about your system. It doesn’t need to know what version of python, perl, or php is included with your distribution, nor what extensions those libraries include.
Linux distributions absolutely must get away from the ‘distribution contains every application’ mentality. Right now, if an application doesn’t come integrated with an additional application, or have a version packaged specifically for that distribution, life sucks for the user. Life also sucks for the application developer, who would like to see his software able to be used by everybody, but can’t, because he uses debian and doesn’t know how to package for redhat.
The answer to this, of course, is the Linux Standards Base (LSB). It describes a set of ABI’s that the OS should guarantee, and defines how an application developer can package up the rest of their dependencies so their application can run on any system providing LSB support. Every major linux distro out there supports LSB applications, except I don’t see a single open source application providing LSB binary downloads!
Why? I’m not positive to be honest, but I’m willing to take a guess. It’s too dang hard to build for. I’ve not done a lot of research on it yet, but I just haven’t seen an easy to use buildroot for LSB on redhat. Nor have I seen an easy to follow howto for building LSB applications. In addition, it’s probably just sorta inconvienient for developers, who pick a disitribution they like and just run with it, following the dependencies.
In our zealotry for open source, we continue to paint ourselves into a binary incompatibility corner that is simply unsustainable. The OS (distribution) absolutely needs to be able to evolve, or not evolve, as it needs. Applications need to be able to evolve (or not evolve) independantly. If I want to listen to be able to mp3’s, I should be able to choose from a variety of mp3 players (the code is out there!) and use them easily. That means we need real binary application compatibility, just like consumer OS’s. If I want to run a bleeding edge browser on my otherwise stable machine, thats my prerogative, and it shouldn’t require me to invest a day resolving all the requisite dependencies and building the thing from scratch. Regardless of what Gentoo folk will try to convince you, rebuilding everything from scratch and customized is not a sustainable way to run an operating system. It takes too long, and is too complicated to ever allow mainsteam users to do it, or even people who just have better things to do!