Please let me inject a perspective from another (non-OS) world. In an automated system (e.g. an OS without "tunables" as discussed above), the system inputs are not controls telling the system what to do, but rather parameters that tell the system things that it cannot possibly know, such as what you like, your priorities, etc.
They present a paradigm which allows the user to leverage the automation to do the dirty work to accomplish his goals. This paradigm must be very carefully thought out with foresight so that it will remain robust and easily expandable into the indefinite future. The appropriate questions are "What are we REALLY trying to accomplish here?" "What are we likely to want to accomplish in the future?" "Assuming we are successful (else we should go home), what will the next set of issues and problems be, after *today's* problems are behind us?" "In what dimensions will the system grow?" "What new dimensions will be added"? "What does the *user* really need?" "What are *they* trying to accomplish (after all, this may be fun, but that is not why they are paying us to do this!)?" Once these are answered, "What are the orthogonal dimensions that are appropriate BOTH to describe what we are trying to achieve, AND the implementation technology (This ensures that you have a good, implementable solution *today*)?" "What aspects of *today's* implementation technology are apt to fade away tomorrow, vs. are intrinsic in the problem space?" All this results in a system that is elegant and gracefully absorbs future feature requests because the solution space created by the architecture is parallel to the dimensions of the true problem space. Things you never thought of, the system already [almost] [or sometimes completely] comprehends. There are an infinite number of solution spaces which will successfully intersect the problem space, but they will break painfully and require inordinate effort to grow to the extent to which they intersect (steep angle) vs. being parallel. It is critical that the system be thoroughly thought out in this manor UP FRONT, so that the first deliverable can be a trivial, degenerate case that you can deliver quickly and reliably (and it works!), yet its capability can grow internally while remaining forward and backward compatible into the indefinite future. Plan for success, not fix-ups, modes, versions, and trap-doors later. Include versions too to accomodate your inevitable residual shortsightedness. (End of soap-box). Yes, the system should analyse and adapt to varying conditions internally, but this does not mean that it should not have "tunable" inputs. It means that those tunable inputs should be oriented toward explaining to the system what it is trying to achieve, vs. what it should do. Its decisions may be different depending on whether you prefer to give priority to network disk accesses or local interactive processes, to manage a disk cache for maximum throughput and minimum response time, or to minimize disk usage to make the most memory available for local processes. I expect that these are mickey-mouse (though real) examples in comparison to what a serious effort would develop. The job of the automation is then to make internal decisions (tune internal parameters if you will, but this model may not be accurate depending on implementation) to achieve what you expressed through the paradigm presented externally. Thanks for listening. Hope it helps. --Ray Clark This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
