ISVs may be wary of fragmentation, but so far, LSB compliance hasn't come at the top of their list of priorities, says Carr. "They generally rank other issues, such as the development tool-chain, product support, features, and the overall ecosystem -- the presence of other ISVs and OEMs - first." This isn't as big a problem as it seems, he says, because Red Hat's close adherence to the specification guarantees a certain degree of LSB application support. "From a Red Hat viewpoint, we adhere to LSB standards and work closely with the LSB to drive the standards forward, keeping up with new developments in the open source community," he says. Still, Red Hat certification isn't the same as LSB compliance.
An initiative from several other Linux vendors is looking to eliminate the difference. The Linux Core Consortium (LCC), officially launched in November by a handful of major vendors, is collectively building a reference implementation of the LSB to be used as the core of all LCC members' operating systems. If LCC founder members Conectiva, Mandrakesoft, Progeny and Turbolinux have their way, an increasing number of Linux distributions will be based on a standard, LSB-compliant core. Linux makers such as Red Hat, SuSE and Debian have been invited to join, but are waiting to see the reference implementation before they commit.
The idea is that if an ISV certifies on an LCC-based Linux, it is practically identical to LSB certification. "All the applications that are certified against this reference implementation will be able to switch from one [OS] provider to another without doing anything," says Mandrakesoft chief executive Francois Bancilhon. "This is a strong enabler to the market."
If most Linux vendors are already agreeing to make their core technology meet LSB standards, the LCC argues, why not go a step further and use the same LSB implementation? "The need to differentiate is absolutely essential, but everybody agrees that this differentiation is in the top layer. There is a strong move toward convergence in the lower layers," says Bancilhon.
The group is learning from the mistakes of UnitedLinux, which commoditised both lower and upper layer software -- all UnitedLinux members' distributions were based on software licensed from SuSE, says Bancilhon. "One vendor controlled it, that was a mistake. Another was that they put the entire distribution in there. It should address only the commodity part of the technology," he says.
The LCC plans to deliver its first reference implementation in the coming months, and LCC-based distributions are due to arrive this year.
The FSG isn't standing still, either. Developments planned for the LSB this year include announcement of ISV support, more Linux vendor certifications, the first LSB certification lab in China, run by the Chinese government, obtaining ISO certification and perhaps most importantly, the release of the LSB 3.0.
The current LSB specification is a big improvement, but to stay relevant, the project must continue to evolve. "The LSB today covers only a part of what is needed for true compatibility and interoperability between different versions of Linux. It's an important step in the right directions but needs to be extended," says Intel's Hohndel. Key additions are more details around kernel extensions and APIs and ABIs higher up in the stack, for example around desktop environments or some managed runtimes.
Talkback
The same problem could happen with Microsoft as they differentiate their products. After all, so far their current version english of MS-Word can't interoperate flawlessly with localized versions of the same software. If you consider slightly different versions, or other platforms than x86 the situation is even worse.
If they can't have their office suite to interoperate with itself how can we expect that various versions of their server software will work together. Not to mention that they simultaneously supports several separate product lines like win2k, win2003 server, XP, and soon Longhorn all slightly different. On top of that we haver various other software such as Exchange, IIS, SQL Server. If you need to upgrade one component, my experience is that you will need to upgrade all the rest, giving lots and lots of headaches.
My guess is that most LInux distros are far more interoperable with themselves and other Linux and unix systems with or without LSB than Microsft manages to be within their own product lines. The GPL factor keepls Linux inline regardless of standards. If one Linux finds some new amazing way of doing things, it will be all over the marketplace as he is required by GPL to share with his competitors.
The only thing that he can keep secret is upgrade and support procedures he runs in his office and it is such difference that makes him competitive, but such differences seldom affects the interoperability of software at the customer location.
At least the licence isn't likely to fork.Once GPLed you are in control of your software. If you go the Microsoft way you can never be sure what licence you end up with. All of a sudden, you download some more or less necessary service pack, and the licence of your entire installation changes.
Now, so far the licence changes applied with service packs have been quite harmless, but the fact that they do change it is worrying.
Would you buy a car, where you all of a sudden find that after your first service, the passenger seats have been removed and you have to buy specil passenger licences to have them added back. I think not.
I remember Linus Torvalds answer to "The forking question" was "so what".
That is, if linux forks there must be some very good and acceptable reason for that to happen.
And there are none, and no demand for that.
In stead there is a strong demand for a standard making life easier for everybody working with linux.
And linux is right now the envolving world standard for supercomputers, embedded devices, consumer electronics,
web-servers, carrier grade, - you name it.
So a standard base for linux is something everybody actively want.
Excuse me?
Quote: "Now, so far the licence changes applied with service packs have been quite harmless, but the fact that they do change it is worrying."
Very wrong, Sir. There already have been security patches from Microsoft that came with an EULA requiring very demanding, one way deal, terms or else no rights to install the patch.
Here's one example:
http://www.theregister.co.uk/2002/06/30/ms_security_patch_eula_gives/
Perhaps people have forgotten how a free market is suppose to work.
In a real free market there are no ways to limit consumer choice other then by providing good quality solutions at competitive prices. Should someone not be able to provide that then somebody else will. Thus enabling the 'better species' (Darwin anyone?) to become dominant until the environment (the needs of the masses) changes and the former 'better species' better adapt to the new environment fast enough or some other 'better species' will become dominant (the innovation need for speed).
Since it stands to reason that good interoperability will be part of the demands required from a 'better species' it's fair to say that in a real free market good interoperability will be no problem at all.
And given the free market nature of Open Source today the mechanics of ensuring good interoperability are already in place today.
Not complying to such Darwinian laws would find any Open Source solution sidetracked and quickly replaced by something else that does. Basicly it's a safety mechanism. Even mistakes are quickly minimized (by means of lesser demand) and thus turned into a thing of the past faster then the PR department of a typical company could change it's PR theme.