Benchmarks For Ubuntu vs. OpenSolaris vs. FreeBSD

Ashmash writes "After their Mac OS X versus Ubuntu benchmarks earlier this month, Phoronix.com has now carried out a performance comparison between Ubuntu 8.10, OpenSolaris 2008.11 and FreeBSD 7.1. They used a dual quad-core workstation with the Phoronix Test Suite to run primarily Java, disk, and computational benchmarks. The 64-bit build of Ubuntu 8.10 was the fastest overall, but FreeBSD and OpenSolaris were first in other areas."

Comments

What about the Sun Studio compiler?

[aliquis]

Various versions of GCC. While one could argue that the compiler is part of the OS it's indeed replaceable so I would had prefered if they had used the same version of GCC and not different for each OS.

It would had been very interesting to see the Solaris results using Sun Studios CC as well (I think it's also available for Linux nowadays?)

Re:What about the Sun Studio compiler?

[Just Some Guy]

While one could argue that the compiler is part of the OS it's indeed replaceable so I would had prefered if they had used the same version of GCC and not different for each OS.

I'm a huge FreeBSD fan. However, I don't have a problem with them testing the compiler as it was shipped with the OS because it's the one officially supported. Since that's the compiler that 99.9% of FreeBSD users will have, that seems like a reasonably fair baseline comparison.

Similarly, they explicitly state that "[a]side from changes made by the Phoronix Test Suite (and adding the GNOME packages to FreeBSD), all operating systems were left in their default configuration." I'm sure all of them could be tuned for higher performance on this benchmark, but I think out-of-the-box numbers are valuable.

Re:What about the Sun Studio compiler?

[ByOhTek]

True, though the only one I think that *really* hurts is sun, since it doesn't have all of the GCC 4 optimizations, and they still handled themselves quite well. My issue is with using FreeBSD 7.1 Beta 2. They should have stuck with 7.0 (the release edition). Usually the Betas and RCs tend to be worse-performing than the final releases (at least to my knowledge with FreeBSD history, I remember that usually being the case).

Re:What about the Sun Studio compiler?

[aliquis]

At least earlier I think you could switch in rc.conf or similar if you wanted to use gcc 3.x or 2.95.x for instance, both may have been available, I don't remember. I don't think that is much of tuning, not much more than trying to benchmark KDE by different versions, or even various versions of Windows on different laptops.

If it's about the compiler version (or options) I know I can switch compiler and get a better result, if it's some other tweaking or totally different kernel or system libs or such it may be much harder to do anything about it.

Anyway, I respect that your opinion is different =P, I won't give it much credit as an OS benchmark though (but in the end benchmarks don't matter much either, running the actual application you want to run on the system do.)

Re:What about the Sun Studio compiler?

[aliquis]

That's why Sun cc would had been fun in case it had owned gcc =P

Re:What about the Sun Studio compiler?

[ByOhTek]

but if you want to go on that route, a lot of changes could be made: - FreeBSD gets much better performance on Intel than AMD. - Were packages or ports used for software installation? I can think of a few more, some affecting all systems, some just one or two. Regardless, these are changes to the base system, and this is a base system test. Those are questions for another test altogether. The proper questions here are if the base system used is the proper one for a valid test.

Re:What about the Sun Studio compiler?

[Anonymous Coward]

My concern is that they had a release version of Ubuntu up against a beta version of FreeBSD (which will still have a lot of debugging crap in there) and a release candidate of Open Solaris (maybe debugging crap?).

Ideally, the benchmarks should all be run on release versions, which is something more interesting to me.

As for default settings, that is prefered. Most people don't go out of their way to change them unless they have a reason to.

Re:What about the Sun Studio compiler?

[Anonymous Coward]

If it's about the compiler version (or options) I know I can switch compiler and get a better result

This is benchmarking the OS, not a biased user-optimization of the OS. Using all GCC would benchmark the GCC implementation on that OS(not the OS itself). Not to mention the GCC may be a biased towards one community over the other(hardware optimizations from one and not the other).

Re:What about the Sun Studio compiler?

[Anonymous Coward]

"FreeBSD gets much better performance on Intel than AMD."

Where can I get the info on this? I'm currently very happy using 7.1 on a 2GHz 2600 barton core, but am beginning to shop for a new machine. I'll go with Intel instead if the performance is that much better. And yes, I do know it's a package deal, and I look at other factors as well (like power use, etc.)

Re:What about the Sun Studio compiler?

[ByOhTek]

I've found stuff in freebsd-questions and I think -qa?

