Re: [9fans] The Case for Bind

["Fran. J Ballesteros" <nemo@lsub.org>]

I'm going to print your mail, and read it every night. 
thanks. 

> El 15 sept 2017, a las 20:07, Brian L. Stuart <blstuart@bellsouth.net> escribió:
> 
>> On Fri, 9/15/17, Marshall Conover <marzhall.o@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
>