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.'"

wishfull thinking

If only they could compare the NT kernel along with them

*sigh*

Re:wishfull thinking

Can one really see how the NT kernel works, with all the stuff stuck together like Windows is?

Saying that the NT kernel and Windows (the Win32 Subsystem) have any relation would be like asking how you can compare any *nix kernel with all the XWindows stuff stuck together...

NT is NOT what most people consider Windows, however it does POWER windows.

Also the NT kernel is not too shabby, considering its design age, and it came from Microsoft. Go pick up Inside NT or a current version that deals directly with the NT kernel and not the Win32 subsystem.

Re:wishfull thinking

Win32 subsystem is TOO much tied to NT kernel and closely coupled to achieve the performance it has today.
That is why NT 3.51/3.53 was more robust than NT 4,0 which moved major parts of the UI code to kernel mode.

Please actually read Inside Windows NT 3.51 by Helen Custer and THEN read Inside Windows NT 4.0 to know the difference.

Sorry, hun, read both and even had this discussion with a key kernel developer at Microsoft a few years ago. (1997 in fact, as we were starting to work with Beta 1 of Windows 2000)

NT 4.0 ONLY moved video to a lower ring. It had NOTHING to do with moving the Win32 subsystem INTO NT - that did not happen.

That is why Windows NT Embedded exists, and also why even the WinCE is a version of the NT kernel with NO Win32 ties.

Microsoft can STILL produce NT without any Win32, and just throw a *nix subsystem on it if they wanted to, but yet have the robustness of NT. Win32 is the just the default interface because of the common API and success of Windows applications.

I think you are confusing Ring dropping of the video driver with something completely different.

NT is a client/server kernel... Go look up what that means, please for the love of God.

Win32 is a subsystem, plain and simple. Yes it is a subsystem that has tools to control the NT kernel under it, but that is just because that is the default subsystem interface. You could build these control tools in any subsystem you want to stack on NT. PERIOD.

How can they?

At this point, in order to see the kernel, you have to sign off on MS's shared source license. By doing that, anybody in the OSS world who signs, is then at risk of being at the receiving end of a MS lawsuit. It would be just as bad as signing off on a SCO license.

Yeah, right, NT scales so well

Just because there's a version of NT that can run on a 128-CPU SMP box doesn't mean it scales that in real-life situations.

If it did, with all Microsoft's billions of dollars, how come there's no NT equivalent to this [ibm.com] for Linux, or this [sun.com] for Solaris?

Those two bad boys scale damn near linearly. I know that, I don't have assume that. I can afford a 7-figure house because I can make those things sing. That Sunfire E25K has 72 CPU slots, and each UltraSPARC-IV chip has 2 full CPUs on each die. The IBM 595 has 64 CPU slots, and when I was at SC-04 in Pittsburgh last year, IBM claimed they were working on an 8-way version of their Power CPU. That's 512 CPUs on an SMP box.

There's nothing like that in the NT world that anyone could buy. And you don't have to sign some NDA that would keep you from getting a job in a lot of places to see the source code for either OS.

Keep your damn toy OS, and your self-admitted assumption that "NT knows how to handle more than 2 processors", because there's no commercially-available system to support that assumption.

Re:Toy computers need not apply

Considering there is 128-way SMP version of Windows (running on NT) available

I might be wrong, but AFAIR, the largest SMP configuration supported by NT is 32 CPUs (or, probably, 16 Hyperthreading-CPUs) because of a constraint compiled into the kernel (Windows "Datacenter Server" Edition).

Anyway, even if you could run NT on some 128 CPUs, it would not scale well. If you actually knew a little about the NT implementation and not just the "microsoft propaganda", you'd possibly figure out, that a lot of (theoretically independent) code portions in the NT kernel synchronize on only one mutex-like synchronization lock (CRITICAL_SECTION) that is shared between these code portions

Example:
If you've got 50 independent data structures, you could use 50 mutex locks (one for each data structure), to protect it form becoming corrupted due to simultaneous modification by multiple threads. The NT design in this example would be to use only 5 CRITICAL_SECTION locks for the 50 independent data structures (one for every 10 data structures), so one thread modifying a data structure will potentially lock out 9 other threads who could be modifying 9 other data structures.

