On Fri, 27 Mar 1998, Steve "Stevers!" Coile wrote:
> Don't get stuck in an "us versus them" mentality. Just because Microsoft
> does something doesn't mean Microsoft's doing it wrong. If people
I'm not. I don't have any religious dislike for Microsoft. I like their
context sensitive help, for example. (I just wish it were more helpful).
I do, however, believe that Linux should not attempt to pretend to be
Microsoft, because it isn't. Users who use Linux want it usually because
it is NOT Microsoft, and they have (for whatever reason) gotten tired of
Microsoft. Either the expense, the instability, the waste of system
resources, or maybe the interface (which drives me nuts).
<digression>
Actually, I think I've been able to trace most of my irritation with
Microsoft interfaces to the fact that they present so many non-functional
controls and so many controls which vanish whenever some random program
decides it should be more important. It is not uncommon for a Windows 95
system to take five minutes to boot and get all the startup programs
launched, and during this entire time you are sitting there trying to run
a program out of the start menu, except that it is constantly
disappearing.
</digression>
> I agree, but we shouldn't ignore conventions and expectations that
> have developed. We don't need to make things difficult just because
This is exactly what I have been saying, and it is why I recommend that we
stick to the existing Linux conventions.
> talking about command names here. The best command name is one that
> users find convenient. If most people thought it was convenient to type
> "moosebuckets" instead of "ls" or "dir", we should accomodate that.
What I am trying to avoid is a situation wherein a user goes to apply for
a position in some company, and they say "Do you have any experience with
UNIX?" The applicant says, "Yes, I've used Linux on my home system for
five years!" The applicant is hired, and is unable to use the Unix system
at the place of work. Even worse, is for the boss to say "That doesn't
count, Linux is nothing like UNIX."
> I disagree with your implication that the average person will, if
> presented with a difficult alternative and an easy alternative, will
> choose the difficult alternative because it may potentially be possibly
A user will rarely choose the "more difficult alternative" under any
circumstances. However, I don't think that 'ls' is any more difficult
than 'dir', and I don't think that 'mkdir' is any more difficult than 'md'
(except that it's longer to type).
When it comes to using a GUI, of course (which any user concerned about
ease of use will want), as long as it's "intuitive" then it doesn't
matter. These days Windows and Macintosh are less and less alike but
they're both "simple enough" so users can cope with it. Just like it
doesn't matter too much whether you type 'ls' or 'dir' it doesn't matter
too much whether you switch between tasks by clicking on the button on the
taskbar or picking them out of the little menu in the corner of the
screen. It all does the same thing, and I don't think there's any useful
way to say that one is 'easier' than the other.
> better maybe. If UNIX is kept difficult under the pretence of encouraging
> users to learn the inner workings of it, UNIX will continue to founder
I'm not advocating that. I simply believe that a dialog box which says
"Windows has detected a conflict between installed devices and was unable
to resolve it." is much less useful than "Windows has detected that your
modem and mouse are both using the same interrupt line, and cannot
automatically resolve the problem. One of the devices must be
reconfigured to use a different interrupt line."
For the non-technical user who doesn't care how it works, then the two
errors have the same effect. "My computer won't work." But a curious
user will wonder "what's an interrupt line?" He might even go look it up
in the documentation (which of course, no longer contains information like
this because it is much more concerned with telling users which end of the
mouse is up). Technical support will have to spend much less time trying
to figure out what the problem is. Overall it is better to present the
information. But Microsoft does not do this.
> Putting aliases around commands is NOT "actively prevent[ing] [users] from
> learning about the system."
It is indeed. A user who comes from DOS, knows dir, and never learns any
different because of the existence of this alias, has been prevented from
learning about the system. A user whose dir alias makes a fuss, has been
encouraged to learn about the system.
> NOT putting aliases in place specifically to "encourage" users to learn
> more about the system is actively preventing users from USING their
> system by forcing them spend time researching operating of the system.
I don't advocate this. Don't forget, I was the one that suggested using
the aliases in the first place. I simply believe that the aliases should
exist purely for compatibility and should strongly encourage the use of
the correct methods. I suggest doing this by inserting a delay in the
command. They might also flash bright purple or play irritating music.
(Of course, enough Windows systems do this already, the user might not
know it's supposed to be annoying.)
It is the same as using "deprecated" commands such as the -'s in the
options for ps (which I mention because Red Hat kindly warns me against
them every time I run several of their scripts). Are you suggesting that
the deprecated commands should have no warnings, so that when the author
does take them out suddenly everyone must quickly rewrite their scripts
and relearn the commands? That is what would happen if a person who
learned on one of your altered systems tried to use "real" Unix. I
believe that a user doing things the wrong way should be encouraged to do
them the right way.
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
