5.4 vs. 6.0

[Danial Thom]

--- Chris <racerx at makeworld.com> wrote:

> Danial Thom wrote:
> >>>Kris is just a PR front man for a "team" of
> >>>developers that is lost. Their "theory" on
> >>
> >>how to
> >>
> >>>build a better mousetrap for MP is
> completely
> >>>wrong, and now they're going to try
> something
> >>>else, using the entire FreeBSD community as
> >>>guinea pigs. First 5.4 was the answer. Then
> >>
> >>6.0.
> >>
> >>>Now it looks like 6.0 sucks too. Its a damn
> >>>shame.
> >>>
> >>>DT
> >>
> >>IF you are such a man that can actually call
> >>himself an engineer - why
> >>hide behind Yahoo mail?

My company requires it

> >>
> >>Next, IF you are as you claim to be - WHY are
> >>you not on the "team" or
> >>at least contributing code?


I think your premise that all of the great
engineers contribute to open source projects is
broken. Perhaps Kris' participation makes him a
better chum than me, and it surely says that he
has a lot more time. As someone who doesn't
contribute significant code (although I have
contributed fixes and ideas over the years under
various aliases), perhaps you might say that I
have no right to criticize. I'll give you that to
some extent. But, as somone who built a product
on FreeBSD and has a significant financial stake
in its existence, I'm mad as heck that this
current "team" has taken a perfectly good O/S,
arguably the best networking OS around in 4.x,
and made it a lot worse. Considering that they
continually bamboozle us by saying how great the
next version is going to be (when they really
just want to have a few 100 people test it for
them), should give us a charter to be pissed off.

At least if they admitted things it would help.
Do some reading in lucky.freebsd.performance.
They are in total denial. Every time someone
complains about network performance they blame
TCP settings or some other ridiculous thing. They
continue to rely on netperf for their
measurements, and its just not the correct way to
test. The problem with netperf is that is loads a
machine to capacity and measures the capacity of
the system. The problem is that no-one runs their
machine at 90%+ cpu. Things change when you
approach "the wall" and when you load the bus, so
you're not really measuring the machine under
normal conditions. What you want to do is measure
the CPU load under high-normal working
conditions, which is more like 50-70% range. As
bus bandwidth diminishes and queues fill, timings
change, because non-normal conditions exist. So
the measurements they use are just wrong. Or at
least they are wrong in measuring the real
performance of a production system.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com