new in 2005-7-9 glibc: no more LinuxThreads

[Arjan van de Ven]

On Sat, 2005-07-09 at 10:06 -0400, Paul Iadonisi wrote:
> On Sat, 2005-07-09 at 14:33 +0100, Mike Hearn wrote:
> > On Fri, 08 Jul 2005 10:01:12 -0700, Ulrich Drepper wrote:
> > > In the last year we've hardly heard about
> > > any problem related to LT vs NPTL and the F4 switch to default to linking
> > > with NPTL also didn't cause any problems we know of.
> > 
> > That's because people got the message that you guys didn't care, not
> > because the programs that needed LinuxThreads magically disappeared.
> 
>   Of course, 'you guys' should be translated 'Linux kernel and glibc
> developers' and not 'Red Hat' or 'Fedora' folks.  As Ulrich said in his
> original post...LT is discontinued *upstream*.

and there is a reason for that. LT was unfixably buggy. (well not
entirely unfixable, the fix is called NPTL), and was holding back
improvements to glibc bigtime. In addition, NPTL *is* compatible to
linuxthreads, but not bug-to-bug compatible, it can't be after all,
since the goal of NPTL was to fix some of the longstanding bugs in LT.

Now there are some apps that depend on some of the bugs in LT. That's a
tricky problem, since what would have happened if we would have found a
way to fix those bugs inside LT instead of in a separate lib??



Also note that some of the "problems" people blame on NPTL interaction
are not that per se, but are new kernel features that just happen to get
disabled with old LT. Again those kernel features (of which I'm
responsible for some of them) change behavior within the allowed bounds
(eg they don't do anything that couldn't happen anyway) but a few
applications have really bad and broken assumptions but just got lucky
most of the time. It sucks to have to depend on such applications, I
realize that. At the same time there is a problem if we'd avoid all
changes that would break ANY defective assumption out there, since
progress would not be possible at all. Do not underestimate how far that
would go (there are some REALLY broken assumptions out there) since any
bug you fix anywhere could potentially be depended on by some app out
there somewhere.

It's not that we don't sympathize with people who have those few apps
out there that don't work in "new linux". It's that the choice between
breaking a few apps and a more secure[1], more standards compliant and
less buggy linux is a hard one but made for the later. It's a balance,
and there have been three years for transition, and the point where it
no longer is possible to keep doing both has come [2]... I mean, even
Red Hat Linux 9 already defaulted to NPTL....
 
There is also another angle to this. Old Old linuxthreads (with fixed
size 2Mb stacks) was kept around for compatibility with old broken apps
that internally used knowledge that the stack used to be 2Mb in size.
Because it was kept around, vendors decided to not fix their apps, not
even in newer compiles/releases. As a result 7 years later there were
still broken apps being shipped.... Fedora Core is not a maintenance
release of enterprise software, it's a linux distribution designed to
bring new technology and features to the masses. Hopefully those masses
include ISVs who will now get of their butts to fix their apps
quicker ;)

Greetings,
    Arjan van de Ven


[1] Half of the problems out there are probably caused by things done in
the ExecShield project to increase linux security and not NPTL per se,
see the upcomming issue of Red Hat Magazine for more details on what
security features have been added in the least few years and what value
they bring to linux. 

[2] The upcomming -fstack-protector feature in gcc/glibc is the nail in
the coffin for LT.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20050709/1ff97233/attachment.sig>