• Sometimes Linux is faster.
• Sometimes FreeBSD is faster.
• Usually the difference between the two is smaller than the difference between IA32 and x86-64.
• The tests were mostly either CPU- or I/O-bound, so there are lots of factors beyond the kernel that would affect the results.
• Debian kFreeBSD uses an old FreeBSD kernel, not sure how old the Linux kernel is but it's probably not representative of the speed of recent releases of either kernel.

Of course it's not everything - but it IS a major part. Cost is another. We're at a tie there.

So what's left? User friendliness? These systems use the same apps - tie there too.

We're basically left with security and stability. If you want to write and article on those feel free - I'm sure Linux won't fare too bad there, but I'd like to see the results.

Still though, to dismiss speed as a criteria is just being naive.

Where many is ~20% of them.

And why would that be surprising? 64 bit lets you address more memory and they did the tests in a machine with memory that 32 bits could address all of. 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.

Some programs aren't going to take advantage of 64 bit registers and so on, but are going to suffer from worse cache performance.

Stick 8 or 12 GB of RAM in and things might be different

What about a performance comparison with original FreeBSD?

On most architectures, 64-bit code is slower. Pointers are bigger, which means you need more memory bandwidth to load them and you use more cache holding them. On x86-64, the situation is confused by the fact that 64-bit means 'using Long mode,' as well as 'using 64-bit pointers'.

Long mode gives you 64-bit registers (so you can store 64-bit values in a single register, rather than spread across two, doubling the number of 64-bit values you can store in registers), more registers, and a few other benefits like removing the 'must use EAX as the target' restriction on a lot of instructions (reducing the number of register-register moves, and decreasing instruction cache usage as a side effect). 64-bit pointers use more memory bandwidth and data cache.

For best performance on x86-64, you want pointers to remain 32 bits, but still run in Long mode. The OS should make sure that everything is mapped below the 4GB line for the process. As far as I am aware, no operating systems actually support this mode of operation. Without that, for any process using less than 4GB of address space, you have some advantages and some disadvantages when running in 64-bit mode. Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.

> Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems.

I am glad I am using 64 bits CPUs to run my 32 bits OSes then ;-)

Well unless somehow, the "twice as much" doesn't get used with 32 bits OSes running...

What do you think ?

In theory, perhaps.

On that web page I see this: "The ports and doc trees use tags whose names begin with RELEASE tags." Excuse me, WTF? You're only going to tell me how the name begins and leave me to guess the end?

Can I go back 15 years? Can I do this for versions 1, 2, or 3?

What about all the stuff it drags in? Is the old source code actually there, or just the build system?

I sure hope that a CVS checkout isn't going to drag a bunch of old history with it. Gigabytes would be unfriendly.

I can go to Red Hat or Debian's site and just download the packages I want, either binary or source. Why does FreeBSD makes things so unusable?

If they're I/O bound, userspace and kernelspace are both waiting for the drive. The layout of the files on disk will have more of an impact than the kernel. You are right that things should be CPU-bound, I should clarify that I meant userspace CPU bound. You want to benchmark things that are systemcall-heavy, like concurrent apps that use lots of synchronisation primitives.

FreeBSD development follows three branches. -CURRENT is where all of the latest stuff is. -STABLE is where stuff that has been tested a bit in -CURRENT goes. -RELEASE branches are where only bug fixes (no new features) go. The 8.x series began development as 8-CURRENT shortly after 7.0 was released (about two years ago). Some features were then back-ported to the 7-STABLE branch, but only those that could be moved without invasive changes that might affect system stability.

8-RELEASE is the latest stable release and has had two years worth of new features on top of the one shipped with Debian, including, among other things:

• Improvements to processor affinity and scalability in the scheduler.
• A completely new USB stack.
• A newer version of ZFS.
• Improvements to the sound subsystem (now contains a full OSS 4 implementation, per-vchan volume control, a massively improved mixing algorithm, and other improvements)
• A new NFS implementation, including NFSv4 support.
• Network stack virtualisation for jails.

It's not a matter of last minute changes, it's a matter of not getting the last two years of improvements. I know that Debian likes the stable-and-tested versions of things, but they don't seem to apply that policy to the Linux kernel.

I can see a really good usage case for this.

You're a sysadmin, and you're running Debian almost exclusively. You have a large number of automation scripts that you use to do your job (security updates, auditing, provisioning, general maintenance, etc). All of them are expecting to run on Debian, because all you run is Debian. So you, as a sysadmin, decide you want to use ZFS somewhere.

You have a few options:

1) Run Solaris
2) Run some derivative of BSD (FreeBSD, OpenBSD, NetBSD, etc)
3) Run Debian w/ ZFS in Fuse
4) Run Debian kFreeBSD

Options 1 and 2 will most likely require you to tweak or rewrite a lot of your scripts. I shouldn't need to explain why option 3 is a bad idea. Since you're working with Debian userland, going with option 4 seems like it would be the path of least resistance. Seems pretty useful.

I'm a Linux fan, but there's a first. A linux user complaining that he needs to tweak the OS to get the most out of it!

Here's a tip, ALL OS's require tweaking to get the most out of them.

Never did I suggest that I was running a random server exposed to the Internet. The box could be running some lab equipment that costs millions of dollars to replace, using a proprietary control program that won't run on a more modern OS. The box could be running a legacy app, with a modern system controlling things over a serial line. Shit happens.

The fact that an unsupported OS suffers bit rot is disgusting. The bits should just sit there forever, as they do for every Linux distribution except Gentoo.

I will never voluntarily put myself or my future successor in such a terrible position. Software needs to be available forever.

No excuses!!!