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
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 problem is the LSB doesn't nail down the interfaces. It can't actually, if Wine has taught us anything it's that interfaces leak. The LSB library specifications are just lists of symbols. There's no attention paid to semantic breaks in behaviour, even though they are often what stops programs from working.
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?
I'm not aware of any LSB applications at all, actually. But let's take RealPlayer for example. Let's pretend that Real had made it an LSB app.
Would that have saved it from being broken by NPTL. No. LSB doesn't specify (as far as I'm aware) that LSB apps must be linked against LinuxThreads.
Let's take XMMS. Let's pretend XMMS was shipped as an LSB app. Would that have stopped it from crashing on startup due to the addition of ARGB visuals to Xlib, a feature that was known to break old software but is being enabled anyway? No.
OK, so the Composite extension isn't enabled by default yet, but there is another env var for this: XLIB_SKIP_ARGB_VISUALS works like LD_ASSUME_KERNEL, ie it's an "unbreak me" switch. You have to know about it in order to use it. I talked to the X guys about this, they aren't interested in inverting the meaning of the switch (ie, making it a "please give me new features" switch) so it's likely when Composite is shipped it'll be in this form. NPTL all over again.
The LSB was supposed to provide a stable C++ ABI. In the end it stabilised one produced by no shipping compiler, and the distro vendors seem to be ignoring it as a result.
I used to be a big supported of the LSB. I really did think it was The Way Forward. But, these sorts of things keep happening and the LSB did nothing to stop them. In investigating *why* they kept happening I came to the conclusion that the LSB doesn't have enough power to really fulfil its mandate currently.
It needs, at minimum, the ability to specify details of implementation, for instance LSB should have specified that LinuxThreads not NPTL would continue to be used by default on all conforming implementations unless a PT_GNU_STACK style flag was present in the ELF headers. But this would have been overriding upstream policy which violates their constitution, therefore they couldn't/wouldn't do it. It should have specified that "." and ".." are always the first entries in a directory listing, but if it does (not sure, LSB references a lot of other specs) then Red Hat ignored it.
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.
Except it didn't. LSB does nothing to stop old apps from being linked to NPTL, unless there's some paragraph I missed in the spec that deals with it. Even if there is, LSB has been around for longer than NPTL and yet we still had to go through a painful transition which would imply it didn't work.
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.
Ah no, the breakage doesn't work that way. The problem is that some apps contain different visual matching algorithms which get confused by the presence of the ARGB visuals. This is especially common in older GTK 1.2 apps which use Imlib, like XMMS, VMware or the Macromedia Flash plugin. These visuals are presented to the app even if it wasn't written to use them.
I do not know if it will affect Wine (probably not). It's like NPTL - the underlying behaviour of a system changed in a way that breaks programs.
IOW it's a semantic breaking change that the LSB does nothing about, and shows no signs of ever doing anything about.
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.
Well, yeah. You're right. I want it to provide a desktop platform that's competitive with Windows, but I don't think it ever will.
thanks -mike
-
Dan Kegel -
Mike Hearn