Date: Tue, 3 Sep 1996 15:01:10 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: darrend@novell.com (Darren Davis) Cc: terry@lambert.org, chat@freebsd.org Subject: Re: FreeBSD vs. Linux 96 (my impressions) - Reply Message-ID: <199609032201.PAA05164@phaeton.artisoft.com> In-Reply-To: <s22c47a5.046@novell.com> from "Darren Davis" at Sep 3, 96 03:06:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Just one question.
>
> What is this OpenBSD thing? I have never heard of the term.
OpenBSD the source code is the NetBSD sources base + fixes from
various places, including FreeBSD.
OpenBSD the political entity is somewhat different.
OpenBSD's "claim to fame" is that it tries to divorce itself from
the "good ol' boy network" inherent in the core team organization
of the NetBSD and FreeBSD. A lot of people see the current NetBSD
and FreeBSD organizations as imposing a "tunneling barrier energy"
which you have to overcome to get to the next higher stable state.
I have to take responsibility for the organization template copied
from the "FreeBSD + patchkit" days. The template resulted from
the inherent requirement for a central serialization authority
for patches because the tools I built were simply not up to
arbitrating concurrent developement. This may, in fact, have
been a key contributor to the NetBSD/386BSD split -- I know that
there were at least two people who later became initial members of
the NetBSD core team who tried to "roll their own" patches in
patchkit format, only to have them formally rejected. Not because
they sucked, but because they disrupted the serialization
mechanism (this didn't stop the people involved from assuming
that the reason for the rejection was a personal attack, however).
OpenBSD's main failing is that it does not impose process controls
to do the coherency control job that the "good ol' boy network"
does for FreeBSD and NetBSD. It is currently metastable because
it does not have a significantly larger number of people than are
in the NetBSD or FreeBSD core teams actually hacking on or checking
in code.
To go back to the electron tunnelling analogy, OpenBSD has less
barrier to moving forward, but at the same time it would probably
take significantly less energy to get it rolling down hill as
easily as up hill. The result would be a throwing on of the
brakes, either unidirectionally, in the form of increased process
complexity, or bidirectionally, in the form of a tiered management
structure (aka a "core team").
Political structures are interesting because their behaviour is more
easily subject to rigorous mathematical analysis than, for instance,
an individual's behaviour. The "path of least resistance" for "throwing
on the brakes" is a tiered management structure ("some pigs more equal
than others"); I suspect that an increase in process complexity would
be fought just as bitterly by the initial OpenBSD comitters as it
was fought in NetBSD (leading to the formation of OpenBSD in the
first place), or as bitterly as the current argument about the
buildability of "-current" taking place on the other list right now.
Given that, and some mathematical modelling that I won't go into
because it is too hard to represent in ASCII, I predict that OpenBSD
will probably develop its own core team, unless it takes exceptional
care. It might take that care anyway as a method of product
differentiation, just as FreeBSD and NetBSD have arrived at an
accommodation on their "product differentiation".
Currently, however, OpenBSD could be described as "lacking brakes",
with both the good and bad consequences thereof.
I supposed the ideal system would have unidirectional brakes, to
inhibit rolling back down hill, but to avoid posing a barrier to
forward movement. So far, none of the BSD camps has arrived at
a political design which implements this. If you project the
potential well for tunnelling into a three dimensional saddle curve,
with Linux on one end (control imbued in an individual), OpenBSD
on the other end (with a flat curve asymtotically approaching the
tangent), then NetBSD and FreeBSD are somewhere in the middle.
This implies that the only reason process changes don't take
place is (social) inertia along the Z axis.
Novell/USG (where you an I both worked) had the exact same problem,
projected along the inverted Z axis. At USL, the process *was* the
product, and the tree because inertially fixed by process limitations
instead of becoming inertially fixed by change limitations inherent
in the number of reasonably managable participants, defined as
sizeof(core team). At USL, it was the limit on the number of people
allowed to write the source tree, and the inherent organizational
limitationon the the ability to make changes which were larger in
scope than one component branch of a checked out source tree. You
couldn't make sweeping changes in the UNIX source base because it
was impossible to coordinate them over all of the affected platforms
because of the way their source tree management process was arranged.
This applied equally to sweeping changes for the better as to sweeping
changes for the worse -- bidirectional brakes.
Ed Lane described this process as what he called "AI", or "Artificial
Importance" -- useless limitations on process output caused by useless
limitations on process complexity.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609032201.PAA05164>