Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software IT

A Comparison of Solaris, Linux, and FreeBSD Kernel 318

Posted by ScuttleMonkey 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.

A Comparison of Solaris, Linux, and FreeBSD Kernel More

A Comparison of Solaris, Linux, and FreeBSD Kernel

Comments Filter:

  • wishfull thinking (Score:5, Interesting)

    by scenestar ( 828656 ) on Sunday October 16, 2005 @09:09PM (#13806613) Homepage Journal
    If only they could compare the NT kernel along with them

    *sigh*

    • Re:wishfull thinking (Score:2, Interesting)

      by wlan0 ( 871397 )
      Can one really see how the NT kernel works, with all the stuff stuck together like Windows is?
      • It's all in the source code that we all got about a year ago from W2K when it- gaah!

        ***Microsoft Trade Secrets Protection Act***
        The person that wrote the above post has been dealt with for sharing Microsoft (R) Windows (R) proprietary source code and is violation of the End-User License Agreement as well as Microsoft Revised Penal Code section 192.168.0.1. The person has been terminated and please disregard the above message.

        Thank you,

        Microsoft Support Team

      • Re:wishfull thinking (Score:2, Informative)

        by Anonymous Coward
        If you're interested in the details of Windows I suggest that you pick up a copy of "Windows Internals". It's quite detailed about the inner workings of Windows.

      • Re:wishfull thinking (Score:4, Insightful)

        by TheNetAvenger ( 624455 ) on Monday October 17, 2005 @12:10AM (#13807299)
        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.

    • How can they? (Score:5, Insightful)

      by WindBourne ( 631190 ) on Sunday October 16, 2005 @09:13PM (#13806629) Journal
      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.

      • At this point, in order to see the kernel, you have to sign off on MS's shared source license.

        I fail to see why an open source programers would want to use or look at the NT/Windows kernel. I figure Solaris, BSD and Linux will all borrow from each other and Microsoft will quietly borrow from open source to get a decent scheduler.

        • Re:How can they? (Score:3, Insightful)

          by WindBourne ( 631190 )
          a good developer can learn from all systems. Sometimes how to design thing, and other times, how not to. Even from MS, there is a lot to learn.

  • Flavourful. (Score:5, Funny)

    by Anonymous Coward on Sunday October 16, 2005 @09:21PM (#13806667)
    " 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? (Score:3, Interesting)

    by Nuclear Elephant ( 700938 ) on Sunday October 16, 2005 @09:26PM (#13806683) Homepage
    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? (Score:5, Interesting)

      by WindBourne ( 631190 ) on Sunday October 16, 2005 @09:34PM (#13806714) Journal
      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.
      • 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).

        • I remember comparisons about how slow threads were to start in Linux compared to other OSes (although Windows is even worse, I think).

          I used to teach linux API and kernel Internals at various companies (HP, IBM, and Avaya). At that time, a student said something similar, so we decided to do some quick benchmarking( on 2.4 vs. 2000). It was what I would expect; Linux was very slow on the thread compared to NT. OTH, Linux blew away Windows on process creation. The simple answer to this, was that Linux's pro

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

          I'm fairly sure Solaris was the first to have an automatically-managed /dev. Solaris has had its /dev and /devices arrangement (in which everything in /dev is a symlink to something in /devices, there is no such thing as MAKEDEV anymore, and everything is automatically maintained) since at least Solaris 2.4, and quite possibly sin

          • You're right about the sub-par /dev managment in Linux. When I first switched to udev from the deprecated devfs (which I never had any trouble with), I couldn't boot properly from my software raid1 volumes because udev needed the root volume mounted to create the mdN device nodes, but the root volume couldn't be mounted until mdadm was pointed to an mdN device node to assemble...

            That was about 2-3 years ago. It all seems to work smoothly these days, I think they just patched some work-arounds (guess the maj
    • Licensing issues. You won't see GPL'ed code in the FreeBSD kernel, for instance.

    • Linux and the BSDs have been cross-pollinating for years. I would imagine that Solaris hasn't really joined the party because it was only so recently released under an open license.

      And for the record, all three flat out rock.

    • Re:When will OSI licenses really start working? (Score:2, Insightful)

      by Anonymous Coward
      Because well none of these licences really permit sharing, well some versions of the BSD licence are GPL compatable (those with two or three clause licences or ISC compatable but not any with the advertising clause. meaning that you could gpl the code (you have to be able to gpl it before you can incorporate it into a system that is already GPLed hopefully you have heard of the viralant nature of the GPL. BSD can't incorporate GPLed code for obvious reasons, CDDL can incorporate BSD code (probably does) bu
    • When will apt finally replace /usr/ports in FreeBSD?

      Hopefully never... Ports rocks!

      • FreeBSD Ports (Score:5, Insightful)

        by 0xB00F ( 655017 ) on Sunday October 16, 2005 @11:51PM (#13807236) Homepage Journal

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

        • Re:FreeBSD Ports (Score:3, Interesting)

          by molnarcs ( 675885 )
          Wow! Is that all it takes to get a +5 Insightful now? - I could ask the same of your own post, because some parts are factually wrong.

          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.

          I don't know about portage, but ports don't leave cruft behind. When you remove a port, you effectively remove a package. FreeB

        • Re:FreeBSD Ports (Score:3, Interesting)

          by Just Some Guy ( 3352 )
          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.

          So [package uninstaller] on [OS] completely removes that package. Golf clap. A properly packaged (your words) application will work that way on any OS, not just Debian.

          I love Debian, and have used it for years. It's great. However, the real admin nightmare comes when you decide you want some non-standard feature supported systemwide. On FreeBSD, for example, if I want LD

    • A port of Dtrace from Solaris to FreeBSD has been announced, and pf from OpenBSD has been ported to the others.

      It is happening. Solaris is the new kid on the block, it will take time for the code to be grokked and made use of. Or vice versa.
      • Personally, I see Solaris having all of its features "stolen" by going open source. Before you know it, LInux and FBSD will have the features, and there will be no compelling reason to run Solaris on x86. I have never seen solaris x86 as particularly competative product. The main reason I see people running Solaris is to take advantage of Sun's big iron (SPARC) systems. I don't think Solaris will ever be able to compete seriously with FBSD and Linux on x86 hardware.

        -matthew

  • Filesystems (Score:2, Interesting)

    by Bogtha ( 906264 )

    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 (Score:3, Informative)

      by salahx ( 100975 )
      LUFS is unmaintained, it has been replaced with FUSE [sourceforge.net]. FUSE includes a LUFS-to-FUSE bridge called Lufis

      FUSE is now merged into the Linux kernel [kerneltrap.org], and will appear in 2.6.14.

    • Re:Filesystems (Score:4, Informative)

      by CyricZ ( 887944 ) on Sunday October 16, 2005 @09:51PM (#13806779)
      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 (Score:5, Interesting)

        by ajs ( 35943 ) <[ajs] [at] [ajs.com]> on Sunday October 16, 2005 @10:15PM (#13806868) Homepage Journal
        "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]
        • I know plenty about ReiserFS. Had you read my post you would have understood that the problem is not with the concepts and algorithms of ReiserFS. The problems are not with the idea nor the Linux implementation, but instead with trying to tack the Linux implementation onto the FreeBSD kernel.

          You cannot take code from two radically different projects, stick them together as is being proposed by others, and then have it magically work. You could run into issues with the FreeBSD file buffering subsystem, for i
        • Unfortunately, while much better than ext2 or ext3, Reiser still doesn't do great at directories containing hundreds of thouands or millions of files. It's better than any other FS I've tried for this but could still use some work. It handles large amounts of files over the entire filesystem well though which is good.

          Layering your own FS on top of Reiser works pretty well. Break up directories into smaller directories containing sub-directories of files increases access time a lot. Squid and other programs

        • Re:Filesystems (Score:3, Interesting)

          by SnowZero ( 92219 )
          The problem with Reiser is that it is Reiser,

          I'd say the real problem is often Hans Reiser. He's usually got good ideas, but he tends to quickly get on people's bad side with his argumentative style. What's strange is that this is usually limited to the first 10-20 posts in some big discussion, then he calms down and works more directly and constructively with developers. If you look at the past few Reiser discussions on lkml, they seem to follow this pattern.
      • Reiser4 implements it own VFS and does intrusive things to the host OS' VFS. Kernel coders don't want a duplicate VFS and want to incorporate features at the appropriate level of the kernel. Reiser wants his filesystem to be differentiated on features and most clearly does NOT want other filesystems gaining them (futile) and that requires the duplication which the kernel devs (rightfully) don't like.

        I doubt Mr. Reiser would have much better luck with the kernel devs on any of the BSDs.
        • Indeed, if that is the case, then it is no surprise that the FreeBSD developers have not dedicated resources towards performing a port, even if it isn't integrated within the core FreeBSD codebase. They're known for engineering a solid operating system, and such shenanigans as you describe do not lead to well implemented designs.

        • As I understand it, Reiser4 barely (if at all) departs from standard POSIX filesystem semantics. While at the same time, allow meta-data capabilities (eg ACLs) of just about any sort. It does this by treating each file as a directory as well. So if you open the file as a file, you get the file. If you open the file as a directory, you get its meta-data. This does not break anything, nor require the use of any extra filesystem primitives. So I would think that in theory a port should be easy to any POSIX sy

    • Userspace Filesystems: try Plan 9 from Bell Labs (Score:5, Informative)

      by djs55 ( 37253 ) on Sunday October 16, 2005 @09:56PM (#13806791) Homepage
      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 (Score:5, Informative)

      by billybob2 ( 755512 ) on Sunday October 16, 2005 @10:15PM (#13806872)
      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 (Score:4, Informative)

      by evilviper ( 135110 ) on Sunday October 16, 2005 @10:49PM (#13806993) Journal
      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 (Score:5, Insightful)

        by SnowZero ( 92219 ) on Monday October 17, 2005 @03:43AM (#13807860)
        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... (Score:5, Funny)

    by Improv ( 2467 ) <pgunn01@gmail.com> on Sunday October 16, 2005 @09:31PM (#13806704) Homepage Journal
    The article was a little bit short and without sufficient substance to be noteworthy on slashdot, I think.

  • Linux kernel better than Solaris kernel. (Score:2, Interesting)

    by Anonymous Coward
    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 (Score:5, Interesting)

    by MBCook ( 132727 ) <foobarsoft@foobarsoft.com> on Sunday October 16, 2005 @09:49PM (#13806766) Homepage
    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.

  • Anyone know if FreeBSD is still using the big lock for SMP?
  • 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 lice

    • Re:Serious things were missed.... (Score:5, Insightful)

      by joe_bruin ( 266648 ) on Sunday October 16, 2005 @11:11PM (#13807082) Homepage Journal
      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 (Score:3, Funny)

    by Anonymous Coward on Sunday October 16, 2005 @10:48PM (#13806986)
    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.
  • 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... (Score:5, Interesting)

    by TemporalBeing ( 803363 ) <bm_witness AT yahoo DOT com> on Sunday October 16, 2005 @11:15PM (#13807096) Homepage Journal
    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.

Slashdot Top Deals

The truth of a proposition has nothing to do with its credibility. And vice versa.

Close