Re: design goals vs mechanisms (was: Re: Let's do some coding :-)

[Jonathan S. Shapiro]

On Wed, 2005-10-26 at 22:43 +0200, Bas Wijnen wrote:

> - support for legacy applications

It is traditional to imagine that this requires source API
compatibility. In non-open systems, it often means binary compatibility,
and legacy support tends to become "all or nothing".

There are two alternative choices that are possible for Hurd:

1. Settle for 90% or 96%. Give up some fraction for the sake of a
   long-term maintainable, principled system design.

   How painful this is depends on whether the 10% (or 2%,
   or whatever) includes applications you care about.
   Unfortunately, it is very difficult to know this without
   trying it.

2. Declare that in some cases small and well-localized source changes
may be okay. One of the HUGE advantages of open source is that we CAN
get changes integrated upstream, and/or maintain port patch-sets as the
xBSD systems have done. Of course, upstream integration is better. There
are a small number of GTK calls, for example, where a change might
involve only two or three lines of well-localized source change in the
calling application, but would result in a significant improvement in
security -- including an improvement on Linux/BSD/etc.

I think that both of these options need to be viewed cautiously, but we
should not forget the additional options that open source creates.

It is useful to remember that one UNIX is not perfectly source
compatible with another anyway. Up to a point, these kinds of small
changes can be viewed as one more small compatibility gap.


shap