Date: Tue, 04 Jun 2002 23:56:21 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: arch@FreeBSD.ORG Subject: Re: Avoiding unnecessary breakage (was Re: Removing wait union) Message-ID: <41485.1023227781@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 04 Jun 2002 17:30:44 EDT." <200206042130.g54LUijN025978@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>>Many software vendors would say that a published interface can only be >>removed after two major releases of the software. One of the things which makes FreeBSD competitive, is our ability to adapt to changing circumstances. If we rigidly enforce inflexible rules like the one proposed above, we will loose most of that agility. Backwards compatibility is a heavy burden, one should not needlessly add to its weight. I agree that backwards compatibility should be sought, but not at any cost, and certainly not in a "one-size-fits-all!" corporate manner. The FreeBSD project is about doing things right, and in doing so we expose other pieces of software which didn't do things right. I'm sure many people here remember the havoc when we suddenly started implementing vfork(2) to spec ? Even inetd(8) broke as far as I recall. Or think about the countless bugs phkmalloc has exposed all over the place ? Is anybody seriously proposing that we should emulate the buggy behaviour of past malloc(3) implementations, just so that we don't break buggy software in ports ? [*] _Of course_ it is unfortunate that we break some number of ports improving FreeBSD, but that is exactly _why we have_ the ports collection in the first place: to be able to shield our users from buggy "all the world is a vax^H^H^Hlinux" software and changes in APIs and preferred ways of doing things. I think I can confidently guarantee that nobody in the project breaks things just to make anybody else' life miserable, they usually have much better reasons than that -- for instance that they want to make FreeBSD a better, cleaner and leaner operating system, instead of the amalgamated union of an endless sequence of backwards compatible hacks and wrappers which prevent progress from happening on timescales shorter than decades. Poul-Henning [*] This was a trick question: phkmalloc has exposed several problems which were potential security issues, most recently in libz. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41485.1023227781>