The lack of fine grained synchronization on NT makes it scale pretty bad, especially compared to Solaris (which scales so well probably mainly because of very fine grained and sophisticated synchronization, for example by using RW-locks instead of mutex-like CRITICAL_SECTIONs in situations where this is possible).

Re:Toy computers need not apply

Considering NT was scaling multi-processors before Linux even existed, this is a bit of a rich statement. (Especially since Linux didn't even consider SMP until 1996, when it was a mature feature of NT by then.)

I find it rather rich that trolls like you have the guts to call others trolls, using rhetoric to prove your point and hoping nobody will notice.
Linux 2.0 came in June 1996 with SMP support. So if SMP was not considered in Linux until 1996, you are basically saying that in less than 6 months, SMP was implemented in Linux better than in NT, where you say it was a mature feature ?!!!
I would call that a feat.And I wonder how you can call SMP a mature feature in NT, when it was not scaling better than in Linux, which was implemented in less than 6 months, like you implied.

Considering there is 128-way SMP version of Windows (running on NT) available, I would assume NT knows how to handle more than 2 processors, just a guess though.

I never heard of any 128-way SMP version of Windows. I heard of a custom secret implementation that supposedly does that, that's all. But no version of Windows commercially sold actually does that. And SMP versions of Windows scales very poorly.

Also considering the desktop versions of WindowsXP support 2 processors standard

Against that's false. Home edition does not support 2 processors standard (HT is not SMP nor 2 processors support), Pro edition does. Stop lying ... oh you can't, without destroying your point.

and NT has for years and years, I might suggest that it even has an edge on some OSes that SMP is just becoming realistic. (XP does Dual Processors with HT, effectively managing 4 virtual CPUs and this is the desktop edition for the average Joe.)

Continuing your lies huh ? HT is not SMP, stop your nonsense. SMP was realistic in Linux way before NT, despite SMP being implemented in NT first : that speaks volumes for NT OS, and tend to prove GP point. Again, WinXP Pro support your 4 virtual CPUs, not Home. The distinction is important, if you want to make Linux comparison, because standard desktop editions of Linux distros come with SMP support. For Windows, standard desktop edition is XP Home, which has no such support. It could, but it doesn't.

Now should we talk about how it hasn't been until later versions 2.4 of Linux that in an SMP world, process affinity even become stable. (According to Intel, AMD and other people trying to create real world Linux SMP solutions.)

Still lying huh ? Process affinity wasn't becoming stable at end of Linux 2.4, it was just not implemented before. And it ended up implemented pretty fast. But I know why you added the word 'stable' in your rant : rhetoric implying it was there but not stable before.
Anyway, despite not having process affinity, Linux kernel was running circles around NT kernel, so you should keep this subject hidden.

Or we could talk about hotplug of memory and processors with Linux - which is still not supported as it is with NT and Solaris. (And Linux you even get the fun of reconfiguring if you want to flip processors in downtime even.)

Well, you got me there. I did not even know that there was this type of hardware supported in x86 architecture. You are not credible though, because these kind of hotplug are only in limited set of configurations, not available to most Linux programmers, that's why, if they exist, they are still not implemented. There are little numbre of devs that can afford a E25K you know ? But you chose a good example, forgetting the load of other features that Linux kernel has, that makes NT kernel a toy OS. Stability is enough to kill any of your arguments though. You will give me crap about NT running for months (with 1 service) and you having seen Linux crash, the difference is that :
Stability in Linux is the norm, in NT it's the exception.
I mean that a Linux crash is news, while a NT running for years is news too.

Call NT a Toy OS all you w

Invitation to flamewar?

And let the flamefest begin...

Flavourful.

" A Comparison of Solaris, Linux, and FreeBSD Kernel"

One is crunchy, the other's chewy, and the last is malt flavoured.

When will OSI licenses really start working?

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?

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?

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).

