epoll, LSB (was: Re: Problem roundup)

[Dan Kegel]

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

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html