"Brandon D. Valentine" wrote:
> On Tue, 25 Apr 2000, Daniel C. Sobral wrote:
> >Because if we do not provide a STABLE ABI, we WON'T get third-party
> >(binary only) kernel modules.
> >
> >I'm very divided in this issue. 4.x has just started, and would be
> >seriously impaired if no further improvements to it's SMP get in.  On
> >the other hand, if we can't garantee third party vendors a stable ABI,
> >we won't get third party vendors.
> The number one excuse large third party server vendors use to justify
> use of NT over Linux on their high end SMP systems is the poor
> performance of Linux SMP.  This is a tremendous opportunity for FreeBSD
> to take market share.  People are seeing the virtues of free, open
> source operating systems in the server farm and providing top notch SMP
> support in FreeBSD will help to see that we make further inroads that
> the Linux guys do.  If the BSDi code assists us in improving SMP
> performance and if the corporate backing helps our PR image, then we
> could be in for a fun ride.  This is the time to start thinking in terms
> of "What can we do better?" or we're going to lose the battle.  Sure,
> those changes could go into 5.x and be released when RELENG_5 is
> branched a year from now.  But in this business, a year is 6 months too
> late.  Think about that before you object to what appear to be vast
> improvements in the performance of the RELENG_4 branch while it is just
> getting off the ground.

I totally disagree, my experience is that commercial users upgrade not
more than once a year and they expect things to continue working on
their chosen branch for that year and to continue to receive bug fix
support on that branch (most places upgrade much less often than once a

"a year is 6 months too late" is true for development branches but it is
not the case for production code. Having a happy user base will mean
that a FreeBSD 5 with improved SMP will be anticipated and widely
adopted when it is released sometime next year (I'd hope). The more we
piss off the production users with unnecessary incompatibilities in
stable branches the more entrenched they become with their existing
releases, regardless of the improvments in later versions, because they
don't trust the project to have a professional release strategy. I've
seen this happen already and early adopters of 4.0 are going to be
really pissed off to find that there is an ABI change in a stable
branch. Most commercial users are not developers, and have no interest
in anything relating to development. Professional sysadmins are
conservative creatures, they expect professional quality code to play by
the rules of the industry and those rules are widely accepted as meaning
that stable branches do no undergo ABI changes. Such changes are
reserved for major upgrades because of the consequences and risks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to