All my FreeBSD machines are AMD at the moment, except my notebook. For most tasks they are very responsive (more responsive than Windows or any flavor of Linux I've used except maybe Gentoo). However the AMD machines in my case seem to have one annoying flaw - namely if I hit caps lock, they freeze up for half a second to a second, then resume as if nothing happened. This does not happen on Intel based machines I've used with FreeBSD.

Re:What about the Sun Studio compiler?

[Sancho]

I regularly read that list.

I don't specifically remember anything about general performance being better. I do remember reading about routing throughput being somewhat higher on AMD than on Intel at high PPS.

All my FreeBSD machines are AMD at the moment, except my notebook. For most tasks they are very responsive (more responsive than Windows or any flavor of Linux I've used except maybe Gentoo). However the AMD machines in my case seem to have one annoying flaw - namely if I hit caps lock, they freeze up for half a second to a second, then resume as if nothing happened.

That's an interesting issue, and one I can't reproduce (I have a number of AMD FreeBSD machines of various versions.)

Re:What about the Sun Studio compiler?

[sgt scrub]

but I think out-of-the-box numbers are valuable.

I couldn't agree more. I like Ubuntu. It is a good distro. But "out of the box" is exactly what a distro is. Therefore it should be judged on its out of the box abilities. People looking at this as a comparison of operating systems are way off. If they wanted to compare the three at their optimum they would have used Linux from scratch, and the equivalent for the others, tweek'd the living crap out of them, then ran them over the cliff. So IMHO that article is a good comparison.

Besides. It gives all three another objective that we will all benefit from.

Re:What about the Sun Studio compiler?

[LizardKing]

I've never used Sun compilers on x86, but on SPARC they produce binaries that are much smaller and faster than those produced by GCC. The same is true on x86 when using the Intel compiler rather than GCC, so it may be down to greater tuning for a single architecture.

Re:What about the Sun Studio compiler?

[Anonymous Coward]

gcc isn't shipped with OpenSolaris; it's only available from the package repository.

So that argument might apply to FreeBSD, but not OpenSolaris.

Re:What about the Sun Studio compiler?

[uassholes]

Even with the same version, I would be concerned that optimization is better for linux than other less used (as far as GCC) OSes.

Re:What about the Sun Studio compiler?

[Anonymous Coward]

Using all GCC would benchmark the GCC implementation on that OS(not the OS itself).

Bzzt. You don't know how computers work, do you?

Hint: GCC will always output the same machine code for a given version and compiler flags. No matter which architecture is hosting GCC. No matter which OS is hosting GCC.

Re:What about the Sun Studio compiler?

[ToasterMonkey]

You think all implementations of GCC are built from the same source? Seriously?

Re:What about the Sun Studio compiler?

[Fweeky]

My issue is with using FreeBSD 7.1 Beta 2. They should have stuck with 7.0 (the release edition). Usually the Betas and RCs tend to be worse-performing than the final releases

Beta and RC should be pretty much as performant as the final release; there's no magical change in CFLAGS or debugging options for a release.

On CURRENT, yes, there's WITNESS and INVARIANTS which drastically reduce performance because it's constantly checking every locking operation to make sure things are happening in the right order, verifying kernel data structures and so forth. This doesn't apply to STABLE, PRERELEASE, BETA or RC releases.

Re:What about the Sun Studio compiler?

[theapp]

A bit off topic, but I had the exact same freezing issue with FreeBSD. This mailing list post proved to be the solution for me: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/hackers/2008-05/msg00318.html It seems to boil down to FreeBSD still loading the atkbd driver even if you only have a USB keyboard connected. Pressing capslock/numlock/scrolllock causes some delays doing this. The solution for me was to add 'hint.atkbd.0.flags="0x01"' to my /boot/device.hints. This resolved the problem entirely for me. Hope this helps.

Re:What about the Sun Studio compiler?

[epine]

I couldn't agree less.

As a practical matter "out of box" is synonymous with lowest common denominator.

The dominant criteria in tuning OOB is that the OS be tolerable for almost any conceivable workload within the capability of the machine.

If you are also able to tweak performance for commonplace tasks (such as the LAMP stack) *without* compromising the former goal, you can do that too, to some degree. Bear in mind not to turn on any performance features that are poorly documented, have surprising edge cases, or security considerations that aren't widely understood.

Let me try again in visual terms. OOB is what results when you ship a Ferrari engine to Volvo who then dress it up as an eight passenger station wagon with air bags, headrests, and seatbelts for every occupant.

Try to picture it. Two long columns of eight-seat station wagons packed together at the start line of the Volvo Indianapolis 500 rumbling their engines. Some powered by Solaris, some by Ubuntu engines, some by FreeBSD.

But "out of the box" is exactly what a distro is.

Enjoy the race, buddy.

Re:What about the Sun Studio compiler?

[ByOhTek]

thanks, that fixed it.
Heh, didn't even notice the 'no ps2' difference on my notebook.

Right.

[shivamib]

Test all three distros out of the box, to see which one is better... Even with all that extra 'default' weight Ubuntu still shines on except when running, eh, Java.

Very informative!

Re:Right.

[Thelasko]

Even with all that extra 'default' weight Ubuntu still shines on except when running, eh, Java.

From my personal, and non-scientific experience, I've found OpenSolaris to have more 'default' weight than Ubuntu.

Re:Right.

[aliquis]

Yeah, because Solaris and FreeBSD are so stripped and optimized for the purpose by default? =P

I still think it's somewhat useless since they had various versions of the compiler, you can't draw any conclusion about the kernel/OS speed when the compiler varies and you can't draw any conclusions on the compiler when the kernel/OS differ. So ...

Put two rowers in whatever boats they happen to have, let them row for a goal, see who wins and decide that person was the best rower? Or which boat was the best one ..

I always hate that factor when people do these stupid comparisons, why not use different versions of the benchmarks to? =P, unzip different archives? :D

Re:Right.

[TheRaven64]

Except that they tested FreeBSD 7.1 beta 2. FreeBSD betas are compiled with extra debugging and checking code which slows the end result down a lot. This includes the WITNESS kernel flags and the malloc checking. These encourage early and reproducible failure for bugs. For release versions of FreeBSD, these are turned off, which generally gives a noticeable speed increase. I note that the Solaris version they tested was a release candidate too, so I wonder if the same is true there.

A lot of their benchmarks seemed to be CPU-limited, with little OS involvement (e.g. FFT, RSA). Differences here are likely to be more down to malloc() implementation than anything in the kernel. In a FreeBSD beta, malloc will be adding guard pages and initialising data to a known value to check for overflows. In Solaris, I'm not sure what the current malloc() strategy is - last time I used Solaris it was still using a brk()-based malloc() (where FreeBSD and Linux both now tend to use mmap()-based versions).

Re:Right.

[Moridineas]

I still think it's somewhat useless since they had various versions of the compiler, you can't draw any conclusion about the kernel/OS speed when the compiler varies and you can't draw any conclusions on the compiler when the kernel/OS differ. So ...

I disagree. While these benchmarks are indeed of limited complexity and utility, they offer a snapshot of out of the box performance on 3 OSes. Obviously you can optimize all of them substantially, try bleeding edge kernels, later revisions, etc.

Re:Right.

[aliquis]

I know they tell how the system performs in its default state, but in that case why even bother to compile the benchmarks? Shouldn't you be using whatever versions is available as packages if there is any?

And default versions doesn't matter much, if anyone is serious enough to start compiling all their own applications they sure will be able to switch compiler version, and there may be both advantages and disadvantages with a new or old version so it all depends on what you want. In this case Ubuntu took many scores except in filesystem but also had the latest GCC, what happens if you compile the same GCC on FreeBSD and Solaris, compile the benchmarks and look again?

Also most people into Solaris would probably be willing to go thru some extra trouble to compile their stuff with Suns compiler.

I have no idea but I guess that GCC may have the best support for Linux to? Also there is that "new" BSD licensed compiler, I don't remember the name, I have no idea if it's complete enough to be able to compile said benchmarks and compete with GCC but it would had been interesting with that one to. If nothing else to compare both compilers.

Interesting don't have to mean "useless unless" in this case :D

Re:Right.

[TheRaven64]

If they wanted a good comparison of what a user sees, they should have used a release version of all operating systems, instead of a release of Ubuntu, a release candidate of Solaris and a beta of FreeBSD. I don't know about Solaris release candidates, but FreeBSD betas come with a lot of extra stuff in libc and the kernel turned on that make tracking issues easier at the expense of speed. Most end users will not be running betas, they will be running the latest stable release.

Re:Right.

[pseudonomous]

Yeah, and they were using a Solaris Release Candidate as well, to really make a fair comparison, you would, I think, want to use actually official "production" releases of each operating system.

In the end, the results don't really seem to stand out a whole lot, except that Solaris does signifacantly better on a couple benchmarks, and then significantly worse on others.

Re:Right.

[compass46]

Except that they tested FreeBSD 7.1 beta 2. FreeBSD betas are compiled with extra debugging and checking code which slows the end result down a lot. This includes the WITNESS kernel flags and the malloc checking.

This is only true in HEAD which will eventually be FreeBSD 8.x. They are turned off in the FreeBSD 7.x branch (RELENG_7)

Re:Right.

[Just Some Guy]

Beyond that, how hard do these tests push SMP systems? For example, the Gzip results could be explained away by compiler version differences. What would happen if it were run twice in parallel? 100 times? This test suite compares that for all I know, but I didn't see that mentioned anywhere.

Re:Right.

[Moridineas]

I absolutely agree with you.

Re:Right.

[Anonymous Coward]

You must also account for any optimizations in the code for a given OS. If any optimizations are made for the Linux kernel or a particular libc then the whole suite is worthless.

Re:Right.

[Galactic Dominator]

Why wouldn't the testers use PCBSD then? That is the basic equivalent of Linux => Ubuntu where optimization for desktop use takes place. All that "comparison" did was compare two generic type bloated RC kernels generally intended for server use vs a stable bloated kernel optimized for desktop usage. All you're going to prove is that one kind of bloat is better than another....it's not even good for a baseline.

Re:Right.

[CAIMLAS]

It's kind of crazy how so many benchmark reviews completely overlook actual use and go for one or two "bullet list" type qualifiers for their benchmarks. Granted, I understand this is mainly in the interest of page hits and ad revenue, and by making it controversial they increase those things, but c'mon. Benchmarks are supposed to be pragmatic, and in order to be pragmatic, they have to operate at or near userland conditions, considering CPU, bus, memory and network speed, and the like - as they pertain to the user (whether the user is a hosting company or a desktop end user).

It seems like a pretty trivial matter to do something like this. Say, use something like MySQL for starters - it's available for a dozen or so systems (major Linux distros, OS X, Windows, etc.) It's also typically offered by the vendor, so you'd be able to get an 'ideal' setup for each release.

Or, how about something like a "Firefox benchmark" as that's user-applicable and can use all hardware. Time how long it takes to start FF on all systems with, say, 50 tabs running.

Or how about a straight-up media playing benchmark for 2D performance? Launch a dozen or so DivX videos at once and see how well it performs: measure CPU load, memory use, and the time it takes for FF to start up completely.

Or how about lengthy disk access (maybe crawling a storage tree or such) and measure the time it takes, as well as the amount of memory which gets cached for the process?

This benchmark, as well as most others, seem pretty trivial and useless, and not all that well thought out. They're certainly not scientific!

Re:Right.

[TheRaven64]

My favourite benchmark: Build LLVM trunk with a parallel make. Set it to something like -j12 (or more) on a 2-4 core machine and see how well the kernel manages overlapped I/O requests and scheduling all of the compiler processes. Try playing a video at the same time, and record the number of dropped frames. I don't think network performance was well tested in this either.

Re:Right.

[Fweeky]

Also there is that "new" BSD licensed compiler, I don't remember the name, I have no idea if it's complete enough to be able to compile said benchmarks and compete with GCC but it would had been interesting with that one to.

You're probably thinking of LLVM. It does have a gcc front-end, so can be used to compile most things gcc can.

There's another one or two, but LLVM's probably the only serious contender against gcc.

Re:Right.

[Fweeky]

FreeBSD betas come with a lot of extra stuff in libc and the kernel turned on that make tracking issues easier at the expense of speed.

No they don't. There's the main kernel debugging options: WITNESS, which tracks kernel locking ordering, and INVARIANTS, which adds in a lot of asserts to validate the integrity of various data structures. libc wise there's MALLOC_PRODUCTION, which turns off a bunch of debugging things in jemalloc.

None of these are ever on unless you're running FreeBSD -CURRENT (currently the 8 series) or otherwise make a custom build where you've explictly turned them on; 7-BETA and 7-RC's are built with the same options as release builds. You'll *know* when someone benchmarks a system with them on because they'll be *significantly* slower.

Re:Right.

[Anonymous Coward]

The limiting factor in your above benchmark is that it doesn't port well to other systems. That's problematic.

Also, these benchmarks are not meaningful for comparing a desktop distro against server OSes/kernels like OpenSolaris and fBSD. Ubuntu is targeted at desktop performance so it's not going to perform well at certain things - but due to the kernel's almost infinite configurability these days, it's not representative of linux servers. Likewise for the others in desktop benchmarking, I suspect (though I'm not familiar w/ them).

Re:Ubuntu may be fast...

[aliquis]

Is that true even if you install grub/lilo to MBR instead of the bootable partition? Do it need anything from /boot? I doubt that?

Sure the boot loader wil remain, but so what? Also it's quite obvious that you need to update it so ..

It's not like Windows offers a way to easily uninstall it either, or even ask before overwriting it ..

Re:Ubuntu may be fast...

[Splab]

You have to do what now?

Ubuntu uses Grub for choosing what to boot and that has the active flag. No matter what OS you use, if you want something else to handle booting you have to use fdisk or the like for changing the boot flag.

Re:Ubuntu may be fast...

[Fallingcow]

Yes, I, too, find this nut and bolt set inadequate for the purpose of assisting Chinese Rhinoceros to learn Western astrology. It seems silly that purple monkey dishwasher.

Re:Ubuntu may be fast...

[gmuslera]

Easy to uninstall as what? An application? Is not an application that runs over Windows and you uninstall it cleaning registry and deleting some files.

Try to uninstall windows the same way... you always have to mess with some boot loader, or at least, whatever that replaces your boot loader.

There are a lot of space to complain about linux missing something or making something harder (playing some specific games, not having some windows-only program, not supporting some hardware that developed/documented drivers only for windows, etc), but installing something to boot itself is almost a must do for all operating systems.

Glad to see FreeBSD getting some press

[Deagol]

I was a bit disappointed by the results, being a FreeBSD fan myself. However, in my quick scan of the article, I didn't see any mention of how they configured the OS. If they truly used the stock 7.1-BETA2 install, that would mean that debugging mode is enabled in the kernel (and maybe the userland, I'm not 100% sure here). Unless I've misunderstood FreeBSD's release methods over the years, they don't disable the debugging until either the RC builds or maybe even the final release tag.

