Truly, "the Linux world is as
strange as it is
liberating."
Most of the time, in the history of computer world, "key decisions were made
for you." Whatever Microsoft (or IBM, or DEC, or Data General...) decided to do, "that was
it." All the rest of us may have groused, but the bottom-line was that
we had no choice but "to go along."
The Linux/Unix community, though, is different:
no one is "in charge."
No one has either the position or the authority to
impose their solution, to any technical problem at all, upon the group! Also, no one has the capacity to
impose a "sea change" upon present or future software development.
The position of Unix and Linux is
especially peculiar because these systems cannot even predict the nature of the hardware upon which they might be run! These systems run on obviously-different hardware types ranging from "the biggest mainframes" to "a portable phone," and
none of them can ever be "locked out!"
The strategy which has thus-far worked out to be most capable of dealing with this very peculiar set of requirements is to allow several "competing" groups of developers and standards-writers to ... so to speak ... "duke it out" in what may
seem (at first) to be a
"let the best man win and let all the others perish in the darkest hell" 
competition.
First, of course, somebody has to "boldly go where no man has gone before." The
linuxthreads library did that... trying its best to forge a respectable notion of "threading" in a world that, at the time, knew only of "processes."
Then, when the underlying architectures have suitably advanced and the question now becomes, "how do we replace 'that dreadful
linuxthreads hack'" ... instead of waiting for a dutiful vendor to impose its will upon all the rest of us ... we "duke it out!"
In this case, the contenders came down to:
- linuxthreads itself (the ever-present "default case", codified by now as the "POSIX Standard")
- NPTL (New POSIX Threads Library)
- NGPT (Next Generation POSIX Threads)
And the general engineering opinion is that "NPTL won."
But...
all of these threading models are built upon a foundation of underlying threading-support that had to be built into the Linux kernel ... a foundation upon which all of the various competing threading-models ultimately had to be built.
Furthermore... all of these threading models are ones which are
exposed by the Linux kernel to user-land programs. "The kernel itself" necessarily plays by much simpler and more restrictive rules. After all, "the kernel itself" does not have to abide by any protocol other than "whatever works... on any number of CPUs... of any type ranging from a mainframe to a portable phone."
