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?
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.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.
- ALSA (moving from TrialUse in 3.2)
- GStreamer
- PulseAudio/SydneyAudio
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.
15 comments:
Read the comment beside pulseaudio its is currently off the table.
Sydneyaudio is more of a wrapper that makes under audio system a non issue.
Reason for needing a different dynamic loader to the rest of the system is that that LSB dynamic loader supports applications shipping with there own .so files that either fill in for distribution missing .so file or over riding Distribution provided .so with your own.
So missing .so file is not really a issue to LSB 3.2. Missing dynamic loader is the second last major bug bear.
Last major bug bear is installation.
Default Distrobution dynamic loader does not allow application developers to use there own things.
Would have paid to find out what the LSB dynamic loader allows that the Distrobution one does not before making a idiot out of yourself.
What's this LSB thing for anyway ? Will this allow me to run the non-existant commercial and proprietary apps written for Linux regardless of which shitty distro I choose to run this week ?
I thought Linux was about "choice": as in "choosing" if I want my default wallpaper to be shitty-brown, or in one of a million kinds of blue or green. Because wallpapers are the main difference between most of the popular distros. Wallpapers and incompatible packages...
"Reason for needing a different dynamic loader to the rest of the system is that that LSB dynamic loader supports applications shipping with there own .so files that either fill in for distribution missing .so file or over riding Distribution provided .so with your own."
Just great. Now a desktop application will ship along with a whole Windows manager, and the proper version of it. Expect MyFavApp to replace KDE 4.1 with KDE 4.0.
Hilarious. :-)
LSB=Linux Standard Base
Non existent is not right. There are a quite few commercial applications out there that do depend on LSB standards.
StarOffice and Lotus notes for Linux both depend on it along with a lot of game servers for linux and other commercial databases and web applications. Those are the cheapest. Lot of the other desktop applications are a few thousand dollars a seat for windows or linux.
Current LSB 3.x applications need a LSB 3.x compatible distribution. LSB 4.0 allows developers to release without that restriction. So yes in time it will allow you to use commercial or open source binaries built to LSB standard independent of what Distrobution you are using.
Shipping with the full KDE runtime would be no different than shipping games with the Full Direct X. To be correct full KDE runtime is smaller.
To be correct with the upcoming X11 alterations. In future if applications want to ship with there own full X11 server and Windows Manager they could.
Of course most developers will not do this due to size. This is also the reason why the installer stage of Linux Standard Base is being developed. So application installs can find out what the distribution provides if its usable if its not install there own.
Some commercial web applications for Linux do ship with a full apache and mysql and php of there own so you could not write of that a application might ship with full box and dice.
KDE 4.0 can be installed long side KDE 4.1 built threw LSB without fighting with each other due to the dynamic loader alteration in LSB.
Overriding for the application. Not overriding for the distribution installed. I should have been clear on that. Ie distribution ships with a broken lib of some form. ISV does fix there application by shipping that .so to there application. Yep the ISV application works ever application provided by the distribution that uses that lib does not how nice. I can see a day where third party installation of applications is preferred over the distribution path.
Game is changing true options of choice is coming to Linux. Even the incompatible packages issue will come to a end soon enough. Why will developers bother building for distrobutions when they can build one package for them all.
I should have clear this up.
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.
Tried in 2002 complete failure. Your ideas are out of date and tried Linux Hater Redux.
LSB has moved on to Distrobution independence because its the only way forwards. Linux Hater had the same issue. Could not see that suggested idea of a constant ABI that distribution must provide just cannot be made work. Linus says controlling developers is like trying to hurd cats. Trying to hurd distrobutions is like trying to control a pack of very hungry man eating lions with a piece of rare stake. Its simple to avoid them.
LSB has been avoid them by doing deals with KDE Gnome ... Many other open source package providers. So distribution being LSB is coming from the location they get there packages from.
Alsa got knocked back to trail again due to lack of a complete set of test cases to make sure its operating correctly.
LSB demand quality from any included parts in the main standard.
Issue is the citadel of distrobutions wanting to all be independent from each other. LSB 4.0 standard implementation will be shippable for diagnostic reasons. Ie if a distribution has tweaked and broke something it will be prove able.
Its part seeing that everything is a stepping stone.
You cannot have binary graphical installers if they cannot run. This is what LSB 4.0 is about. Applications can always run.
LSB 4.1 is when the installation system is time lined. Missed the 4.0 window for include. Its a high priority project.
Notice beside pulseaudio and other frameworks is marked low.
I think I am going to have to put forward that Project Plans include a guide what. High medium and low mean in LSB terms.
High really should have made it in some form trial or full standard just not ready yet ie next release.
Medium would have been useful most likely next release if all lsb criteria get meet.
Low looked at some time in future. Not important even a chance it will never ever make it into the LSB standard.
Also order is important. V4L, XVideo will both be looked at before pulseaudio is even looked at. So pulseaudio at soonest include is at least 2 years way heading towards never.
Its also a sign of pulseaudios low importance. It does not even have its own line.
You also need to be aware at the start of the LSB 4.0 cycle pulseaudio got to medium and was before V4L and XVideo for include. Its been knocked down 1 level and lowered in order to look at.
So yes LSB people think pulseaudio in its current state is crap. Just not sure if its future state will stay crap.
Yes its understanding low. They looked at pulseaudio with the idea of removed it from time table completely case just could not be made for that yet. LSB 4.1 could see it fall off the project list completely.
Low is not the location you want if you want something in the standard.
PS Open Sound System has been in the LSB since 2002. Its ALSA sorry state why its taking so long to get into the main standard.
oiaohm, I do not see what LSB 4.0 offers ISVs that they did not already have. If you have to include various .so's for particular distributions to get your application to work on them, you are probably better off just statically compiling the damn thing.
Hosted on a Linux server, and a fork of another blog. This blog is sad and ironic, and not worth taking seriously.
Hosted on a Linux server, and a fork of another blog. This blog is sad and ironic, and not worth taking seriously.
Reminds me of desktop Linux, and more specifically, of LSB :P
Promises, promises... Ongoing for last 17 years.
You never learn, do you?
The problem with both GNU and Linux, is that their APIs are moving targets and ever changing. You can't standardized them, and when you do they have been already obsoleted.
Really no you don't understand what the problem is with static building.
Static building provides no updating path and no common shared .so files option. Yes LSB 4.0 alteration is a boost. If you are producing more than one application as a ISV you can now depend on a common runtime for them all.
Please look closer at windows applications you will find some applications do exactly the same thing when installing on Windows 98 2000 XP and Vista. Installing different compatibility libs. One catch with LSB solution libs needed across all distrobutions will be the same .so files. Not special different ones per windows version as windows developers have to produce at times.
LSB 4.0 is a stepping stone. Applications allowed there own .so always was the first step.
Secound step is the dynamic loader removed from problem.
Thrid step is the installer ie LSB 4.1. This way ISV's can share third party bits.
Part of your problem you don't understand the full reaching effects of things.
Other next step is also Dbus. Dbus is leading to a common configuration system for all distrobutions.
The game is a foot in many directions.
The problem with both GNU and Linux, is that their APIs are moving targets and ever changing. You can't standardized them, and when you do they have been already obsoleted.
Sorry Myth. ABI's of Linux and Unix are far more stable than most people are aware. LSB has been working on a viral method as well as direct talking to distrobutions. Viral method get standard inserted at source ie the projects distrobutions take there source from to build there packages.
Its the reason that most distrobutions that think they have no LSB compatibility have 70 percent or higher.
The desktop distrobutions that are 70 percent have gone out of there way choosing/writing windows managers that don't support freedesktop standards. Yet this does not stop LSB 4.0 applications from working.
So yes add installation system and most distrobutions will be close enough for a lot of LSB applications to run on there distrobutions without extra run times.
The compatibility game is a lot more complete that you are aware. Lot of the changes now are the final clean ups.
Uh am I right, when I have the impression that this blog's author and the lusers reading it use 'citadel' instead of 'cathedral'? The book by ER is called 'the cathedral and the bazaar'. No citadel to be found.
Thanks for listening.
There is a reason why I use citadel over cathedral. http://en.wikipedia.org/wiki/Citadel vs http://en.wikipedia.org/wiki/Cathedral
Citadel is a location with hardened walls you can fight from.
Cathedral is more about praying.
Distributions are more Citadels groups a hard core that will fight.
Just like a Citadel there are sections of them that are friendly to other groups.
Inside that Citadel there is something that appears to be a open bazaar yet it is controlled by the rulers of the Citadel.
Should have really explained why I was using that term instead of straight Cathedral.
I really should publish my white paper on it.
Post a Comment