I've been a big fan of FreeBSD since I first acquired 4.4 on 4 CDs. By that point, I had already spent a lot of time in Linux, but I was always put off by its instability and inconsistency. Once I had FreeBSD installed, it felt like a dream. Everything worked the way it was supposed to, and the consistency of its design meant even older documentation would be mostly applicable without having to figure out how my system was different. There is a reason why in the early days of the Internet, a huge portion of servers ran FreeBSD.

But, that was a while ago. Since then, Linux has matured greatly and has garnered a lot of momentum, becoming the dominant Unix platform. FreeBSD certainly hasn't stood still, however. The FreeBSD team has kept current with hardware support, new features, and a modern, performant design.

The biggest "stability" or "workload" issue we've come across comparing our FreeBSD systems to our Debian Linux systems: if a process spins out-of-control on Linux, spiking load averages over 20, there's nothing you can do but power-cycle the box. On FreeBSD, you can still SSH in, kill the process, and carry on.

We run into this 2-3 times a month. For some reason we haven't been able to track down yet, BIND9 will peg the CPU at 100% and we're unable to login to the Linux box over the network. Have to phone the school and ask someone to power-cycle the box.

On the FreeBSD systems (ZFS storage boxes), even when I do stupid things that run it out of RAM or CPU spikes or I deadlock the storage pool, I can still login via SSH and fix things.

This is a common occurrence on various mailing lists/forums I'm on as well. Once a process spins out of control on Linux, you're locked out; a similar situation on FreeBSD is usually fixable.

Interestingly enough in our organization we've had the opposite issue.

Some FreeBSD boxes have processes that die every now and then (ldap,sshd. etc and even bind) rendering them inaccessible from the network. Someone with console access can restart those services no problem, and things get back to normal. Whereas linux boxes (workstations mainly) tend to be accessible through the network,even when their console is locked up by some nasty process.

Logging in to or even using Linux systems with ridiculous load averages is a problem that got solved with "the patch that does wonders" included in 2.6.38.

I created a "fork-bomb" that created 200 instances of itself, all of them using all CPU time that are allowed to use. The load average moves asymptotically towards 200 and logging in/out of the system via SSH is more or less as fast as if the system was idle.