Just another reason to get rid of NetBSD…

After finally completing the task of cutting my network routing over to the DSL service fully, I am reminded yet again why I need to trash NetBSD and put something useful on my firewall.

The Good, The Bad & The Unixy

First up, I’d like to say that most of this article is tainted by the behaviour of one or two NetBSD people, not the majority. I haven’t dealt with the majority. Some of the jibes here are based on limited experience with the team, and shouldn’t be taken too seriously. Other opinions are based on raw fact — that some important bugs and issues just haven’t been resolved, even though others out there have raised them as issues.

So, lets get the major good points about NetBSD out of the way first, shall we:

• It’s stable, extremely stable, when finally coaxed into a working configuration
• It is very standards-based, and the developers mostly strictly adhere to them
• The source is tight, secure and well managed
• It’s very very portable. I believe it boasts the largest number of platforms it’ll run on (la de fucking da, I’ve always wanted to run a Unix box on a fucking Atari console)
• The source/binary management system, pkgsrc(man: no entry for pkgsrc in the manual.) is quite a work of art. This is an area to be very proud of; without using anything proprietary or different, they have an excellent system based around make(1)

Now, here’s a quick overview of what absolutely shits me about NetBSD:

• Doesn’t appear to be user-driven in fixes and feature additions (ie. “Ah well, there’s a serious panic bug in this piece of code, but none of us c00l BSD dev guys feel like fixing it cos we don’t use that bit, so we won’t”)
• The documentation is shitful. Really, really shitful. They should be embarassed. And the usual reply you’ll get from a NetBSD guy is, “well, if YOU don’t like it, fix it and submit a PR!” No, how about YOU guys fix it and document this supposed masterpiece you’ve created
• Their pages on searching for bugs and whatnot is way too verbose; I don’t care to wade through paragraphs to find the search link, give me a table or bullet points for links, geez

The NetBSD Mantra

“Well, if you don’t like it, fix it.” I mostly don’t have a problem with this (and have to a small extent done my part by submitting PRs and fixes when I can), but as a blanket rule? You have to be kidding. Sure, I’ll just hack networking code and fix a problem that your guys are too lazy to fix, or don’t deem important enough to fix, not. I’m capable of a few things, but knowing the NetBSD sources inside and out is not one of them, nor do I desire to know, and shouldn’t need to know.

Promote, Don’t Hide

NetBSD seems to be comfortable with the fact that theirs is one of the least-used variants of Unix out there. So be it. “Yeah well, we don’t WANT a big userbase.” Fine. Just another reason to use FreeBSD or even Linux, because at least they advocate large userbases through decent marketing, ergo more bugs get fixed, more features added, more “cutting edge.” Ever wondered why NetBSD and FreeBSD need Linux compatibility? Because the likes of Mozilla, previously Netscape, and other software/driver developers only bother doing Linux ports. And they only do that because of userbase demand.

My only guess is that they, quite fairly, don’t want the typical “hi guYz, eye juz g0t netbsd and 1nstall3d it an n0w my windoze dun work” type questions bouncing around, and that type of userbase. A small price to pay for a far broader audience and better-utilised OS.

I mean, they still use ICB to collaborate for fucks’ sake. “It does the job” they say, no doubt. Making a forum hard to find versus using modern chat systems, or security through obscurity, is more than a tad dubious. I finally discovered the server and channel they hang on and was quickly spoken-to by a Net guy over it. “How did you find it”, “Don’t go in there until you’re known, you’ll piss people off”, etc. I mean, c’mon.

Keep It Up To Date, ALL Of It

I’m not new to Unix. Far from it. I’ve used many variants of it for at least ten years. The fact that I have troubles finding the information I need and the methods that *BSD uses to do these things shows that it’s not just the weenie end-user that is a dumbshit and at fault; it shows that the project suffers from a lack of guidance. There is always the problem of great software having bad documentation — even more reason to make sure it is good, so as to fob off that nasty stereotype.

