I really like this description. Thank you
> On Sep 15, 2017, at 2:07 PM, Brian L. Stuart <blstu...@bellsouth.net> wrote: > >> 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 >
