bad practice: not reading the manpage

[Florin Andrei]

On Mon, 2005-06-13 at 23:09 -0400, Bill Nottingham wrote:
> Florin Andrei (florin at andrei.myip.org) said: 
> > Why "--del" should be different from "off"?

> Because they're different things.
> 
> 'off' - configure the service to not start
> 'del' - remove all state for the service entirely

But that's a state in itself, functionally equivalent to "off on all
runlevels". It's unique only in the way that it is not preserved by "rpm
-U"

> So, misuse of the command to make --list easier to read is worth
> changing the behavior that's existed since the command was introduced?

Making --list easier to read is actually very valuable. If you have a
lot of things to take care of, you don't want to spend "brain cycles"
needlessly; plus, which services are on or off is a pretty important
issue, you don't want to make mistakes there.

I've seen this type of problem many times, when sysadmins and software
engineers are looking at the same issue. It's frustrating sometimes to
make engineers understand the issue from a real world perspective;
what's nice, clean and logical in the lab might be a huge drag in the
real world.

I understand, "--del" takes the service to a state that's not preserved
by rpm. Fine. But who did --del? Most likely the sysadmin. Why should
the software disregard a human decision? The system did not end up in
that state at random, but by human intervention. The software should not
overrule it.
Why should --del be different, other than "this is the way our
forefathers did it"?
This is the core of the problem and I don't think I received a good
answer yet.

Tradition is fine and all that, but it should change when it's hampering
the usability. Maybe I spent too much time lately with the Gnome HIG and
stuff like that (not strictly related, I know, but you get the idea),
but I think it's the computer semantics that should bend over backwards
to adapt to human semantics, not the other way around.

-- 
Florin Andrei

http://florin.myip.org/