FreeBSD Ports

Wow! Is that all it takes to get a +5 Insightful now? So I guess this will be modded Troll or Flamebait.

I can never really understand why FreeBSD ports is better than Debian's APT. Perhaps it's only because they look at "package installation" as the only use for these tools, whereas I use these tools for "package management". Everything comes down to the packagers who make and maintain the packages and the quality of the tools used to make and maintain the packages. I've used FreeBSD, Gentoo, and finally Debian for servers and desktops. Based on my experience APT is a more elegant solution to package management compared to FreeBSD Ports and Gentoo Portage for the following reasons:

Package Building

Although building Debian packages can be a bit overwhelming especially for newcomers, it really shines especially if you have installed debhelper, dh-make, dbs, dpatch, and lintian. What's really great about APT is the automatic runtime dependency resolution prior to packaging the final debs. After building the package and before it gets packed into a deb, a dependency checker is run through it and it will automatically figure out the runtime dependencies for you. On FreeBSD Ports and Gentoo Portage, you have to figure out and specify runtime dependencies yourself.

The "Dusty Deck" Problem

When I install a package using ports or emerge, it will also install the dependencies. But most of the time you will essentially be installing from source (and yes I am aware that Ports and Portage also have pre-built packages). When you do that, Ports and Portage will install and build the build-time dependencies of the package you are installing. Now, that's fine if those build-time dependencies are also needed at run-time. But some dependencies are only used at build-time and will never be used again until you upgrade the packages that depend on them. You can decide to remove them after build time, but then when you update the package they will be downloaded, rebuilt, and installed again. You eventually grow tired of this cycle that you just leave these build-time only packages and then they continue to accumulate on your disk mostly wasting space.

This is probably the reason why there are "developer" packages for libraries that contain only the header files and the link libraries. Once you're done with building, you can uninstall the developer package. Try doing that under Ports or Portage. Oh, wait! You can't. The runtime and build-time dependencies are all in one package.

Package Uninstallation

Now this is where Ports and Portage, IMHO, really suck. When I uninstall a package from my system I want it gone. apt-get remove --purge and a properly packaged deb will do that for you. Ports and Portage will leave "package cruft" on your system. "Package cruft" can be anything from stale config files to build-time dependecy packages. You will have to track and remove those things manually.

I know these three points can be resolved on both Ports and Portage if the packages are done correctly. This is where APT has an advantage over Ports and Portage: being able to make a proper package. On Debian, with the tools I mentioned above installed, a package maintainer's life is greatly simplified.

Ports (and Portage) does Rock, but only if all you ever care about is package installation and not package management (package building, installation and uninstallation).

Filesystems

Does anybody know why ReiserFS 3 hasn't been ported to any of the BSDs yet? ReiserFS 4 looks as though it's pretty revolutionary, if distributions settle on that as a default, I can see that giving quite an advantage to Linux compared with the other kernels.

I noticed that the article didn't mention LUFS [sourceforge.net]. This alone allows for tremenduous possibilities, not least of which is rapid development of filesystems. Do any other systems (besides GNU HURD) have userspace filesystems?

Re:Filesystems

The GPL has absolutely nothing to do with it whether or not it can be ported to FreeBSD.

Yes it does. A filesystem is a part of the kernel. The kernel is under the BSD license. The inclusion of Reiserfs code in the kernel would require it to be under the GPL license instead.

So is Ext2 & Ext3 file systems.

The ability to read ext2 file systems is included, but it is not the ext2 file system itself. You cannot create and write to ext2 file systems with FreeBSD.

Re:Filesystems

Revolutionary often suggests a higher degree of complexity. Licensing issues aside, it's not just a matter of getting the ReisierFS3 or ReiserFS4 code to compile with the FreeBSD kernel. 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.

The FreeBSD and Linux kernels do differ fairly significantly, so it may not even be an easy task porting over the code (again, licensing issues aside). Indeed, it may even be a better idea for the FreeBSD team to perform their own implementation of the ReiserFS4 concepts and algorithms.

Re:Filesystems

