Any guesses as to when is 3.0 -release is going to come out?

Tnks,
Amancio

Sometime in the spring of 1998. And that's as specific as I'm
going to get. :)

>Any guesses as to when is 3.0 -release is going to come out?
>
> Tnks,
> Amancio

On Tue, Dec 02, 1997 at 01:24:18AM -0800, Jordan K. Hubbard wrote:
>>Any guesses as to when is 3.0 -release is going to come out?
>
>Sometime in the spring of 1998. And that's as specific as I'm
>going to get. :)

What, another 9 to 12 months? What will you do in the meantime?

Greg

>On Tue, Dec 02, 1997 at 01:24:18AM -0800, Jordan K. Hubbard wrote:
>>>Any guesses as to when is 3.0 -release is going to come out?
>>
>>Sometime in the spring of 1998. And that's as specific as I'm
>>going to get. :)
>
>What, another 9 to 12 months? What will you do in the meantime?
>
>Greg

Cool, ISPs will not run SMP for a very , very long time!

Great!!!
Amancio

>Cool, ISPs will not run SMP for a very , very long time!
>
> Great!!!

I'm never sure when Amancio's being sarcastic or not on account of the
fact that he always talks this way but, just in case he was, let me
simply say that ISPs steering clear of SMP right now is actually A
Good Thing. Before we're ready to start telling customers that it's a
good, cost-effective idea to purchase and operate x86/SMP systems, we
need to be sure of several things:

o That there are compelling performance reasons for
running "typical" applications (those being web servers,
interactive users, news servers, whatever) on SMP
configurations, and at which number of CPUs this becomes
most (and least) cost-effective.

o That the SMP design and implementation has stabilized to
the point where no unforseen traumas are likely to occur
during the customer's tracking of the 3.0 branch (which
we must, as usual, encourage).

o That appropriate developer's interfaces exist for taking
specific advantage of SMP, be it by way of kernel threads,
mutexes or whatever mechanisms are generally the rage among
SMP applications developers that week. We cannot forget
the people who will be in the "first wave" of trying to
make various real-world problems work faster since they'll
be our staunchest advocates (or loudest detractors) if we
don't provide them with all the necessary support for
making SMP (and FreeBSD in general) look like a wise
decision to their employer(s).

In other words, let's get psyched about SMP and keep helping the likes
of Steve Passe to test and improve our SMP support, but let's not jump
the gun and try to "sell" this as something to be used for actual
production purposes before all the proper pieces are in place and we
can recommend it with real confidence in our numbers, our stability
and our feature set. Getting to that stage is going to take the time
it takes, and I don't predict rapid so much as steady progress on that
project.

And even so, for those final remaining ISPs who are in the "I don't
care how dangerous it is, just let me try it for myself!" category
(you know, the same ones who occasionally parachute to work and land
in the parking lot or free climb the side of the building to their 8th
floor offices, just to stay in practice), we have 3.0-current and the
current.freebsd.org snapshot server just waiting to deliver the latest
bits in a convenient selection of formats.

To put it another way, if you want the release du-jour then you've got
it, ready to install or upgrade you to very the latest bits. If you
want one with 6 months worth of refinement and testing put into it,
you wait 6 months. It's darn simple, really! :-)

Jordan

I believe that it is *critical* that we don't set up any false
hopes, and extolling the virtues of half baked code is something
to avoid. Some of my code has been in that category, and I hope
that we have learned from those mistakes. It is okay, for example,
given the state of the code, for us to say that SMP works in -current.
That warns the users of the beta or even incomplete nature of the
implementation. More and more, we are in the position of FreeBSD's
performance and quality being "paraphrased: better than expected",
but of course not perfect. I hope that we stay in that position.

Perhaps we are getting more conservative, but that is probably
natural given the project's maturing. One thing for sure, if we
start becoming overly conservative and stagnent, I will be one to
try to push things along.

I tend to agree with the position that we have more time to go before
3.0 is ready... Those users who really really want SMP, kernel
threads, AIO or whatever fancy new feature that is going into
-current will have to realize that the code is pre-release and
immature, and tracking the code will require more effort than code
that is released and stabilized.

