Re: [CFT] packaging the base system with pkg(8)

On 4/19/16 7:47 AM, dan_partelly wrote:
>
>> Look, take a look at history and the Linux kernel threads story and its
>> impact on FreeBSD.  If you'd like I can talk about it.
>>
> Please, yes, I would love to hear about it.
Sure, so back in late 90s, ~1999 sometime after Solaris released kernel 
threads Linux did as well.

It was pretty laughable, it was basically a hacked up version of fork 
that shared address space, files and a few other things and was horribly 
unstable and you couldn't use most of libc with it as there were many 
single-threaded deps in it.

It was so "laughably bad" that if you logged into a Linux system with 
threads and ran "top", it would look very strange as each thread had its 
own pid.  So if you were running something like mysql it would look like 
you were forkbombed.

Now the point of all of this however was to get threads, and also to get 
threads that did well with disk IO.

FreeBSD at the time had threads, but they were "green threads" or 
"userland threads" which means they were super good for network IO, but 
nearly useless for disk IO.

This made Linux a much better platform for mysql, as mysql performed an 
order of magnitude better on Linux.  In fact not only was FreeBSD 
slower, but in my experience it was buggier because the green threads 
implementation, while very cool, was complex and had its own share of bugs.

Some years passed and many people migrated to Linux to get the high 
performance mysql that was available on the platform.

Now during those years, as more and more people migrated away, FreeBSD 
had many, many, many, oh gosh, so many discussions on what to do about 
threads.  So many opinions were had by so many people during which more 
people moved to Linux as a web platform...  Not only were there 
opinions, but also implementations suggested, but those implementations 
were shot down in the search for the "one true threading system".  Of 
course there were some loud folks that even insisted that threads were 
bad (and probably a phase) and we shouldn't even support them).

Luckily during that time (~2002) someone made this crazy "Linuxthreads" 
port which made """Linuxthreads"""  available on FreeBSD, it had many of 
the same problems, but at least mysql was fast.  Spoiler: The funny part 
about calling it "Linuxthreads" was that "Linuxthreads" wound up being 
the defacto way to do threads across *UNIX* because it was just simple 
and worked, should have just called it "realthreads" in my opinion.  
Luckily with the Linuxthreads port the die hards in the FreeBSD 
community who needed to run mysql for performance (or other software 
requiring real threads) could stay using FreeBSD while the community 
sorted out what exactly was to be done.

Places like Yahoo moved off of FreeBSD because they "just wanted 
threads" and if you tell someone to get "good performance with threads, 
then use Linuxthreads" (and of course make a grumpy face because "it's 
Linux") then they reason, "geez, why I am not just using Linux anyhow?" 
which they then migrate to.

So some years later (~2005) we went with a far more complex solution 
than needed called libkse.  Libkse offered N:M threads, which didn't 
work very well for years due to complexity (hats off to those that 
*tried* to get it working in FreeBSD's political climate) to which 
finally Sun abandoned its N:M threads because they themselves could 
never get it right, and finally FreeBSD switched to 1:1 threads 
following Solaris.  That was probably in 2007 timeline.

Now rewind to ~2001, about 2 years after the introduction of the sloppy, 
weird and strange kernel threads in Linux, and they had a pretty solid 
implementation.  It wouldn't be until nearly 2009 when FreeBSD had a 
truly solid threads library and even now it suffers due to added 
complexity because we did things "smarter" than Linux.

Moral of the story?   My takeaways from this story (and there are many 
similar ones in our recent history) are:

1) Graciously and rapidly accept steps forward and then contribute to 
them.  Anything else leaves you stagnant and worse for wear.
2) Simple over complex.
3) If something someone else did is working for someone, then copy it 
and move on, don't waste a huge amount of your customer's time trying to 
make something better until you are sure that just copying it will not 
suffice.

-Alfred