Re: Background to the argument about CML2 design philosophy

[Helge Hafting <helgehaf@idb.hist.no>]

"Eric S. Raymond" wrote:

> 
> To reduce the problem further, I looked for symbols with missing
> entries that I could turn into derivations, eliminating their
> questions and the requirement for a help entry.  

Adding help entries is nice.  But please don't go around
making "unlikely" choices unconditional in order to avoid writing
help text.  Leaving the help blank for such questions
is better than eliminating the question.

[...]
> By doing this I killed two birds with one stone -- got rid of some holes
> in Configure.help and (more importantly) moved the configuration experience
> away from low-level, hardware-oriented questions towards where I think it
> ought to be. That is, you specify a platform and the services you want and
> the ruleset computes the low-level facilities to be linked in.
> 

> 3. The MVME derivations are correct *if* (and only if) you agree to ignore
> the possibility that somebody could want to ignore the onboard hardware,
> plug outboard disk or Ethernet cards into the VME-bus connector, and
> do something like running SCSI-over-ATAPI to the outboard device.
> (I missed these possibilities when I wrote the derivations.)
> 
> I used case 3 to explore a touchy question about design philosophy, which
> is really what caused all hell to break loose.  The question is this:
> holding down configuration complexity is a good thing, but supporting
> all hardware configurations that are conceivably possible is also a good
> thing.  How should we trade these good things off against one another?

I'd say support all possible configurations that is supposed to work.  
You never know what someone might want to make out of 
spare parts and dusty old things.  

Particularly, not compiling (or modularizing) the driver for a built-in 
device is always a valid way of saving memory.  I don't compile IDE on
my
home pc, because all my devices are scsi.  And the built-in floppy
controller is modularized because it is so rarely used.  Why give
it permanent unswappable memory?

Your trade-off considerations should be wether "odd but possible"
choices
belong in an EXPERT category or if they should be there for everybody.
Don't consider eliminating something that would work.  Of course you
don't have to worry too much about help texts for the expert stuff - let
the experts add that themselves if you don't want to write for
fringe cases.

> The MVME situation is an almost perfect test case, because while
> breaking the assumption behind that derivation is physically possible
> it would be a rather perverse thing to do.  The VME147 is an old
> design, dating from 1988; it's long since been superseded by MPCxxx
> SBCs based on the PowerPC that have a better processor, lower power
> consumption, and more on-board peripheral hardware.  IDE/ATAPI didn't
> exist during most of its design lifetime, and the only way anyone is
> ever going to hook an outboard device to one of these puppies again
> is if some hacker pulls a dusty one off a shelf for some garage project.

Hackers get things like this for free when companies get rid of them, 
then turns them into mp3 players or hobby device controllers.

> So the real question here is whether it is ever acceptable to say that
> a possible configuration is just silly and ruleset will ignore it, in
Maybe it is acceptable to say something is too silly.  You have to
come up with a better example though.  People may definitely want to 
not have a driver, or make a module instead of compiled-in.

And they may want to not use the built-in device because they
use something better.  Like a fast ethernet connected to 
that old vme box because the net they connect to
is fast even though the box may be too weak to really
take advantage of it.  Or wide scsi instead of the built-in thing.

> order to hold down ruleset complexity and simplify the user
> experience.  The cost of deciding that the answer to that question is

The user experience can be simplified by a NOVICE/EASY/SANE_DEFAULTS 
option, and perhaps a HACKER option for the really strange 
but _theoretically_ ok stuff.

> "yes, sometimes" is that on rare occasions like this one you might
> have to haul out a text editor to tweak something in your config.  But
> the cost of deciding that the answer is "no" will be some pretty
> serious complexity headaches both in the configuration user experience
> and (down the road) in the maintainability of the ruleset.

If EXPERT options makes it too complex, consider having some rules
that are advisory only.  The debian packaging system has 
both absolute dependancies, and "suggestions".
Consider:
suggest MVME16x_SCC from MVME16x & SERIAL
which means that someone who turns on MVME16x_SCC and SERIAL
get MVME16x_SCC turned on when they do so.  
But the choice is visible and
it is possible for the user to turn it off at will.  Maybe shown in 
a different color or with some other hint that it is a defaulted
but overrideable thing.

Configuration gets simple for the vast amount of common cases,
but experts can do whatever they want.  
You could even have a user-interface option for not showing
such defaulted options.  That wouldn't complicate the rulebase,
it would be a UI-thing only.

Now you get both the simple rulebase and the nice user interface.
And satisfied experts.

Helge Hafting