Still, FreeBSD came out on top on 3 of the tests -- not bad for a beta release. I can't wait for 7.1, as using 7.0 on my desktop since its release has been great. I just hope the fully-virtualized IP stack within jails made it into 7.1, as well as a slightly more stable ZFS.

Re:Glad to see FreeBSD getting some press

[TheRaven64]

debugging mode is enabled in the kernel (and maybe the userland, I'm not 100% sure here).

Betas generally have a few malloc flags set, which make malloc() a fair bit slower, resulting in everything in the userland being slow. The point of a beta is to catch bugs before the shipping release, so everything is run in debug mode.

I'm also looking forward to 7.1, although I'm sad that the per-vchan volume control patches appear to only be in the 8.x tree. These implement the OSS 4.x ioctls and allow applications to just open /dev/dsp and write sound there, with simple ioctls to set the volume. 7.0 supports the ioctls, but they set the master volume, not the virtual channel's volume.

Re:Glad to see FreeBSD getting some press

[cstdenis]

I just hope the fully-virtualized IP stack within jails made it into 7.1, as well as a slightly more stable ZFS.

No virtual IP stack yet. ZFS is slightly more stable, but still has a ways to go.

Re:Glad to see FreeBSD getting some press

[Anonymous Coward]

Betas and the CURRENT branch always have debugging turned on. Debugging gets turned off once the build hits RELEASE.

Not bad at all, coming out on top in 3 tests and not keeping it close in the majority of tests it didn't place first in, while being slowed down by being in debugging debugging mode!

Re:Ubuntu may be fast...

[shivamib]

.. but what it's missing is the ability to easily uninstall it. It's not the only distro not to be easily uninstallable

sudo rm -rf /

Re:Ubuntu may be fast...

[jgtg32a]

dammit so /. decided to eat my good post so I'll just leave the quick and dirty instead. This is why /boot gets its own partition, it lets you remove things very easily, and adding them is simple as well.

ZFS

[devinteske]

For desktop use, I find this to be an accurate test (as many desktop users will likely use the default configuration). However, I feel this to be a generalized test only suited for the purpose of picking a Desktop OS.

For Servers and anybody that has intimate knowledge of the capabilities of each OS, it should be duly noted that Linux and FreeBSD could have performed better. Linux could have been configured to use the EXT-4 file-system, which may or may-not have performed better (or at least on-par) with Solaris' ZFS. Similarly, I would have liked to see the results if FreeBSD-7 was configured to use ZFS, so we could have seen an Apples-to-Apples comparison between Solaris and FreeBSD. I also wonder if FreeBSD's implementation of ZFS is faster than Solaris'.

Re:ZFS

[setagllib]

ext4 doesn't really exist yet, and it's definitely not up to the level of ZFS. It's pretty much just a minor revision on ext3, which is admittedly generations behind. btrfs may compete with ZFS, but only in a few years when it's actually ready.

Ubuntu performance

[MikeRT]

The reason that I never really seriously used Linux on my PC laptop was that Ubuntu was sluggish, even with the newest ATI drivers, compared to Windows. Maybe people have good experience with nVidia drivers there, but Windows is a lot more usable as a desktop for me on the performance side of things. Granted, my main computer is a MacBook Pro running Leopard, but I can't imagine putting Linux back on my old PC laptop for when I need to use it.

Re:Ubuntu performance

[Hatta]

These days a full install of Ubuntu, with all it's bells and whistles is going to be slower than a bare install of XP. The nice thing is that you don't need all that cruft, and it's pretty easy to install a command line system and add things as needed. Use a lightweight WM or desktop like fluxbox or XFCE and you're set.

Re:Ubuntu performance

[troll8901]

The reason that I never really seriously used Linux on my PC laptop was that Ubuntu was sluggish ...

Why don't we try Xandros Linux? (It's the one installed in some Eee PCs.)

