Slashdot Mirror
Byte: FreeBSD vs Linux Revisited
Beerwolff writes: "This time I have remembered the link to the Byte article that's a follow-up to two of Moshe Bar's previous articles comparing FreeBSD and Linux--This time with the new Linux VM. His Apache "results show that Linux is better at handling I/O cache than FreeBSD, and that FreeBSD is more efficient at building up and tearing down processes."" As usual, please take benchmarks with a grain of salt, caveat emptor, look before you leap, and so forth.
"As usual, please take benchmarks with a grain of salt, caveat emptor, look before you leap, and so forth."
In particular, be sure to read the very bottom of the article:
Before you fire up your e-mail program to contest the results or suggest some neat trick to get even more out of either the Linux benchmark server or the FreeBSD server, remember what I said at the beginning of this review: This was not a scientific benchmark in a professional benchmarking lab. All results are only valid within my own environment and you are certainly bound to see a different result on your machines. The benchmark was only about finding out how well Linux handles stress loads compared to FreeBSD, and I do not claim that one OS is better than the other one.
These aren't scientific. These are the results one person sees - and also note that the various problems presented to the servers give different results. FreeBSD and Linux both had strengths and weaknesses even in his tests.
Regardsless of what some reviewer comes up with, I have just found that they each do something specific. For servers, I would run FreeBSD. All of the daemons are ported, and the security is great. For my desktop, it's linux all the way. I think this is comparing apples to oranges.
Um, this is my sig.
MAXUSERS was set to 20!!
Jeez, I won't even set it that low for my personal machine. For the purposes of this kind of benchmark, I would have at least started with 128. If you want to be fair in I/O benchmarks, have BOTH machines mount the filesystems asynch. If you're going to do a comparison, at least compare apples to apples. Softupdates rocks, but I still think async is going to be faster.
"To those who are overly cautious, everything is impossible. "
Personally I would use FreeBSD for a server for the sheer fact that I can never crash it. For desktop uses I would definantelly use linux.
But both of them being free in the same world will always complement each other. The only thing holding FreeBSD back from the desktop is a pretty installer ...
though this _might_ count as a desktop varient of FreeBSD ...
The latest releases of mandrake and redhat are full of wonderful packages and resources that make linux more than a prime candidate for the desktop.
But Linux and FreeBSD will ALWAYS complement each other ...
SuperDuG
Ignore the "p2p is theft" trolls, they're just uninformed
Tell one person using OpenBSD that they should use Linux instead because the I/O cache is faster, and they'll tell you to GFY. Likewise if you tell a desktop Redhat 7.2 user that FreeBSD is going to suit him better because of process creation statistics.
It's just another stupid OS jihad that doesn't matter. People should take a lesson from Linus when people ask him what he thinks of the "competition".
You know, everytime a topic on slashdot looks like a flamefest (*BSD v. Linux / Emacs v. Vi) everyone says something about the impending flamefest, and I have yet to see one....
Is my threshold too high?
Note that this is systems benchmark, not a VM one.
There are a lot more different things in the two
kernels, than the VM. And note, that the server was
SMP, an area where FreeBSD folks admit "Linux is a
year ahead". It may turn out in the end that
actually the FreeBSD VM performs better, making
able the Big Lock BSD kernel catch up with more
fine graned Linux .
-velco
Lies, damned lies, statistics
I run both (slack-8/2.4.14 and FBSD 4.4) on my workstation. I find FreeBSD way easier to manage and generally have better performance, more pleasant to administer.
Support of "important" hardware is about the same.
My USB printer and scanner function well in both, for example.
Support of more exotic hardware still is more problematic in FreeBSD: No 3D graphics on nvidia because nvidia's driver has not been ported to FBSD yet. My DVB-S (satellite card) is not supported in FBSD, in Linux I can use it to watch and digitally record programs. DV-video through Firewire doesn't work in FBSD. I don't know whether Linux does any better (I think so) because I switch to Windows to capture and process video.
For software (except 3D games as mentioned) FreeBSD has somewhat less native software, but almost everything (even including VMWare for Linux) runs extremely well under the Linux emulator, often even surpassing the speed when run natively under Linux (this is possible since technically it is not really emulation, but all Linux system calls have been added via a loadable kernel module).
Your argument makes no more sense than the following:
If journalling is so good, why has BSD not used the same approach?
Please karmawhore with your own material if you have to.
The FreeBSD kernel is able to run Linux binaries, once you have installed the Linux emulation port (it adds a kernel module that is able to work with Linux ABI binaries plus stores a couple of system libs compiled for Linux - so it is rather a different operation mode than an emulation).
Quake3 Arena for example works under FreeBSD just fine.
Where there is a problem is the support of acclerated graphics drivers. Where such a driver is open source, it has been ported to FreeBSD (Matrox drivers, the rather slow nvidia driver for XFree86 3.3.x series, ..).
Where there is only a binary driver, and most unfortunately, this is the case for the fast nvidia drivers, this has yielded no results yet.
The problem is that while the nvidia binary driver might work in theory on all x86 plattforms, with just a different kernel interfacing (for which the source exists), in reality it does only run with certain Linux kernels. Here is a report that goes into details.
Regards,
Marc