Why is Apache httpd the number 1 most used web server out there? Two very important reasons:

1. It’s a good, stable and well maintained and updated product
2. It has amazing, thorough, complete and accurately-updated documentation, using modern documentation formats and build techniques (ie. not living in the dark ages of *roff typesetting, but instead using 21st century methods like XML, and decent build systems like Apache’s Ant)

Yes NetBSD guys, sorry, not only does documentation matter, but so does keeping it up-to-date and accurate. We don’t all subscribe to kern-bugs and read through PRs and CVS updates every day to stay informed of minor little issues like how a good portion of the gre(4)/gif(4) code has been modified to render it useless according to “current” documentation. Oh, not meant to use gre(4) anymore? I should have known by only finding out after 15 pages of Google searches through propellorhead mailinglists!

Oh, but that’s right, you don’t want a large userbase. Ah yes, you don’t want to get over your stupid archaic mentality that nroff sources are still the best. Choice of output options doesn’t matter, because we all still live in a line printer world and using a typesetting system only ever designed for line printers is still the way to go. Who uses screens anyhow eh? Who likes their documentation to be astetically-readable and portable? Not us, we all still use text consoles!

Yes, even Linux is better for this. Again, because at least they have a decent documentation project going on. Linux may be mostly shit, but at least there’s a stupid amount of documentation around that doesn’t presume that the reader has been a BSD nut for the last 10+ years. It leaves NetBSD behind because not only is there newbie help, but also good, solid technical documentation if the reader wants it.

A Case In Point

The examples in gif(4). They’re stupidly out of date. They have a cute ASCII picture, and yet it’s mostly unintuitive. Most importantly, someone had bothered to patch the manpage at the bottom to state:

     It should be possible to use the add command of route(8) to add an inter-
     face route to a gif interface in one step rather than having to tweak it
     later with change.

“Should” be possible?!? Reassuring. And yet, whomever did this patch didn’t bother to go that little bit extra and fix the rest of the manpage which still shows to use create in the example! Not to mention the above text is under the BUGS section! They could have, at the least, marked the example as being outdated and incorrect.

There is this mentality in their camp that if you want to be a NetBSD user, you have to be smart and read between the lines. There is a lot of implied assumptions when doing things in NetBSD. “Oh yeah, by the way, if you want your kernel/box to reboot and work after upgrading sources, you should have just KNOWN to check there were ipfilter upgrades involved too.”

My Firewall Issues, or, The Point Of This Rant

NetBSD has, and for some time has had, a very serious bug in its gre(4)/gif(4) code that causes instantaneous system hangs. The problem is simple — if you setup a tunnel, and the endpoints of said tunnel don’t have a direct route in the routing table, the box dies as soon as a packet is thrown at the tunnel. Dies. Dies quick, reliably and without warning. Not even a panic.

This problem doesn’t appear obvious or apparent to most it seems, because they would usually have a default route present, at the least. What if the tunnel you’re attempting to create is meant to be the (eventual) default route? Well, therein is where the fun lies.

Bugs exist. I’m not a complete idiot. This kind of bug should have been qwashed long ago. It should NOT cause the whole machine to just die. Even someone as rusty as I with C could fix it enough at least to prevent a hard hang. There is no way I’m going to get intimate with the netinet code in order to fix it, and nor should I have to.

Conclusion

I know. Do my bit. Contribute. Well, I have been in a limited sense. I will in the future as well. I also participate in a few other major documentation projects, and only have so much time. I’m not entirely sure why there isn’t far more activity on documentation for NetBSD. They have a team to do it all…

I would also like to state that most of this will come under criticism, no doubt. I’m open for discussion. Perhaps I have it all wrong. I’d like to be proven wrong. Criticism I throw at NetBSD through a friend is almost always taken personally, I hope that any discussion from this rant is not reacted upon that way.