* ducks *

Re:Ubuntu performance

[sheepweevil]

That's what Xubuntu is for. Xubuntu uses Xfce, which makes it work well on older computers. I have a system dual-booting Xubuntu and Windows XP, and the performance improvement is very noticeable (although it largely has to do with the crappy AV running on XP).

Re:Ubuntu performance

[Anonymous Coward]

> Use a lightweight WM or desktop like fluxbox or XFCE

or even tick the reduced resources flag for gnome.

Re:Ubuntu performance

[jgtg32a]

Oh I see you mentioned Mac, because most of your post says that you prefer Windows to Linux, but you weren't modded troll.

Re:Ubuntu performance

[Shadow Wrought]

I've used Xubuntu as a live CD and it works great. Its going to be going on my next box.

Re:Ubuntu may be fast...

[gad_zuki!]

Huh? Ubuntu is an OS not an application. It installs its own boot loader called grub. It does this because the windows boot loader will not recognize a linux install. Perhaps your beef, if you truly have one, is with MS. They could make their boot loader play nice with other OS's. I believe you can load windows with grub just fine. The /mbr restore for windows is to wipe grub and go back to using the windows loader.

If you think any other non-MS OS is easier to "uninstall" then youre just wrong.

Re:Ubuntu may be fast...

[TheRaven64]

Uninstalling FreeBSD means deleting the partition. It either uses the boot loader you already had installed, or it installs a multiboot menu that fits in the MBR, so continues to work when the partition has gone away. If you install Ubuntu, I believe it installs grub and points the MBR at stuff on your /boot partition. If you destroy this, you will not be able to boot any OS.

Not that this is a major problem, since uninstalling an OS (outside of a VM) is not something that many people do very often.

A particular distribution vs different OSs

[gmuslera]

Could be nice to do those comparisions in the same hardware betweeen i.e. Ubuntu, Gentoo and OpenSUSE, all for 64 bits, as is not clear when they are measuring against Linux or against optimizations or not that do a particular distribution. Or put where it applies (i.e. the java tests) the numbers for Windows and MacOS.

What about some combined loads?

[tlhIngan]

Interesting results, and great if you're planning a server, but what about desktop use?

How well does each OS do when doing something like playing back audio/video, and handling background processing loads? What about performance and system response as the load climbs up? (load averages of 5/10/20 ?).

Only because I've seen Linux systems start to crumble around 5 (uniproc machine), and easily get unusuable, but have heard reports of BSD machines being able to still play MP3s without skipping/suttering even around 20 or so...

(And yes, I'll allow tweaking system priorities - it only gets you so far, and impacts the other background processing tasks, to which we'll also be interested in how long they take to run. So renicing the media player to -20 works, but not if it makes all the other tasks take 10x as long to finish...).

Re:What about some combined loads?

[Fallingcow]

Let's bring BeOS in on that test :)

You could IM and browse the web on that OS without making your MP3s skip, all on a Pentium 133 w/ 64MB ram. None of its contemporaries were even close in terms of UI responsiveness under load and smooth media playback, and no bloated modern OS is even close. Damn impressive.

Re:What about some combined loads?

[Hatta]

How do you measure interactive performance? When you're just crunching numbers, or doing sustained reads from a disk it's pretty easy to get meaningful numbers. But when you have 5 or 6 different things going on at the same time, it's hard to replicate those conditions exactly on different systems. And if you do, what sort of metric are you going to use that will look good on a graph and actually tell you something about how well the system is performing?

Re:What about some combined loads?

[jyro1980]

Interesting results, and great if you're planning a server, but what about desktop use?

Totally agree!

Re:What about some combined loads?

[poopdeville]

Me too!

Re:What about some combined loads?

[Anonymous Coward]

Welcome to Slashdot, where no consensus is met no matter how detailed a benchmark is.

I have used my Ubuntu box with high loads without a problem (not sure if 5/10/20, nor how I would discover, top?).

However when you say desktop use, I am sure that I qualify since this is all I do with my computer. As an example I have the following running on my desktop:

1 - Full GUI
2 - Playing movie
3 - Firefox is open (3 windows, around 3-5 tabs per window)
4 - Torrents are downloading
5 - Newsgrounds are downloading
6 - Multiple widgets/gadgets/??? running

I am sure I qualify as a typical desktop user, I am not sure what my load value is, but whatever it is, even whenever I am installing, compiling I never see problems with audio and video playback. I don't see stutter, I don't see my system crumbling, I don't see any performance issues, not even a window taring.

I sense FUD from the FreeBSD community. Did I mention that I also have all of those visual what-its running in the background (my firefox window wiggles, and my 3d cube cubes without slow downs/hick ups/stutters/audio crackles/anything negative).

Re:Ubuntu may be fast...

[Anonymous Coward]

thats not how it works.

ubuntu software runs on the windows that pcs run on and so you need to remove the ubuntu layer to get to the normal windows again.

when you uninstall ubuntu it puts the desktop colours back to the normal windows ones so you can run your programs again. though you need to reinstall some programs still.

if windows was not also installed there is no way to run ubuntu as you still need to move the mouse.

What OS for PostgreSQL?

[Anonymous Coward]

According to those benchmarks FreeBSD with ZFS would be the best bet?

Re:What OS for PostgreSQL?

[uassholes]

I got the impression that file writes and reads were better with Solaris.

In your face Ballmer!

[PinkyDead]

Sorry, I got a bit carried away there. Eh, what was the article about again?

