Category Archives: NetBSD

My view on the NetBSD operating system

NetBSD meeting in Cambridge

Yesterday we managed to have the second NetBSD get-other in Cambridge in a pub called the Carltom Arms. Besides the usual suspects (NetBSD developers and users living in the area) Cherry Mathew showed up. He is currently visiting Cambridge and set the ball rolling by asking for NetBSD people in the area who are up for a beer.

Like the first meeting it was a nice and relaxed evening. We talked a lot about geek stuff like NetBSD (no surprise here), WLANs, ISPs and DSL routers of course. But because Gavan Fantom brought his lovely fiancรฉe we also covered a lot of non-technical topics like the quality of fish and chips in Cambridge or which country has the worst taxi drivers. ๐Ÿ™‚

I really enjoyed the meeting and it was good to experience some positve NetBSD spirit after the recent commotion.

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. 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.

NetBSD 4 branch created

Jeff Rizzo created the NetBSD 4 branch yesterday. It will result in the NetBSD 4.0 release in a few month from now. I’m personally not convinced that NetBSD-current was ready for this. There are e.g. compatibility problems between GCC 4.1.2 and GDB 5.3: you have to compile binaries with -gstabs or GDB won’t be able to load a core dump written by a program.

I however see Core’s point that branching now will probably help to stabilize things after a few weeks. But it will probably require a lot of pullup requests and therefore a lot of work by release engineering to get there. ๐Ÿ™

But maybe there is no better way to deal with such things in large Open Source projects.