From owner-cvs-src@FreeBSD.ORG Thu Mar 10 17:02:44 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C3C116A4CF; Thu, 10 Mar 2005 17:02:44 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13EE743D1F; Thu, 10 Mar 2005 17:02:44 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j2AH2YfP026205; Thu, 10 Mar 2005 09:02:34 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j2AH2XhG026204; Thu, 10 Mar 2005 09:02:33 -0800 Date: Thu, 10 Mar 2005 09:02:33 -0800 From: Brooks Davis To: Brian Fundakowski Feldman Message-ID: <20050310170233.GA25556@odin.ac.hmc.edu> References: <422E407B.4080507@portaone.com> <86k6oht386.fsf@xps.des.no> <422F087F.9030906@portaone.com> <20050309.085035.129356491.imp@bsdimp.com> <422F6703.70409@portaone.com> <20050310161607.GO98930@myrddin.originative.co.uk> <20050310165510.GE993@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <20050310165510.GE993@green.homeunix.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Maxim Sobolev cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: alfred@FreeBSD.org cc: cvs-all@FreeBSD.org cc: des@des.no cc: "M. Warner Losh" cc: Paul Richards Subject: Re: cvs commit: src/sys/compat/linux linux_socket.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2005 17:02:44 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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@portaone.com> > > > > Maxim Sobolev 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. > > >=20 > > > As a junior of ABI wars I think I have a realistic expectation about= =20 > > > what can be done. Yes, many developers don't care about `backward'=20 > > > compatibility, let alone `forward' compatibility, but in fact both ar= e=20 > > > really necessary in we want to position FreeBSD as a sound design. > >=20 > > >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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. >=20 > 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 --=20 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 --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCMH2pXY6L6fI4GtQRAiDLAKDBv9R/OEDr4zbwzGhq/d4va91DJwCgnPuh Kj9RyZ5wIBSwmu1BHgnUV88= =Qsln -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn--