epoll, LSB (was: Re: Problem roundup)

[Mike Hearn]

> 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