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

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>

Hi, I am John Dyson, a core team member of FreeBSD.  We have done
alot to make the FreeBSD OS much more stable.  We do have some minor
limitations in some areas relative to other BSD variants or Linux, but
likewise they have some too.  I am never into being religious or opinionated,
but I strongly suggest trying FreeBSD.  The new release that is about
to come up addresses one of the major problems regarding stability,
the VM system.  We have almost totally redone broken portions of the
VM system and support both swapping and paging, a very good LRU/Clock
algorithm for paging, optimized pmap code, multi-page cluster pageins,
bypassing the buffer cache for paging in, and lots and lots of bug fixes.
We actually have people that truely understand the VM system, and our
if_ed driver, written by our team member, David Greenman, is *very*
reliable and attains THE ethernet bandwidth.  The sound driver that we
support is very good (as I have heard.)  Our interrupt latency is very
short and we can sustain very high interrupt rates.  We are dedicated
to product quality code and do have a lot of future goals.  Our software
is open and currently keep our latest development sources available for
everyone to read.  If you have any questions, email me at
dy...@implode.root.com (that is where I usually use email.)  I realize
that this does not answer your question about the BSD consortium, but
sometimes diversity can lead to more creativity due to competition.  The
new release will be out in a couple of weeks, but current sources look
good.  Let me know if you are interested...

John
dy...@implode.root.com

he's right.  freebsd is cool.

In <R60q1p-.dys...@delphi.com> John Dyson <dys...@delphi.com> writes:

Not that it means a heck of a lot, but at any rate, a small
indication of the better stability of FreeBSD at this point is
the fact that it manages to survive crashme for several hours (I
have a system running crashme at the moment, and it has been
going nearly 8 hours).
(As a comparison, 386bsd0.1+patckit0.1 survived crashme for a few
seconds !  SunOS 4.1.1 survives crashme for between 30seconds to
just under 30 minutes!)

Geoff.
(Please note that I am _not_ trying to say that NetBSD or Linux
are any less stable - I know that people have run crashme for
weeks on Linux.)
--
 Geoff Rehmet, Computer Science Department,        | ____   _ o         /\
 Rhodes University,  South Africa                  |___  _-\_<,        /\/\/\
   email : c...@cs.ru.ac.za                        |    (*)/'(*)    /\/\/\/\/\
         : ge...@neptune.ru.ac.za (private)        |

But in fairness, SunOS 4.1.1 is about 3 years old, and Sun does have a patch
that enables it to withstand crashme.
--
hay...@cats.ucsc.edu
hay...@cats.bitnet

"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"

OK -- I'll bite. What does `crashme' do, exactly? What about it is so
"detremential" ?

--
// James Robinson ::: University of North Carolina at Charlotte      \\
// jlrob...@uncc.edu: Senior, BS Computer Science, Math Minor (Fun!) \\
// FreeBSD/XFree86 :: The best things in life are Free!              \\
Frank Zappa : "There's a big difference in bending down and kneeling over."

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.

In <CL8Jyr....@unccsun.uncc.edu> jlrob...@unccsun.uncc.edu (James Lee Robinson) writes:

From the crashme man page ;-) :

DESCRIPTION
       crashme  is a very simple program that tests the operating
       environment's robustness by invoking random data as if  it
       were  a  procedure.   The  standard signals are caught and
       handled with a setjmp back to a loop which will try  again
       to produce a fault by executing random data.

......

BUGS
       Not all signals are caught, and the state of the user pro-
       gram/process enviroment can be sufficiently  damaged  such
       that  the  program  terminates  before  going  through all
       [NTRIES] operations.

       Beware: This program can crash your computer if the  oper-
       ating  system  or hardware of same is buggy. User data may
       be lost.

AUTHOR
       George J Carrette. G...@MITECH.COM

;-)
Geoff
--
 Geoff Rehmet, Computer Science Department,        | ____   _ o         /\
 Rhodes University,  South Africa                  |___  _-\_<,        /\/\/\
   email : c...@cs.ru.ac.za                        |    (*)/'(*)    /\/\/\/\/\
         : ge...@neptune.ru.ac.za (private)        |

If I recall correctly, crashme works by executing random instructions.
It was initially used to "prove" that RISC processors were more buggy
than CISC, but the explanation turned out to be that the operating
systems on RISC machines (which have to do more interesting work
handling traps) were more buggy.