"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 [namesys.com]

Re:STFU CYRIC!

Yes he posts a lot. Yes he sometimes states the obvious. On the other hand, he resonably often says something useful, can spell and construct sentences, and, as far as I know, is not waging a war as an anonymous coward against others. His OP above, even if he didn't mention b-trees, is still a true statment. I think I'd rather have him over for dinner than you.

Userspace Filesystems: try Plan 9 from Bell Labs

Plan 9 had userspace filesystems. Moreover, it encouraged services to export control interfaces as filesystems -- so you could mount a service and then configure it using open(), read() and write().

Have a look at the Plan 9 wiki [bell-labs.com]. You can even run it inside vmware or Xen.

Re:Filesystems

I noticed that the article didn't mention LUFS. This alone allows for tremenduous possibilities, not least of which is rapid development of filesystems. Do any other systems (besides GNU HURD) have userspace filesystems?

LUFS hasn't been maintained since 2003, and is therefore almost dead. FUSE (Filesystem in Userspace) [sourceforge.net] is the most promising alternative that is getting merged into the 2.6.14 mainline Linux kernel. It works with several network filesystem protocols like:
SMB for FUSE [tudelft.nl]
SSH Filesystem (SSHFS) [sourceforge.net]
FuseDAV (WebDAV) [0pointer.de]

Linux-FUSE can also provide all applications on the system (even shell utilities) with access to network locations set up under KDE. There's a tutorial [ground.cz] for how to do this, but last time I tried it did not compile :-(

These are much needed improvements to usability of the Linux desktop, because unprivileged (non-root) users shouldn't have to contact their sys. admins everytime they need to mount network locations. The KDE approach to providing network access is not complete without Linux-FUSE, because only KDE apps can open/save to network locations set up under KDE. Hopefully the KDE devs will create a GUI for mounting/unmounting FUSE shares so that all apps (GTK, Motif, even shell utilities) can access network files.

Re:Filesystems

Does anybody know why ReiserFS 3 hasn't been ported to any of the BSDs yet?

Two reasons.

1. It's GPL'd code. Why in the world would a BSD-licensed project include GPL'd code, and in the kernel of all places?

2. UFS2 is better in just about every way. The issue of journaling vs. soft-updates has been rehashed a million times over, and soft-updates are simply better. http://www.usenix.org/publications/library/proceed ings/usenix2000/general/full_papers/seltzer/seltze r_html/index.html [usenix.org]
The one issue journaling had in it's favor was fsck times, and UFS2 with it's "background fsck" has eliminated that problem. A system based on UFS2 will be up-and-running far faster than a ReiserFS journaled system, due to reiserfsck taking much longer to complete.

So let me ask you. For what reason should anyone even consider porting reiserfs to any of the BSDs?

Re:Filesystems

I agree that BSD does not need Reiser, but I disagree with the blanket statement that BSD's filesystem is necessarily better. Comparative benchmarking of full implementations has shown that the differences between filesystems is not that large for most workloads, so nobody needs to care as long as the filesystem safeguards its integrity.

2. UFS2 is better in just about every way. The issue of journaling vs. soft-updates has been rehashed a million times over, and soft-updates are simply better.

The link you give is (a) written by the people that wrote soft updates, and (b) compares outdated journaling file systems, which are essentially strawmen. Reiser looks great in the papers on their own website too, but that's not a really an objective comparison either. If you want to put this to rest, you'll need to run a benchmark with more modern journaling file systems (in particular, those with wandering logs).

The one issue journaling had in it's favor was fsck times, and UFS2 with it's "background fsck" has eliminated that problem. A system based on UFS2 will be up-and-running far faster than a ReiserFS journaled system, due to reiserfsck taking much longer to complete.

The point of a journaling file system is that you don't need to run fsck (except in the case of a hard drive failure, of course). Mounting a several-hundred GB Reiser partition takes a few seconds, even if it was not cleanly unmounted. How much faster do you want that to be?