Re:MACOSX WILL WIN

[Anonymous Coward]

From my personal, and non-scientific experience, I've found OpenSolaris to have more 'default' weight than Ubuntu.

Re:Ubuntu may be fast...

[Waffle Iron]

Forget uninstall. Is there even yet a way to *install* Windows without trashing the MBR w.r.t other OSes? If not, I say Windows is not ready for the desktop.

Just wat I was looking for: Java performance

[InterBigs]

This couldn't come at a better time. I was recently wondering if FreeBSD was a good platform for deploying our first Java EE application (since we use fbsd for everything else) or that Linux or Solaris might be better. It's good to see that FreeBSD isn't all that bad, but I know now that switching to (Open)Solaris might be worth it. But as far as I see, OpenSolaris is mainly geared towards desktop use, isn't it?

Re:Just wat I was looking for: Java performance

[ToasterMonkey]

OpenSolaris is no more "mainly geared" towards desktops than your typical Linux distro.

From what you just said though... stick with what you've got, because I'm afraid you'd be switching OS's for reasons you really don't understand. Nothing you've read here on Slashdot today is worth basing an OS/platform decision on, there are many, many other things to consider.

Solaris Requires tuning

[Anonymous Coward]

I have not played with Open Solaris but with normal Solaris you need to set parameters in the /etc/system file to get good performance. By default Solaris is set very conservative. In many tests I have run Solaris may not be the fastest with single test but under a heavy load with many applications running my experience has been it can handle a much bigger load then Linux on the same hardware. I use both but for backend heavy loaded servers I would choose Solaris.

Re:Solaris Requires tuning

[RiotingPacifist]

I have not played with Open solaris but ubuntu was running on ext2 with linux if you want performance you need to pick an alternative file system (i find reiserfs to be good but support for it seams dwindling and answers such as use a supported fs (despite reiserfs being supported) are not uncommon), anyway my point is that these tests are pointless!

Re:Solaris Requires tuning

[TheLink]

Trouble is reiserfs suffers from vendor lock-in ;).

Re:Solaris Requires tuning

[kindbud]

I have not played with Open Solaris but with normal Solaris you need to set parameters in the /etc/system file to get good performance.

Solaris 10 deprecates almost every setting you are used to putting in /etc/system. Most of the no longer have any effect. Instead, you create resource controls in the global zone using the zone management tools (or editing the files by hand). The new method allows you to adjust any tunable without having to reboot the kernel.

Re:Ubuntu may be fast...

[X0563511]

Grub needs it's stage files and config file. Lilo however, lives entirely in MBR.

Re:Ubuntu may be fast...

[indi0144]

Wrong. You can always put the Win installer disk and choose to restore the MBR F2 or F6 (not sure) on the start up menu.

Phoronix Test Suite

[fialar]

Does anyone know if the Phoronix Test Suite will work under OpenBSD and NetBSD too? Says on the website: "Runs On Linux, OpenSolaris, Mac OS X, & FreeBSD Operating Systems"

I'm curious as to how the other BSDs would perform.

Re:Phoronix Test Suite

[kwabbles]

I know it will work on OpenBSD - I don't see why it wouldn't work on NetBSD as well.

Moronic comparison

[Anonymous Coward]

It seems a bit lop sided and ridiculous to compare Ubuntu 8.10
a released distro against 2 BETA distributions.
Ubuntu release runs faster than 2 other unixes that are still in debug and haven't been released yet.
Who'd have thunk it?

Re:Ubuntu may be fast...

[TheRaven64]

Exactly. The system is unbootable. You need to add a bootable device (e.g. the Windows install disk) in order to boot it.

They should include Vista

[Billly Gates]

I am curious to how it actually performs and not just what most the slashdotters say.

It may actually suck and I am curious as to how much.

I am contemplating leaving vista where I do php, apache, and java development. I wonder if there is an advantage at all.

Re:Ubuntu may be fast...

[stinerman]

To be fair, if you decided to use NTLDR instead of GRUB and you delete your Windows partition, the system is rendered unbootable as well. So in this instance, Ubuntu is no worse (or better) than Windows.

FreeBSD does do an excellent job by making the bootloader small enough to fit in the MBR.

Mostly pointless

[klapaucjusz]

Except for Bonnie++, all of their benchmarks are compute-bound. In other words, they're benchmarking the bundled compiler, not the distribution.

The one exception is Bonnie++, on page 6, which measures raw filesystem performance... and is something that is known to greatly depend on how old and how full a given filesystem is.

Re:Mostly pointless

[TheRaven64]