Here is a case in point, I just committed a "fix" to support the
MS_SYNC msync flag. The logical value for it is "0", at least a
couple of commercial U**X's have chosen "0", but a couple of other
free U**X's have chosen "4". The value that I chose *might* be
changed, and if it is, it will have been because of good reasons.
Someone using the code in production will likely not be too pleased
by such a change, but we need the freedom to issue such corrections.
-Current is just not ready for release, and there is alot to do for
us to meet reasonable goals for 3.0.

It is possible that a release could occur before *everything* is done,
but that is a bridge that doesn't appear to be time to cross.

John

 * From: "John S. Dyson" <dys...@FreeBSD.ORG>

* I tend to agree with the position that we have more time to go before
* 3.0 is ready... Those users who really really want SMP, kernel
* threads, AIO or whatever fancy new feature that is going into
* -current will have to realize that the code is pre-release and
* immature, and tracking the code will require more effort than code
* that is released and stabilized.

You are absolutely right. But only problem is that there are pretty
stable things (like 2-way SMP) as well as definitely work on progress
stuff (AIO to pick the latest example). Since we only have one
-current, we can't cut 3.0R until everything stabilizes. Which is a
real shame, because we are losing the market share right now to those
who already offer SMP in their releases.

No, I don't know what we should do. We definitely don't want to
branch the tree any further, and merging SMP into 2.2-stable is out of
question. It's just frustrating to me (who's pretty much an outsider
when it comes to /usr/src) to watch the 3.0 release date slip and slip
while there is already quite release-quality work in there.

Satoshi

>You are absolutely right. But only problem is that there are pretty
>stable things (like 2-way SMP) as well as definitely work on progress
>stuff (AIO to pick the latest example). Since we only have one
>-current, we can't cut 3.0R until everything stabilizes. Which is a
>real shame, because we are losing the market share right now to those
>who already offer SMP in their releases.
>
>No, I don't know what we should do. We definitely don't want to
>branch the tree any further, and merging SMP into 2.2-stable is out of
>question. It's just frustrating to me (who's pretty much an outsider
>when it comes to /usr/src) to watch the 3.0 release date slip and slip
>while there is already quite release-quality work in there.
>
>Satoshi

I know you all are goint to yell at me for this, but... I am using -current
on a production system. I needed SMP support, and couldn't wait, and didn't
want to switch to linux.

The only problem I see with what I'm doing is nfs file corruption(which is
rare, and minor). I know there's a lot of code being played with, tested,
etc. but it all seems stable.

A -current machine is handling www.mk4.com (2,000,000+ hits per month),
several shell accounts, and other heavy uses. (and it's running rc564 in the
background) The only crashes I've had were from nfs locking up after it's
server was rebooted, and from some bad simms....

But you are correct in assuming that you are going to lose market share by
waiting. If -current hadn't been stable when I grabbed it first, I probably
would have switched to linux, and probably not switched back.

I've got nothing to do with development here, but I know a lot of us lowly
users would *really* appreciate either a quick 3.0 release after everything
that's being worked on is 'done', or something similar.

The 2.2 series is really getting out of date. :)

Kevin Day
DragonData

Hi,
>You are absolutely right. But only problem is that there are pretty
>stable things (like 2-way SMP) as well as definitely work on progress
>...
>real shame, because we are losing the market share right now to those
>who already offer SMP in their releases.

SMP is definately NOT ready for prime-time. I'm going to be spending most
of december working on it, my goal is to hash out a design for "the real
thing". Some major design changes to the kernel will be necessary, there's
likely to be blood on the floor b4 we're done... Tune in to sm...@freebsd.org
to participate in the discussions.
--
Steve Passe | powered by
sm...@csn.net | Symmetric MultiProcessor FreeBSD

On Wed, 3 Dec 1997 17:43:11 -0600 (CST), Kevin Day
<toa...@home.dragondata.com> wrote:

>But you are correct in assuming that you are going to lose market share by
>waiting.

