Date: Wed, 30 Jan 2002 20:02:32 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>, Garance A Drosihn <drosih@rpi.edu>, Alfred Perlstein <bright@mu.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Jordan Hubbard <jkh@winston.freebsd.org>, Dallas De Atley <deatley@apple.com>, arch@freebsd.org Subject: Re: __P macro question Message-ID: <3C58C1D8.D6A71365@mindspring.com> References: <20020131030329.2E01C3A9A@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > > The point is that if I were wanting to use a freely > > available reference implementation of TCP/IP, right > > now I would prefer to use FreeBSDs implementation, so > > long as it remains portable to my platform. > > Well, our network stack is nowhere near K&R compliant, not by a million > miles. So forget that line of the argument. Willful negligence is not a philosophical argument. > > One of the *points* to using Open Source code at all > > is to reduce your maintenance burden and bootstrap > > overhead. > > Ahh you see, that is a problem. The FreeBSD project's purpose is to make a > viable free operating system, not to bend over backwards to make it > convenient for other vendors who want to take our code and run it on a cpu > from 1974 with a compiler from 1973. We the project have no such > obligations. *If* our code is useful, then go for your life. If not, then > too bad. We have no obligation to *support* some arbitary fictitious > vendor who is so damn cheap that they want to save 3 seconds of engineer > time to run unprotoize on components of our source tree. To my mind, the purpose of the project is to produce code, without attaching constraints on how or where that code can be used. The use of that code by as much of the ecological niche in which the code is suited as possible furthers another goal: it ensures interoperability of systems with otherwise dissimilar goals. In other words, it is the next step better than publication of protocol definitions. What is the point of a reference implementation, if it is never used as reference? The distinguishing feature that seperates FreeBSD and Linux is the license, and the uses to which the code can be put are, I think, the primary reason people choose to contribute to FreeBSD, over contributing to Linux. Anything which touches on the fundamental utility of the resulting code, whether it's a license change, or a style change or discontinuation of the use of a portability tool, *should* be considered carefully. > > While it is valid to state that there is other work to > > do, that other work is unavoidable. We are talking > > about increasing the avoidable work here. > > If you add up the number of developer hours that have been wasted over the > last 8 to 10 years on this subject and reapply it to kernel development, > we'd have *finished* SMPng by now. No we wouldn't. There is considerable dissent over the value of SMPng and the approach taken, and those hours would therefore have been applied to other tasks, if they were applied to code, at all. That is the problem with volunteer efforts: you can not schedule or level resources: people volunteer for what they volunteer for, or FreeBSD would have had a new installer by now. Even funding the work was not able to get this accomplished, because the funded work had to transit the gatekeeper(s). As Jordan has been heard to say, "it is like hearding cats". The only thing you can do is attempt to influence the gatekeeper(s), if there are any... as this thread is attempting to do, and is why you and I are participating in it still, I think. All in all, a clearer policy statement would have avoided the question that raised the issue, in any case. In my original posting in this thread, I noted both the currently stated policy which was apparently inadequately communicated (ANSIfication of new code, leaving old code alone), and the reasoning behind the __P() existing. Whether you agree with the validity of the reasons or not does not make them any less the reasons. All the fuss and blather of people reacting to their validity is a side issue, in any case. The only thing of value here is whether or not there will be a policy change on the basis of this discussion, and whether or not such a policy change will be a result of a consensus among the *BSD camps (in which case it should wait until BSDCON for discussion), or whether it will be made by fiat. -- Terry 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?3C58C1D8.D6A71365>