Re: [PATCH] Remove absolute paths from gpg.rc
On Wed, Mar 21, 2007 at 08:18:52PM +0100, Oswald Buddenhagen wrote:
> On Wed, Mar 21, 2007 at 05:32:55PM +0000, Dave wrote:
> > On Wed, Mar 21, 2007 at 03:51:02PM +0100, Oswald Buddenhagen wrote:
> > > this is silly. everbody makes mistakes.
> >
> > That doesn't matter. The user is in charge of deciding how many (if
> > any) limits he wants to place on his own decisionmaking authority.
> > The question is outside of the domain of the programmer.
> >
> i sure agree that the programmer has no right to forbid the user to do
> something utterly stupid,
nor to interrupt him by asking questions before doing what he asked for
> but he definitely has the "moral obligation"
> to guide the user away from doing it.
I don't think there's any such obligation. I think it's nice to tell people in
the documentation about "interesting" things your program can do as side-effects
of doing its job, but that belongs in the documentation (to educate the user),
not the program (to get in the user's way).
> the sillier the thing, the
> stronger the guide should be. simple principle.
You're working on a sliding scale here. Sliding scales are never simple without
a mapping function. Your mapping function here is way too subjective to be
simple.
> > > confirmation dialogs are a typical example of a measure to prevent
> > > small mistakes from having big effects.
> >
> > That's why mv(1), for example, offers the -i option. [...]
> >
> in which case it is perfectly ok. however, when pressing F8 instead of
> F7 means as much as deleting all of /home instead getting a dialog to
> create a directory, you really start to appreciate confirmation dialogs.
> ;)
The problem there is artificial, created by the user interface. I'd counter
(from a UI design perspective) that since the function keys aren't on the QWERTY
keyboard, they're probably not being hit accurately. If that's the case, then
assigning a destructive (i.e., difficult to undo) function to a function key is
probably not wise in general. Additionally, I'd argue that if you're going to
assign a destructive function to a function key (say, it's a commonly used
function), you'd probably be wise to keep it away from often used nondestructive
functions. However, none of this is the domain of the programmer. It's up to
the UI designer (who's ideally (very close to) the user himself) to decide what
functions (if any) should be mapped to function keys. I, for example, wouldn't
want to map anything to the function keys, since (a) they're off the QWERTY
keyboard (er, the Dvorak keyboard), and (b) they're used for VT switching. As
the user, it's my domain to decide on my interface. (After all, it's called a
user interface for a reason.) The cleanest interface for a program is a
command-line interface. The second-cleanest is a command-based interface.
(There are some applications where a command-line interface is considered
impractical for one reason (excuse) or another. For them, the best
recommendation is to simply read commands on stdin and dump results on stdout.
A user can then easily script a UI to meet his own needs, or ask (pay) a friend
(vendor) to script one for him. The original programmer may want to bundle his
own UI (if he uses one himself) for users to take a look at and maybe even use
as a starting point. That (among other things) is what contrib/ is for.)
> i cut the rest of the quote, as it just doesn't make sense. the example
> simply doesn't fit. ;)
Why doesn't it fit?
> > > but like any other safety measure, they have to be placed wisely.
> >
> > You just hit the nail on the head: the user himself is the only one in
> > a position to reverse engineer his own psychology in order to place
> > prompts wisely.
> >
> it might surprise you, but hardly anybody is able to do that.
It does surprise me. I'm not a UI design "expert" and I was able to build my
own UIs for my own (now defunct - thanks to dead server) editor, chat program,
and email program. (My primary toolchain revolves around those three
applications, so I don't really need any other substantial user applications in
the course of my normal life.)
> apart from that, you are completely misinterpreting my statement. ;)
Sorry ... what did you mean? ;-)
> > A programmer should write programs that simply do their job without
> > asking qusetions, and leave Psychology assignments to Psychology experts.
> >
> surprisingly (not really, at least to me), those psychology experts found,
> that confirmation dialogs in sensitive places are really sensible. ;-)
The Psychology experts who conducted those tests were looking for a Democratic
solution. Unfortunately, people aren't all the same. What's "really sensible"
for your average user is "a real drag" for a power user. One of the things I
hate most about programs with an integrated GUI is the "Are you sure you want to
overwrite this file?" prompts every time I want to clobber a file. Psychology
experts may decide that those dialogs are the greatest thing since sliced bread,
but not for me. I don't want my programs to decide that I don't know what I'm
doing just because they're too narrowminded to know (or care) that I'm working
on a versioned filesystem. I don't like programs that try to be smart. I like
stupid programs that do exactly what they're told. I'm the expert, and I backup
anything I care about. (That last part about backing up I learned the hard way.
It's the reason I'm back on Mutt again.)
> in less critical places, confirmation dialogs with a "do not ask again"
> checkbox have proven useful.
[OT] That's probably covered by some patent in the US :-(
At any rate, there's nothing stopping your UI from doing that. Here's an
obvious "user-friendly" sample for an rm(1) interface (assuming you already have
a window program that fits in with your way of life):
FILE=$1
ANS=$(window -opts='Yes|No' "Are you sure you'd like to delete '$FILE?'")
if [ "$ANS" = 'Yes' ]; then
rm "$FILE"
window -opts='OK' "File deleted"
else
window -opts='OK' "Deletion cancelled"
fi
Another advantage of separating the UI from the program is that you can combine
programs in an interesting way (much like the UI bash(1) already allows), say,
to create an entire file management UI. Programs with hardcoded UIs don't play
well with other programs they know nothing about.
> undo functions (to which i account the trash bin) have also proven to be
> very useful, because they don't disrupt the workflow and still even big
> mistakes can be reverted.
I love undo functions. If I never discover an error, it doesn't matter; if I
discover the error someday, I can find and restore the pre-error state, and/or
merge it with the current state, and/or any point in between.
> however, this only works closed systems.
Please explain. I'm stupid ;-)
> and
> is useless if you don't realize you made a mistake,
That's only the case without multilevel undo. A versioning system is the
correct solution to the problem, and it works without special support from
programs. I get to keep my rm(1) binary, which does one thing and does it
right, rather than being stuck with some bloated "file manager" application that
doesn't even let me clobber a file without croaking at me first.
> which is often
> enough the case in security context.
An undo button is extremely useful after a guy breaks into your system and
trashes everything he can get his hands on.
> > A programmer shouldn't have to be a security expert and a psychology
> > expert, in addition to being an expert at whatever task he's actually
> > hoping for his program to perform after all the prompts.
> >
> don't you think that the programmer is quite more likely a security
> expert than the user?
He might be. It makes no difference, though. If he happens to also be a
security expert, he can do two jobs. However, that fact doesn't automatically
merge the two jobs into one.
> also, in every professional software development
> environment which takes its users seriously, there is a psychology
> expert (usually called usability expert ;).
There you have a fantastic reason to KISS. No Psychology/usability/whatever
expert is required in the design of the rm(1) program, nor in the design of the
mv(1) program, nor the cat(1) program, etc. I've just shown you how to save a
lot of money _and_ take your users seriously :-)
> of course it is not their
> task to take away the gun from the user, but pointing out to him that
> pointing it at himself is no good idea is perfectly within scope.
In the documentation, they can point out some easy ways to shoot yourself in the
foot. The program shouldn't try to be smart and guess when the user is shooting
himself in the foot.
> > > dude, it is a config file that can be overridden, so such dogmatic
> > > argumenation is completely pointless.
> >
> > As Robin Hood would put it, it's the principle of the matter, if nothing
> > else.
> > (We don't know if it's anything else, because once you start violating user
> > rights, all bets are off. [...]
> >
> i give up. it's a lost case.
Mwahaha ... I win! (Actually, I lose. At the end of the day, we both lose out,
as does anybody else who happens to be reading our exchange.)
The problem is that it's trivial to prove the possibility of a fair world if you
start out with the assumption that everybody has full rights to his own stuff
and no rights to other stuff, and that all stuff is owned by somebody. In the
world of computers, that assumption is trivially true in virtually all cases.
In other words, we have a formula that guarantees us a fair world. If you're
not going to stick to that formula, though, all bets are off.
- Dave