On Mon, 15 May 2000, Mike Bilow wrote:
> We spend a lot of time dealing with the fallout from Microsoft's poor
> networking implementations. For example, when our Unix mail server fails
> a message, it does so properly and sends a polite English language
> explanation of what went wrong -- which Microsoft mail clients throw away.
[...]
> At least half of technical support volume is this sort of stupidity, such
> as failure to reflect a simple error message to the user. MSIE also makes
> up its own "friendly" web error messages by default, suppressing any
> custom web page we generate to try to help the user.
You're not the only person to notice this.
I dislike Microsoft for a number of reasons in a number of scopes. One of
the ones that bothers me the most, in day-to-day usage, though, is their
habit of not telling you what went wrong.
Oh, they will happily tell you that *something* went wrong. But what,
exactly, failed, is so often kept hidden you would think it was a state
secret.
It is so extremely frustrating to get a message like "Server error" or
"Could not open file". Non-technical people just cannot understand how that
makes my blood boil. If they would just tell me *WHAT THE FSCK THE PROBLEM
WAS*, I might be able to fix it! But, *oh*, *no*, the user might be
*confused* by a useful error message! As if "Server error" is enlightening
and user friendly! The user is gonna call me for help either way. Might as
well let me do the job. But no, Microsoft won't *let* me do *my* job, which,
most of the time, is fixing *their* broken software. For Tux's sake, I'm
trying to *help* their freaking business, but they keep getting in the way!
(What's that? Oh, this isn't alt.sysadmin.recovery? ;-)
And now, to place this on-topic: Not surprisingly, one of the things I hate
most about MSFT is mirrored as one of the things I like best about Linux. It
isn't that Linux is necessarily any more stable or secure then MS-Windows
(although it is). It is that, when Linux breaks down, most of the time, I can
actually *fix* the flippin' thing.
Error messages are generally useful. Unix error messages follow a common
pattern. The software will tell you what it was trying to work on, and what
went wrong. What it was trying to do is often evident from that alone, but if
not, the action trying to be accomplished is also mentioned. Why do so many
Unix programs follow this pattern? Because *it works*.
Example:
$ rmdir foo
rmdir: foo: Directory not empty
It tells you what it was trying to do (remove a directory), what it was
working on (namely, the directory "foo"), and what went wrong (the directory
isn't empty). Everything you need to know to fix the problem.
Could this be more user-friendly? Sure. It could offer a longer
explanation ("A directory must be empty before you can remove it.") It could
offer to remove the entire directory tree for you, with appropriate warnings.
And, if it weren't for the fact that GUIs are generally used over CLIs for
this sort of thing, I suspect a "beginner's shell" that included that sort of
prompting would appear.
But the point is, it doesn't try to hide the fact that something went
wrong. If Microsoft were to write that error message, you would see:
$ rmdir foo
The command did not complete successfully. Contact your system
administrator if you need help. (Error code 0x0F3D97B4)
(And you can bet dollars to donuts that error code wouldn't be documented
anywhere.)
> Is it just a penchant for sabotage?
As much as I'd like to blame Microsoft's evil (of which they have plenty)
for this, I think this is more a case for Hanlon's razor: Never attribute to
malice that which can be adequately explained by stupidity.
That principle applies a lot in Microsoft's case, I've noticed.
--
Ben Scott <[EMAIL PROTECTED]>
| Why do we call them apartments if they are together? |
| Why do we call them buildings if they are already built? |
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