Not to mention which filesystem you use. With Solaris, you have a choice between UFS and ZFS, with very different performance characteristics. With FreeBSD, you have ZFS or UFS with a load of options (GEOM-level journalling, soft updates, and so on). With Linux you have four or five choices of filesystem which make sense for desktop use. Each of these has advantages and disadvantages - some have more features, some have better performance at random writes, and so on. With Linux, as I recall, you get a noticeable (if you're benchmarking, not so much in normal use) difference in performance depending on whether you enable extended attributes (needed for ACLs) on a filesystem.

Re:Mostly pointless

[Khashishi]

That's the problem with all operating system benchmarks. You are essentially benchmarking the computer, not the OS. What really matters for an OS is how usable and efficient it is for getting things done. This means, of course, that the kernel is mostly irrelevant. The shell is what will influence how efficient a user can use it.

Re:Mostly pointless

[stor]

> The one exception is Bonnie++, on page 6, which measures raw filesystem performance... and is something that is known to greatly depend on how old and how full a given filesystem is.

The type of I/O scheduler you use, combined with the type of RAID controller can make a significant difference to bonnie++ results/ IO performance too. For certain RAID controllers and workloads, using the NULL or deadline scheduler can increase performance significantly over CFQ or AS.

-Stor

ULE

[Anonymous Coward]

What's the default scheduler in the 7.1 beta? Most sites say that ULE will be default in the 7.1 release, does this mean beta as well?

Re:ULE

[Just Some Guy]

ULE has been the default in 7-STABLE for quite a few months now.

Re:ULE

[TheRaven64]

Yup, ULE 3 has been default for 7-STABLE for a while (and the first thing I've done since 6.1 was recompile a new kernel with ULE instead of 4BSD). ULE has matured a lot since the 5.x days, and now scales very nicely as well as managing to give very low latency to I/O-bound processes without harming throughput for compute-bound ones. ULE 2 was, as I recall, almost a complete rewrite after the original developer vanished, and ULE 3 is now outperforming 4BSD on pretty much all workloads (ULE always has on desktop workloads).

Re:ULE

[Chreo]

No ULE in 7.1 is not a complete rewrite. It was written by Jeff Robertson and he did not vanish, he just took a break. He also fixed some issues that was present in ULE before 7 branched and prevented it from being the default scheduler. It, AFAIK, still use the same basic ideas, which sofar in my opinion is the best scheduler for any OSS-desktop with unmatched interactivity. It is, in the current incarnation, rock solid

Re:Ubuntu may be fast...

[Anonymous Coward]

If you install Ubuntu, I believe it installs grub and points the MBR at stuff on your /boot partition. If you destroy this, you will not be able to boot any OS.

Are you saying that the OS that you install after you give up on Ubuntu, won't be able to write to the MBR?

Re:Ubuntu may be fast...

[pxc]

By default, I believe Ubuntu creates a separate /boot partition. You can free up the 20GB or whatever you're using for Ubuntu by deleting the Ubuntu partition (and the swap partition, if it creates one) and just leaving the /boot partition behind. That partition doesn't have to be very big to hold your kernels and your grub installation; you won't miss the 100MB space at the beginning of your partition table.

Why ubuntu?

[Anonymous Coward]

Why do they even bother comparing ubuntu with freebsd when freebsd is obviously much faster then ubuntu

Yes, but they should have used 32-bit kernels

[Anonymous Coward]

I agree. But the test is a bit of a WTF.

They are using 64-bit kernels when they only have 4 GB of RAM. It would have been far more interesting to use 32-bit kernels instead.

One loses performance when one goes to 64-bits, not gains it. One should only use a 64-bit kernel when one has more than 4 GB of RAM, and actually USES it.

Otherwise, just stick to 32-bits.

If they had done that comparison, my suspicion is that FreeBSD would've done even better.

Re:Yes, but they should have used 32-bit kernels

[Just Some Guy]

One loses performance when one goes to 64-bits, not gains it.

That's the first time I've ever heard that claim. Evidence?

One should only use a 64-bit kernel when one has more than 4 GB of RAM, and actually USES it.

On when one wants to do a lot of math. Or use ZFS (on FreeBSD). Or let the compiler use lots of registers.

Re:Yes, but they should have used 32-bit kernels

[Anonymous Coward]

64-bit vs 32-bit pointers uses up more memory. This means that the caches hold less data (big impact) and bus performance decreases. On the positive side, there are additional registers in x86-64 that can help performance. Overall, its a wash but seems to generally favor 32-bit due to better caching.

Re:Yes, but they should have used 32-bit kernels

[Just Some Guy]

That's wholly dependent upon a given data set. For instance, if you're working with a linked list of chars, then the overhead will be substantial. If you're mainly dealing with pointers to decoded bitmaps, then the extra 4 address bytes won't really matter.

Re:Yes, but they should have used 32-bit kernels

[Anonymous Coward]

"That's the first time I've ever heard that claim. Evidence?"

Various benchmarks over the years. I first came across it while doing Sun's 64-bit port. People then were noticing the difference, and it wasn't in favor of 64-bit being faster. In part for the reasons another person already noted.

This has been known for over 10 years now and is pretty much ancient news.

Re:Yes, but they should have used 32-bit kernels

[setagllib]

If you're doing any math on 64 bit integers, suddenly 64 bit mode is orders of magnitude faster because it's not hacking together the results from individual 32-bit operations. This can make a substantial difference for some applications, and a great case study is AES.

Re:Yes, but they should have used 32-bit kernels

[Anonymous Coward]

Yes, which is why it can be a wash as stated. But given no change 60% and better caching 40%, its an overall improvement at 32-bits. Other tasks are registry starved, etc leading to 64-bit showing strong gains. This is why I didn't state a hard fact by saying one was better, just that 32-bit tended to be better overall in the average cases.

Also, in this case, FreeBSD is heavily optimized on 32-bit and much less so at 64-bit. There are a number of factors that discredit the benchmark from being worth using to gauge the performance of any of the operating systems tested in a normal production environment. So the OP's point of using a 32-bit kernel is quite valid.

Re:Yes, but they should have used 32-bit kernels

[TheRaven64]

Nonsense. x86 has had 64-bit arithmetic support since the Pentium. Implementations have 64-bit ALUs which work on pairs of 32-bit registers. The issue is not 'hacking together the results from individual 32-bit operations' it is that it effectively halves the number of registers you have. With 64-bit values, on x86-32, you need two GPRs from your set of eight for each value. With x86-64, you need one GPR from your set of 16 for each value, effectively quadrupling the number of GPRs you can use (the x86-64 instructions also require less register-shuffling).

Note that this only applies to integer arithmetic.

Re:Ubuntu may be fast...

[jgtg32a]

It doesn't as of Hardy

They all require tuning (duh)

[Xtifr]

All three come with tunable performance parameters. All three can have their performance boosted even further by recompiling everything optimized for the particular hardware being used, possibly using specialized compilers (e.g. from Sun or Intel). But that's not the point, IMO. This isn't (or shouldn't be) a pissing match--this should be an opportunity to improve all three systems by seeing where their strengths and weaknesses are, and working to bolster their weaknesses and improve their strengths.

In my experience, these sorts of tests on free/libre/open-source systems quickly become out-of-date because the developers take them as a challenge, and that's a good thing for everyone! :)

Ff your tests were more than a couple of years ago, they're probably so out-of-date as to be utterly meaningless, but that's a separate issue. Personally, I'm a big fan of all three systems and want to see all three thrive and grow and improve. This kind of testing can only help with that, once you get past all the dick-waving by narrow-minded advocates.

It's pretty sad

[MikeRT]

That someone would actually be modded down because they happen to think that Linux isn't all that as a desktop. That sort of thing is why I think that any moderation system that allows users to mod down rather than only up is broken.

BSD is okay, but OS X is far far better

[Anonymous Coward]

I like BSD better than Lin-SUCKS, but OS X is still far and away the best platform for computing. It is faster, more stable, more secure and better designed than anything else available. PERIOD.

Re:Ubuntu may be fast...

[Sancho]

the windows boot loader will not recognize a linux install

My notebook, which has Windows XP and Ubuntu Linux, and which uses the Windows bootloader to boot the Linux partition, disagrees with you.

Rebuttal

[Anonymous Coward]

That sort of thing is why I think that any moderation system that allows users to mod down rather than only up is broken.

Nigger?
Nigger. Nigger Nigger!

Get me some popcorn.

See? A use for downmodding.

Re:Ubuntu may be fast...

[norminator]

Or Intrepid. Not that it's hard to do, but someone who doesn't know anything about partitioning will just use the automatic partitioning, so they won't get a separate /boot partition.

Don't forget...

[Anonymous Coward]

...to pay your $699 licensing fee you cock smoking teabaggers!

Re:Ubuntu may be fast...

[vadim_t]

That's an advantage, but not the main reason.

The main reason for /boot is that some ancient BIOSes can't read past 1024 (IIRC) cylinders. So placing files used by the bootloader at the end of a 500GB disk wouldn't work, even if Linux could handle the disk fine once it booted.

The other reason is that people keep coming up with fancy filesystems, and it's difficult for the bootloader to support every FS with each possible option. For instance, when ReiserFS was new, GRUB couldn't deal correctly with tail packing. Having /boot on say, ext3, or reiserfs without packing solved that issue. This way, you don't have to worry about your bootloader not being able to read from btrfs, or getting confused by extents in ext4.

Note that this last part applies to GRUB specifically, since LILO doesn't really understand the filesystem. But LILO runs into another issue: Since it doesn't know the FS and follows the offsets that were determined when it was installed, it can't possibly deal with something like a filesystem that defragments itself.

Hmm

[Anonymous Coward]

Pretty piss poor article. FreeBSD betas are built with debugging enabled, so performance is not indicative of what the final release will be like.

Re:Ubuntu may be fast...

[McGiraf]

euh.... nah, forget it.

Re:Ubuntu may be fast...

[origin2k]

Indeed, I use http://www.winimage.com/bootpart.htm to setup booting linux from windows.

Kernel Architecture would offer same prediction

[TheNetAvenger]

If you take a look at the OS kernel models and would form base predictions from the kernel architecture alone it would closely mimic the results of the tests.

There is a reason kernel architecture is a highly engineered science, and why even old models of inherent pluses or negatives would still manifest even in today's latest incarnations of these kernel architecture models.

If you look at Linux, with its microkernel heritage, it is going to offer better low level kernel multitasking and kernel messaging. Also if you look at a classic monolithic kernel design (even with Apple duct tape) the OS X kernel is going to be better at straight non-conflictive messaging and queues at the kernel level with a lighter API, but have a harder time moving past the multi-threading bottlenecks.

This is also why OS X being tied to 'specific' hardware is a plus for OS X, because if it had to deal with more diverse hardware and kernel level exceptions it would be even harder to squeeze performance out of the system and not run into multi-threading bottlenecks from the MACH kernel with the BSD API interface.

The reason I am stating (in generic terms) the obvious, is that the kernel models in use in all these OSes are very DATED concepts. In fact, every kernel architecture compared in these tests and OS X where deemed to be too primative for even the MS NT team back in 1990, which gave rise to the NT kernel which is neither a microkernel nor monolithic in nature, and why MS to this day, with even as 'bloated' as Windows is seen in the technical world, can use the NT architecture to shove around some suprising numbers not only in the consumer desktop markets, but even now in the supercomputer markets, all using the same code.

So with this in mind, it isn't a NT is great speech, but food for thought that the OSS world still needs to rethink its heritage, use Virtual Machine concepts and rally around a new set of kernel architectures that can shove NT into the ground.

Until this happens, these 'old' kernel models and architectures are going to trail NT just based on something as simple as the basic kernel theory and architecture that MS chose to use and abandon the 'in use' kernel concepts of 1990 and instead build NT around kernel technologies that were nothing but a group of theories at the time.

And there is no reason that almost 20 years later the OSS world cannot do the same and give up the primatvie kernel architectures it has been rehashing and slapping bandaids on to move forward and remain competitive.

Yes there have been some really good work on the existing technologies and bringing some 'new' ideas back to these dated concepts (even Apple has done well with putting bandaids on the monolithic nature of BSD/MACH), but why continue to work backwards and keep 'repairing or patching' technologies to move them to new hardware and instead rally behind a set of new kernel designs that are just now mainly theory.

If MS could do this 20 years ago and even choose to NOT use a *nix model as well (they owned XENIX remember), there is no reason the OSS community cannot dig deeper and start from scratch as well and VM existing OS models on the new kernel technologies.

Re:Kernel Architecture would offer same prediction

[styrotech]

If you look at Linux, with its microkernel heritage...
....Also if you look at a classic monolithic kernel design (even with Apple duct tape) the OS X kernel....
...even Apple has done well with putting bandaids on the monolithic nature of BSD/MACH...

Linux is a microkernel? Mach is monolithic? Since when?

...In fact, every kernel architecture compared in these tests and OS X where deemed to be too primative for even the MS NT team back in 1990...
...and architecture that MS chose to use and abandon the 'in use' kernel concepts of 1990 and instead build NT around kernel technologies that were nothing but a group of theories at the time.

As for NT being a completely new design, it started off as a pretty standard microkernel with an awful lot of its design inspired by (some cynics might even say copied from) VMS and RSX-11 which are roughly the same vintage as Unix, and NT later became more of a hybrid incorporating some monolithic aspects for performance reasons. NT wasn't anywhere near as new or theoretical as you make it sound, it was based on tried and true ideas which is just as well for MS.

Re:Kernel Architecture would offer same prediction

[TheNetAvenger]

Linux is a microkernel? Mach is monolithic? Since when?

Should read, "Linux with its non-microkernel heritage"

The point was that Linux has no traditional microkernel alignment in contrast with OS X that keeps the traditions of a microkernel that when paired with a monolithic BSD interface kills a lot of the concept of what the MACH kernel was intended to do.

Originally MACH was a microkernel concept, but in its current incarnations, like OpenBSD, OS X, etc, it is no longer a microkernel by any set of definitions other than being another abstraction layer for the upper level kernel API sets.

MACH when paired with BSD, a monolithic kernel API you lose a lot of the direct hardware one request concept of a microkernel, especially on today's architectures.

Linux was true to itself in that it never attempted to abstract hardware and instead set its own rules for what was expected of the hardware, and when running on hardware that cannot meet the needs, the functionality that Linux requires must be simulated on that hardware.

So you have Linux that will outperform OS X because of its all in one nature that doesn't have to cross call API layers for kernel processes. On the other hand you have a BSD/MACH concepts like OS X that can do well for hard crunching simple tasks that funnel all the way to the MACH kernel, but when it gets to handling multiple requests, process communication gets sticky and multi-tasking can kill the once low level elegant level of performance offered.

NT has neither of these pitfalls. It has a very fast process creation system, a low level HAL, and multi-layered kernel API sets. Not only do you get the near speed of a microkernel, but you also get the robust API sets that STILL reside in true kernel layers.

On Windows this is taken to such an extreme that even Win32, which is an OS subsystem running on NT, has its own kernel32, that is technically a 'kernel' level API, yet sits all the way up in an agnostic subsystem.

There is a reason the kernel designer of MACH let it go and moved on to Microsoft and has put their knowledge and work behind NT, because they believe in the architecture, even over their own creation.

As for NT being a copy or rip off of VMS, there is some truth that the knowledge from the VMS team didn't forget what they learned when they went to Micrsoft, but also remember, they were wanting to replace VMS when at DEC even and much of their concepts where thrown by corporate politics, preventing any massive innovation to the platform that they seriously wanted to explore. This is what moved so many to go to MS so they could make the next generation OS.

NT wasn't just a overnight bastard creation, it was the best and brightest from MS and VMS and even the UNIX developers of the time...

Cutler is brilliant, but in today's kernel world, even he admits he is getting dated. (Even Windows 7 moved in a few new people to optimize in different directions reworking old standard Cutler level code in the kernel.)

So if we can say, what Culter's team did in the 1990s was more revolutionary than evolutionary, as NT really doesn't conform to VMS concepts, especially theoretical kernel concepts, then why can't we ask the OSS world today to revisit kernel architecture on a larger scale?

Instead I see articles flying around about BSD vs Linux and Linus writing about why monolithic kernel designs will alwasy be better and other experts debating that moving back to an more inclusive microkernel with modern hardware in mind would be better.

Where are the movers in the OSS word that are outside this box and why isn't the actively working on even a basic hybrid kernel technology of its own that with what kernel engineers know today will leapfrog kernel design?

Instead the big work you see on actual new kernel concepts are yet again coming from places like Microsoft Research where they are playing with singularity and other kernel concepts that range from managed code kernel designs to even frankenstei

Re:Kernel Architecture would offer same prediction

[styrotech]

Just another correction:
OpenBSD has nothing to do with Mach or microkernels in general (were you thinking of DragonFly? That has a hybrid kernel). The OpenBSD kernel is about as monolithic as they come these days (it doesn't even really have modules), and descended from NetBSD which descended from the original BSD source code after the famous lawsuit was settled.

You will never see revolutionary kernel designs come from established open source projects. They have enough on their plate as it is. Open source is about releasing frequent evolutionary improvements. Without frequent releases it is very difficult to maintain momentum and attract more users/developers. There just isn't any widespread itch to scratch with revolutionary new kernel designs.

There always have been small breakaway groups or fresh projects that try out revolutionary ideas, but they have an uphill battle getting those ideas into the mainstream and turning them into useable working 'products'. The Hurd was probably full of revolutionary ideas when it first started, but look how far that has got after all these years. Hell even Linux probably required some help from the uncertainty surrounding the BSD lawsuit holding back BSD to get past that growth threshold. I doubt it would've taken off at all if it had been a radical new kernel either - it would've made it harder to attract developers.

And frankly, the rest of the world just doesn't care whether an OS has a revolutionary or evolutionary kernel. Also I disagree about how revolutionary the Windows kernel is, it is still just evolving IMO. Sure that evolution might be faster because it has more resources available.

PS: what made you think adhoc wireless networks were something new in Linux?

Re:Kernel Architecture would offer same prediction

[TheNetAvenger]

Just another correction:

Everything is not just Wiki definitions, even OpenBSD is more complex in 'trying' to define it in general terms as we are trying to keep this dicussion. If you want to get technical, we can write out some information and you can use it to append the Wiki pages properly.

Monolithic and microkernel are very vague general terms used to describe two aspects of current kernel design, and even the use of 'hybrid' kernel if you read from Wiki is very bad, as it will even call OS X a hybrid kernel because of the duct tape Apple added to improve multiprocesses handling, but this really does not make it a hybrid kernel.

Ok, so enough with the base line Wiki level of understanding?

You will never see revolutionary kernel designs come from established open source projects. They have enough on their plate as it is. Open source is about releasing frequent evolutionary improvements.

Why? Why do you believe this 'belief' system of what OSS should be to be true?

So OSS should just limit to working with existing technologies, really? Again why?

If the concept of OSS is combine resources and minds and push forward, why can't the sins of the past also be considered?

Do you think Linus set out to create a status quo OS, or want to try something different? If he would of had your mindset, it still would be a version of Minux. Although it jumped back to standard kernel concepts for Linux, at least it was a new direction.

Just as you define Windows as more evolutionary once again, you are missing a bigger picture. NT was not evolutionary, and people in the OS theory and engineering world will step up to recognize even if they don't like Microsoft. NT's kernel design was mix of many current and theory based ideas, and yet has no true fathers. There was nothing out there that worked like NT, and to this day it STILL is in a league of its own with no mainstream kernel technologies even close to challenging it.

The problem with this is that MS has a strong dynamic kernel technology that can STILL do many things other technologies cannot, and they will be able to further tap these abilities to keep leaping over anything thrown at them.

Think of even this simple aspect of the NT kernel, it has a client/server kernel nature (yes terms that are not hybrid, micro, or monolithic). With its layered client server nature, it already inherently runs a full BSD subsystem OS, that is a 'technical' equal to Win32 or Win64. This demonstrates that Microsoft can use NT, give a BSD access to the massive Windows driver database and if they want do even more.

So not only do you have an OS that is upper level agnostic and can support upper level kernel OS technologies like BSD or Win32, but now with the new VM abilities introduced in Windows Server 2008, it can leverage both hardware virtualization along with an agnostic kernel. So they could drop a FULL and REAL OS X subsystem (let users install OS X themselves), a Linux subsystem, and still run these on the NT kernel and when needed leverage the VM abilities to give the subsystem level OSes hardware level performance that in theory could be faster than native Linux or OS X.

The only reason this isn't done with Windows NT is that Microsoft saw what promoting other OSes did for OS/2 and is doing for OS X with boot camp.

However if Microsoft ever starts to lose the development or desktop front, they could move to being the best Linux or best OS X 'base' if they chose to do so, and bring along either a multi-front OS concept or even lock in and optimize for any OS variant while still keeping the NT driver model, making the distribution eclipse everything else out there with hardware support that is unheard of in the OSS and *nix world.

So even if OSS brings about major innovation to existing technologies, there is nothing preventing MS from using it, just as Apple used MACH/BSD with little return to OSS.

It kills me that people so underestimate Microsoft in this regard and are

Re:Ubuntu may be fast...

[Anonymous Coward]

You can boot just fine from a grub terminal, all you have to do is enter manually the information that would normally be found in grub.conf. Of course, you would need a kernel, which would usually be in /boot..

8 core CPU?

[VincenzoRomano]

Is not exactly what I'd say "average nix user hardware".
I bet that less than 5% of NIX users have that kind of machine on their desktops.
Why not running the test on either a "normal" desktop or even better on a laptop?
And, by the way, Opensolaris 2008.11 is still a release candidate!

For me, the real problem is applications

[walterbyrd]

I installed OpenSolaris on my laptop about one week ago.

Laptop: 1.7mhz celeron, 512mb ram.
Previous OS: Xubuntu.
IMO: OpenSolaris loses by a mile.

OpenSolaris installation was easy, but very slow. It hangs at 99% for hours. This is a well know bug. OpenSolaris was noticeably slower than xubuntu. Bootup and shutdown are especially slow. The worst problem is applications, I can not find a chm reader, or mp3 player that works - on xubuntu (or any linux) this is a cinch. The applications that come with OpenSolaris are old, for example firefox 2.0. After installation, I had additional configuration to get OpenSolaris on the internet, usually linux does not require such additional configuration. I find package management in solaris to be much difficult than with any debian based, or redhat based, linux. HW detection was not a problem for me with either linux, or opensolaris.

I installed OpenSolaris for the learning experience, so I am getting that. Although it may just be a personal preference, I dislike the whole Solaris way of doing anything. Ironically, the Linux CLI, directory hierarchy, and configuration files, are a lot closer to generic UNIX than Solaris - especially Solaris 10. It might be easier for me to learn solaris, if I didn't already know some unix and linux. These days, solaris is practically it's own OS, as opposed to a version of UNIX.

All JMHO, of course.

Re:Ubuntu may be fast...

[Anne Thwacks]

Windows is not ready for the desktop.

Well given that it can't boot headless, it is sure as hell not ready for the server market!

Crock of shit.

[jvd]

I don't fucking get these benchmarks lately, I mean how credible is this crock of shit? You're benchmarking one STABLE system (Ubuntu) against an almost stable system (OpenSolaris) and against a Beta release (FreeBSD)... WOW that sure seems like a bad benchmark to me! In a typical benchmark, FreeBSD would've simply owned Ubuntu, and OpenSolaris for that matter! So, don't pay attention to these bullshit benchmarks, because they're worth shit, in my opinion. Puh-lease, bitch.

Flawed test methodology

[Anonymous Coward]

At the end of the day benchmarking default installs is fundamentally flawed. Who runs a default install in a production environment? Don't even get me started on benchmarking a Beta or RC build against a production release.

There was no clearly defined testing methodology, and I would have expected an objective test to include more test relating to network performance.
All operating systems perform differentially when tuned for specific tasks. (ignoring Windows)