How can you even call it a "market" when it's free? Walnut Creek is
never going to become a Microsoft by selling FreeBSD CD-ROMs for $39,
even if they sell a blue million of 'em.

John

>On Wed, 3 Dec 1997 17:43:11 -0600 (CST), Kevin Day
><toa...@home.dragondata.com> wrote:
>
>>But you are correct in assuming that you are going to lose market share by
>>waiting.
>
>How can you even call it a "market" when it's free? Walnut Creek is
>never going to become a Microsoft by selling FreeBSD CD-ROMs for $39,
>even if they sell a blue million of 'em.

No. I'm not talking about Walnut Creek. :)

I just mean that if there wasn't a SMP kernel available anywhere, I would
have moved to Linux, and probably switched all my machines.

If I didn't feel comfortable paying with experimental software, I wouldn't
have tried at all, and definately gone with Linux.

I'm saying that I think it would be a shame to lose FreeBSD users because of
a lack of features that other OS's have, and no-one has even given a rough
date that these features will be available.

Kevin

 * From: Steve Passe <sm...@csn.net>

* SMP is definately NOT ready for prime-time. I'm going to be spending most
* of december working on it, my goal is to hash out a design for "the real
* thing". Some major design changes to the kernel will be necessary, there's
* likely to be blood on the floor b4 we're done... Tune in to sm...@freebsd.org
* to participate in the discussions.

Oops, sorry. Obviously my impression has been wrong.

Satoshi

Satoshi,

> * From: Steve Passe <sm...@csn.net>
>
> * SMP is definately NOT ready for prime-time. I'm going to be spending most
> * of december working on it, my goal is to hash out a design for "the real
> * thing". Some major design changes to the kernel will be necessary, there's
> * likely to be blood on the floor b4 we're done... Tune in to sm...@freebsd.org
> * to participate in the discussions.
>
>Oops, sorry. Obviously my impression has been wrong.

Perhaps I overstated the issue, I get up times of many weeks on my dual P6
here that is used as a development system. Obviously many others are also
using SMP for real work. But the efficiency just isn't there yet. We
would bench very poorly against a good SMP system, and thats what needs
improvement b4 we go prime-time with SMP.

--
Steve Passe | powered by
sm...@csn.net | Symmetric MultiProcessor FreeBSD

>I just mean that if there wasn't a SMP kernel available anywhere, I would
>have moved to Linux, and probably switched all my machines.

Great, feel free.

>If I didn't feel comfortable paying with experimental software, I wouldn't
>have tried at all, and definately gone with Linux.

Then why are you using Linux/SMP?

>I'm saying that I think it would be a shame to lose FreeBSD users
>because of a lack of features that other OS's have, and no-one has
>even given a rough date that these features will be available.

The people who run the 'OS of the day' aren't that critical to FreeBSD's
success, since there will *always* be something that causes them to
switch to another OS.

Nate

>Perhaps I overstated the issue, I get up times of many weeks on my dual P6
>here that is used as a development system. Obviously many others are also
>using SMP for real work. But the efficiency just isn't there yet. We
>would bench very poorly against a good SMP system, and thats what needs
>improvement b4 we go prime-time with SMP.

Luckily we only have to compete against Solaris and UnixWare, and not
good SMP systems... Dynix doesn't run on commodity hardware, and
neither does Unisys's SVR4.0.2 ES/MP (which did the locking the right
way instead of the Solaris/SVR4 way). And SMP SunOS 4.1.3 isn't
widely sold, and where it is, it's mostly Japan and Bay Area ISP's,
and then only on SPARC hardware...

Terry Lambert
ter...@lambert.org---
Any opinions in this posting are my own and not those of my present
or previous employers.

Nate Williams said:
>>I just mean that if there wasn't a SMP kernel available anywhere, I would
>>have moved to Linux, and probably switched all my machines.
>
>Great, feel free.

Let's all try to be kinder and gentler. We all understand that SMP is an
important feature, but also we shouldn't be inviting people away :-(.

--
John
dys...@freebsd.orgjdy...@nc.com