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

[Brooks Davis]

On Thu, Mar 10, 2005 at 11:55:10AM -0500, Brian Fundakowski Feldman wrote:
> On Thu, Mar 10, 2005 at 04:16:08PM +0000, Paul Richards wrote:
> > On Wed, Mar 09, 2005 at 11:13:39PM +0200, Maxim Sobolev wrote:
> > > M. Warner Losh wrote:
> > > >In message: <422F087F.9030906 at portaone.com>
> > > >            Maxim Sobolev <sobomax at portaone.com> writes:
> > > >: and need this tool to upgrade otherwise perfectly working system(s).
> > > >
> > > >As a veteran of ABI wars, I think that you have an unrealistic
> > > >expectations about what can be done.  While an interesting goal, too
> > > >many of the developers are hard wired to not even think about such
> > > >considerations to make it successful.  We have a hard enough time
> > > >making backward compatibility work, there's no hope for 'forward'
> > > >compatability.
> > > 
> > > As a junior of ABI wars I think I have a realistic expectation about 
> > > what can be done. Yes, many developers don't care about `backward' 
> > > compatibility, let alone `forward' compatibility, but in fact both are 
> > > really necessary in we want to position FreeBSD as a sound design.
> > 
> > >From a commercial standpoint, forwards compatibility is I think
> > actually more important. When you release a commercial product
> > you're actually more concerned about it working on already existing
> > systems.
> > 
> > Imagine something like Photoshop being written on the most recent
> > version of Mac OS X and finding that compatibility only worked
> > forward.  That would mean that most users out there would have to
> > upgrade their OS in order to use the most recent version of Photoshop!
> > What's most important commercially is that you can use the most up
> > to date development environment to target the largest possible
> > installed user base. It matters a lot less if you have to support
> > patches for newer systems since that's a much smaller user base to
> > support and the onward development of your own product tends to
> > keep pace with future platform changes.
> > 
> > A "stable" ABI means it doesn't change, not that it changes in a
> > backwards compatible manner. We should be able to enhance future
> > versions of a branch without creating these ABI incompatibilities
> > by supporting the existing interfaces until a future major release
> > removes them.
> > 
> > Better yet, lets stop "developing" our stable branches and focus
> > on stabilising them and getter more rapid development done in our
> > -current branch. There was a rash of MFCs for the next stable release
> > which were nothing more than a feature push and were of dubious
> > value in helping stability.
> 
> How is this even a problem?  The company targets 5.3-RELEASE, period,
> for all of 5.x.  They do not need to upgrade their build computer to
> anything past RELENG_5_3 even in the face of security issues.

This is certaintly how it's done in the Windows world.  If you want to
run on an older version you develop and compile on that version even
though it sucks compared to the newer one.  You still have to test newer
versions to make sure the vendor didn't change something out from under
you and that you don't use depreceated features, but development is done
on the oldest version you support.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20050310/6aedf815/attachment.bin