[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: design goals vs mechanisms (was: Re: Let's do some coding :-)
From: |
Jonathan S. Shapiro |
Subject: |
Re: design goals vs mechanisms (was: Re: Let's do some coding :-) |
Date: |
Wed, 26 Oct 2005 17:31:07 -0400 |
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
- Re: Let's do some coding :-), (continued)
- Re: Let's do some coding :-), Jonathan S. Shapiro, 2005/10/26
- design goals vs mechanisms (was: Re: Let's do some coding :-), Marcus Brinkmann, 2005/10/26
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Bas Wijnen, 2005/10/26
- Re: design goals vs mechanisms, ness, 2005/10/26
- Re: design goals vs mechanisms, Bas Wijnen, 2005/10/27
- Re: design goals vs mechanisms, Marcus Brinkmann, 2005/10/27
- Re: design goals vs mechanisms, Jonathan S. Shapiro, 2005/10/27
- Re: design goals vs mechanisms, Marcus Brinkmann, 2005/10/27
- Re: design goals vs mechanisms, Brian Brunswick, 2005/10/27
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Jonathan S. Shapiro, 2005/10/26
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-),
Jonathan S. Shapiro <=
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Marcus Brinkmann, 2005/10/26
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Jonathan S. Shapiro, 2005/10/26
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Michal Suchanek, 2005/10/28
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Marcus Brinkmann, 2005/10/28
- Message not available
- Fwd: design goals vs mechanisms (was: Re: Let's do some coding :-), Michal Suchanek, 2005/10/31
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Jonathan S. Shapiro, 2005/10/28
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Michal Suchanek, 2005/10/31
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Jonathan S. Shapiro, 2005/10/31
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Jonathan S. Shapiro, 2005/10/26
- Re: design goals vs mechanisms (was: Re: Let's do some coding :-), Marcus Brinkmann, 2005/10/26