cvs commit: src/sys/compat/linux linux_socket.c

[Scott Long]

Paul Richards wrote:
> On Thu, Mar 10, 2005 at 07:24:30PM +0100, Poul-Henning Kamp wrote:
> 
>>In message <20050310181903.GU98930 at myrddin.originative.co.uk>, Paul Richards wr
>>ites:
>>
>>
>>>That's the crux of FreeBSD's problem really. We can't tell the
>>>commercial world to change the way they work to suit what we want
>>>to do. If we want them to take FreeBSD seriously we have to fit
>>>with the expectations they have.
>>
>>No, the crux of FreeBSD's problem is the differing opinion on how
>>serious we want to be taken.
>>
>>I for instance, do not want "the commercial world", (by which we
>>in this case means "application producing companies") to take us
>>anymore serious than we are able to be.
>>
>>Being realistic about our capacity and ability is far more important
>>to everybody, than promising specific goals of dubious reachability.
> 
> 
> I have no disagreement with that position. In fact, raising this
> issue bolsters that position by showing just how far away we are
> from being able to produce a product suited to that sort of commercial
> environment.
> 

Oh, please stop the FUD Paul.  This argument is just getting silly.
You've now turned this thread into a diatribe of why FreeBSD isn't 
suitable for a commercial environment.  Just relax for a minute, and
consider that your view of the world isn't the same as others, and
that professing your view of the world doesn't make it any more correct
nor does it help promote FreeBSD.  K, thanks!

Now that that is said, we as a project will do the best that we can to
support backwards compatibility.  We can't guarantee that because
significant security or reliability fixes might preempt that, but we
will also do our best to document what changes need to be bad and to
keep then as minimal as possible.  Now, for forwards compat, what you
are saying is that all APIs present now in RELENG_5 should be completely
frozen and never touched.  Well, what you are actually describing is
a RELENG_5_X branch, where everything is frozen, and only critical
bug fixes and security fixes are made.  RELENG_5 is still a development
branch, though it is a stable one where only tested features and fixes
are committed.  Making it completely frozen makes it nearly impossible
to have future releases that maintain the state of the art.  If the
only time that a new feature, or even a new, non-conflicting flag is
allowed to be introduced is at a major rev, then we'll quickly fall out
of relevancy since there will be no point in waiting 18-24 months for
minor improvements to be allowed out of the gate.

So, contrary to your uninformed and closed view of the world, there is
quite a bit of software out there for other OSes that sets minimum
version levels for the OS that often happens mid-stream for the major
cycle of that OS.  It happened with OSX 10.2.4, it happened with MacOS
7.6, it happened with NT 4.0 SP3, it happened with W2K SP2, and I'll bet
a dollar that it will happen with WinXP SP2.  The major Linux vendors
don't even try, and ISVs and IHVs often wind up shipping a version of
their software for every point release, or just tell people to use a
certain point release and don't call them if a different point release
doesn't work.  I've developed commerical apps for major companies for
all of these OS's, so I think I can speak with some confidence here.
What we are doing in FreeBSD is no different than any other OS, and it's
a strong improvement over the API anarchy that we had before.  So
instead of throwing up your hands and declaring that no one understands
you and that FreeBSD is doomed, consider the opposite opinion that we
are taking positive and appropriate steps to be more commercially
viable, and that those steps are in line with other OSes.

And if you change your argument again to find yet another different
angle that you can whine about, I'll k-line you.  Thanks,

Scott