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
