Category Archives: Computing

Hardware, software, computer science and the rest

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.

First test of the Mac Pro

Issue 18/2006 of the c’t magazine contains a quick test of the Mac Pro. The machine is faster than the old Quad Power Mac G5 (if running native software) but consumes only 223W instead of 340W at full load. It’s also very silent with only 1,0 sone unless the harddisk is used, probably another questionable Maxtor harddisk similar to the one in my Power Mac G5.

Its excellent performance, the low price (for such a machine) and the lack of noise make the Mac Pro a worthy challenger for highend workstations sold by companies like HP, IBM or Sun. Let’s hope they follow Apple’s lead and rid us of noisy fans.

PHP – Pretty Hopeless Programming language?

I’ve updated a package of the NetBSD package source collection today. The package contains a PHP application which surprisingly required a security fix. And I have committed a lot of security updates for PHP based packages to package source recently. And from what I read on the Heise Newsticker it looks like there have been a lot more vulnerabilities in PHP based web applications recently.

The amount of such security holes which are always caused by the same problems (uninitialized variables, cross-site scripting, etc.) make me wonder whether the design of the PHP language is flawed. Yes, there are also a lot of security holes in applications which were writtten in C or C++. But these programming languages are much more versatile and therefore used to solve much more complicated problems.

PHP however is an application language. It was designed to write web applications. And based on great PHP products like WordPress or phpMyAdmin it seems to do that job very well. But it seems that security was not a design goal when the language was created. E.g. being able to assign arbitrary values to variables via parameters embedded in the URL is a really bad idea. Even the ancient cgiparse program which was part of the W3C HTTP daemon distribution was clever enough to prefix all shell variable names to stop a remote client from overwriting important things like the PATH variable.

Perhaps it is time to redesign the PHP language. The new version should not try to be fully backwards compatible. It should instead remove all those features which have caused security problems in the past. That will of course require changing a lot of existing PHP code. But anything else will just result in more problems in the long term.