Last I heard from some of the authors, the main drawbacks keeping softupdates from being used elsewhere were that it was more invasive to the VFS than a journaling file system, and had extremely bad memory usage behavior for specifically crafted (but unrealistic) benchmarks. I'd be interested in knowing if there has been some progress on these since 2000. Journaling file systems have come a long way in that time.

I was expecting a beefier article...

The article was a little bit short and without sufficient substance to be noteworthy on slashdot, I think.

Re:I was expecting a beefier article...

You don't come here much anymore, do you?

Re:I was expecting a beefier article...

It also had a few factual errors, for example ext2 and ext3 are not extent based at all, they are classical block based filesystems.

Also, most of the Linux page fault code is architecture independant. As it happens, I just wrote an article explaining Linux page fault handling [linux-mm.org] for the Linux-MM wiki. You can find some details there...

Linux kernel better than Solaris kernel.

Interesting comparison between the Linux and Solaris kernels from someone who used to work SunSoft in the kernel group.

http://www.ultralinux.org/faq.html#q_1_15 [ultralinux.org]

Hyperthreading

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.

Big lock

Anyone know if FreeBSD is still using the big lock for SMP?

Re:Big lock

Only for some of the drivers, which nobody got around to modifying yet. Most of the things are outside the "Giant" already. 6.0-release is imminent. Try it...

Serious things were missed....

1. The SELinux kernel wasn't mentioned; it's security model is different, perhaps better in the final analysis than OpenSolaris.

2. The concept of Solaris containers is nearly science fiction. Building them and then watching them through dtrace is a work of art, as in the Sistine Chapel. LVM is a different school of thought that gets to a similar conclusion; this all skewed by the beauties of VMWare and multiple instance/clustering management possibilities.

3. The licenses-- very important differences in licenses-- are glossed==> ignored. There's all that messy intermingling of licensing trivia that's somehow an invisible characteristic of all of this. Fooey.

4. While Sun can speak anytime Sun wants, at least there were other citations mentioned early. This is Sun propaganda. Remember that. Well thought out propaganda, but propaganda, not a third party examination of the facts and implications.

5. There are other *nixes missing. Consider that real-time OS and embedded OS considerations are real, and while BSD and Linux has made progress there, Solaris is essentially missing, unless you consider weird programming profiles still based on non-Solaris OS.

These are just the extemporaneous thoughts. Take this article with a grain of salt, although it's not bad for a vendor-hosted view.

Re:Serious things were missed....

Who modded this insightful? As the author states, this is a comparison of three components that are similar in the three OSs (and even those not in great detail). It is NOT an overall comparison of every feature of the three kernels. This throws out the parent poster's points 1, 2, and 5. This was a technical analysis, so license is not relevant (parent's point 3). The article is skewed to a Solaris direction, but I would hardly call it propaganda. To summarize the skew:

1) Solaris has more abstraction for architecture dependent code than Linux, and is therefore slower but more portable.
2) There are also more people working on Linux, leading to faster development but not as high a quality.

See, that wasn't so bad. Overall, the author concludes that the three OSs do things quite similarly and stand to benefit from each other in the future.

SCO Engineers Do It Best

Since they wrote the linux kernel, SCO engineers had a lot of skill and foresight to create such a great operating system.

Don't say it isn't true - or our lawyers will be calling.

Mod article is Flamebait

I wish I had mod points right now plus the ability to Moderate this entire article as Flamebait :)

But flamewars are so much fun to read, so bring it on!

Interesting Model Breakdown...

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.

How much of Solaris has gone open source?

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. Lets see them open up the kernel internals like the thread model... I am skeptical that Sun will ever release their Kernel as open source as I recently had Sun reps argue with me that Linux/FreeBSD is 'single threaded' and cant scale across more than one cpu, to which I replied 'Bovine Scatlogical Pathology'. Sun is a hardware company people, and keeping Solaris uber-elite and closed source is their only way to sell expensive hardware.

Re:How much of Solaris has gone open source?

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 [opensolaris.org].

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

OK, here's the directory with the dispatcher stuff [opensolaris.org] and here's thread.c specifically [opensolaris.org].