Slashdot Log In
A Comparison of Solaris, Linux, and FreeBSD Kernel
Posted by
ScuttleMonkey
on Sun Oct 16, 2005 09:07 PM
from the sibling-rivalry dept.
from the sibling-rivalry dept.
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.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
wishfull thinking (Score:5, Interesting)
*sigh*
How can they? (Score:5, Insightful)
Parent
Re:wishfull thinking (Score:5, Informative)
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.
Parent
Re:Toy computers need not apply (Score:5, Informative)
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).
Parent
Re:Toy computers need not apply (Score:5, Insightful)
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
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
Parent
Flavourful. (Score:5, Funny)
One is crunchy, the other's chewy, and the last is malt flavoured.
I was expecting a beefier article... (Score:5, Funny)
Re:I was expecting a beefier article... (Score:5, Funny)
Parent
Re:I was expecting a beefier article... (Score:5, Informative)
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...
Parent
Hyperthreading (Score:5, Interesting)
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.
Interesting Model Breakdown... (Score:5, Interesting)
P.S. Sorry to repeat myself on that...just not sure how best to say it.
Re:When will OSI licenses really start working? (Score:5, Interesting)
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.
Parent
Re:When will OSI licenses really start working? (Score:5, Interesting)
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).
Parent
FreeBSD Ports (Score:5, Insightful)
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).
Parent
Re:The Answer is Clear (Score:4, Informative)
B) Linux has SystemTap [sourceware.org], which goes above and beyond what DTrace is capable of. It is still in heavy development by Red Hat (Intel and IBM also helped start up the effort), and it's already quite a product.
Your post was one big troll, why do you find it amusing to spread random misinformation?
Regards,
Steve
Parent
Re:The Answer is Clear (Score:5, Informative)
Of course, systemtap is still in its infancy, perhaps after a couple re-writes that seem standard in major components in the Linux Kernel, they can make it stable. But today its, not and any where near stable. There for your statement of "Linux has SystemTap, which goes above and beyond what DTrace is capable of. It is still in heavy development by Red Hat (Intel and IBM also helped start up the effort), and it's already quite a product." Is complete rubish. Of course one would have to think about. If its still under heavy development, also shows just how far from ready it is.
Of course, the truth really is that DTrace is far more feature rich than systemtap is, or will be for a long time. Systemtap biggest stumbling block is "guru mode" that allows the user to disable any protection that systemtap engineers have added. Systemtap's language is lacking in some basic concepts, like variable types like struct and typeset, making guru mode necessary for far too many scripts, and in-escapable when userland probes are created. Along with the other problems documented in my blogs.
You may try and dismiss me as a troll, but nothing could be farther from the truth. I'm stating the facts, I have also contributed to the Systemtap product, and commented on code changes. But I refuse to sit quietly as people try and pass Systemtap off as stable or better than DTrace. Dtrace is stable, and Enterprise Production ready and more full featured than Systemtap, even though they have left out features, that have to be worked around by the programmer.
Parent
Re:The Answer is Clear (Score:4, Insightful)
Parent
Re:Filesystems (Score:4, Informative)
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.
Parent
Re:Filesystems (Score:5, Interesting)
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]
Parent
Userspace Filesystems: try Plan 9 from Bell Labs (Score:5, Informative)
Have a look at the Plan 9 wiki [bell-labs.com]. You can even run it inside vmware or Xen.
Parent
Re:Filesystems (Score:5, Informative)
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.
Parent
Re:Filesystems (Score:5, Informative)
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.
Parent
Re:Filesystems (Score:5, Insightful)
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.
Parent
Re:Serious things were missed.... (Score:5, Insightful)
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.
Parent
Re:Big lock (Score:5, Informative)
Parent