Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!sunic!news.funet.fi!
sauna.cs.hut.fi!hsu
From: h...@cs.hut.fi (Heikki Suonsivu)
Newsgroups: comp.os.386bsd.development,comp.unix.bsd
Subject: Could the BSD 4.4 Lite be a new beginning?
Date: 14 Feb 1994 02:39:07 GMT
Organization: Helsinki University of Technology, Finland
Lines: 46
Distribution: world
Message-ID: <HSU.94Feb14043905@laphroaig.cs.hut.fi>
NNTP-Posting-Host: laphroaig.cs.hut.fi
While all (?) BSD groups are working on to get 4.4-Lite incorporated, could
it be possible that we could also see a formation of some kind of BSD
consortium, which would act as a collector of fixes and enchancements to
4.4-Lite sources? Thus, we at least would have common BSD tree, even if we
can't have one unified free BSD operating system?
I'm still somewhat angry and depressed of the current situation, and this
problem is not getting any better with time, but turning up more and more
often. We are now running NetBSD 0.9, and it is clear that we need to go
to some other operating system because of the stability problems in it. We
would have to choose from at least four different operating systems
(NetBSD-current, FreeBSD, BSDI and Linux), each of which shine in some
aspect. I need to make enchancements to several utilities, but I would
have to first select one of the source tree to patch and then select who I
will return the modifications to. If I pick up the wrong thread, I'll
probably get stuck with the OS which looses like BETA lost over VHS, and
have to go through the trouble of reinstalling all my work to the next
winner.
Linux people seem more mature and develops faster, but the distant odor of
system V has kept me away from it.
Would it be possible that UCB would allocate at least one guy to keep the
4.4 tree up to date with all of the groups? This would be the easiest
solution, if UCB can arrange for funding.
Or would it be possible that all these groups would allocate part time of
their least cocky guy to synchronice the work with others, effectively to
form a kind of "BSD consortium" similar to X consortium. I think this
would be the best solution.
Or could someone else take care of merging the changes? The FSF? BSDI?
Cygnus?
I'm not proposing that non-BSD parts like installation utilities should be
merged (that probably is too much asked), but at least keeping the original
BSD work together.
I know this has been discussed before. It just seems the right time to
start it again, when everyone once more have to look at the same source
tree. And I still refuse to believe that it is that difficult.
--
Heikki Suonsivu, T{ysikuu 10 C 83/02210 Espoo/FINLAND,
h...@cs.hut.fi home +358-0-8031121 work -4513377 fax -4555276 riippu SN
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!cs.utexas.edu!swrinde!
sgiblab!gatekeeper.us.oracle.com!decwrl!decwrl!vixie!vixie
From: vi...@vix.com (Paul A Vixie)
Newsgroups: comp.os.386bsd.development,comp.unix.bsd
Subject: Re: Could the BSD 4.4 Lite be a new beginning?
Date: 13 Feb 94 19:10:19
Organization: Vixie Enterprises
Lines: 52
Distribution: world
Message-ID: <VIXIE.94Feb13191019@office.home.vix.com>
References: <HSU.94Feb14043905@laphroaig.cs.hut.fi>
NNTP-Posting-Host: office.home.vix.com
In-reply-to: hsu@cs.hut.fi's message of 14 Feb 1994 02:39:07 GMT
I've been thinking about this for a long time. I would support a BSD Consortium
if such is created; however, there are several reasons why our situation
differs sufficiently from X11 and the X Consortium that it'll be very hard
to get a BSD Consortium in place. Here's my thinking, starting with X11
differences.
1. vendor support. almost all X Consortium members (which in turn means:
X Consortium funding sources) are system vendors who want to ship X11
with their systems and see this as a cheaper/better alternative to doing
their own incompatible window system. i do not see a corresponding list
of system vendors eager to stop shipping their own proprietary UNIX-like
operating systems in favor of something based on the output of a proposed
BSD Consortium.
2. egos. even with CSRG, who is fairly introfocused and apolitical, i suspect
that each BNR2-derived system (BSDi, NetBSD, FreeBSD, and to some extent,
Linux) will pick and choose from what they see in 4.4-lite and put in only
the things that won't overwrite the parts of the system that each group has
done a lot of work on and therefore has a strong personal interest in. even
if those conflict areas have already resulted in lots of code being "donated"
to CSRG, sometimes CSRG has to do something "else" for whatever reason and
in those instances i know of specific strong personalities in each of the
BNR2-derivative camps who will say "sorry, i don't agree, we're not moving
that part of our system to 4.4-lite". a BSD Consortium would have a hard
time staying relevant since so many BSD folks are wild-assed cowboys who
want to be different sometimes just to be different. again, the X Consortium
has less trouble with this because the people _in_ the X Consortium wrote
most of the code that they ship. folks outside the X Consortium pretty much
_expect_ that the system's interface and architecture will continue to evolve
and they _trust_ the people in the X Consortium to "do the right thing". I
don't see enough of the CSRG team (even counting emeritus members) remaining
who would want to be a part of a BSD Consortium; therefore the people who
would form the BSD Consortium would have a large credibility problem with
the great unwashed mass of BSD cowboys.
All that aside, I think this is a great idea and if I thought I could make it
work (that is, not go bankrupt in the first year) I'd give it a go. But it's
hard to do it without funding, and the people who would need to fund a BSD
Consortium are all out there chasing OSF/1 and SVR4 as their O S strategy. We
are working on a "public internet software consortium" for various components
like BIND that still tend to have "one true version", cast in the image of the
highly successful GateD Consortium. but a Consortium covering all of BSD seems
impossible for several reasons, some commercial, some political, all shown
above.
Vendors with interest in funding this sort of activity are welcome speak up
and prove me wrong, of course...
--
Paul Vixie
Redwood City, CA Also: <comp-sources-u...@uunet.uu.net>, <vi...@bsdi.com>,
decwrl!vixie!paul <ftpmail-ad...@pa.dec.com>, <vi...@sony.com>,
<p...@vix.com> <{bind-workers,objectivism}-requ...@vix.com>
Path: gmd.de!xlink.net!howland.reston.ans.net!pipex!uknet!EU.net!ieunet!
news.ieunet.ie!jkh
From: j...@whisker.hubbard.ie (Jordan K. Hubbard)
Newsgroups: comp.os.386bsd.development,comp.unix.bsd
Subject: Re: Could the BSD 4.4 Lite be a new beginning?
Date: 15 Feb 1994 01:05:24 GMT
Organization: Jordan Hubbard
Lines: 120
Distribution: world
Message-ID: <JKH.94Feb15010524@whisker.hubbard.ie>
References: <HSU.94Feb14043905@laphroaig.cs.hut.fi>
NNTP-Posting-Host: whisker.hubbard.ie
In-reply-to: hsu@cs.hut.fi's message of 14 Feb 1994 02:39:07 GMT
Several people have already responded to this, either to give some
likely reasons why it probably wouldn't work (Paul V) or to beat the
drum for one of the *BSD variants - something I won't criticise since
the folks in question are understandably proud of their efforts, but
beating the drum admittedly does not quite answer the questions posed
here. As one of the 3 founders of FreeBSD, and somebody who's also
sacrificed countless hours, spent significant amounts of personal cash
and lost far too much sleep for "the cause" of a freely available BSD,
just let me toss in my two cents into the pot.
First off, let me just say that I think it's a little unfair of Paul
to label us collectively as "BSD cowboys" (or the great BSD unwashed),
the image being that of some wild and wooly group of hackers who hack
on BSD for the sheer joy of screwing with it (or screwing it up).
From his perspective as a paid BSDI consultant, it's perhaps easy to
look down his nose at those who are doing it for less well defined
reasons and no obvious financial reward - we're not making money, we
must be doing it for the raw thrills and public adulation, right?
Not necessarily.
To really understand why we're doing what we're doing, it is important
to understand how the *BSD groups came about in the first place.
Nobody just woke up one morning and thought "Hey, think I'll get
seriously involved in pushing out an operating system release! For no
money! Yeah, that should wreck my social life real good! :-)".
No. What happened was one Bill Jolitz, who *did* wake up one morning
with that thought, and out came 386BSD 0.0, followed shortly by 0.1.
For those of us who still saw Linux as a very embryonic UNIX variant
(which it definately was, back then), 386BSD appeared as something
promising to look significantly more like the versions of UNIX we were
all used to, and we jumped at it. The problem was that 386BSD was a
diamond in the rough [some would call that charitable, but let's be
kind] and it required a lot of patches to fix all the various bugs
that brought it frequently and grindingly to a halt, thus evolved the
"Unofficial Patchkit". Please note that at this stage none of us were
thinking of ourselves as "CSRG wannabees" or "The next wearers of the
BSD mantle" (I shudder to even contemplate it), we simply wanted an
operating system that was free, could be talked about openly with
other enthusiasts (without having to demand a signed copy of a license
agreement before exchanging sources), and enabled us to escape the
scourge of SCO and SVR4 on our PC's. We weren't looking to win any
religious wars, or become figureheads for any larger effort, we just
wanted the bits!
Of course, real life generally doesn't let you get away with a free
lunch for very long, and before we knew it the patchkit had become a
full-time job. Life without it was unthinkable, since utter chaos was
the only alternative and Bill Jolitz had all but deserted us after 0.1
(and is still AWOL, over 2 years later). What were we to do? We'd
already invested significant time and effort into fixing up 386BSD and
people were relying on us (the patchkit coordinators) to try and make
some sense of it all. Well, after several changes in "patchkit
leadership" and a growing mountain of patches, we found ourselves
faced with only one real alternative - another release. It was sheer
chance that the minds of several folks at Berkeley were moving along
similar lines right about the time that the patchkit moderators were
throwing up their hands and deciding to go for another release of
their own. Which effort came first is a matter of debate and
completely unimportant, what is important is the fact that the "split"
was not by design, it was simply a result of the chaotic times we were
in and a complete lack of information on what was "real" and what
wasn't - were the Berkeley folks serious (I.E. "real")? Were we?
Would Bill J. come back, as he kept promising, and release 0.2 to save
us all the time and grief? Nothing was certain until it had
progressed along almost to its conclusion, by which time it was a
little late for U-turns.
To all of our credit, we did spend significant time and effort in
discussions of how we might merge the FreeBSD and NetBSD groups, but
was here that the lamentable (and far too frequently reported) ego
problems surfaced and got in our way. However, fraternal problems
aside, we're still much the same groups we always were - volunteers,
many of us with full-time jobs and long careers in the computer
industry, banging out the bits because we want to use them ourselves
and because no one else is doing it. If someone came along tomorrow
with a serious BSD consortium promising a full-source, freely
available version of 4.4 BSD with support for all the various and
sundry PC peripherals (which is the hard part - your average
SPARCstation is a cake-walk by comparison, and changes very slowly
once made to work), then I'd throw my full weight behind it in a
heartbeat. Do you think I'd want to continue giving up my nights and
weekends if some former god of BSD from CSRG got up and promised to
give up _his_ nights and weekends to deliver to me an operating system
of higher quality, integration and user focus? Hell no - I'd breath a
long heartfelt sigh of relief, sit down in the bleachers and hold out
my hands for the tape - "gimme - my turn to sit down".
The same goes for getting a UCB/CSRG/BSDI person to help coordinate
changes - I'd LOVE such a thing, and would jump through hoops to
coordinate the FreeBSD side of it, but the chances of something like
this happening are close to nil.
So unless Santa Claus comes early this year, I'll continue to do what
I can do ensure that our own "BSD for the PC" work goes forward. I'll
also continue to welcome the participation of anyone cares to
contribute anything of their own without using the opportunity to try
and impress me with their brilliance, deride the efforts of others, or
inflict their bad day on our group of long-suffering volunteers. Life
is too short, and there's only a certain amount of grief one will
tolerate for free! :) If you think you see a method I've missed that
won't generate a lot of extra work for us, and doesn't subject me to
more ego-friction grief, then by all means please let me know!
Lest I end this on a bad note, let me take this last paragraph to say
that just about everyone who has worked with or used FreeBSD (I cannot
speak for NetBSD, though I'm sure they feel similarly) has been really
terrific - we put in a lot of work, and it's not always a bowl of
cherries, but every once in awhile we get somebody who's using a
FreeBSD box to do something really interesting, or is teaching a group
of students about operating systems design on an inexpensive cluster
of PCs, and they tell us how much they're enjoying the fruits of our
labors. At those times, it seems worth the effort again! :-)
Jordan Hubbard
(FreeBSD core group)
--
Jordan K. Hubbard FreeBSD core team Electric Bivalves Anonymous
On the net, no one can hear you scream.
Path: gmd.de!urmel.informatik.rwth-aachen.de!newsserver.rrzn.uni-hannover.de!
hrz-ws11.hrz.uni-kassel.de!news.th-darmstadt.de!math.fu-berlin.de!MathWorks.Com!
europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!sdd.hp.com!
apollo.hp.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mycroft
From: mycr...@duality.gnu.ai.mit.edu (Charles Hannum)
Newsgroups: comp.os.386bsd.development
Subject: Re: Could the BSD 4.4 Lite be a new beginning?
Date: 17 Feb 1994 23:02:43 GMT
Organization: MIT Artificial Intelligence Lab
Lines: 71
Message-ID: <MYCROFT.94Feb17180243@duality.gnu.ai.mit.edu>
References: <HSU.94Feb14043905@laphroaig.cs.hut.fi> <R60q1p-.dysonj@delphi.com>
NNTP-Posting-Host: duality.gnu.ai.mit.edu
In-reply-to: John Dyson's message of Mon, 14 Feb 94 02:58:31 -0500
Well, I guess today is a good day for advertising...
I am a founding member of the NetBSD group. We have done a lot to
make NetBSD more stable, and to move it toward existing `standards'
(POSIX.1 and .2, and 4.4BSD). Several very broken parts of the kernel
have been completely replaced, and others have been extensively
modified; the details are too much for me to repeat, and are available
elsewhere. NetBSD runs on a wide range of hardware, including (some)
Pentiums (depends on the bus; we don't do PCI yet), many models of
Amigas and Mac IIs, the HP300 series, some models of SPARC, and PC532
machines. We are close to, but not quite, POSIX.1 compliant. (Some
other systems incorrectly claim that they already are.) We've added
IP multicast and the full range of System V IPC (shared memory,
message queues, and semaphores). NetBSD-current has several things
that were previously missing from Net/2-derived systems, including
shared libraries (for the i386 port, all the m68k ports, and the sparc
port), some old utilities such as at(1), quot(8), units(1) and others,
the AMD automounter, a full process file system done more like System
V, a loopback file system, etc.
There are a few features you will not find in NetBSD-current, however:
* We do not supply our own console driver with virtual terminals.
However, either pcvt or syscons can be acquired and used with very
little effort. Traditionally, these drivers have been large and slow,
and they are maintained by third parties.
* We do not supply Amancio Hasty's port of the Linux sound drivers.
These (or at least the ports to BSD-du-jour) seem to be fairly buggy.
Again, this is maintained by a third party, and can be acquired and
dropped in with little effort.
* We do not supply a colorized ls(1).
In his previous post, John Dyson brought up a few points that I would
like to expand on:
optimized pmap code,
Except for two uses of i386 assembler code which in practice make
little difference, the one in NetBSD-current is faster, and in
particular does fewer TLB flushes.
multi-page cluster pageins,
You mean `pageouts', I think, and Mike Hibler's VM code for 4.4 does
this, and I dare say has been more thoroughly tested. It seems a
better choice to me for us to wait for that code to be available.
and our if_ed driver, written by our team member, David Greenman,
is *very* reliable and attains THE ethernet bandwidth.
Before he was officially(?) a FreeBSD `team member', he also donated
this code to NetBSD. We have added multicast support and cleaned this
up a bit. In addition, `our' if_ep (3COM 3C509 driver) has been
clocked at full ethernet bandwidth, and works reliably in NetBSD.
The sound driver that we support is very good (as I have heard.)
I considered incorporating the ported Linux sound drivers into NetBSD.
On inspection, I found several obvious bugs and a few things simply
turned off because someone didn't bother to port them properly. This
code is not stable enough that I would recommend anyone use it.
--
- Charles Hannum
NetBSD group
Working ports: i386, hp300, amiga, sparc, mac68k, pc532.
In progress: pmax, sun3.
Path: gmd.de!xlink.net!howland.reston.ans.net!EU.net!ieunet!news.ieunet.ie!jkh
From: j...@whisker.hubbard.ie (Jordan K. Hubbard)
Newsgroups: comp.os.386bsd.development
Subject: Re: Could the BSD 4.4 Lite be a new beginning?
Date: 18 Feb 1994 06:40:49 GMT
Organization: Jordan Hubbard
Lines: 55
Distribution: world
Message-ID: <JKH.94Feb18064049@whisker.hubbard.ie>
References: <HSU.94Feb14043905@laphroaig.cs.hut.fi> <R60q1p-.dysonj@delphi.com>
<MYCROFT.94Feb17180243@duality.gnu.ai.mit.edu>
NNTP-Posting-Host: whisker.hubbard.ie
In-reply-to: mycroft@duality.gnu.ai.mit.edu's message of 17 Feb 1994 23:02:43 GMT
In article <MYCROFT.94Feb17180...@duality.gnu.ai.mit.edu>
mycr...@duality.gnu.ai.mit.edu (Charles Hannum) writes:
Well, I guess today is a good day for advertising...
No, actually not.
Sigh.. I was sort of hoping we wouldn't get to this stage in this
discussion, which is why I veered away from active comparison in my
own follow-up to this topic. Please, folks, there are three important
points that really have to be remembered here in this pointless
"feature by feature war" between NetBSD and FreeBSD:
1. Nobody speaking for any feature, or lack thereof, in the
other group's OS can be trusted as far as you can throw them.
Personal agenda takes over from technical accuracy after the
3rd or 4th word.
2. It is ludicrous to even attempt a point-by-point comparison
of the two systems since that comparison will be obsolete within
a week. The system changes _every single day_, and people from
Iceland to Australia are constantly donating bits to it. I don't
even try, which is why it's just stupid to infer a lack of "hyberhoo
widgets" in one OS just because one camp advertises them in 10 foot
neon letters and the other simply puts them in and doesn't make a lot
of fuss about it. Yes FreeBSD has shared libs, yes we have SYSV
IPC and shared memory, yes we have a /proc filesystem, ok ok - if
you're really interested then go look, ok? Why should I waste your
time here?
3. In making any overall comparison _For Your Own Purposes_ (since
any other comparison is truly meaningless), you need to take into
account the complete range of attributes: "Does the system do what
I want it to?" "Does it run on the hardware I have?" "Are all the
optional packages I need easily available?" "Are the people nice and
willing to answer my questions?" You can have a brilliant system that
falls short in one or more of these areas and turns out overall to be
a less than positive experience.
Charles's trashing of the new VM system and the sound drivers (which
work just great for a LOT of folks!) was unwarranted and uncalled for.
Sure, members of both camps can sit here until they get haemorrhoids,
pointing out flaws in the others' code base and screaming, spittle
flying from their lips, "BUG! Nyah nyah! I see a bug! LOTS of them!
That system is UNUSABLE!!" And meanwhile, the rest of the world will
go right on happily using that system and very glad indeed to be
getting their bits for free.
Can we all get back to improving our systems now? Thank you!
P.S. FreeBSD doesn't have a colorized ls either - that's Linux.. :-)
Jordan
--
Jordan K. Hubbard FreeBSD core team Electric Bivalves Anonymous
On the net, no one can hear you scream.