NetBSD: Designed to Fail
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.
Isn't the POINT of NetBSD that it supports all those architectures? Not everyone has a rack full of modern servers and runs a bunch of web servers. Some people do "oddball" things on "oddball" hardware. NetBSD is directed towards those folks.
ReplyDeleteI ran it on a student computing cluster at Caltech in the mid-90s, and sure, I wouldn't do that today. But when we did a research project involving designing a new MIPS-compatible processor, guess what? There comes NetBSD to the rescue. When I was experimenting with an old VAX.. NetBSD...
NetBSD is great for that kind of stuff and my guess is that the unpaid volunteers of NetBSD are also interested in precisely that kind of stuff. Not that strange after all, and certainly not useless!
But in your previous article you recommended
ReplyDeleteNetBSD as an alternative to OpenBSD?
Just as Anonymous #1 said, the point of NetBSD is to run on older hardware. Got 9-track tapes? NetBSD is perfectly at home with them. Have an old DEC Alpha-based box? No problem.
ReplyDeleteI recently used NetBSD to convert a bunch of QIC-02 tapes written in the mid 80s.
A lot of our modern history is still buried on old machines and media.
Heck, a lot of systems using NetBSD can't even display graphics.
Homo Baggins, that's the problem with people who are trolls. You can't tell when they are being serious and when they are being trolls. He says he has $100,000 dollars to donate to netbsd.
ReplyDelete