A Comparison of Solaris, Linux, and FreeBSD Kernel

v1x writes "An article at OpenSolaris examines three of the basic subsystems of the kernel and compares implementation between Solaris 10, Linux 2.6, and FreeBSD 5.3. From the article: 'Solaris, FreeBSD, and Linux are obviously benefiting from each other. With Solaris going open source, I expect this to continue at a faster rate. My impression is that change is most rapid in Linux. The benefits of this are that new technology has a quick incorporation into the system.'"

Comments

wishfull thinking

[scenestar]

If only they could compare the NT kernel along with them

*sigh*

When will OSI licenses really start working?

[Nuclear Elephant]

Solaris 10, Linux 2.6, and FreeBSD 5.3... all have strengths, weaknesses, features, and deficiencies... so why hasn't the OSI succeeded in the cross-pollination of these three great OS's? If they're really going to benefit from each other, why not get some linux kernels with SMF or better SMP out there? When will apt finally replace /usr/ports in FreeBSD? And when will Soalris' TCP stack not suck by implementing code from Linux or BSD? I hug all three of these OS's on a daily basis, but if open source is really working why can't we seem to make an OS out of these three that flat out rocks?

Re:When will OSI licenses really start working?

[WindBourne]

Off hand, I would say that all three flavors rock. And they also currently borrow from each other.

BTW, you mention Solaris's network stack. For Solaris 9.9.x, just before the release, Sun did an internal test comparing between Solaris and all the major OSs. It turned out that Solaris lost big to Linux 2.6 when it came to networking. So Sun delayed it so that the internal team could re-design it to beat Linux's networking. According to one of my friends there, they believe that they have done so. But he also said that they borrowed ideas from Linux and BSD. So yes, the x-pollination is occuring.

Re:When will OSI licenses really start working?

[MBCook]

I'd have to agree. As each OS adds something (like randomizing the starting number (can't remember right name now) for TCP a few years ago in one of the BSDs), the others look at it and add it. It can take some time because the code can't be directly lifted due to the differences that exist at the kernel level (unlike user-space where a port between Linux and FreeBSD may require VERY little work). I remember talk about Linux's TCP/IP implementation not being up to snuff with some of the BSD stacks. They are quire competitive now, I think. I remember comparisons about how slow threads were to start in Linux compared to other OSes (although Windows is even worse, I think). But that lead to (or at least put a fire under) the NPTL project (and the others doing the same thing). I image that FreeBSD worked on their version of the Big Kernel Lock and SMP support because of Linux having better and better SMP support in the last few years, and working to remove Linux's Big Kernel Lock (still remains to some degrees).

The system has been working very good. Plus there are obvious connections. FreeBSD (and I assume Solaris) can both read ext2 (and I assume 3). Both have DevFS (which Linux has had, at least in some form, I don't know how close/far apart they were). So code which can be easily adapted does get moved. I would be VERY surprised if there were only a handful of drivers for FreeBSD that said something along the lines of "Based on the Linux driver by Mr. Reverse Engineer", and I'd imagine there are drivers that go the other way too (I'm not nearly as familiar with FreeBSD as I am with Linux).

Hyperthreading

[MBCook]

This was an interesting little article, I read it earlier today when I saw a link from OSNews. But one thing struck me as odd (there were a few others, but this was the one I was sure about).

For hyperthreaded CPUs, FreeBSD has a mechanism to help keep threads on the same CPU node (though possibly a different hyperthread). Solaris has a similar mechanism, but it is under control of the user and application, and is not restricted to hyperthreads (called "processor sets" in Solaris and "processor groups" in FreeBSD).

I am positive that the 2.6 kernel understands hyperthreading and does something similar to FreeBSD. Why wasn't that mentioned? Did the author not know that?

Overall through, it was interesting. I'd read it as a longer series, if they had one. This is an area that I'm interested in. I read kernel-traffic, and subscribe to LWN (you should to!) almost entirely to read the kernel page. I've learned so much about operating systems and computers from reading about the improvements in the Linux kernel, why the old version wasn't good enough, etc. While I no longer use Linux since I got my Mac (OS X fills all my needs), I continue to learn a large amount about computer architecture and operating system concepts from it.

Re:Filesystems

[ajs]

"It has to be tested for compatibility, quality and performance. You can't be losing data, and if it doesn't offer a performance benefit over UFS or UFS2 then there's very little point in porting it."

Clearly you don't know about Reiser (no offense, it's just that that question shows a stark lack of understanding with regards to why Reiser is interesting in the first place).

Reiser solves one of the oldest problems facing the old Unix-style filesystem: the adoption of btree-order performance directory lookups (using Reiser's "dancing trees") without significant loss in other areas of filesystem performance, e.g. directory entry creation and deletion, etc. This is something which was long thought impossible.

This lead to further development, since the major reason to avoid creating thousands of temporary files has always been directory lookup times. So, now the question is: how far do you go with files? Reiser 4 answers that question by adding significant semantics to files which were not practical with slower filesystems (again, keep in mind that when I say "slower" I refer to the performance bottleneck surrounding large directories primarily).

The problem with Reiser is that it is Reiser, and none of the exisiting filesystems can match its performance in these areas. That means that if you write an application that relies on Reiser's performance, it really RELIES on Reiser, and cannot perform well under normal filesystems without significant engineering (e.g. writing special-case code for Reiser and non-Reiser filesystems). In some cases (e.g. databases) this might be worthwhile, but in the case of more mundane applications, having filesystem-specific code is not always viable.

For more information, see the Reiser4 site: http://www.namesys.com/v4/v4.html

Interesting Model Breakdown...

[TemporalBeing]

I find it quite interesting that (at least according to the article) Solaris (which supports a few x86, and mostly Sun's Sparc line) has a full abstraction, while Linux (which supports some large number processor architectures) goes with less abstraction; with FreeBSD somewhere in the middle. It certainly does yield higher performance for Linux, and makes sense in that respect...It's just interesting that the OS that seemingly runs on fewer processor architectures and has been controlled by an incorporated company would take the abstraction route, while the OS that runs on a far greater number of processor architectures and is not tied to corporate funding (directly, at least) is more focussed on less abstraction & fewer layers.

P.S. Sorry to repeat myself on that...just not sure how best to say it.

Re:How much of Solaris has gone open source?

[adrianmonk]

Its been what, 2-3 years since the open-source solaris announcement came out? How much has been open sourced? AFAIK, all the have opened sourced is DTrace (a very cool tool/framework), but nay else.

Well, it's good that you said "AFAIK", because what YK turns out to be out of date. Browse the Solaris source code right here.

Lets see them open up the kernel internals like the thread model

OK, here's the directory with the dispatcher stuff and here's thread.c specifically.