I would be interested to know the results of running crashme on a BSD
machine without a floating point processor - floating point emulation
is a fine area for bugs.

-- Richard
--
Richard Tobin, HCRC, Edinburgh University                 R.To...@ed.ac.uk

"We demand guaranteed rigidly defined areas of doubt and uncertainty" - HHGTTG

greyw...@autodesk.com (SAVE MY WALRUS) writes in <2jrj5a...@autodesk.autodesk.com>
/*
 * Pardon the inclusion of most of the article; it's a bit hard not to do
 * since the context is necessary to avoid misconstruction.
 *
 * vi...@vix.com (Paul A Vixie) writes in <VIXIE.94Feb13191...@office.home.vix.com>
 * /*
 *  * 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.
 *
 * 1.  While the vendors might not be eager to stop shipping their *NIX clones,
 *      perhaps if the "consortium" (if it happened) could advertise
 *      a *NIX for their platform, it certainly might put a dent in the
 *      proprietary OS' efficiency.
 *
 *  *
 *  * 2. egos.
 *
 * I think it's time that we temporarily suspended the anarchy long enough
 * to make a concerted effort.  I, for one, am damned tired of the only
 * option for a SPARCstation being to upgrade to Solaris 2.x (which is not
 * really an upgrade -- they just want you to *think* it is an upgrade).
 * The BSD camps should put their pride down just a bit and really get
 * together and see what can be done via a collective effort.  Of course,
 * "should" and "should not" should not :-) be necessary in this case -- it
 * indicates a plea against a brick wall.  This means that 386BSD, NetBSD
 * and FreeBSD need to stop fighting amongst themselves.  There is no place
 * for this.  Not now, not when we need more than ever to be a cohesive
 * unit.  Ideally, I'd like to see BSD give SVR4 -- and NT -- a real run
 * for their money.
 *
 * I think that 4.4-lite would be the best starting place; even BSDi is
 * following that route for 1.2 or 2.0 or whatever it turns out to be
 * (they might want to make 2.0 a beta-test release so that 2.1 is the
 * real release, thus avoiding the stigma regarding "never trust releases
 * ending in '.0' ...).  I'm sure there are some things which may be done
 * better or worse, but with 4.4-lite being the last release available to us,
 * it is ours to shape.  We need to make sure that we make it into a cohesive,
 * usable unit instead of everyone jumping on it and squashing it as though
 * they had mistaken it for a bug from Mars.
 *
 * We are at a crossroads where we have the potential to keep BSD alive
 * or to destroy it.  Let us choose wisely.  Sun chose poorly, from my
 * perspective as a user.
 *
 * As far as funding goes, it is hard to do anything without funding.  I'm
 * surprised I don't have to pay to breathe, yet.  But "hard" does not mean
 * "impossible".  It's a matter of how much blood, sweat, tears and time we
 * are willing to devote to such an effort.  It's a Utopian vision at
 * best:  a stable, (relatively) free Operating System complete with source
 * code, where bug fixes pop up relatively soon.  Of course, that's the
 * easy part.  The hard part is preventing the OS from growing too quickly
 * and suffering from leeching featurism.
 *
 *  *
 *  * 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.
 *
 * Being the optimist that I am, *nothing* is impossible, if you don't hold
 * the constraints to the physical universe, although it looks that way.
 *
 * Perhaps a consortium is idealistic at this time, but I don't think that
 * a BSD alliance is impossible.  It will just mean a lot of give and take,
 * a lot of communication, and while a bit of pride in one's work is healthy,
 * egoism is not.  (If you're resting on your laurels, you're wearing them
 * on the wrong end.)
 *
 * Forgive the ramble and the sick optimism, but where I'm about to get
 * forcibly migrated to NT WRT my immediate responsibility and work environment,
 * I must seek some light.
 *
 *  *
 *  * Vendors with interest in funding this sort of activity are welcome speak up
 *  * and prove me wrong, of course...
 *  */
 *
 * May the source be with you.
 *
 * Greywolf
 * --
 * People who cannot be persuaded to use turn signals or ashtrays while driving
 * should not be permitted to drive.

--
I'm really a software toolsmith and a musician by trade, but nobody really
needs a software toolsmith much, and the music industry is so cutthroat
that it would probably do me in.  So I do systems administration on the
side as a hobby.  Funny that my hobby finds more work than either of my
professions...
--
People who cannot be persuaded to use turn signals or ashtrays while driving
should not be permitted to drive.

