Could the BSD 4.4 Lite be a new beginning?
Heikki Suonsivu
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
Paul A Vixie
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-sou...@uunet.uu.net>, <vi...@bsdi.com>,
decwrl!vixie!paul <ftpmai...@pa.dec.com>, <vi...@sony.com>,
<pa...@vix.com> <{bind-workers,objectivism}-req...@vix.com>
John Dyson
>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
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
Timothy J Kniveton
Geoff Rehmet
>Heikki Suonsivu <h...@cs.hut.fi> writes:
>
>>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
>
>
>Hi, I am John Dyson, a core team member of FreeBSD. We have done
>alot to make the FreeBSD OS much more stable.
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 : cs...@cs.ru.ac.za | (*)/'(*) /\/\/\/\/\
: ge...@neptune.ru.ac.za (private) |
James H. Haynes
In article <g89r4222.761250723@kudu> g89r...@kudu.ru.ac.za (Geoff Rehmet) writes:
>seconds ! SunOS 4.1.1 survives crashme for between 30seconds to
>just under 30 minutes!)
>
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"
James Lee Robinson
"detremential" ?
--
// James Robinson ::: University of North Carolina at Charlotte \\
// jlro...@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."
Jordan K. Hubbard
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.
Geoff Rehmet
>OK -- I'll bite. What does `crashme' do, exactly? What about it is so
>"detremential" ?
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
Richard Tobin
>(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!)
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.T...@ed.ac.uk
"We demand guaranteed rigidly defined areas of doubt and uncertainty" - HHGTTG
SAVE MY WALRUS
/*
* 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.94F...@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.
Linus Torvalds
Richard Tobin <ric...@cogsci.ed.ac.uk> wrote:
>
>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.
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
UNIX hacker and security officer
[ 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."
Mark Sienkiewicz
Heikki Suonsivu <h...@cs.hut.fi> wrote:
>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 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.
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...
Charles Hannum
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.
Jordan K. Hubbard
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
John Dyson
>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.
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.)
> 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.
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!!!!!
> 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.
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
Charles Hannum
Congrats, John! You've just won the first Rob Kolstad (Used Kernel
Salesman) award!
In article <hq5JeSv...@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
Congrats, John! You've just won the first Rob Kolstad (Used Kernel
Salesman) award!
In article <hq5JeSv...@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.
--
Lennart Augustsson
> Congrats, John! You've just won the first Rob Kolstad (Used Kernel
> Salesman) award!
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.]
Danny Thomas
> myc...@duality.gnu.ai.mit.edu (Charles Hannum) writes:
>
> > Congrats, John! You've just won the first Rob Kolstad (Used Kernel
> > Salesman) award!
>
> and I'll switch to Linux. Can't you people ever stop.
actually these posting are absolutely relevant to the inital msg in the
thread, though confirmation was unnecessary. The answer is no.
cheers
Danny Thomas
John Dyson
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
Joel M. Ward
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;
Danny Backx
> 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 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
Sascha Wildner
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.
John Dyson
>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.
NetBSD VM stuff will be faster than the FreeBSD stuff and vice versa. The
criteria should/might consider other facets of the system too. Speed is
not the only issue, and even though I know how the VM stuff works, I
honest can't say how to measure ALL of the aspects of the system to say
which is really better in a general sense. I can still have opinions
and feedback (both positive and negative) from users stating their opinions.
I do have some benchmarks from various sources (including myself) that
I use to measure performance, but wow -- it would be a serious challange
indeed to come up with a VMMARK benchmark :-).
John
dy...@implode.root.com