Subject: Re: MP/Threading...
To: Lord Isildur <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 03/21/2001 22:17:33
On Wed, 21 Mar 2001, John Hawkinson wrote:
# > No decision has been made as to what point we will move to 2.0 from
# > 1.x; there's lots of unrefined speculation.
Point taken, especially regarding MP, but I think perhaps I may have been
unclear. Obviously, MP is going to have to be tested, and that means
wide distribution; I just thought there'd be a way to have it tested and
done through the ones who like to follow the bleeding edge (like myself
as soon as I can get an MP box!) so that the more casual users (the ones
who go for the releases) will have something that they won't have to
guinea-pig (that's what the daring ones are for!).
Obviously, it was an unreasonable demand, and I apologise for being the
idio^Wsysadmin trying to wield the wand of the kernel wizard; please, I
meant no affront by what I was saying.
On Thu, 22 Mar 2001, Lord Isildur wrote:
# and lets keep it this way. All the rest of the world has felt this
# incredible pressure to keep changing version numbers. Until theres a
# _bloody_ good reason to start using 2, lets keep to version numbers that
# have meaning.
I think kernel MP is a damned good reason to go to 2.x. I don't see a
reason to bump the major number until then. And it COMPLETELY eludes me
as to what in the world would ever cause us to go to 3.x, assuming that
we last that long without complete degeneration into just another not-quite-
linux (something of which I'm not wholly convinced).
# we're at 1.5. logically, the next version, which should
# not really be dictated by a calendar but by a significant enough change in
# the system to warrant it, willbe 1.6. 1.7 would logically follow 1.6 and
# so on and so forth, 1.11, 1.15, or whatever, down the line.
# if suddently some really importantly big change takes place, maybe then
# one could go to 2's.
Isildur, I was HARDLY suggesting that we immediately jump to 2.x regardless.
But going to MP seemed to me to be a significant enough improvement to
# > We do not decide whether to release or not to release on the basis of
# > a SINGLE FEATURE.
I was rather thinking, foolishly, at the time, that we could keep MP in the
-current area, or in -current-mp (uck, this is looking even uglier now
that I'm typing it) while never dropping it into an official release until
finer locks were available. As soon as I began trying to verbally
rationalise that, I began to see why that wouldn't work, which was why I
didn't press the issue on that.
# > Obviously we'd love to see more finer grained locks,
# > but we certainly will not hold back a release for it. It can be in the
# > next release.
Point taken. Well, I've shown off my assh^Wopinion on versioning,
which was *not* the point of the original posting. The emphasis was
on the differentiation between BigLock [TM] and finer locking.
The initial sarcasm with which I was met was rather disheartening, but
it did show that I was off base (which was what I was asking in the
So now that the flames and sub-flames have sprung and hopefully died,
we now return you to your regularly scheduled technical discussion.
*BSD: The server is up!