Sunday, November 9, 2008

Standardizing Linux Suckiness 3.0

Well, lusers keep crying that "LSB 4.0 will be the ultimate enabler of Linux on the desktop and seal Microsoft's fate!" Well, looking at the project plan, it appears to be just as useful as all the other releases (i.e. completely fucking worthless). It mostly seems to contain a list of library updates. I was told to read the LSB 4.0 specification, but I cannot find any such thing. The closest thing I have found is this Project Plan.

OK, I was told that it included a way to make packages that would render the distributions irrelevant (something about a dynamic linker, I think). I do not see any such thing. The closest thing I could find was Best Effort Dynamic Linking. Here is the description of the 'Vision' of this wonderful technology.

Right now, the LSB requires a different dynamic linker than the rest of the system. This linker is often not provided at all on non-LSB systems, and cannot be guaranteed to be available even on distros that can be LSB-compliant (if the LSB environment is not installed).

WTF? Why does it even require a separate dynamic linker in the first place?

This is a serious obstacle to acceptance of the LSB by ISVs; no one wants to have to make sure the proper dynamic linker is installed. The tools we have provided to try and mitigate this problem have not been good enough.

To encourage ISV adoption, therefore, we need to implement the dynamic linker change a different way.

Theodore Ts'o has proposed an alternative mechanism for supporting the dynamic linker. In this model, the ELF dynamic linker is the same as for all other binaries on the system, but the LSB SDK embeds some code into the executable--either via crti.o or via an init function called early--which checks if the executable needs to be run with the LSB dynamic linker instead, and re-execs the binary if necessary. This provides a "best effort" system for running LSB applications, which can be ensured to run correctly on all Linux systems regardless of the status of LSB support on the specific machine.

Umm, Theo, how does your system cope with a missing shared-object file? If a distribution does not include the required .so, does your system download it from the internet? How does this help with LSB noncompliance? This certainly does not look like it will make the distributions irrelevant.

Well, what other exciting, cool things will LSB 4.0 add to the Linux Desktop? Hmmm... Not much. It looks like a bunch of library updates. However, the Desktop Module does not cover all the things needed for a good desktop, so let's look at the Multimedia Module. For the lazy hater, here are the features it lists.
  • ALSA (moving from TrialUse in 3.2)
  • GStreamer
  • PulseAudio/SydneyAudio
Wow! It does feature PulseAudio, that performance-sucking wheel-reinventing beast! However, maybe it does not. Thank you for making that crystal-clear, LSB! The thread linked to from PulseAudio's status features a great quote by the way, "Applications having to worry about 4 different audio interfaces when they could just be worrying about 3 is just wasting resources."

Well, call me a cynic, but I think this new standard is the same-old same-old. It does not seem to offer anything all that compelling to make me think "this is truly the year of the Linux desktop!" If the LSB was serious about standardizing Linux, there is one thing they need to do: take the LSB Sample Implementation and make a complete desktop out of it. Then, compel the major Linux distributors to build their distros around the LSB system. All the distros could still add their proprietary touches and package managers, but there would be uniformity at the heart. Sure, the distros might be a little wary at first, but they should soon see the light. Even if the distros had to give up some 'competitive edge' with other distros, the extra revenue gained from a deluge of new customers who heard that Linux was finally not broken into several hundred pieces should more than make up the difference. Also, the distros would incur less inhouse maintenance costs. That alone could make Canonical profitable. This is the same lesson that has been learned throughout history: if you can put aside your petty squables and unite, the potential losses to competition will be dwarfed by the gains you have made. Too bad lusers don't seem to care about history.

No comments:

Post a Comment