Slashdot Mirror
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.'"
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. You can even run it inside vmware or Xen.
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) 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
SSH Filesystem (SSHFS)
FuseDAV (WebDAV)
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 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.
Aparently you need to stop reading the media and do a bit deeper research into what systemtap is and how unstable it is. You can start with Active Bug, non guru mode. That bug affects non-guru mode, which is supposed to be safe to use in production. Nothing like that ever happens in dtrace. Why you may ask? Because its developed to be safe in Production use at the expense of giving up some features. For a more indepth comparison of systemtap and its problems check out the links mentioned in my blog's SystemTap Links. Systemtap vs. dtrace the debate continues is a good place to start.
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.
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.
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).