The Future of the NetBSD Project

Charles M. Hannum, a former NetBSD developer, sent out an e-mail earlier this week which resulted in various discussions e.g. on Slashot about the future of NetBSD. A fellow worker who had read the article even asked me straight whether the project is going to die.

My honest answer is that I don’t know. There are indeed problems within the NetBSD project but I guess that this is the case in most open source projects. So what are the particular problems of the NetBSD project? There are definitely technical shortcomings in NetBSD. Here is a list of things which come to my mind:

  1. No journaling filesystem
  2. Insufficient ACPI support
  3. Network or I/O intensive workloads don’t benefit from SMP
  4. Problems with thread support on SMP systems and various platforms
  5. X.org integration is not completed
  6. Insufficient support for i386 systems with more than 2GB of memory, no support for more than 3.5GB

Why did NetBSD fall behind?

Back in 1995 when I started to use NetBSD on PC hardware it was really the better operating system than Linux. While it had less hardware drivers it was much more robust. I’ve e.g. never experienced any serious problems with FFS on my server. If the machine was brought down ungracefully fsck always fixed the filesystem during the next reboot automatically. At work I spend hours to copy data of a corrupt Linux ext2 partition after our development server lost power. e2fsck was not able to repair the filesystem and the kernel simply hung if I tried to access one of the bad directories. And that required another hard reboot with more runs of e2fsck which still wasn’t able to repair that partition.

But after a few years the situation changed. Linux e.g. had SMP support long before NetBSD. I had bought a Dual Pentium 2 400 in 1999 hoping for SMP support in NetBSD but finally gave up waiting for it. I sold the hardware and bought a faster single CPU system instead. And over time Linux got more and more features which NetBSD hadn’t e.g. several journaling filesystem.

The reason that this happened is IMHO the resources available to both projects:

  1. Linus Torvalds himself has been able to work on the kernel fullfime for many years now.
  2. Commercial Linux distributions like RedHat and SuSE appeared on the market. They created more fulltime positions for people working on Linux or software for Linux.
  3. Companies like IBM or SGI started contributing code written by their developers.
  4. These days a lot of Linux kernels developers are employed by the Open Source Development Labs and can work on the project fulltime.

The NetBSD project unfortunately didn’t receive that much support. I’m only aware of one NetBSD company and they unfortunately keep most of their work private. And a lot of the people who were initially able to spend a lot of time working on NetBSD couldn’t do that any more: they now have fulltime jobs, wifes and children. New developers joined of course over the years but there was just not enough manpower to keep up with the competition. In some cases people also lost interest, especially in maintaining NetBSD support on old platforms. Running NetBSD on a machine which is a hundred times slower than your PC desktop is simply not much fun.

What other problems does the NetBSD project have?

Besides technical deficits there are also (the usual?) structural problems within the NetBSD project. The worst problem is probably the tendency to discuss problems to death instead of doing something about them. It doesn’t only waste a lot of time it also often hurts motivation badly. And there is of course also a history of unfortunate decisions or even more often the lack of any decision. But that definitely affects other open source projects, too (or Linux would have a builtin kernel debugger and be able to write crash dumps).

What will happen in the future?

I don’t know … of course. I’m still using NetBSD on my server and my firewall because it works fine for me. From time to time I’m tempted to switch to Linux. But having to deal with one of the existing Linux distributions at work usually cures that madness quickly. 😉

I’ll probably stay with the NetBSD project and contribute to it as long as I get something out of that commitment e.g. an operating system which I can use on my server. If I had to switch now I would probably give FreeBSD a try. Solaris 10 would also be a nice choice if I were convinced that Sun is still committed to it. But considering how many Solaris developers Sun has laid off in the last few years I’m not.

This entry was posted in NetBSD. Bookmark the permalink.

3 Responses to The Future of the NetBSD Project

  1. Mika says:

    Sun is really commited to Solaris. In fact, it is the only UNIX that is really innovative.

    You can also look at opensolaris.org. A lot of activity going on there…

  2. Yes, some parts of Solaris (e.g. D-Trace or ZFS) are really innovative. But other parts are ancient, badly designed, broken or all of the above. Just compare something very basic like the “/bin/sh” in Solaris with the shell provided by other operating system.

  3. David says:

    Hi! Really simple and clear analysis of the situation, thanks. I followed the Big Thread (Hannum’s) (and I’m quite disappointed by the fact that nothing has really happened apart from some losses (it was sad to read that jmmv isn’t going to use NetBSD anymore and so on…) and I finally read a comment different from e.g. “These problems don’t exist, NetBSD is perfectly well and alive, everything is a success, failed SoC projects are a success too [no, just kidding here!]”. Thank you for being an interesting voice in the community!

Comments are closed.