Subject: Re: The future of NetBSD
To: None <firstname.lastname@example.org>
From: Ingo Schwarze <email@example.com>
Date: 09/02/2006 23:38:19
Gilbert Fernandes wrote on Fri, Sep 01, 2006 at 11:59:57AM +0200:
> I have a dream. A dream of unification. Having one BSD.
> Merging the three projects and, why not, keeping incompatible
> stuff as options that would be either one or another.
Options are mostly against the goals of OpenBSD.
I, for one, want as little of them as possible.
The less complicated something is, the easier it is to maintain.
Correctness is too often sacrificed to complexity.
That's exactly the main reason why i hate Debian GNU/Linux so much.
Options abound, and at least 95% of them are completely useless.
You can hardly imagine how much time i already lost digging through
literally thousands of lines of completely useless script files,
scripts that are advertised for option management - desperately
trying to track down some problem in Debian that would have been
completely trivial to solve when encountered while using OpenBSD.
Some of the worst examples that come to mind look like /etc/cron.*
/etc/logrotate.d /etc/alternatives /etc/init.d /etc/rc?.d, runlevels
in general and the grub boot manager - and last not least that whole
Zillions of options - and you can not even decide to not use most of
them, but are usually forced to learn at least a bit about nearly
all of them.
Besides, i don't want an option to compile a blob-free kernel,
but i want a completely free operating system.
Besides, i don't want security options but security by default.
It is nice NetBSD, FreeBSD and OpenBSD developers have the option to
freely copy code from each other whenever it fits the need at hand.
It is also nice to have the option to run either.
But stay away from me with any additional options...
By the way, there are also a few corners in OpenBSD where options
are overdone - if i understand correctly, mostly for historical
reasons. The standard example of course is mailwrapper(8) - well,
even the man page says so. But i would gladly trash securelevel(7),
too, just to give one additional example.