The Future of NetBSD
ErisCalmsme writes "In this email Charles Hannum (one of the founders of NetBSD) tells us that 'The NetBSD Project has stagnated to the point of irrelevance. It has gotten to the point that being associated with the project is often more of a liability than an asset. I will attempt to explain how this happened, what the current state of affairs is, and what needs to be done to attempt to fix the situation.' What will happen to NetBSD?"
While there will be those who see this as flamebait, it's high time someone puts into words what many of us are thinking - namely, that something's not quite right, and we should look to those with more experience to give us some clues...
I love NetSBD. It's stable, it's fast, the package management is great (and upto date), NetBSD folks don't seem to feel the need to evangalise and beat people over the head with their OS choice. A lot of interesting development is also done in NetBSD (like integrating Xen into NetBSD 3.0, the CCD driver, RAIDframe, etc).
I don't understand what this guy's on about - I use it and love it, so do lots of other people, we have upto date software and a great base system. How exactly is NetBSD irrelevant again? Is he bitching because of a lack of marketshare compared to other BSD/Linux distros? In a world of free software, why exactly does that matter?
It's disingenuous to bitch about the things he does as if they were important - flash file system? So what? Journaled file system? There's a very good reason for the omission of journalling and you can't tell me this guy doesn't know about softdeps.
Just sounds to me like this guy is pissed off with not getting some kind of glory for his work and it's all sour grapes.
OpenBSD was a fork() of netbsd. Is there any chance they could reunite to make a single stronger OS? How difficult would reconciling the politics and the codebase be?
------ Take away the right to say fuck and you take away the right to say fuck the government.
I must say, it is an interesting read but I am struck by the humility and honesty of this guy.
I've been waiting for this to happen ever since I read how Theo De Raadt was treated in there and how he eventually left the group to work on his own branch. I think you can find an archive of his emails with the NetBSD dev team somewhere...
Now the problem is admitted: FTA:
This is basically what drove Theo out (as far as I understand his great ideas were ignored by the boureaucratic system and he felt frustrated) and now the basic reason why NetBSD is dying.
But NetBSD still lives: in its decendants, like OpenBSD. So let us treat NetBSD with the same respect we would give to a dying grandfather :)
I'm a big BSD guy, mainly a FreeBSD user, but I intently follow DragonFlyBSD and OpenBSD. Unless I'm mistaken, this is the same Charles Hannum that was directly responsible for kicking fellow NetBSD founder, Theo de Raadt, out of the core group, removed his CVS priviledges, and made Theo twist in the wind for 7 months until he was forced to leave to found OpenBSD. (reading the log I don't see how Theo lasted 7 weeks, he really made an effort to continue with NetBSD despite all of that). So now the evil cabal takes over and kicks Charles out of the core and removes his commit priviledges. It's sad, and I think Charles' points are spot on, but it's a bitter pill to swallow coming from this messenger. You have to shake your head when you think of what NetBSD could have been had they been able to avoid childish political antics in their "cabal".
NetBSD has features that others don't and in some aspects is innovative(or at least different), so it's valuable(for its own users and for the whole OSS "universe"). What we don't need is the zillionth Linux distro, which just repackages applications in a different way.
It is a pretty interesting read. I can give you my experience with NetBSD over the past couple of years...
Outside of my regular job we were developing an embedded system. The first thing I thought of was NetBSD. Downloaded it, tested it, critiqued it, and couldn't find enough benefit to use it. The big gotcha was there was no filesystem at the time for running on flash devices. Well, almost every embedded project is going to run on a flash device. Mind you this was a couple of years ago, but according to the post not much has changed. There were a couple of other small gotchas, but in comparing it to Linux, there just wasn't enough reason to use NetBSD.
And therein lies much of the problem. I don't think NetBSD is bad. It's not. However, a lot more people are using Linux for advanced embedded devices than NetBSD and are solving real world problems so you don't have to. NetBSD may run on a plethora of hardware pretty well. But 90% of the embedded world really needs it to run on is i386, arm, and mips. So there is really good linux support for those arches because so many people are developing systems with the linux/uclibc/arm combo. It's the new lamp. NetBSD may have the shock factor of running on things like toasters, but Linux is running on real world things like my phone.
On top of that, the term "embedded" is becoming looser and looser. There was a time when "embedded" meant a 12mhz processor and everything was in assembly and C. Today, I can get a 400mhz gumstix and do all my development in python. I would consider it embedded by today's standards, but in reality that was a normal desktop development machine 5 years ago.
Again, NetBSD isn't bad. If I had to really run something on a 12mhz CPU I doubt I'd be able to use linux/uclibc/arm and NetBSD might be my answer. However, in a world where embedded hardware is the desktop hardware of 5 years ago, there just isn't any benefit to trying to use the same embedded tools of 5 years ago.
If an officer ever threatens to taze you, say you have a pacemaker.
No they don't, only heritage. But when something relevant is developed for one of the BSD's, the other will soon port it over, since it is easier to cross-port between the BSD's then from Linux to BSD.
:)
The fact that each BSD has it's own kernel AND it's own userland is what makes it so great: each project has a different set of goals, and they are reached by focussing on that one, without having to think about what the other projects would like in the kernel.
Eventually, the projects can grow apart as far as you can think. But since basic functionality is often shared, that won't happen. And thus they abide
Free beer is never free as in speech. Free speech is always free as in beer.
There's a lot of reasons to have it around.
The BSDs do stuff differently, and there's a lot of cross-pollination among them (and to a lesser extent linux). Someone might have an idea they implement in NetBSD that ends up getting ported to FreeBSD and OpenBSD, and vice-versa.
You also have the fact that the focus of the three major BSDs are different - FreeBSD is a general system, OpenBSD is focused on security, and NetBSD is focused on portability between different architectures.
This also gives more people the chance to contribute to the system in general. If you've got an idea for a new scheduler, you can try to get it implemented on one of the systems. If it works, other systems may copy it for themselves. If there's only one system, though, it's a lot harder to get into development because there's fifty other people with scheduler ideas you have to compete with.
Then, of course, the real reason why there's multiple BSDs around - developers want to work on them. Let them have their fun - just 'cause they make it doesn't mean you have to use it.
Those who can't do, teach. Those who can't teach either, do tech support.
FreeBSD is a general system, OpenBSD is focused on security, and NetBSD is focused on portability between different architectures.
NetBSD is clearly the odd-man-out. FreeBSD's 7 arches probably cover 99% of the computers people would want to use. While NetBSD has sacrificed features and speed for portability, FreeBSD has managed most of the portability (from a practical standpoint) while adding new features. OpenBSD has a good niche, as security is a goal for while people are willing to sacrifice some features and speed. Portability alone is a strange goal however, since the only question that really matters is "does it run on all the computers I have".
I'm a Linux user myself, so I don't have much reason for favoritism for a particular flavor of BSD. I try to keep up with OS news in general however. I don't have anything against NetBSD, though I can't say I'd miss it that much (just like slackware as a Linux distro - historically important, but now largely irrelevant). If I had any current concern, it would be that I really hope DragonflyBSD succeeds, as it is pursuing some really interesting ideas in modern OS design.
NetBSD also has a ridiculously clean codebase. That means if you're porting the OS to a new architecture, or doing some sort of OS research, the NetBSD code is a much better place to start than the FreeBSD or Linux code.
A deep unwavering belief is a sure sign you're missing something...
One such example, in my honest opinion, is Gentoo. I was a developer for about a year and a half before I finally called it quits. The major problem that I saw with Gentoo, and is the problem with NetBSD apparently, is that there is no main driving force to give the project direction. One of the great strengths of Gentoo is that there are many people working on things to scratch everyone's itch, but there is no general goal, and that is what leads to all of the flamewars. Everyone has their own idea of what Gentoo should be, and since there is no one to decide it, some people are content with arguing over it until the project dies from stagnation.
The best way to solve this, as I see it, is to adopt the idea of having a permanent "steering committee" for the project. Some major projects already do this, and it provides the central authority/leadership that is needed for any large scale project. Most developers/contributors don't want to deal with the politics that come from not having a central leadership, and there are the vocal few that will make it a living hell for everyone else.
I used to be a firm believer in letting projects govern themselves, but since I've been part of one that operates that way, I see the problems that come from that type of system, and they are crippling.
Mark Loeser