While FreeBSD and Linux are hard to shake, I gave NetBSD a glance recently and found some serious problems that not only made me secure in my choice to stay with FreeBSD and Linux, but also compelled me to write this mini-review of NetBSD.
I'm a Unix guy and have been since the mid-Nineties, when Linux was taking off and BSD was shaking off its lawsuits. I currently use FreeBSD on our servers in our local library system and we have Linux desktops light end-use, and I use a highly-tweaked FreeBSD installation at home.
Every few years I feel I owe it to myself to do a high-level reevaluation of my unices of choice and see if the market hasn't shifted to produce something better for what I do so that our library can serve its users better.
For serious unix system administrators, FreeBSD has the best uptime, period. It has the longest average uptime for both personal and server usage, the longest uptime between urgent patches, and the least amount of kernel panics. It's also hard enough that it can handle the most amounts of data per system memory and per clock-cycle, and also happens to handle the data most efficiently against performance-per-watt.
When I went to check NetBSD's numbers, however, I found that it had the worst placements in these stats or, worse, no place at all—meaning that no one was using it for serving.
Digging deeper, I started looking at hardware support, specifically x64, multicore, and large memory installation support. And after checking NetBSD's hardware support page, it became clear why it was so absent on best-of benchmarks: NetBSD's hardware support is a mismanaged nightmare.
For instance, there are eight tier-I hardware platforms, meaning that each gets high-priority attention during development and testing. That means that ARM evaluation boards get the same amount of priority that high-end x64 servers and workstations do. Which, I don't think I have to point out, is complete nonsense.
There are only three platforms that deserve tier-I support, and those are x64, x86, and Xen, which is simply x64 and x86 for virtual platforms. ARM is anything but high-end and can't really support full operating systems or their services, and MIPS, POWER, and SPARC are all has-been serving platforms that have been dying for well over a decade.
Intel's x64 is it as far as serious computing goes nowadays and into the foreseeable future; x86 is important because of its installed user-base that's not likely to fade any time soon. Giving tier-I priority to anything else is sheer insanity, especially when you're dealing with a bunch of unpaid volunteers.
By contrast, there are 49 ports with tier-II status. While I would argue that five of the eight tier-I ports should be tier-II priority, having so many tier-II ports also belies a serious mismanagement of project priorities. All of them are obscure, and many of them are downright obsolete and ought to be made tier-III or just dropped entirely.
For example, the BeBox is a tier-II platform? Really? The BeBox ran dual 66 MHz PowerPC 603 chips, later upgraded to 133 MHz. At the time this was novel but fell short of being a big deal; 14 years later, it's at best a footnote. But not for NetBSD. It's tier-II support status! Man the decks! Compile the kernel! We've got to get this support for all 1,800 BeBoxes that were ever shipped! Go go go!
As a system admin whose time is valuable, I have no patience for NetBSD unless it gets serious about what's important. It's almost like NetBSD is designed for failure. And this isn't even touching on some of its other serious. For instance, NetBSD 6.1 is over a year late.
When Matt Thomas and company get their heads together, they might leave the world of hobbyists and people like me will adopt their toy-like operating system.
In the meantime, FreeBSD and Linux are it for me and my library's IT department and NetBSD is relegated to the scrap-heap. I urge other system administrators and end-users to, at best, try it out under virtualization. NetBSD just doesn't belong on anyone's serious hardware deployment right now. NetBSD is designed to fail.
