Windows' market advantage is hardly a result of its simplicity or ease of use. And the ton of settings isn't done through toggles and switches, but through Registry settings. Which is sort of like changing gears by taking the gearshift lever to a shop and re-shaping it on a lathe. In the dark, by informing a deaf-blind paraplegic through Braille.
The non-technical user has no clue, and the power-user bristles every time they have to deal with it.
"Sane defaults" is the best way to accomplish ease-of-use. A mix of autoconfiguration to task-at-hand and reasonable interface expectations.
At least CLI and assignment-based config files are both scriptable and manageable in version control (and hence, through configuration management systems such as cfengine / puppet / chef / etch, and source control (git, Hg, etc.).
Your car analogy made me chuckle. However, I think there are other items that it describes better than the Windows registry. For example, I remember using Ubuntu a few years back and discovering that the only way to change some system font setting (don't recall exactly which one) was to recompile a package from source.
Yeah, I recall an internationalization bug that required me to patch and build from source as well. Then again, it was pretty beta code.
I'll also add that I'm no fan of GNOME's bug-for-bug compatible reimplementation of the Windows Registry through gconf. At least the underlying data are slightly more accessible, but it's still a massive festering boil.
One system that I find works pretty well is WindowMaker. Configuration is through a set of textfiles, but most functionality is exposed through a pretty slick configuration utility. Since all of this is based on Steve Jobs's NeXT interface, I'm not overly surprised that it works pretty well most of the time.
When I configure a new desktop/laptop, I just port over the GNUstep directory. Every 6-12 months I may tweak a configuration setting, usually through the GUI utility. But if I want to I've got the full functionality exposed through files.
A realization I had a few weeks back is that GUIs are ultimately limited in their surface area and dimensionality. There's only so much functionality they can expose, and in any sufficiently rich interface, some stuff will be buried deeply, and inevitably, two configurations you'll want or need to tune together will be in utterly different branches of the config menus/interface.
With a CLI, all dimensions are uniform. If the interface is sufficiently broken, you can write a wrapper around it (a classic example is rlwrap, a readline wrapper around other commands, such as Oracle's utterly broken CLI SQL client). I'll frequently write one-off shell functions to put the argument I want to tweak at the end of a command line to make readline bash editing easier and more convenient.
Granted, this is power-user stuff, but it's what makes the shell environment so damned powerful and flexible.
And ... been meaning to amend my original post with this:
If what you build becomes sufficiently ubiquitous, then even a bad design becomes "intuitive", if only by way of familiarity.
Is it intrinsically "better" to drive on the left or right side of the street (it apparently mattered in days of knights on horseback and needing your sword arm where it could do some good). Probably not .... but once you make that decision, you'd damned well better stick to it, and there's a lot else that follows as a consequence.
The non-technical user has no clue, and the power-user bristles every time they have to deal with it.
"Sane defaults" is the best way to accomplish ease-of-use. A mix of autoconfiguration to task-at-hand and reasonable interface expectations.
At least CLI and assignment-based config files are both scriptable and manageable in version control (and hence, through configuration management systems such as cfengine / puppet / chef / etch, and source control (git, Hg, etc.).