I'm going to print your mail, and read it every night.
thanks.
> El 15 sept 2017, a las 20:07, Brian L. Stuart <blstu...@bellsouth.net>
> escribió:
>
>> On Fri, 9/15/17, Marshall Conover <marzhal...@gmail.com> wrote:
>>
>> I'll start digging in to see what I can do. I think I jumped the
>> gun by trying to contribute a feature, ...
>
> On this point, I'd suggest a slight shift of perspective. This is something
> that I've tried to convey both to collegues when in industry and to
> students when teaching. Don't think in terms of implementing features.
> Think instead of implementing mechanisms. The mindset where every
> feature is implemented with its own mechanisms is the reason so much
> software is so poorly engineered. Witness the browsers mentioned
> earlier. Good engineering involves designing and selecting a good
> set of simple mechanisms that when used in various combinations
> provide a rich set of features. If a mechanism doesn't fit, don't include
> it. Remember that perfection is achieved not when there's nothing
> left to add, but when there's nothing left to remove.
>
> Bringing this back to bind, I wouldn't think of bind itself as a feature.
> However, when the bind mechanism is used in conjunction with the
> union directory mechanism and the architecture environment variable,
> the feature of sane multi-architecture binary handling emerges. No
> where in the source of the shell or the kernel or anywhere else is
> there code specifically designated to make it possible to run the
> correct binary based on the architecture. Of course, there are
> other ways of accomplishing this feature, such as a path variable,
> but the beauty of this approach is that all of the mechanisms involved
> also find application in other features. For example, bind and per-
> process name spaces make possible the elegance of rio which
> in turn provides the feature of recursively running rio inside a rio
> window, something that takes a lot of special effort in X. Likewise,
> when bind is used with import, you can get a particularly elegant
> form of network gatewaying. So I suggest not thinking of bind as
> a feature, but as a very general tool for building features.
>
> One objective when implementing a mechanism is that is reduces
> the amount of code in other places by more lines than it takes
> to implement the mechanism. There are two major reasons why
> it's important to keep the number of lines of code down. First,
> every line is a potential bug. To a first approximation, the fewer
> lines of code the fewer places where you might have bugs. Second,
> every individual and organization has a maximum level of complexity
> that it can manage. Once that point is hit, all new releases merely
> rearrange the bugs. They don't really make the product any better.
>
> A well designed set of mechanisms is like a set of basis vectors
> and each point in the vector space is a potential feature. If your
> set of features isn't larger and richer than the set of mechanisms,
> then you should go back and rethink the set of mechanisms. So
> when adding a mechanism, you want to make sure you're adding
> a new dimension to your feature space.
>
> BLS
>