In article <CL9MHI....@cogsci.ed.ac.uk>,

I agree.  I've asked lots of people to run crashme on linux, and the
floating point emulator has been cleaned up as a result of the results
(it didn't actually crash, but the kernel complained a lot).  The
"floating point" operations crashme tends to try out are rather
interesting (undefined precision masks, weird prefixes etc), and it does
take some work to fix them all (and yes, all reported errors fixed now).

One particularly interesting way to mess up the floating point emulator
that Bill Metzenthen (who wrote the current linux FPU emulator) came up
with is to modify the FPU instruction *after* it has already been
pre-fetched.  So by the time the floating point emulator gets to emulate
the instruction that trapped, the instruction no longer exists, and the
emulator sits there looking at an instruction which isn't a floating
point instruction at all.

Just for interest: so far, I have three reports of actual kernel lockups
after running crashme for some hours, one of which was due to a buggy
i386/i387 combination.  The reason for two are yet to be determined.
The other reports are successful, but the longest specific report was
just a few over-night runs: good, but not conclusive by any means.

                Linus

[ much drabble deleted -- So the dip posts again by accident ]

Sorry about the dup post (it was to have been something more like this).
I hope the Cancel makes it through.

Never mind what I said in the original posting.  I have been
Enlightened(TM) by several people who know what happens behind the
scenes of this newsgroup!  To all who would deign to flame me for my
naivete', don't bother.  To the ones who responded and listened to my
response, thank you for your understanding.

I confess to being nowhere near the level of kernel engineering and
hence not "in on" the behind-the-scenes stuff.  My intentions were
well-meant, honest!  I'm extremely interested in what's happening, and
it just saddened me a bit to see that while the industry plods along
with Motif/SVR4, BSD _appeared_ _to_ _be_ fighting amongst themselves.
Several people filled me in on this and I understand much better, thanks.

"Away put your weapon.  I mean you no harm."
--
I'm really a software toolsmith and a musician by trade, but nobody really
needs a software toolsmith much, and the music industry is so cutthroat
that it would probably do me in.  So I do systems administration on the
side as a hobby.  Funny that my hobby finds more work than either of my
professions...
--
People who cannot be persuaded to use turn signals or ashtrays while driving
should not be permitted to drive.

In article <HSU.94Feb14043...@laphroaig.cs.hut.fi>,

...

If you are thinking of the technical problem, you are right-- it isn't
that hard.

But it is not a technical problem -- it is a political problem.  It has
to do with individuals working in the various groups, the directions they
want the work to go, and certain attitudes and opinions they bring
with them.

Further, I will point out that the problem is not really "the fault" of
any individual-- it is a combination that does not work together.
[ i.e. various readers need not flame me -- no offense is intended. :) ]

To fully understand the problem, consider this hypothetical situation:
The one united BSD is coming, but to get it, *your* favorite feature has
to be replaced with something grossly inferior.  What are you going to do?

Mark S.

p.s. You are not going to use a piece of junk when you can get the source
code for the better solution.  Then you are going to give it away to other
people who agree with you, and the problem starts all over again...

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.

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.

The new pmap code is *significantly* improved over the *old* pmap code
which is essentially what NetBSD is using ( some uninspired tweaks.)
The tlbflush doesn't cost really that much and in fact the new code
is faster (try the code Charles, before making out-of-hand statements.)
The pmap code is really a *VERY* minor part of our VM improvements anyway.

Our pmap code (actually changes) supports fully the concept of page-table-paging
and is faster.  The 1.1 version of the code (about to be released and in
current) has been improved upon further, DG and myself have seen really
significant improvements, beyond anything else to date. (BTW, pmap
is a *small* *small* part of the performance puzzle.)  The biggest
gains can be gotten by restructuring the rest of the VM system.
Look out for 1.2 -- it will *even* be better....  I am currently running
about 20% of the changes for 1.2, and it works well so far.  (and
screams.)

Huh?  No I said pageins.  Have you even bothered to look at the
code?  It is obvious to anyone as experienced as I assume that you

are that the code in the VM system has changed and been improved
significantly and there is code (significant amounts) to
support clustered pageins.  The 'dare say' doesn't seem to come
from someone to be trusted considering the misinformation or
assumption made that I did not know the difference between
pageins and pageouts!!!!!

