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.


Reply via email to