Mike Hearn wrote:
[The LSB] really doesn't deal with anything useful at all that isn't already stable and on every Linux system anyway.
Correct. When a commonly-needed package becomes "stable", a snapshot of its interface specification is taken, and added to the LSB. LSB applications can then rely on that interface being available. That might sound like a no-op, but the painstaking attention to detail involved in nailing down the interfaces of the LSB offers a lot of stability.
The LSB is toothless while upstream projects continue to treat platform stability as a trivial detail.
I'm not aware of e.g. an LSB-1.3 application that doesn't run properly on any system that supports LSB-1.3. Are you?
Note: the LSB did nothing to avoid the NPTL fiasco
The transition to NPTL, like many other transitions in Linux's history, was painful, but that's exactly the kind of pain the LSB saves applications from.
and it's doing nothing to avoid the COMPOSITE ARGB mess despite both libc and Xlibs being a part of the supposedly "stable" base.
http://freedesktop.org/pipermail/xorg/2004-August/002326.html says "COMPOSITE is experimental, users of it should expect things to break." I believe that the COMPOSITE extension is not part of LSB, so any application using it is not LSB-conformant. Here again, applications that conform to the LSB are saved from the pain of unstable interfaces changing.
The LSB process moves so slowly though that there's no chance of them ever having an up to date desktop specification.
That's ok. All we need is that they have a useful, working desktop specification. Mike, I get the feeling you want the LSB to be something it's not. Relax, let the LSB folks do their thing. Yes, LSB applications will always be using stable old interfaces, but *that's the point*. - Dan