In fact, I was an alpha-tester for his if_ed driver and saw the initial
simple-minded first phase hack, the total conceptual rewrite throwing
away the original code -not even looking at it- and produced the *most*
robust driver for ethernet cardS that I have ever heard of.  It is great
because it *really* works for so many card types.

I had *much* of the VM code written before joining the FreeBSD team, and in fact
have not been considered a CORE team member until a week or so ago.  I made the
changes to the VM code to produce a *robust* implementation because my A** is
on the line to get a related product out.  I 'dare say' that I would not trust
any operating system whose VM code code is very fragile.  That is the reason
that FreeBSD decided to take on my code (I did not even lobby strongly for it,
I just wanted something to work for me.)

I realize that NetBSD would have problems integrating the new very improved
FreeBSD MACH-based VM system because of some very subtile (but major)
improvements to the pmap and other layers.  I am willing to help, but realize
that closed-mindedness sometimes prevails.  FreeBSD is going to be running
in a difficult mission-critical environment, and if there are problems,
they will be fixed post-haste.

I suggest that before making a decision on any operating system, really
look at it.  Off-the-cuff judgements by people that have been pubescent
probably for half the time that many of us have been programming are

not worth much.  I am *VERY* willing to take constructive comments on the
new VM system as a whole, and *VERY* willing to accept suggestions for
improvement.  The 1.1 code is frozen, and the 1.2 code is in the
works.  Remember, we are really improving the VM code and solicit any
constructive comment.

To sum up my response to Charles' comments:

The FreeBSD pmap code is still in flux, already I have a *new* version.  The
tlbflush change only makes about a 10% difference (which is vastly
overshadowed by other enhancements that we have made.)  We have a new change
for 1.2 that already improves the most common VM operations by 3X!!!!!
I measure 4X and DG measures 3X.

We do support clustered pageins and do bypass the buffer cache.  If 4.4
has good ideas, we will integrate them with ours, then we will have the
best of both worlds.  Remember, the changes that we have made to the
VM system do not affect the API at all!!!!!  So anyone running on other
BSD variants might give us a try.

Being honest, though unless you are a really experienced kernel hacker,
wait until the release comes out.  The upgrade procedures can be tricky
and the automated procedures are much safer.

One more thing, re: clustered pageouts... there is little need on our code,
because we do get practically disk transfer rate bandwidth already.

I would not have sent this message except the tone of Charles' comments
was not respectful and I would not have commented negatively publically
about his groups achievments (multi-platform.)  We will probably go
multi-platform when the improved VM code and other things are *fully*
included.  If anyone wants to correspond, mail me at 'dy...@implode.root.com'
and any ideas that are submitted and included will get proper attribution.

Remember, FreeBSD is being used in *real* work and my A** is really on
the line.  IT WILL/DOES WORK!!!!

Anyone who has directly worked with me on BSD has usually been pleasantly
suprised with how easy I am to get along with.  Charles, next time that
you have technical questions that you cannot answer, just talk to me... I am
really very nice... (1-317-547-8347).

John Dyson
dy...@implode.root.com

Congrats, John!  You've just won the first Rob Kolstad (Used Kernel
Salesman) award!

In article <hq5JeSv.dys...@delphi.com> John Dyson <dys...@delphi.com>
writes:

   The new pmap code is *significantly* improved over the *old* pmap
   code which is essentially what NetBSD is using ( some uninspired
   tweaks.)

That is fallacious.  Had you looked, you'd find that most, if not all,
of the changes in `your' pmap module are identical to ones I did in
`ours' (with the exception of the bit of assembler code).  I actually
compared the code out of curiosity.

   (BTW, pmap is a *small* *small* part of the performance puzzle.)

No joke.  I wonder why you even brought it up.

   [...] and produced the *most* robust driver for ethernet cardS that
   I have ever heard of.  It is great because it *really* works for so
   many card types.

You sound like a used car salesman.  I've seen plenty of such drivers
equally as reliable, and even more so because they don't rely on a
buggy chip.  I also compared `his' NE[12]000 code and found most of it
textually identical to the code I sent him (which was based on, but
not the code from the original if_ne driver).

   Remember, FreeBSD is being used in *real* work and my A** is really
   on the line.  IT WILL/DOES WORK!!!!

And so is/does NetBSD.  I've talked with people who use it for a wide
variety of `real' work.

