[OT] Debian mailinglists [was: RE: Debian or Ubuntu?]

[Les Mikesell]

Derek Broughton wrote:
> 
>>>> Safer isn't usually the point.
>>> I disagree - I think it's the whole point.
>> Doing something no one anticipated it often the point.  Or repeating it
>> hundreds of times.  Neither works well in GUI's.
> 
> Why would "repeating hundreds of times" not work well in a GUI?  A properly
> designed GUI would let you enter the change once, and apply many.

How would that happen?  The repeated instances would be on different 
machines and/or at different times.  Command lines and text files are 
easy to recall/cut/paste and in many cases the documentation can be a 
pastable copy, where with GUI's you end up with screen shots of settings 
you have no way to reproduce without going through all the same motions.

>> There's a reason for that, which is that the programmer can't anticipate
>> what you want and for the same reason can't check that it is correct.
> 
> But he _can_ check that it's correct.

Not in general.

> For instance, to configure postfix as
> a smarthost, it needs to know your ISP's SMTP server name, port, and
> authorization information.  When you enter those into a config tool, it can
> open a connection to the server and test it.  

First, remember that postscript was written specifically to be easy to 
configure so you are cherry-picking an example.  Then consider that you 
may be configuring a machine to ship elsewhere and the tests you want to 
perform won't work when you need to make the change.

>> It's not trivial, and in the case of arbitrary settings isn't going to
>> help you anyway.  If you have a small list of choices that just have to
>> be spelled right, a wizard can help, but those aren't that hard to get
>> right by yourself.
> 
> It _is_ trivial.

Let me know when you are done writing it.

>> Start by assuming the program is wrong and that's why you have to fix it
>> and maybe you'll see the problem.
> 
> Which program?  The gui config tool? 

Any part of any program can be wrong.

> Why would I assume _it's_ wrong any
> more than I would assume somebody screwed up the config in an editor?

You haven't been doing this very long, have you?   Wade through the bug 
history on a few large programs to catch up.  It's a pretty safe 
assumption that every program has bugs and it's just as easy to make a 
mistake in program source as a config file. And you'll find some 
programs where the config file is actually a snippet of program source - 
this is pretty common with perl applications and gives you arbitrary 
freedom in what you put there.

>>> If I was your boss, I'd need a written explanation of exactly why you had
>>> to hand-edit a config file for a sensitive server before I'd permit it if
>>> there was a tool available for it.
>> If it is a sensitive server, the changes should be under revision
>> control which is trivial with things controlled by text files and
>> arbitrary editors and generally impossible with wizardly things.  
> 
> Sorry, that's an insane statement.  If I am editing a config file with an
> editor, it's up to me to make sure changes are checked into version
> control.

And that's a problem?  Why?

   If I'm editing it with a wizard, I'd absolutely build svn right
> into the wizard.  

Great, let me know when it's done.  And when it will match my version 
control system.

> It's not only not "generally impossible" it's a sight
> simpler.  I've never suggested that we make the config files
> non-human-readable, I just don't want them edited directly by people.

And I'm not saying that things can't be improved, but it's not a new 
problem and GUI's haven't helped solve it yet.  I am surprised that some 
distribution hasn't wrapped system management around one of the version 
control systems to a point where someone could 'publish' their 
configuration (packages plus all the setup with some local exclusions) 
and any number of others could automatically clone it and track changes. 
  A few hundred of these tuned for different purposes would probably 
take care of most people's needs.

-- 
   Les Mikesell
    lesmikesell at gmail.com