epoll, LSB (was: Re: Problem roundup)

[Mike Hearn]

On Sat, 20 Nov 2004 17:09:18 -0800, Dan Kegel wrote:
> LSB 2.0 doesn't deal with sound, scanning, or printing (beyond lpr, anyway?),

It really doesn't deal with anything useful at all that isn't already
stable and on every Linux system anyway.

> so an LSB 2.0 version of Wine would probably have to do without those.

Those were just random examples, there are many more. An LSB 2 version of
Wine would be seriously crippled next to a non-LSB version.

> LSB 3, on the other hand, is going to add Gnome support, 

Possibly. They've been saying they were going to be adding desktop support
for years. The LSB process moves so slowly though that there's
no chance of them ever having an up to date desktop specification. GNOME
releases on a 6 month release cycle, GTK is more like 9 months but these
are all less than a year. Are people going to hold back depending on new
APIs because it's not in the LSB yet? No, there's no evidence of that at
all.

They also said they were going to add C++ support to LSB 2 - didn't
happen, except as an optional "module" that Red Hat aren't going to
implement anyway. Why? Because the gcc team decided stability right now
would hurt their engineering goals and Red Hat employee a lot of the gcc
team. In other words the primary distro developers support the LSB when
it's convenient to do so, and don't when it isn't.

> so they're at least thinking about the desktop now.
> (Your other objections - FreeType, fontconfig, libjpeg, OpenSSL, etc -
> could be packaged along with an LSB implementation of Wine, so they're
> not really an issue.)

That would be a bad idea. Statically linking FreeType would stop
people who have switched on the TrueType bytecode interpreter from using
it (some people do have licenses), OpenSSL has a very poor track record
for needing security updates and wasn't libjpeg found to be vulnerable to
buffer overflows lately? Some things it just makes no sense to statically
link like libasound as it communicates directly with kernel interfaces
that may not be stable.

Dynamic linking exists for a reason, we should use it. The fact that the
LSB is apparently constitutionally unable to meet our needs shouldn't mean
turning our back on dynamic linking. It should mean either fixing the LSB
or using something else.
 
> It would be worth doing an LSB 2.0 implementation of Wine as a
> demonstration of what's missing in the LSB; IMHO it would help
> put pressure on the LSB folks to include the missing bits
> in the next version.

About a year ago (maybe more) I tried to do an LSB compile of DBUS and
failed miserably. Not only was the LSB build environment buggy but it
would have implied producing a bloated and crippled version. These days
it'd be even worse, ie no SELinux support.

I really don't think an LSB build of Wine would be easy or productive.

As for putting pressing on the LSB folks, I don't think they care about
us. They seem to care more about ISO certification, witness the mess
produced from trying to get the gcc team to make a stable C++ ABI to
meet ISO deadlines.

> But remember, LSB can only standardize what has already stabilized
> in the field, and things like sound and printing are only now
> starting to not suck on Linux...

That's one of the problems with it. The LSB is toothless while upstream
projects continue to treat platform stability as a trivial detail. Note:
the LSB did nothing to avoid the NPTL fiasco and it's doing nothing to
avoid the COMPOSITE ARGB mess despite both libc and Xlibs being a part of
the supposedly "stable" base.

Other problems involve the fact that it has no traction at all with
popular distros - out of the box big-name distros aren't compliant
eg Slackware (no PAM), Fedora (no LSB package installed by default),
Gentoo (standards compliance difficult on this distro anyway
due to its level of configurability) etc. In fact I'm not aware of any
distros at all that are actually LSB compliant out of the box, even though
most of them could be with minimal work. You usually have to install extra
packages, and even then the guarantees provided by the LSB are minimal.

The backwards compatibility breaks that actually matter to people (because
they break their software) have never even been raised by the LSB team.

This shouldn't be surprising. There's little they can do, unlike Microsoft
they can't fire maintainers who make breaking changes.

Believe me. I've looked into the LSB extensively as part of working on
autopackage, posted to their lists, even developed easier to use (if less
provable) equivalents of their tools and come to the conclusion that the
LSB isn't a solution, it's a symptom.

thanks -mike