--
- Charles Hannum
  NetBSD group
  Working ports: i386, hp300, amiga, sparc, mac68k, pc532.
  In progress: pmax, sun3.

Congrats, John!  You've just won the first Rob Kolstad (Used Kernel
Salesman) award!

In article <hq5JeSv.dys...@delphi.com> John Dyson <dys...@delphi.com>
writes:

   The new pmap code is *significantly* improved over the *old* pmap
   code which is essentially what NetBSD is using ( some uninspired
   tweaks.)

That is fallacious.  Had you looked, you'd find that many of the
changes in `your' pmap module are identical to ones I did in `ours'
(with the exception of the bit of assembler code).  I actually
compared the code out of curiosity.  The ones that weren't are mostly
irrelevant.

   (BTW, pmap is a *small* *small* part of the performance puzzle.)

No joke.  I wonder why you even brought it up.

   [...] and produced the *most* robust driver for ethernet cardS that
   I have ever heard of.  It is great because it *really* works for so
   many card types.

You sound like a used car salesman.  I've seen plenty of such drivers
equally as reliable, and even more so because they don't rely on a
buggy chip.  I also compared `his' NE[12]000 code and found most of it
textually identical to the code I sent him (which was based on, but
not the code from the original if_ne driver).

   Remember, FreeBSD is being used in *real* work and my A** is really
   on the line.  IT WILL/DOES WORK!!!!

And so is/does NetBSD.  I've talked with people who use it for a wide
variety of `real' work.

--
- Charles Hannum
  NetBSD group
  Working ports: i386, hp300, amiga, sparc, mac68k, pc532.
  In progress: pmax, sun3.

In article <MYCROFT.94Feb19131...@duality.gnu.ai.mit.edu> mycr...@duality.gnu.ai.mit.edu (Charles Hannum) writes:

Please, please!!  Not these juvenile *BSD wars again.  Any more of this
and I'll switch to Linux.  Can't you people ever stop.

--

        -- Lennart Augustsson
[This signature is intentionally left blank.]

actually these posting are absolutely relevant to the inital msg in the
thread, though confirmation was unnecessary. The answer is no.

cheers
Danny Thomas

I really apologize to people for my response to the attack on me.  I did not
really know what I was getting into.  I guess that I will just stay to myself
and get real work done.  There is really a positive side to the work that
all of the *BSD groups have been doing, and I wish that people would get
rid of the us/them arguments.  The *BSD that I am using is the best u**x
that I have ever used, and I am sure that other variants are good too in
their own ways.

Take care, and my sincere apologys from/for myself

John Dyson
dy...@implode.root.com

        ok, in regards to Net/FreeBSD vm wars, why doesn't someone write
a vm info / benchmarking program to compare the two?  then, we could
have something REAL to fight about :)
        This someone could be me, btw, if there isn't a program out
there already.  I'd jsut need a little info on vm type stuff.  I'd
actually like to, it would teach me a thing or two :)

--
     ++Joel;

In article 4...@harpo.uccs.edu, jmw...@elbert.uccs.edu (Joel M. Ward) writes:

This is a chicken-and-egg issue.

Making a benchmark to find out which VM system is the best (fastest,
least or most aggressive, ...) depends on choices. You'll have to
fight religious battles on what exactly you want to measure and how
much you will take this feature into account versus the others.

Simplification of the problem: will your benchmark use a couple of
really big programs or will it use lots of small ones. Will these
be all the same applications, or will they all be different ones.

etc.

        Danny
--
        Danny Backx
        System Engineer

E-Mail: d...@sunbim.be    (or uunet!mcsun!ub4b!sunbim!db)

Telephone: +32(2)759.59.25      Fax : +32(2)759.47.95

Postal Mail :
        Danny Backx
        BIM
        Kwikstraat 4
        3078 Everberg
        Belgium

In article <2kgnia$...@harpo.uccs.edu> jmw...@elbert.uccs.edu (Joel M. Ward) writes:

           ok, in regards to Net/FreeBSD vm wars, why doesn't someone write
   a vm info / benchmarking program to compare the two?  then, we could
   have something REAL to fight about :)

Or better yet: Send a copy of each to Dennis Ritchie and Ken Thompson
so that they may decide which one is the one true Unix and settle this
issue one and for all.

This bitching on the other *BSD (from either side) is just plain boring.

--
        Sascha Wildner, Am Druvendriesch 27, 50354 Huerth, Germany

                         A happy FreeBSD user.