idiot's guide to unix/linux
Shyamal Prasad
Stuart Herbert <ac3...@sunc.sheffield.ac.uk> wrote:
>Shyamal Prasad (shy...@seas.smu.edu) wrote:
>
>: And please remember - you *can* run Linux without posting for help on
>: comp.os.linux.help and you should try to do so!
>
>I disagree - if you've only done DOS/Windows, and only know people in the
>same boat, then you've got to have *somewhere* to ask - what's the point of
>a .help group if you tell people not to ask for it?
>
I do not disagree with your point of view - but I do observe that the
Linux help group is simply flooded with trivial requests. I know,
because 6 weeks ago I installed Linux on my own box and I did manage
to get it running without asking for help. This included patching the
kernel to work on my dumb IBM PS/1. I found all my answers in the FAQs
and simply by *reading* the group.
What I noticed was :
(a) the FAQ's have the answers
(b) if you think they are not there, look again and you will find
them.
(c) the FAQs do suck, but you get what you pay for.
(d) many questions are not even specific to linux.
I just wish people would try harder before posting. Thats all....its
worth the effort. Yes, I've known UNIX for nearly as long as
Messy-DOS, so Linux came easy.
Sorry for the sermon, I'm a newbie who is totally in love with his new
operating system :-)
Lets all have a good one! :-)
Shyamal
--
Shyamal Prasad, Department of Computer Science
Southern Methodist University, Dallas TX 75275, USA
Mingfang Li
> I do not disagree with your point of view - but I do observe that the
> Linux help group is simply flooded with trivial requests. I know,
> because 6 weeks ago I installed Linux on my own box and I did manage
> to get it running without asking for help. This included patching the
> kernel to work on my dumb IBM PS/1. I found all my answers in the FAQs
> and simply by *reading* the group.
If nobody is asking questions the answers to which you have been *reading*
in this group, you would be asking those questions right? :-)
I also believe there are people in this group who do not have the kind of
exposure you have had (as you say you have about the same exposure to both
DOS and Unix). So it's possible some may simply be too new to figure out
some basic things.
> (a) the FAQ's have the answers
Since there are so many FAQ's, it's kind of difficult to read them all and
still remember.
Regards.
mli
P.S.
I am typing this in my Linux box with XFree installed. I've went through
a lot during the last two to three days to get this to work. I can
appreciate why some are asking questions.
Mario Gutierrez
: >: And please remember - you *can* run Linux without posting for help on
: >: comp.os.linux.help and you should try to do so!
: >
: >I disagree - if you've only done DOS/Windows, and only know people in the
: >same boat, then you've got to have *somewhere* to ask - what's the point of
: >a .help group if you tell people not to ask for it?
: >
: I do not disagree with your point of view - but I do observe that the
: Linux help group is simply flooded with trivial requests. I know,
: because 6 weeks ago I installed Linux on my own box and I did manage
: to get it running without asking for help. This included patching the
: kernel to work on my dumb IBM PS/1. I found all my answers in the FAQs
: and simply by *reading* the group.
[skipped ...]
: I just wish people would try harder before posting. Thats all....its
: worth the effort. Yes, I've known UNIX for nearly as long as
: Messy-DOS, so Linux came easy.
This is your advantage. For example to an MSDOS/Windows person they have
no clue as to what a /dev/hda5 means. It certainly does not look like
an extended partition on the the first drive. If anything it looks like
some drive A:.
Moreover, DOS people have no idea what a swap drive is. There is a warning
in the Slackware setup telling you to create it before proceeding if you
don't have enough memory.
To the unexperienced this is very daunting. I don't know why people make
such a fuss, you can skip or delete articles at your discretion. I am
very grateful to the many people who have helped me solve my problems
in minutes instead of the hours it would have taken had I relied on the
FAQs alone.
: Sorry for the sermon, I'm a newbie who is totally in love with his new
: operating system :-)
I realize your intentions are good. You want to keep the newsgroup clean
of redundant questions. There is nothing wrong that. But, helping true
'newbies' will only make Linux more popular.
---
mario l gutierrez
mgut...@mentor.sdsu.edu
Michael A Iverson
Shyamal Prasad <shy...@seas.smu.edu> wrote:
>In article <2q15uu$c...@hippo.shef.ac.uk>,
>Stuart Herbert <ac3...@sunc.sheffield.ac.uk> wrote:
>>Shyamal Prasad (shy...@seas.smu.edu) wrote:
>>
>>: And please remember - you *can* run Linux without posting for help on
>>: comp.os.linux.help and you should try to do so!
>>
>>I disagree - if you've only done DOS/Windows, and only know people in the
>>same boat, then you've got to have *somewhere* to ask - what's the point of
<< stuff deleted >>
>
>What I noticed was :
>
>(a) the FAQ's have the answers
>(b) if you think they are not there, look again and you will find
>them.
>(c) the FAQs do suck, but you get what you pay for.
>(d) many questions are not even specific to linux.
>
>I just wish people would try harder before posting. Thats all....its
>worth the effort. Yes, I've known UNIX for nearly as long as
>Messy-DOS, so Linux came easy.
>
>
I think one of the major problems with the FAQ's is the sheer
quantity of information. After a new user has spend hours downloading
all of slackware, he or she probably is not in the mood to search through
all of the documentation.
Why not create an on-line searchable database of stupid questions
and stupid answers?
Mike
--
****__Michael Iverson___________________________****
****__iv...@ee.eng.ohio-state.edu_____________****
****__The Department of Electrical Engineering__****
****__The Ohio State University_________________****
Ken Firestone
: In article <1994May2.0...@seas.smu.edu>,
: Shyamal Prasad <shy...@seas.smu.edu> wrote:
: >In article <2q15uu$c...@hippo.shef.ac.uk>,
: >Stuart Herbert <ac3...@sunc.sheffield.ac.uk> wrote:
: >>Shyamal Prasad (shy...@seas.smu.edu) wrote:
: >>
: >>: And please remember - you *can* run Linux without posting for help on
: >>: comp.os.linux.help and you should try to do so!
: >>
: >>I disagree - if you've only done DOS/Windows, and only know people in the
: >>same boat, then you've got to have *somewhere* to ask - what's the point of
: << stuff deleted >>
: >
: >What I noticed was :
: >
: >(a) the FAQ's have the answers
: >(b) if you think they are not there, look again and you will find
: >them.
: >(c) the FAQs do suck, but you get what you pay for.
: >(d) many questions are not even specific to linux.
: >
: >I just wish people would try harder before posting. Thats all....its
: >worth the effort. Yes, I've known UNIX for nearly as long as
: >Messy-DOS, so Linux came easy.
: >
: >
: I think one of the major problems with the FAQ's is the sheer
: quantity of information. After a new user has spend hours downloading
: all of slackware, he or she probably is not in the mood to search through
: all of the documentation.
: Why not create an on-line searchable database of stupid questions
: and stupid answers?
I agree! The howtos and FAQs contain many, many meg of very useful
information, but they sometimes lack one or two very key things for
the beginning user.
For instance, the material on XFree addresses all sorts of configuration
issues, problems that may occur with some hardware, etc. But I don't
think it says any where how to actually start an XFree session!
(ie type "xinit"). This is not helpful for the complete novice who
does not know any "gurus".
I for one would like to know how I am supposed to use the dosemu system.
I have yet to find what command, or commands I have to run to get it
going!
So yes, a Linux for Dummies would be a good idea, perhaps with a more
dignified name. Anyone with enough sense to try Linux is not a Dummy!
--
============================================================================
Ken Firestone, N3JBU | If you look at things right, its best not to know
ke...@clark.net | who you really are. Because anything that happens
| to anybody who doesn't know who he really is
| actually happens to somebody else. So it makes no
| difference at all. -- Nelson Algren.
============================================================================
Dan Newcombe
>:>Why not create an on-line searchable database of stupid questions
>:>and stupid answers?
>And why do you think people would use it? In fact the FAQs and HOWTOs are
>'searchable databases', just grep them for the keywords.
>There should be no support for people who are not willing to read
>documentation.
Okay, so I'm new to Linux and maybe even unix. Chances are that I have no
clue what grep is, how to use it, and so on. Of course I could grep the FAQ
on it, but that won't tell me anything (oh, wait...I don't know how to grep.)
That's okay...it's not Linux Specific, so I wouldn't find it in there anyway.
Yes, people should read documentation. It would make other's lives easier.
But the people that write the documentation should write it in the mindset
that it is going to be looked at more often by the clueless instead of the
in-the-know.
--
Dan Newcombe newc...@aa.csc.peachnet.edu
Clayton State College Morrow, Georgia
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"And the man in the mirror has sad eyes." -Marillion
Michael A Iverson
Helmut Geyer <ge...@polyhymnia.iwr.uni-heidelberg.de> wrote:
>Michael A Iverson (mive...@magnus.acs.ohio-state.edu) wrote:
>
>:>and stupid answers?
>
> And why do you think people would use it?
Good point, that's the real disadvantage of an on-line database.
the routine c.o.l.help answer would become "query the database"
instead of "read the FAQ".
> In fact the FAQs and HOWTOs are
> 'searchable databases', just grep them for the keywords.
But you have to download ALL of these to do this. Some people
pay for their internet connections. A gopher server would allow
a user to search the current, relevant documentation quickly.
Also, how good are unix newbies at using grep? What if they don't
even have linux running?
>There should be no support for people who are not willing to read
>documentation.
Is that justification to provide documentation in a difficult to
use format? I think many make unnecessary posts to c.o.l.h because
that is the *easiest* way to get help.
I, against *all* of my better judgement, would be willing to
help set up such database, using gopher or some other method, if
there is reason to believe that people would actually use it.
Stuart Herbert
: There should be no support for people who are not willing to read
: documentation.
: Helmut
What about those who are unable to *understand* the documentation? Should
they be comdemnded, as the unwashed masses?
(And why is it you always see this sentiment? DOS users to Mac-lovers,
unix-lovers to DOS users, et al ...)
Stuart
--
Stuart Herbert -- S.He...@shef.ac.uk
Paul Tomblin
>Helmut Geyer (ge...@polyhymnia.iwr.uni-heidelberg.de) wrote:
>: There should be no support for people who are not willing to read
>: documentation.
HEAR HEAR!
>What about those who are unable to *understand* the documentation? Should
>they be comdemnded, as the unwashed masses?
If you can't understand the documentation, then you should be offering
suggestions to the maintainer of that documentation.
>(And why is it you always see this sentiment? DOS users to Mac-lovers,
>unix-lovers to DOS users, et al ...)
What? You think it's some sort of prejudice that we don't want to answer the
same questions over and over again when the answers are there for the taking?
--
Paul Tomblin, Head - Automation Design Group.
Gandalf Canada Limited
This is not an official statement of Gandalf, or of Vicki Robinson.
"Hello, this is Linus Torvalds, and I pronounce Linux as Linux"
Dan Newcombe
>>(d) many questions are not even specific to linux.
When I started using Linux, I knew VERY little about Unix. I didn't even know
how to delete a file. All I knew was from what I had picked up here and there.
At one point I posted questions to comp.os.linux that I now know are very
un-linux specific. I had no clue back then. It is very hard for a new person
to know what is and isn't linux specific.
Technically, the only questions we should be seeing about Linux are about the
kernel, as everything else is a program that was ported over. :)
Jeremy Bettis
>Helmut Geyer (ge...@polyhymnia.iwr.uni-heidelberg.de) wrote:
>: There should be no support for people who are not willing to read
>: documentation.
>What about those who are unable to *understand* the documentation? Should
>they be comdemnded, as the unwashed masses?
>(And why is it you always see this sentiment? DOS users to Mac-lovers,
>unix-lovers to DOS users, et al ...)
If theyt cannot understand the documentation then they should hire a
consultant to set up the system for them. It is just like anywhere else,
when business owners cannot understand how to install their DOS accounting
software they hire someone to install it for them. No one complains about
how the docs are hard to understand. And the Linux docs we have are much
better than most comercial software I have seen.
We cannot expect every person to understand every detail. That is why there
are admins AND users. Let the users remain merely users and keep them away
from the ``hard'' things.
--
Jeremy Bettis -*- Jerbo Jehoshaphat -*- University of Nebraska
INET: jbe...@cse.unl.edu "Those who stand in the middle of the
UUCP: je...@tddi.UUCP road are often hit by passing cars."
Running Linux -- The Free Unix for i386/i486/Pentium machines. Ask me how.
Matt Welsh
>So yes, a Linux for Dummies would be a good idea, perhaps with a more
>dignified name. Anyone with enough sense to try Linux is not a Dummy!
The book "Linux Installation and Getting Started", as well as the
Installation-HOWTO, attempt to be very closely geared towards complete
UNIX newcomers. That's always been my intention for that introductory
documentation.
But, here's a simple truism. If we make the documentation _too_ simple,
there are a number of drawbacks:
a) Simple documentation is for simple systems. Linux is anything
_but_ simple. To oversimplify the documentation would invariably
cause many, many readers to fall through the cracks. You need
to achieve a balance between simplicity and flexibility. I fear
that the current documentation is already too simple, in that
it stresses the use of a single root filesystem, for example.
b) Too much of the time, we blame the complexity of Linux on the poor
quality of the documentation. This isn't always the case. Linux
really _is_ complex, and nothing but documentation at the appropriate
technical level can do it justice. As a somewhat unrelated example,
I couldn't reduce the paper here on my desk, "Object Recognition by
Affine Invariant Matching", to "layman's" terms without losing the
content. Simply, this isn't a paper meant for someone without
experience in machine vision research. The process it describes isn't
meant for someone without experience in machine vision, either.
Reducing the paper to nontechnical terms wouldn't do the reader any
good at all.
c) Similar to the above, someone who can read and understand "instructions
for idiots" won't be prepared at all for the reality of Linux. It's a
UNIX system. Literally volumes and volumes have been written about
how to use and run UNIX systems. To be a UNIX systems administrator
for a business, you usually need several years of experience doing so.
It's not the kind of thing that we can expect MS-DOS users to do overnight,
plain and simple. And, even if we could get them to install Linux
overnight (the current instructions should be clear enough to do so),
they won't be ready for the big task: Running the system.
So, in some sense, the documentation has to "screen out" readers who
aren't ready for what lies ahead. "Linux for Dummies" would attract just
that---dummies. People who aren't ready for the complex task of running
a UNIX system. It's not something that everyone is cut out for, mind you.
You wouldn't expect an MS-DOS user to move to running System V or SunOS
overnight, would you? Of course not. Why so with Linux? Because Linux
runs on a PC? That doesn't make it any less complex. And, arguably, Linux
is more complex and hackish than other UNIX implementations---it's more
ad hoc, in some sense, and it's not documented as completely.
While I'll be the last person to turn away interested MS-DOS users to the
wonders of Linux, there is a point where you have to draw the line. Linux
just isn't for everybody. It's for people with UNIX experience, first of
all, and hopefully people who have experience running UNIX systems, and
hacking them. Those are the kinds of people who can pick up Linux and
use it with little trouble. But it's also for people who want to get away
from MS-DOS and start using UNIX. However, installing and running your
own UNIX system is a huge task, and isn't something that you can reasonably
expect a complete UNIX neophyte to do.
Instead of turning away the MS-DOS masses, I do try my best to help those
who want to learn by doing. However, it should be made very clear from the
outset that it's not going to be easy, especially if you've never run
a UNIX system before. As long as the newcomer is willing to put forth the
effort, and do a lot of hacking, they have as much "right" to run Linux
as anyone else. But as I have said, it's not for everybody. Making it appear
to be for everybody (a la "Linux for Dummies") would be very, very misleading.
mdw
Matt Welsh
>>(b) if you think they are not there, look again and you will find
>>them.
>MAY help, if you can think of a good keyword in a directory full of FAQs.
I don't see what's so hard about _reading_ the documentation. This is a
UNIX system, for crying out loud, and I don't think it's unreasonable
to expect new users to read around 100 pages or so in order to get off
of the ground. If you disagree, go to the bookstore and pick up any
book on using UNIX, and flip through it. Notice how little material is
covered in the first 100 pages. And these books barely scratch the
surface: None of them talk about how to download, install, and configure
your own UNIX system. That's left for books on systems administration
and manuals from specific vendors. O'Reilly's "sendmail" book alone
is over 800 pages long!
Excuse me for sounding a bit testy, but everyone seems to be struggling
over new ways to search the documentation for the answers that you're
looking for. I've got a great way of doing it---use your built-in biological
grep. It's called "reading".
mdw
Jim Graham
would call it a ``General UNIX Publications HOWTO'', and would probably
simply take the suggested reading list from whatever comp.unix.* group
it is that publishes a beginner's reading list.
In article <newcombe.1...@aa.csc.peachnet.edu>
newc...@aa.csc.peachnet.edu (Dan Newcombe) writes:
>Okay, so I'm new to Linux and maybe even unix. Chances are that I have no
>clue what grep is, how to use it, and so on. Of course I could grep the FAQ
>on it, but that won't tell me anything (oh, wait...I don't know how to grep.)
>That's okay...it's not Linux Specific, so I wouldn't find it in there anyway.
Nor should you.... If you want to find out information about simple UNIX
utils like grep, etc., you should be looking in a book (or online
documentation...whatever) that's designed to be an introduction to the
world of UNIX. There are a great many such books out there. It also
wouldn't hurt to read the comp.unix.* groups. I've been without access
to those long enough to forget the group names, but I seem to recall that
there were at least a couple of beginner-level groups in there (perhaps it
was comp.unix.questions?). I also seem to recall that there was a rather
long list of suggested reading. Now, it might not be a bad idea for that
list to be duplicated as a HOWTO---perhaps something like a ``General UNIX
Publications HOWTO''.
Anyone who is new not only to UNIX system administration, but to UNIX in
general, and is installing it on their machine at home (whatever), should
be prepared to do a lot of reading...they have a lot of catching up to do.
Part of that reading needs to include at least one of the many excellent
books that provide an introduction to the UNIX operating system.
Getting back to the example raised about not finding out about utils like
grep in the Linux HOWTOs, FAQs, etc., those documents are designed to
provide information about Linux, specifically. There are a great number of
publications (some free, some not free) out there that already provide a
wonderful introduction to UNIX in general. Why would anyone want to
re-invent the wheel by trying to duplicate that effort? Improving on it
is one thing...but to simply duplicate existing UNIX manuals and call them
Linux manuals instead is, *IMHO*, a waste of time and space.
Again, I would like to suggest something along the lines of a ``General
UNIX Publications HOWTO'' that would suggest a long list of books and
online material that the UNIX newbie would find helpful. Of course, the
next question is, would people bother to read that HOWTO, and if so, would
they bother to look into getting a copy of any of the books (and if so,
would they then read them)????
I suggest taking a position such as the one you'll find in the preface to
``UNIX System Administration Handbook'' (by Evi Nemeth, et al), which
reads:
UNIX System Administration Handbook is intended primarily
for people with little or no background in system
administration....
We assume throughout that you are already familiar with the
basics of UNIX and know how to use the shell and commands
such as mkdir, vi, and sh. If you don't, you *must*
[emphasis theirs] supplement this book with some additional
reading. Consult the UNIX bibliography at the end of this
book for some specific recommendations.
This way, there is no mis-understanding, and people know exactly where else
they need to look for information (i.e., what titles to look for at their
local library or bookstore).
>Yes, people should read documentation. It would make other's lives easier.
>But the people that write the documentation should write it in the mindset
>that it is going to be looked at more often by the clueless instead of the
>in-the-know.
See above....
Later,
--jim
--
73 DE N5IAL (/4) < Running Linux *1.00*! >
j...@n5ial.mythical.com ICBM: 30.23N 86.32W
|| j.gr...@ieee.org Packet: N5IAL@W4ZBB (Ft. Walton Beach, FL)
E-mail me for information about KAMterm (host mode for Kantronics TNCs).
Juha Laiho
>6 weeks ago I installed Linux on my own box and I did manage to get it
>running without asking for help. This included patching the kernel to
>work on my dumb IBM PS/1. I found all my answers in the FAQs and simply
>by *reading* the group.
>
>What I noticed was :
>
>(a) the FAQ's have the answers
>(b) if you think they are not there, look again and you will find
>them.
grep -i 'someword' *
MAY help, if you can think of a good keyword in a directory full of FAQs.
>(c) the FAQs do suck, but you get what you pay for.
Do you have any ideas for better question/answer pairs? If so, try to get
them to the FAQ maintainer.
>(d) many questions are not even specific to linux.
Yes. It's just that in the beginning it may be very hard to find the "border-
line" btw Linux/generic *ix/applications.
--
Wolf a.k.a. Juha Laiho Helsinki, Finland
(Geek Code 1.0.1) GCS d? p c++ l++ u(-) e+ m+ s+/- n- h(*) f(?) !g w+ t- r y+
"...cancel my subscription to the resurrection!" (Jim Morrison)
Stuart Herbert
: of the ground. If you disagree, go to the bookstore and pick up any
: book on using UNIX, and flip through it. Notice how little material is
: mdw
Go to the bookstore and stare at all the 'DOS for Dummies' books, you mean.
There's no denying that people need to read more, and even understand more,
than they do for DOS, but the point is that there simply *isn't* the info
there in the first place.
Not everyone who owns a computer majored in Computer Science or Software
Engineering.
Stuart Herbert
: If theyt cannot understand the documentation then they should hire a
: consultant to set up the system for them. It is just like anywhere else,
: when business owners cannot understand how to install their DOS accounting
: software they hire someone to install it for them. No one complains about
: how the docs are hard to understand. And the Linux docs we have are much
: better than most comercial software I have seen.
I disagree. I find myself pulling info out of the man pages here at the Uni
because the Linux docs simply aren't as good. That's not a go at the DOC
people - they're writing for a different audience.
: We cannot expect every person to understand every detail. That is why there
: are admins AND users. Let the users remain merely users and keep them away
: from the ``hard'' things.
True, but there's a lot of stuff that people could understand better if it was
pitched at their level. Simply telling them that they are a 'mere user' who
should not do 'hard' things is pious.
Shyamal Prasad
Juha Laiho <jla...@ichaos.nullnet.fi> wrote:
>shy...@seas.smu.edu (Shyamal Prasad) said:
>>6 weeks ago I installed Linux on my own box and I did manage to get it
>>running without asking for help. This included patching the kernel to
>>work on my dumb IBM PS/1. I found all my answers in the FAQs and simply
>>by *reading* the group.
>>
>>What I noticed was :
>>(c) the FAQs do suck, but you get what you pay for.
>Do you have any ideas for better question/answer pairs? If so, try to get
>them to the FAQ maintainer.
I think I must comment on what I meant when I said the FAQs suck - I
mean I would never disagree with people (mostly from the Messy-DOS
world) who say FAQs suck as documentation. I was just suggesting that
if you think that the FAQs suck, well just go on thinking that way but
do get along with life. Linux is UNIX, and UNIX is complicated enough to
make any documentation "suck". There is no point in being bitter about
a system that is so complex that even with "good professional
(expensive)" docs a person would feel overwhelmed anyway.
I am very happy with the FAQs and believe they do a really good job at
describing what is inherently a complex system. I certainly don't
want to sound ungrateful to all the wonderful people who write and
maintain the FAQs. Like I said, I've always found my answers in the
FAQs.
Cheers!
gva...@eagle.wesleyan.edu
> In article <2q33im$s...@sun0.urz.uni-heidelberg.de>,
> Helmut Geyer <ge...@polyhymnia.iwr.uni-heidelberg.de> wrote:
>>Michael A Iverson (mive...@magnus.acs.ohio-state.edu) wrote:
>>
>>:>Why not create an on-line searchable database of stupid questions
>>:>and stupid answers?
>>
>> And why do you think people would use it?
Because it would be far less painful than wading through FAQs, HOWTOs, etc?
Because it would be an easy way to "ask a question" without risking a flaming
from some irritated Unix/Linux-know-it-all? I would definitely use it (but
then, I've spent a great deal of time poring over the FAQs, HOWTOs, and Linux
Documentation Project books).
> Good point, that's the real disadvantage of an on-line database.
> the routine c.o.l.help answer would become "query the database"
> instead of "read the FAQ".
I think the critical difference is that a database would be easier to query.
BTW, why are people so fond of saying "read the FAQ" when a reply like "use
grep" would be sufficient?
>> In fact the FAQs and HOWTOs are
>> 'searchable databases', just grep them for the keywords.
Great advice for newbies! :-P I didn't know what grep was when I first
installed Linux. Unfortunately, many "gurus" are apparently not aware that
there are people who (gasp!) don't know ANYTHING about Unix, but would like to
learn. You don't have to help them if you don't want to; no one's holding a gun
to your head. And you don't have to be so f**king pious about the "right" ways
to obtain information.
> But you have to download ALL of these to do this. Some people
> pay for their internet connections. A gopher server would allow
> a user to search the current, relevant documentation quickly.
> Also, how good are unix newbies at using grep? What if they don't
> even have linux running?
IMHO, a gopher server, or a set of Mosaic pages, is a great idea.
>>There should be no support for people who are not willing to read
>>documentation.
>
> Is that justification to provide documentation in a difficult to
> use format? I think many make unnecessary posts to c.o.l.h because
> that is the *easiest* way to get help.
That's exactly why there are so many posts to c.o.l.h. And a lot of the
questions I've seen are asking for information I've found (the hard way) in the
FAQs and other documentation. I must admit I'm a bit irritated about that,
though I've learned quite a bit from the documentation.
> I, against *all* of my better judgement, would be willing to
> help set up such database, using gopher or some other method, if
> there is reason to believe that people would actually use it.
If it's easy and friendly, people will use it. Like I said, I would certainly
use it. I think it's an extremely good idea.
Guido
Ian Soboroff
Stuart Herbert <ac3...@sunc.sheffield.ac.uk> wrote:
>Go to the bookstore and stare at all the 'DOS for Dummies' books, you mean.
>There's no denying that people need to read more, and even understand more,
>than they do for DOS, but the point is that there simply *isn't* the info
>there in the first place.
??? perhaps what you need is a change of bookstores. o'rielly and
associates puts out a wonderful selection on Un*x references from
(well, slightly-above-the) ground on up.
ian
--
+---------------+------------------------------------------------------+
! Ian Soboroff ! "When you have learned to snatch the error code from !
! i...@umbc.edu ! the trap frame, it will be time for you to leave." !
+---------------+------------------------------------------------------+
mi...@b64063.student.cwru.edu
A new user should read a book on unix, and then use the FAQ's as a reference.
Matt Welsh
>Yes, I think there might be a need for a new HOWTO.... I, personally,
>would call it a ``General UNIX Publications HOWTO'', and would probably
>simply take the suggested reading list from whatever comp.unix.* group
>it is that publishes a beginner's reading list.
There already is one; look at sunsite.unc.edu in
/pub/Linux/docs/HOWTO/Reading-List. James Haynes <hay...@cats.ucsc.edu>
maintains it. If you'd like to add to it, please send mail to him!
>Nor should you.... If you want to find out information about simple UNIX
>utils like grep, etc., you should be looking in a book (or online
>documentation...whatever) that's designed to be an introduction to the
>world of UNIX. There are a great many such books out there.
The I&GS book includes a UNIX tutorial for new users. If you would like
to see something added to it, again, please send mail to me. :)
>Anyone who is new not only to UNIX system administration, but to UNIX in
>general, and is installing it on their machine at home (whatever), should
>be prepared to do a lot of reading...they have a lot of catching up to do.
Exactly.
HOWTOs aren't meant to teach the basics of UNIX---they can't. Perhaps
I could cut out the UNIX tutorial chapter from the I&GS and
release it as a separate HOWTO. What do people think of this? I suppose
it would be very useful for folks who don't have the ability to print
an entire 200-page document.
mdw
Matt Welsh
>In article <2q3dsr$p...@charm.magnus.acs.ohio-state.edu>, mive...@magnus.acs.ohio-state.edu (Michael A Iverson) writes:
>> In article <2q33im$s...@sun0.urz.uni-heidelberg.de>,
>> Helmut Geyer <ge...@polyhymnia.iwr.uni-heidelberg.de> wrote:
>>>Michael A Iverson (mive...@magnus.acs.ohio-state.edu) wrote:
>>>
>>>:>Why not create an on-line searchable database of stupid questions
>>>:>and stupid answers?
I've always wanted to work up a WAIS database of questions and replies
to postings in c.o.l.* (.help, specifically). However, I lack the
time to do so. Such a database could be accessible from a number of
interfaces (any WAIS client, as well as from WWW).
If someone would like to work on such a project, please get in touch with
me. Of course you don't need my permission to do so, but I have some ideas
on how it could be implemented. For the most part it would need to do
context searches of both article headers and bodies.
Of course all Linux documents would be included in such a database as well,
but with such prepared docs there's no substitute for actually _reading_
them.
>Great advice for newbies! :-P I didn't know what grep was when I first
>installed Linux.
Surely you must know of *some* means of searching a text file, under
_some_ operating system... "grep" has equivalents on many UNIX systems,
and in fact I suppose an MS-DOS port of GNU grep is available.
mdw
Matt Welsh
>In article <1994May3.0...@cs.cornell.edu>, m...@cs.cornell.edu (Matt Welsh) writes:
>>a) Simple documentation is for simple systems. Linux is anything
>> _but_ simple.
>>
It's not complicated to set up, you mean. Pre-packaged distributions make
it really easy to install and set up a Linux system. But that's just the
icing on the cake. I doubt that very many Linux users without, oh,
three or four years minimum UNIX systems admin experience really
understand all of the intricasies of the system---how to build shared
libraries, how to hack sendmail.cf, and so on. Most of it is done for
you with standard distributions, but that's only hiding the complexity
from the systems administrator. Once they dig into it, there's a lot
to learn.
>>b) Too much of the time, we blame the complexity of Linux on the poor
>> quality of the documentation. This isn't always the case.
>
>As much as I have to admire everyone in this effort, it is sometimes the case
>that a lot of seemingly obvious (but not really obvious) things are
>ommitted from the documentation.
Such as what? I personally try my best not to assume much of anything,
and in so doing often have to say the same thing several different
ways (also knowing that many readers of Linux documentation aren't
native speakers of English). But I do wish that you and others would
point out these glaring inconsistencies. If you don't, we can't do anything
to correct them.
>Read that again. In order to be able to admin a unix system, you have to have
>been doing it already?
Not necessarily, but you at least need to read a great deal about it, and
probably apprentice yourself under another UNIX systems admin. (I was
lucky enough to have Jon Magid---now sunSITE administrator---as my guru.)
But diving into the deep end of the pool with your own UNIX system, without
anyone to help you out and no books to lead the way, is usually a very
bad idea.
My main point is that no matter HOW good the documentation is, it can
NEVER replace experience. Experience _sometimes_ comes with "just doing it"
on your own. More often it comes by looking over someone's shoulder for
a few months and playing on another UNIX system, before taking one
over yourself. Books can't teach you everything.
>> It's not the kind of thing that we can expect MS-DOS users to do overnight,
>> plain and simple. And, even if we could get them to install Linux
>> overnight (the current instructions should be clear enough to do so),
>> they won't be ready for the big task: Running the system.
>>
>What? This is really condescending.
No, it's not. It's a reality check.
I too was once an MS-DOS user (and before, that an Apple IIe user, but
let's not get into that.) With the documentation available today, I
probably could have installed and set up my own Linux system. But that
doesn't mean that I would have _understood_ any of what I was doing.
>>However, installing and running your
>>own UNIX system is a huge task, and isn't something that you can reasonably
>>expect a complete UNIX neophyte to do.
>>
>But that is exactly what these new distributions enable people to do. Many
>new linux users are students, who have no possibility of already having
>had unix experience
I'm fully and completely aware of that. Of course this doesn't mean that
they _should_ be running Linux, but they can, of course. My point is that
running a Linux system without understanding what you're doing, as is
the case much of the time, is hazardous and leads you into situations where
you have to complain on c.o.l.h. All of this can be remedied by taking
things a bit more slowly and learning step-by-step. People who have been
using UNIX for less than a month shouldn't be hacking Smail configuration
files, but unfortunately with Linux that is the case. I took me a few
months just using UNIX before I was ready to run a system on my own.
With Linux, however, the user is forced to install, configure, run,
_and_ learn to use the system all at once. That's why it's not for
everybody---it takes a lot of committment if you've never used UNIX before.
>Also true. But please don't put newbies off with the suggestion that they are
>just too dumb to learn.
I never said that. Everyone can learn. The question is, _how_ will they
learn? It's something like throwing a piano at a five-year-old and
expecting them to turn out a perfect rendition of the Moonlight Sonata.
(Some five-year-olds could do it, and some could not.) It has nothing to
do with stupidity or intelligence---just experience. Usually to do
these kinds of things takes months (if not years) of reading, learning,
and tinkering. Blaming the troubles of neophytes purely on inadequate
documentation is really underhanded. Even if the documentation were
absolutely perfect, it can't replace actual experience.
mdw
Ulick Stafford
<mi...@b64063.student.cwru.edu> wrote:
> I think for a new unix user, the FAQ's are worthless.
>A new user should read a book on unix, and then use the FAQ's as a reference.
I doubt if there is a subject upon which more bad books have been written.
I got a number from the library just after installing linux, and found
they never had the answers to basic questions in the index. Also, it is
impoissible to glean anything from a computer book without having a computer
to try things out. Thankfully, I was a UNIX user (but not administator) and
was quite capable of getting Matt Welsh's guide from sunsite using a Sun
prior to getting my own system up and going. This guide is indispensible
to beginning users.
_____________________________________________________________________________
'There was a master come unto the earth, | Ulick Stafford,
born in the holy land of Indiana, | Dept of Chemical Engineering,
in the mystical hills east of Fort Wayne'.| Notre Dame, IN 46556
| ul...@ulix.cheg.nd.edu
Marc ter Horst
>I could cut out the UNIX tutorial chapter from the I&GS and
>release it as a separate HOWTO. What do people think of this? I suppose
>it would be very useful for folks who don't have the ability to print
>an entire 200-page document.
I think it would be very usefull to have something like a list of commonly
used terms with explanations, mayby some basic info on searching for info
under linux, like man pages, grep etc.
A current list of device numbers (majors), and maybe a basic explanation of
the concept of devices, and how to use them would be usefull too.
Marc
>mdw
Stuart Herbert
: In article <2q5fon$i...@hippo.shef.ac.uk>,
: Stuart Herbert <ac3...@sunc.sheffield.ac.uk> wrote:
: >Go to the bookstore and stare at all the 'DOS for Dummies' books, you mean.
: >There's no denying that people need to read more, and even understand more,
: >than they do for DOS, but the point is that there simply *isn't* the info
: >there in the first place.
: ??? perhaps what you need is a change of bookstores. o'rielly and
: associates puts out a wonderful selection on Un*x references from
: (well, slightly-above-the) ground on up.
: ian
Yes, but trying finding them in a bookshop on THIS side of the pond. I
live in the fourth-largest city in England, and other than the X books,
there's nothing. Most people won't order books blindly either - I know
I won't.
My point is that telling people to go elsewhere for help defeats the
purpose of the exercise, because that help may not be there.
Russell Marks
|
| : of the ground. If you disagree, go to the bookstore and pick up any
| : book on using UNIX, and flip through it. Notice how little material is
|
| : mdw
|
| There's no denying that people need to read more, and even understand more,
| than they do for DOS, but the point is that there simply *isn't* the info
| there in the first place.
I got my first Unix book for 2.95 pounds in W H Smiths. I don't think they
come any more mainstream than that, at least in the UK. (It was right next
to all the 'DOS for dummies' books :^) ) This book taught me enough to get
reading man pages to learn some more. A year later, I bought a rather
larger SVR4 reference also at Smiths. I'm not saying that finding Unix books
in mainstream stores is easy, but in no way is it an impossible task.
And about Matt's last point - the "little material" that these Unix books
cover is immeasurably useful to a newbie, as I was about 18 months ago. I'm
probably still a newbie, though. :)
| Not everyone who owns a computer majored in Computer Science or Software
| Engineering.
No kidding. Hence the aforementioned 'DOS for Dummies' books. I believe
there's also a 'Unix for Dummies' book, FWIW.
| Stuart
| --
| Stuart Herbert -- S.He...@shef.ac.uk
-Rus.
--
/ russell marks ::: rm1...@gre.ac.uk ::: speak softly and carry a +6 kitten \
| GCS -d+ -p+ c++++ l++ u++ e+(*) m+@ s+/++ n--(---) h+(*) f+ !g w+ t+ r- y? |
\ ::: "His world is under anaesthetic - subdivided and synthetic" - Rush ::: /
Juha Laiho
>In article <Cp6sC...@ichaos.nullnet.fi> jla...@ichaos.nullnet.fi (Juha Laiho) writes:
>>>(b) if you think they are not there, look again and you will find
>>>them.
>>grep -i 'someword' *
>>MAY help, if you can think of a good keyword in a directory full of FAQs.
>
>I don't see what's so hard about _reading_ the documentation. This is a
>UNIX system, for crying out loud, and I don't think it's unreasonable
>to expect new users to read around 100 pages or so in order to get off
>of the ground.
We agree, Matt. But: as you know, for many people, it is much harder to
actually _read_ _through_ a document, or a FAQ, than to f.ex. post to
col.help. That's why I made the suggestion about grepping the FAQs. It's
much faster than reading through; comparable with posting to the Net.
>Excuse me for sounding a bit testy, but everyone seems to be struggling
>over new ways to search the documentation for the answers that you're
>looking for. I've got a great way of doing it---use your built-in biological
>grep. It's called "reading".
Yes, I (usually) have enough patience for doing that, but I know a lot of
people who don't. For them, grepping (or asking from the Net) are the
only ways to go. And even they are able to learn..;)
gva...@eagle.wesleyan.edu
>
> There is a good free introduction to installing and several simple commands
> in Linux, it's called the Installation Guide & Getting Started by Matt Welsh.
> If you do not know _any_ unix, you should read this first, as the HOWTOs
> and FAQs are designed to answer rather specific questions once the system is
> installed.
You're right--Matt Welsh's book is extremely useful, and is also quite
readable.
> In order to get some information into these, it is necessary to
> assume that the reader knows some basics on Unix. (I am tired of getting
> flamed that I did not tell how to read a manpage or that there are things
> missing in the HOWTO, that aren't
No one should be flamed when they're trying to help someone.
> If people do not want to read the documentation they _have_, why should I make
> new documentation?
Well again, you can choose to do whatever you want to do. You are not being
forced to write documentation, and you're not being paid to do it, so no one
can blame you for not wanting to do it.
My point is merely that I think more people would be inclined to read the
documentation (versus posting naive questions on c.o.l.h) if it were a bit
easier to obtain, and a bit easier to read. This would really be helpful to
those who already read the documentation, too.
It's also a bit disheartening when you obtain a Linux document (let's say, as
an example, the Kernel Hacker's Guide), and it has a warning which tells you
that it's an alpha version, that a lot of the information within may be wildly
inaccurate, and that if the reader acts on the information and gets burned,
it's his own tough luck.
> A database built on a question & Answer base targeted at
> newbies would not be successful because of many points. Here some of them:
> - If someone does not know Unix, you cannot expect to get it running just by
> reading some answers. You have to learn first something on the Unix
> environment (commonly used programs, file system, structure, ...). You
> wouldn't expect to write a book in a foreign language just by having
> access to a dictonary, would you?
I heartily agree with you, which is why I bought a book on Unix. However, a
question and answer database would be invaluable for finding SPECIFIC
information, and for answering SPECIFIC questions. Such a database would have
literally saved me hours of time when I was setting up my Xconfig file.
> - One main problem here is that there are many users of DOS or other
> popular systems that simply are not used to reading doicumentation as
> one can guess most relevant things anyway. A unix system does not work
> that way.
That's true--Unix is not as intuitively accessible. But this seems to argue in
favor of an easily accessed database, rather than against it!
> People are not willing to read the documentation.
I don't think that's fair or true. Can we change that to "Some people . . ."?
> A simple
> example:
> I frequently get mail (or see postings) that someone has a
> problem with XFree86. All documentation has been read and nowhere an
> answer could be found. The second part is true as often as not, but when I
> look at the post that describes what's wrong I have to doubt the first part:
> In most cases none of the relevant information that should be included in
> any query (as is listed in the HOWTO) is provided. The questions get posted
> to a linux group, not to the appropriate comp.windows.x.i386unix group.
> All this is described in the HOWTO that has been read thoroughly (at least
> many people claim this).
> I only can conclude that they do not want to read it. In fact, I think that
> a sure way to protect information from many people is to label it documentation.
Some people (maybe a lot of people) are like that. They want the quick answer,
and they aren't willing to do their homework. They're lazy. So don't improve
the documentation for them. Do it for those of us who really want to learn
Unix/Linux properly.
> :>IMHO, a gopher server, or a set of Mosaic pages, is a great idea.
>
> Yes, true, it would be great. But I sincerely doubt that it will change
> anything.
I think it will.
> :>That's exactly why there are so many posts to c.o.l.h. And a lot of the
> :>questions I've seen are asking for information I've found (the hard way) in the
> :>FAQs and other documentation. I must admit I'm a bit irritated about that,
> :>though I've learned quite a bit from the documentation.
> :>
> Is it so hard to read a text that has more than 40 lines?
If it has a LOT more than 40 lines, and if you have to wade through all of it
to get a simple answer to a simple question, yes, it IS hard. Especially if you
don't have much time on your hands, and you later discover that somebody else
asked the same question on c.o.l.h. I try to avoid asking questions on
c.o.l.h., except as a last resort.
> If people have a
> modern distribution running (and I think most have), all documentation files
> are online in the /usr/doc directory (or the /usr/X386/lib/X11/etc directory
> for XFree86 documentation) unless they tried to save disk space by omitting the
> documentation packages. So I wonder, why people do not read them.
I think a lot of people do read them. Why not make them a little easier to read?
> :>> I, against *all* of my better judgement, would be willing to
> :>> help set up such database, using gopher or some other method, if
> :>> there is reason to believe that people would actually use it.
> :>
> :>If it's easy and friendly, people will use it. Like I said, I would certainly
> :>use it. I think it's an extremely good idea.
>
> At the best, people would have to read it. This seems to be too much an efford
> for some.
Yes, "for some", but not for all.
Guido
Dylan Smith
: And why do you think people would use it? In fact the FAQs and HOWTOs are
: 'searchable databases', just grep them for the keywords.
I put my Linux system online for people to dial into, and left text files
in the the guest directory where they would first log into. The typical
DOS user response who had never seen UNIX before was:
guest> dir
readme commands-to-use
guest> type readme
readme is ./readme
guest> type commands-to-use
commands-to-use is ./commands-to-use
guest> dir/w
dir/w: command not found
guest> logout
I ended up putting a quick noddy message in /etc/motd telling DOSsers
how to use the More command. Slackware doesn't even come with this: if
a new to UNIX user manages to install it at all (unlikely) the user is
unlikely to be able to know how to read the FAQ's! If you want people
to move from DOS to Linux you need some very simple help (which is not
available at present) and a sympathetic ear. Let's face it - what
we think is easy to understand may not be for someone else. Consequence
of your attitude - people frightened off Linux and spread the word that
it is difficult to use (when it's not really any harder than DOS when you
think about it).
--
#include <disclaimer.h>
Internet: dy...@vnet.ibm.com | JANET: dylan%vnet.i...@uk.ac.nsfnet-relay
Byron A Jeff
most new Linux users won't be operating in a vacuum. Typically there will
be someone there with more experience then the new user has. I'd like to
tackle the concrete example of this: my parents. They have a new box
with Linux on it. They are completely new to the computer game: no
experience whatsoever. However they have a son that is working on a PhD
in computer science, is an instructor at a University in computer science,
and is quite well versed in the usage of Unix boxes in general and
Linux boxes in particular. BTW the machine is 500 miles away from said son.
First of all I think that the distributions do a fairly good job of
insulating much of the original setup tasks. The real problems as Matt
has pointed out occurs not only when you attempt to administrate the machine
but when new computer and Unix users attempt to use it. My quandry is how
to teach my parents long distance on how to use this machine. I think this
example points to the heart of the discussion.
Now first of all I'm smart enough to realize that I'm the admin for the machine
even though I don't have physical access to it. So I have 2 novice users
that fortunately don't have to deal with neither the installation (I did that)
or maintenance (I do that too). But my question is what documentation is
appropriate for a complete novice? Now on to the discussion.
In article <1994May3.2...@cs.cornell.edu>,
Matt Welsh <m...@cs.cornell.edu> wrote:
>In article <1994May3.1...@ns1.cc.lehigh.edu> dl...@ns1.cc.lehigh.edu (DAVID L. JOHNSON) writes:
>>In article <1994May3.0...@cs.cornell.edu>, m...@cs.cornell.edu (Matt Welsh) writes:
>>>a) Simple documentation is for simple systems. Linux is anything
>>> _but_ simple.
>>>
>>Not really. It's not that complicated.
>
>It's not complicated to set up, you mean. Pre-packaged distributions make
>it really easy to install and set up a Linux system. But that's just the
>icing on the cake. I doubt that very many Linux users without, oh,
>three or four years minimum UNIX systems admin experience really
>understand all of the intricasies of the system---how to build shared
>libraries, how to hack sendmail.cf, and so on. Most of it is done for
>you with standard distributions, but that's only hiding the complexity
>from the systems administrator. Once they dig into it, there's a lot
>to learn.
True. There are some solutions here:
1) Automate as many of the sysadmin tasks as possible. As much as I hate
it I think there needs to be a sysadmin tool on the order of SMIT for
AIX. I personally wouldn't use it but I think for the novice sysadm
it would be a boon.
2) Simplify the task. Sendmail used to be a perfect example. I hacked on
sendmail.cf files for months and I still don't really understand it.
However smail ( and I believe IDA) bring the level of complexity down
to answering a few simple questions.
3) Documentation. Obviously. And the more examples the better.
A combination of the three would help greatly in many tasks such as:
- mail setup
- printer setup
- new users (adduser actually does a pretty good job of this)
- X setup
You get the idea.
>
>>>b) Too much of the time, we blame the complexity of Linux on the poor
>>> quality of the documentation. This isn't always the case.
>>
>>As much as I have to admire everyone in this effort, it is sometimes the case
>>that a lot of seemingly obvious (but not really obvious) things are
>>ommitted from the documentation.
>
>Such as what? I personally try my best not to assume much of anything,
>and in so doing often have to say the same thing several different
>ways (also knowing that many readers of Linux documentation aren't
>native speakers of English). But I do wish that you and others would
>point out these glaring inconsistencies. If you don't, we can't do anything
>to correct them.
Matt you're exempt ;-) You're guide is a shining example of how to do it
right. However other documents assume much. Perhaps we should think about
documenting the same info at different levels and have a rating systems
for documents (Beginner,Intermediate,Advanced,Expert,Guru) so that folks
can pick out an appropriate level for their skills. And as Matt pointed
out in another post, sometimes with complex topics oversimplification can
drop the relavent information. However an oversimplified overview with
other more complex documents may help novice users get their feet wet.
>
>>Read that again. In order to be able to admin a unix system, you have to have
>>been doing it already?
>
>Not necessarily, but you at least need to read a great deal about it, and
>probably apprentice yourself under another UNIX systems admin. (I was
>lucky enough to have Jon Magid---now sunSITE administrator---as my guru.)
>But diving into the deep end of the pool with your own UNIX system, without
>anyone to help you out and no books to lead the way, is usually a very
>bad idea.
Agreed. Admin is definitely an apprentice type of system. Sit at the feet
of the master and watch them operate. I'm now the top admin in the C.S
department where I work and folks come and ask questions, watch how I work,
read books and docs, and the like. That's how we learn.
>
>My main point is that no matter HOW good the documentation is, it can
>NEVER replace experience. Experience _sometimes_ comes with "just doing it"
>on your own. More often it comes by looking over someone's shoulder for
>a few months and playing on another UNIX system, before taking one
>over yourself. Books can't teach you everything.
>
>>> It's not the kind of thing that we can expect MS-DOS users to do overnight,
>>> plain and simple. And, even if we could get them to install Linux
>>> overnight (the current instructions should be clear enough to do so),
>>> they won't be ready for the big task: Running the system.
>>>
>>What? This is really condescending.
>
>No, it's not. It's a reality check.
Right. I think that they can become good users relatively quickly but
the sysadm task takes a while to learn. Consider: sysadm is easy to do
as long as everything works as advertised. However at the first glitch
the difference between a seasoned admin and a novice is quite apparent.
I'll give a simple example. I just bought a HP Deskjet 520. I'd tested it
the a Dell Laptop I'm borrowing but yesterday I finally got around to
hooking it up to my main machine. Not wanting to screw around with the
lp[rqd] system I tried to cat a file to /dev/lp1. I get the message.
cat: /dev/lp1 no such device
Probably would send a novice into a conniption. I recognize that as the
driver not being compiled into the kernel. So I reconfig and recompile
the kernel (and don't say that everyone knows how to do this because I
see a post every week in the newsgroups about "How do you compile the kernel?")
and because I was planing on trying a PLIP connection with the aforementioned
Dell laptop I dropped PLIP support it. Well when I bring it back up the
Printer's busy light stays on and nothing prints out. There goes another
post to the newsgroup from the novice sysadm. I however sit a minute and
think about what can conflict with the printer. I was rebooting the machine
when the PLIP status message caught my eye. AHA! (sysadmining is a lot of
AHA experiences). Took PLIP out, recompiled, tested, works like a champ.
Being a good sysadm is like being a good programmer: you have to understand
your tools, and you have to understand the interactions between the parts
of your system. It takes awhile and I think that all Matt is saying.
>
>I too was once an MS-DOS user (and before, that an Apple IIe user, but
>let's not get into that.) With the documentation available today, I
>probably could have installed and set up my own Linux system. But that
>doesn't mean that I would have _understood_ any of what I was doing.
>
>>>However, installing and running your
>>>own UNIX system is a huge task, and isn't something that you can reasonably
>>>expect a complete UNIX neophyte to do.
>>>
>>But that is exactly what these new distributions enable people to do. Many
>>new linux users are students, who have no possibility of already having
>>had unix experience
>
>I'm fully and completely aware of that. Of course this doesn't mean that
>they _should_ be running Linux, but they can, of course. My point is that
>running a Linux system without understanding what you're doing, as is
>the case much of the time, is hazardous and leads you into situations where
>you have to complain on c.o.l.h. All of this can be remedied by taking
>things a bit more slowly and learning step-by-step. People who have been
>using UNIX for less than a month shouldn't be hacking Smail configuration
>files, but unfortunately with Linux that is the case. I took me a few
>months just using UNIX before I was ready to run a system on my own.
>With Linux, however, the user is forced to install, configure, run,
>_and_ learn to use the system all at once. That's why it's not for
>everybody---it takes a lot of committment if you've never used UNIX before.
True enough. Now back to my issue: how to make usable users out of novices?
Is there any docs/books that might make my task easier? And sometimes
standard unix stuff is not enough. For example: joe. To subject any new user
the vi is like sticking bamboo slivers under fingernails: torture. So I find
that joe is relatively easy to learn and use, until you meet the user that
asks what the ctrl key is for. And there's no books available for that
particular system. I'll probably end up writing an info sheet for my
parents but how do you hold the hands of such novice users?
>
>>Also true. But please don't put newbies off with the suggestion that they are
>>just too dumb to learn.
>
>I never said that. Everyone can learn. The question is, _how_ will they
>learn? It's something like throwing a piano at a five-year-old and
>expecting them to turn out a perfect rendition of the Moonlight Sonata.
>(Some five-year-olds could do it, and some could not.) It has nothing to
>do with stupidity or intelligence---just experience. Usually to do
>these kinds of things takes months (if not years) of reading, learning,
>and tinkering. Blaming the troubles of neophytes purely on inadequate
>documentation is really underhanded. Even if the documentation were
>absolutely perfect, it can't replace actual experience.
Correct. There has to be a combination of reading, using, asking questions,
making mistakes, and handholding. That's how we learn.
The only question: is there docs for neophytes to start with?
Later,
BAJ
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332 Internet: by...@cc.gatech.edu
Kevin Lentin
> Okay, so I'm new to Linux and maybe even unix. Chances are that I have no
> clue what grep is, how to use it, and so on. Of course I could grep the FAQ
> on it, but that won't tell me anything (oh, wait...I don't know how to grep.)
> That's okay...it's not Linux Specific, so I wouldn't find it in there anyway.
If you are so new to unix that programs like grep and man are unknown to
you, then you should get an introductory book on the subject. Granted a
distribution shuold come with some helpful hints etc but if you're going to
install and operate a unix system then you should go and read some proper
books on the subject before you get into the linux specifics. I think that
efforts should be concentrated not on rewriting information that is in
abundance out there, but rather into working on stuff specific to Linux.
--
[==================================================================]
[ Kevin Lentin |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kev...@bruce.cs.monash.edu.au |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!' |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]
Mike Kenney
Matt Welsh <m...@cs.cornell.edu> wrote:
[ stuff deleted ]
>
>Excuse me for sounding a bit testy, but everyone seems to be struggling
>over new ways to search the documentation for the answers that you're
>looking for. I've got a great way of doing it---use your built-in biological
>grep. It's called "reading".
>
>mdw
Well put. Folks new to Unix need to understand that they are becoming
System Administrators when they install Linux on their PCs. They need to
be willing to invest some time in learning how things work.
If you want learn Unix, there is an excellent reading list in the
comp.unix FAQs.
----
Mike Kenney
UW Applied Physics Lab
mi...@apl.washington.edu
Matt Welsh
>No one should be flamed when they're trying to help someone.
Not necessarily. A common argument used in defense of the poor status
of Linux support is, "It's free, so put up or shut up." I don't know if
adhering to that attitude gets us anywhere. If it did, then Linux would
still be completely a UNIX hacker's paradise, unreachable by neophytes.
A better statement would be, "It's free, so put up or help out." Instead
of complaining about the status of Linux software, documentation, what
have you---help the developers to make it better. I've heard many
complaints from people that Linux is a disorganized, bug-ridden and
flea-bitten operating system that isn't worth the dust accumulating in
the cooling fan. However, if Linux were the perfect solution, I'm sure
those very same people would be happy to pick it up and use it, free of
charge.
The point is, there are two types of people: People who care about
developing Linux, and those who care only about using it, or making money
from it. Linux is where it is today because of the former group, not
the latter. And, yes, it still has a long way to go. But it's never going
to get there as long as people are content with the system as it is
and don't help out to push the envelope. Of course, not everyone has time
to do so. That's fine. But if you want to "give something back" to the Linux
community, the best thing that you can do is join in the fray. Implement a
new kernel driver. Port some nifty software application. Write some man
pages. (Write a HOWTO, and mail it to me.) You don't have to be a guru or
complete UNIX wizard in order to do these things---sometimes the best way
to learn is by doing.
Everyone who complains that the FAQs and HOWTOs don't contain the
information they need should be morally OBLIGED to send in corrections
and additions once they DO find the answers. Perhaps we should make
that a condition for redistributing them. :)
>It's also a bit disheartening when you obtain a Linux document (let's say, as
>an example, the Kernel Hacker's Guide), and it has a warning which tells you
>that it's an alpha version, that a lot of the information within may be wildly
>inaccurate, and that if the reader acts on the information and gets burned,
>it's his own tough luck.
Disheartening, yes, but the entire user community is responsible for that.
As you may know, Michael Johnson is now acting as editor for the Linux
Journal, and doesn't have a lot of free time on his hands. If you're
displeased with the quality of the documentation, please do something about
it. Write or rewrite a chapter, and submit it to him. If you know what
you're talking about, I'm sure he'll be happy to include it.
What I'm trying to get across is this: Linux needs more developmental
participation from its users. As Linux has grown, the user base feels
somehow disconnected from the developers. There is no distinction. The
"developers" are simply those users who take the time (some far more so
than others) to hack the system and contribute to the community. Somehow,
many users feel that it's not their place to comment on the documentation,
or send in corrections, and so forth---perhaps because they don't want
to insult or offend the writers. Hogwash! I appreciate nothing more than
corrections and suggestions on the Linux documentation. Without that
kind of feedback nothing can improve. I imagine that the same goes for
maintainers of various software packages, and the like.
mdw
Matt Welsh
>1) Automate as many of the sysadmin tasks as possible. As much as I hate
> it I think there needs to be a sysadmin tool on the order of SMIT for
> AIX. I personally wouldn't use it but I think for the novice sysadm
> it would be a boon.
You know what they say---"SMIT Happens".
Something that I've been thinking about in terms of Debian is a
system administration tool similar to "sysadm", found on DG/UX and
other systems. Tcl could be used for a terminal-based interface to
such a beast, where systems administration tasks were implemented
as Tcl scripts, and Tk could provide a simple X interface to it as well.
In this way you get two for the price of one.
Such a tool is not too diffcult as long as you know what your
system configuration is like, and where all of the relevant files
are. Debian and the FSSTND will fix that problem, we hope. And, if
so, I don't think that such a tool will be too long in the making.
There have been a few attempts but the inconsistency between
distribution layouts has made it nearly impossible to complete.
>A combination of the three would help greatly in many tasks such as:
>- mail setup
>- printer setup
>- new users (adduser actually does a pretty good job of this)
>- X setup
Exactly. What I have in mind would provide a simple X or terminal-based
menu-driven system, stepping the system administrator through these
tasks and doing sanity checking. This is a great thing to have, even for
grease-monkey UNIX sysadmins like myself. It means that you don't have to
THINK about what you're doing---you can add a user in about 30 seconds,
fire-and-forget.
X setup gets to be a bit more tricky, but feasible, I imagine.
>Perhaps we should think about
>documenting the same info at different levels and have a rating systems
>for documents (Beginner,Intermediate,Advanced,Expert,Guru) so that folks
>can pick out an appropriate level for their skills.
I've got it: Each HOWTO and other doc could be rated on a scale,
from one virtual beer for novices, to a six-pack of virtual beers for
gurus.
Actually, I don't like that idea. It's easier to spell out at the top
of the document what audience it is for and what it assumes.
This is also more flexible.
>True enough. Now back to my issue: how to make usable users out of novices?
>Is there any docs/books that might make my task easier? And sometimes
>standard unix stuff is not enough. For example: joe. To subject any new user
>the vi is like sticking bamboo slivers under fingernails: torture.
Oh, vi is fun. You just have to learn to appreciate self-mutilation.
It's something like getting a tattoo---it's painful at first, but the
experience stays with you for life.
>So I find
>that joe is relatively easy to learn and use, until you meet the user that
>asks what the ctrl key is for.
Those are people who are in a complete vacuum, for whom there's no hope.
It is NOT reasonable to expect anyone with that level of inexperience to
run Linux. That's where I draw the line. They can certainly learn those
things, but should do so on a tame system such as MS-DOS.
>The only question: is there docs for neophytes to start with?
Books, books, books. The I&GS includes a UNIX tutorial for beginners.
Of course this assumes knowledge of MS-DOS or _some_ operating system.
I don't think that new computer users should be using Linux. That's
my personal philosophy: That before running Linux, a computer user
should go through at least two years of the same torture that I did,
before moving to Linux: MS-DOS.
mdw
Anthony J. Stuckey
>I put my Linux system online for people to dial into, and left text files
>in the the guest directory where they would first log into. The typical
>DOS user response who had never seen UNIX before was:
>guest> dir
>readme commands-to-use
>guest> type readme
>readme is ./readme
>guest> type commands-to-use
>commands-to-use is ./commands-to-use
>guest> dir/w
>dir/w: command not found
>guest> logout
This just goes to show how distinctly lousy DOS is.
In early versions of DOS, you could use MORE on files as well.
Nowadays when you try it, you get an error of "too many files specified on
command line" -- you have to use more < file.
I have trained many people away from ever using TYPE in my time, only
to see all of that effort blown away by later versions of DOS.
>I ended up putting a quick noddy message in /etc/motd telling DOSsers
>how to use the More command. Slackware doesn't even come with this: if
>a new to UNIX user manages to install it at all (unlikely) the user is
>unlikely to be able to know how to read the FAQ's! If you want people
>to move from DOS to Linux you need some very simple help (which is not
>available at present) and a sympathetic ear. Let's face it - what
>we think is easy to understand may not be for someone else. Consequence
>of your attitude - people frightened off Linux and spread the word that
>it is difficult to use (when it's not really any harder than DOS when you
>think about it).
Slackware as a specific, and Unix as a whole, could do a whole hell of
a lot to make Unix easier to use. I'm a strong advocate of a set of hard
links, myself. /bin/delete -> /bin/rm and so on. Other than that
stunningly annoying beast of "backwards compatibility", there's no reason
not to be using real words for commands.
Insert smileys wherever you can.
--
Anthony J. Stuckey stu...@mrcnext.cso.uiuc.edu
"And if you frisbee-throw a universe where does it go?" -- Steve Blunt.
GCS/S -d+@ p c(++) l u+ e+(-) m+(*) s+++/-- !n h(*) f+ g+ w+ t+@ r y?
KiboNumber == 1
Byron A Jeff
you read nothing else of this post, read it.
In article <1994May5.0...@cs.cornell.edu>,
Matt Welsh <m...@cs.cornell.edu> wrote:
> [ Matt and I agree that a sysadmin tool would be helpful. ]
>>Perhaps we should think about
>>documenting the same info at different levels and have a rating systems
>>for documents (Beginner,Intermediate,Advanced,Expert,Guru) so that folks
>>can pick out an appropriate level for their skills.
>
>I've got it: Each HOWTO and other doc could be rated on a scale,
>from one virtual beer for novices, to a six-pack of virtual beers for
>gurus.
>
>Actually, I don't like that idea. It's easier to spell out at the top
>of the document what audience it is for and what it assumes.
>This is also more flexible.
That's correct. What I'm saying is that we need to think about covering
the material on different levels. A rating system really isn't necessary.
However pointing out the documents for the same material at the different
levels in a particular doc might be useful.
>
>>True enough. Now back to my issue: how to make usable users out of novices?
>>Is there any docs/books that might make my task easier? And sometimes
>>standard unix stuff is not enough. For example: joe. To subject any new user
>>the vi is like sticking bamboo slivers under fingernails: torture.
>
>Oh, vi is fun. You just have to learn to appreciate self-mutilation.
>It's something like getting a tattoo---it's painful at first, but the
>experience stays with you for life.
I know this is tounge (sp) in cheek. vi is the mose horrible excuse for
an editor ever written. The fact that it's the only thing I use notwithstanding
;-)
>
>>So I find
>>that joe is relatively easy to learn and use, until you meet the user that
>>asks what the ctrl key is for.
>
>Those are people who are in a complete vacuum, for whom there's no hope.
>It is NOT reasonable to expect anyone with that level of inexperience to
>run Linux. That's where I draw the line. They can certainly learn those
>things, but should do so on a tame system such as MS-DOS.
>
>>The only question: is there docs for neophytes to start with?
>
>Books, books, books. The I&GS includes a UNIX tutorial for beginners.
>Of course this assumes knowledge of MS-DOS or _some_ operating system.
>I don't think that new computer users should be using Linux. That's
>my personal philosophy: That before running Linux, a computer user
>should go through at least two years of the same torture that I did,
>before moving to Linux: MS-DOS.
>
Matt this is where we disagree (sort of). I'm not talking about running Linux
I'm talking about using it to get work done. We all know that an editor is
an editor is an editor. My take on this is not to expose new users to an OS
that they won't use for the long haul. Human nature is to stick with what
you know and what you learn first. If I expose my parents to DOS/WINDOWS
once they learn how to use it, they won't feel a need to switch. That's
why Linux is on their machine. It's the same tasks regardless of the OS.
Linux just gives them many orders of magnitude more tools to use eventually.
And I won't have to bother explaining why Linux is so much better than
DOS/Windows during the transistion process. I mean why ruin a blank canvas
(which you'll have to admit we Linux advocates don't get very often) with
crayon when we can paint fine art on it even if it takes a bit more time
initally?
And remember my parents won't have to run the machine, that's my job. It's
one of the primary reasons I put in a second phone line and a 14.4 modem
in the machine, so I can call and handhold while actually being logged
in at the same time.
What I'm pointing out is that most of the documentation is for DOS refugees
and current Unix users. What I've failed to see (and I admit I've only given
a cursory look) is documentation for rank novices. I plan to take a look
at my favorite computer bookstore for something but I'd gladly accept
suggestions.
Actually while I've been sitting here writing this message I've thought of
a throwback to the old SLS days: menus. With the really cool dialog command
it would be a piece of cake to throw together a simple menu to do the
simple tasks that rank novices need: editing, printing, communications, etc.
I guess I'm a bit biased because one of my Human Factors Professors was
doing usability research in progressive systems and found that menus and
help do a great deal for novice users but generally hinder experts.
I'll try this dialog based thing as an experiment with my parents and let you
know how it comes out.
Also I've found from experience (Freshman computer science students) that
novices are much more paper dependant than experts. Experts will use
on-line searchable documents. But novices tend to gravitate to paper.
Again it's a fallback to folks using what they are comfortable with.
That's why I'm interested in Unix documentation for the novice class.
I figure in the next year I'll introduce 20-30 folks to Linux. Most will
not be experts. Most however will have some computer usage experience.
My first book for them is always Matt's guide. However I don't have anything
yet that'll fill the need of the rank novice. And remember we're not talking
about sysadmin tasks, just regular old usage. Something with an explanation of
the file organization, logging in and out, using an editor, printing, etc.
Written from the novice perspective (i.e. assume nothing).
I remember that one of the Waite books did a pretty good job of this. I'll
check it out at the bookstore this evening.
BTW does joe have a users guide?
BAJ
Lastly I want to share a file that I received in my E-mail this morning
that'll give you an idea of the type of user we may have to deal with in
the next couple of years as Linux enthusiasts. Just something for you
to think about.
--------------------------Begin Included Text -------------------------
I thought you guys would enjoy this look at the state of the PC users in
1994.
=>>From the Wall Street Journal, Tuesday, March 1, 1994.
=>Date: Wed, 2 Mar 1994 14:58:28 -0500
=>
=>BEFUDDLED PC USERS FLOOD HELP LINES, AND NO QUESTION SEEMS TO BE TOO BASIC
=>
=>AUSTIN, Texas - The exasperated help-line caller said she couldn't get
=>her new Dell computer to turn on. Jay Ablinger, a Dell Computer Corp.
=>technician, made sure the computer was plugged in and then asked the
=>woman what happened when she pushed the power button.
=>
=>"I've pushed and pushed on this foot pedal and nothing happens," the
=>woman replied. "Foot pedal?" the technician asked. "Yes," the woman
=>said, "this little white foot pedal with the on switch." The "foot
=>pedal," it turned out, was the computer's mouse, a hand-operated device
=>that helps to control the computer's operations.
=>
=>Personal-computer makers are discovering that it's still a low-tech
=>world out there. While they are finally having great success selling
=>PCs to households, they now have to deal with people to whom monitors
=>and disk drives are a foreign as another language.
=>
=>"It is rather mystifying to get this nice, beautiful machine and not
=>know anything about it," says Ed Shuler, a technician who helps field
=>consumer calls at Dell's headquarters here. "It's going into unfamiliar
=>territory," adds Gus Kolias, vice president of customer service and
=>training for Compaq Computer Corp. "People are looking for a comfort
=>level."
=>
=>Only two years ago, most calls to PC help lines came from techies
=>needing help on complex problems. But now, with computer sales to homes
=>exploding as new "multimedia" functions gain mass appeal, PC makers say
=>that as many as 70% of their calls come from rank novices. Partly
=>because of the volume of calls, some computer companies have started
=>charging help-line users.
=>
=>The questions are often so basic that they could have been answered by
=>opening the manual that comes with every machine. One woman called Dell's
=>toll-free line to ask how to install batteries in her laptop. When
=>told that the directions were on the first page of the manual, says Steve
=>Smith, Dell director of technical support, the woman replied angrily,
=>"I just paid $2,000 for this damn thing, and I'm not going to read a book."
=>
=>Indeed, it seems that these buyers rarely refer to a manual when a phone
=>is at hand. "If there is a book and a phone and they're side by side,
=>the phone wins time after time," says Craig McQuilkin, manager of
=>service marketing for AST Research, Inc. in Irvine, Calif. "It's a
=>phenomenon of people wanting to talk to people."
=>
=>And do they ever. Compaq's help center in Houston, Texas, is inundated
=>by some 8,000 consumer calls a day, with inquiries like this one related
=>by technician John Wolf: "A frustrated customer called, who said her
=>brand new Contura would not work. She said she had unpacked the unit,
=>plugged it in, opened it up and sat there for 20 minutes waiting for
=>something to happen. When asked what happened when she pressed the
=>power switch, she asked, 'What power switch?'"
=>
=>Seemingly simple computer features baffle some users. So many people have
=>called to ask where the "any" key is when "Press Any Key" flashes on the
=>screen that Compaq is considering changing the command to "Press Return
=>Key."
=>
=>Some people can't figure out the mouse. Tamra Eagle, an AST technical
=>support supervisor, says one customer complained that her mouse was hard
=>to control with the "dust cover" on. The cover turned out to be the
=>plastic bag the mouse was packaged in. Dell technician Wayne Zieschang
=>says one of his customers held the mouse and pointed it at the screen,
=>all the while clicking madly. The customer got no response because the
=>mouse works only if it's moved over a flat surface.
=>
=>Disk drives are another bugaboo. Compaq technician Brent Sullivan says
=>a customer was having trouble reading word-processing files from his
=>old diskettes. After troubleshooting for magnets and heat failed to
=>diagnose the problem, Mr. Sullivan asked what else was being done with
=>the diskette. The customer's response: "I put a label on the diskette,
=>roll it into the typewriter..."
=>
=>At AST, another customer dutifully complied with a technician's request
=>that she send in a copy of a defective floppy disk. A letter from the
=>customer arrived a few days later, along with a Xerox copy of the floppy.
=>And at Dell, a technician advised his customer to put his troubled floppy
=>back in the drive and "close the door." Asking the technician to "hold on,"
=>the customer put the phone down and was heard walking over to shut the
=>door to his room. The technician meant the door to his floppy drive.
=>
=>The software inside the computer can be equally befuddling. A Dell
=>customer called to say he couldn't get his computer to fax anything.
=>After 40 minutes of troubleshooting, the technician discovered the man
=>was trying to fax a piece of paper by holding it in front of the monitor
=>screen and hitting the "send" key.
=>
=>Another Dell customer needed help setting up a new program, so Dell
=>technician Gary Rock referred him to the local Egghead. "Yeah, I got me
=>a couple of friends," the customer replied. When told Egghead was a
=>software store, the man said, "Oh! I thought you meant for me to find a
=>couple of geeks."
=>
=>No realizing how fragile computers can be, some people end up damaging
=>parts beyond repair. A Dell customer called to complain that his
=>keyboard no longer worked. He had cleaned it, he said, filling up his
=>tub with soap and water and soaking his keyboard for a day, and then
=>removing all the keys and washing them individually.
=>
=>Computers make some people paranoid. A Dell technician, Morgan Vergara,
=>says he once calmed a man who became enraged because "his computer had
=>told him he was bad and an invalid." Mr. Vergara patiently explained
=>that the computer's "bad command" and "invalid" responses shouldn't be
=>taken personally.
=>
=>These days PC-help technicians increasingly find themselves taking on
=>the role of amateur psychologists. Mr. Shuler, the Dell technician, who
=>once worked as a psychiatric nurse, says he defused a potential domestic
=>fight by soothingly talking a man through a computer problem after the
=>man had screamed threats at his wife and children in the background.
=>
=>There are also the lonely hearts who seek out human contact, even if it
=>happens to be a computer techie. One man from New Hampshire calls Dell
=>every time he experiences a life crisis. He gets a technician to walk
=>him through some contrived problem with his computer, apparently feeling
=>uplifted by the process.
=>
=>"A lot of people want reassurance," says Mr. Shuler.
=>
=>----END OF MESSAGE---
Patrick Schaaf
>I for one would like to know how I am supposed to use the dosemu system.
>I have yet to find what command, or commands I have to run to get it
>going!
Funny. I type 'info "DOS emulation"' and get the best doc I've seen since
the Cygnus libc documentation. The docs come straigt out of the DOSemu
package.
The docs are there. Probably not on your machine, probably not on your
distribution, but they are there. When you are missing something,
the first thing to do is to get the original distribution of the software
you have questions about.
We are experiencing a big culture clash here. On the "development" side
are people who work with a "do it yourself" mentality. On the "user" side
are people who want to be spoonfed anything. Problem is: the developers
do their best to put the docs in your fridge, but you are too lazy to
cook them; you prefer to starve or go to Mac Donalds. Mac Donalds is
closed. Learn to cook.
Please don't take this as a flame. What I just said was exaggerated
a lot, but I think it is basically correct.
bye
Patrick
Andrew R. Tefft
>In article <1994May3.1...@ns1.cc.lehigh.edu> dl...@ns1.cc.lehigh.edu (DAVID L. JOHNSON) writes:
>>In article <1994May3.0...@cs.cornell.edu>, m...@cs.cornell.edu (Matt Welsh) writes:
>>>a) Simple documentation is for simple systems. Linux is anything
>>> _but_ simple.
>>>
>>Not really. It's not that complicated.
>
>It's not complicated to set up, you mean. Pre-packaged distributions make
>it really easy to install and set up a Linux system. But that's just the
>icing on the cake. I doubt that very many Linux users without, oh,
>three or four years minimum UNIX systems admin experience really
>understand all of the intricasies of the system---how to build shared
>libraries, how to hack sendmail.cf, and so on. Most of it is done for
>you with standard distributions, but that's only hiding the complexity
>from the systems administrator. Once they dig into it, there's a lot
>to learn.
Really, what makes you (not you Matt) believe that Linux is any less complicated
than any commercial unix? The distributions are geared towards those
with little admin knowledge, and indeed they are somewhat usable by
the pure user, who is just learning administrative tasks. But the moment
that something goes wrong -- and things often do, no fault of Linux's,
but any time you add anything more than the simplest piece of software
to the system you risk unknown interactions -- the beginner runs to c.o.l.h.
If Unix was considered non-administration-intensive, then every
workstation user on the planet would have the root password to his
workstation. You don't need root access or root knowledge to make use of
your Linux system, but you will need that knowledge (or someone to do
it for you) to add any significant utility, or fix bugs in the system
software. And trying to learn unix at the same time you're learning unix
administration is rough.
I learned what I know from Unix mostly from "man -k". I did
read an incomprehensible unix book way back, and at least learned
how to make directories, copy files, and about file permissions.
But I waste a lot of time handholding unix users as it is now.
Handholding is never the way to go.
---
Andy Tefft - new, expanded .sig - tef...@cs690-3.erie.ge.com
Rob Ransbottom
<In article <2q33n2$q...@clarknet.clark.net> ke...@clark.net (Ken Firestone) writes:
<>So yes, a Linux for Dummies would be a good idea, perhaps with a more
<>dignified name. Anyone with enough sense to try Linux is not a Dummy!
<The book "Linux Installation and Getting Started", as well as the
<Installation-HOWTO, attempt to be very closely geared towards complete
<UNIX newcomers. That's always been my intention for that introductory
<documentation.
<But, here's a simple truism. If we make the documentation _too_ simple,
<there are a number of drawbacks:
<a) Simple documentation is for simple systems. Linux is anything
< _but_ simple. To oversimplify the documentation would invariably
...
<b) Too much of the time, we blame the complexity of Linux on the poor
< quality of the documentation. This isn't always the case. Linux
< really _is_ complex, and nothing but documentation at the appropriate
...
<c) Similar to the above, someone who can read and understand "instructions
< for idiots" won't be prepared at all for the reality of Linux. It's a
...
I agree with you. However we should realize that we are envisioning
Linux configured as a traditional unix system. This is not
the only vision possible.
Steve Horsley
And if you want to know why, look at the postings here. Around half the
postings support the attitude that if you can't find what you need to
know in the README and FAQ files, then you are lazy, stupid, or
(probably) both.
With an attitude like that, unix will never oust other well documented
(though perhaps inferior) operating systems.
I, like many others, am a DOS fugitive, who installed linux with the
intention of learning about unix. I may be no Einstein, but I don't
scrape my knuckles on the ground when I walk. I have found serious
problems trying to do the simplest things.
The man pages are great if you know what command you want to use and
what it does, but can't quite remember the syntax. They are useless if
you are trying to figure out what a command does and what you might
want it for (I have just posted a question about tar for this reason).
Unix is not the only o/s guilty of this - I once read a VMS manual from
cover to cover and found the same thing.
More specifically to linux, the HOWTO documents often take a high-level
line, or simply omit vital info. Here is an example:
Mitsumi CDROM drive, for instance... The kernel said the drive was there,
but how the f*** do you mount it? The howto doesn't say. I couldn't find
anything that said. I spent ages guessing before I got lucky with
-t iso9660! You won't find that in a book from Smiths. Incidentally, I've
compiled system-V file system support in, and expect that it will take me
at least an hour to get the first sys-v floppy mounted, again because
I will have to guess what linux calls the file system type in the mount
command.
Configuring Xwindows - I couldn't find anything that said the config file
was called /var/X11/lib/X11/Xconfig. I was left to guess and make one.
Although I understand why they don't give a default timing database, it
would be nice if the readme file said what the config file should be called.
Configuring Xwindows again - there was NO list of the available mouse drivers.
Some of the examples used different mouse drivers, and the readme mentioned
that most Logitech mice need the Microsoft driver, but NOWHERE is there a
full list of the drivers you can choose from. Neither did ANY documentation
mention the existence of a test-mouse utility.
Configuring Xwindows again - I couldn't find any mention of the hot-key which
flips between the video modes in the Xconfig list. I found by trial and
error that it is <Alt><Ctl><Keypad+>.
These are all real basic stuff that anyone familiar with linux knows
without thinking, but as a newcomer, it seems that absolutely everything
I want to do is a big problem. With most other systems, I would spend a
lot of time reading documentation finding out how to do these basics. With
linux, I just spend a lot of time finding that it is not documented.
I agree that people should RTFM, but there seems to be no index which says
which FM to R, and far too often it's just not in any FM at all.
If anyone asked me what operating system they shoud use for their department,
I would say that although linux seems pretty comprehensive and stable, they
should use anything else, but NOT linux. The documentation is simply not
sufficient for anyone other than a keen hobbyist or the very desparate.
Thanks for letting me get that off my chest. I do see some people making
great efforts with documentation, but there are a lot of holes to fill, and
people with anti-learner attitude do no good at all.
--
Steve Horsley st...@rigel.demon.co.uk
Lars Wirzenius
> UNIX IS DEAD - UNIX IS DEAD - UNIX IS DEAD
Long live Linux :-)
Your points about the documentation were good. It is too difficult to
find the information in the documentation, when it is there at all.
Well, it usually is there, in one form or another, but the finding part
is difficult. This is exemplified by your specific complaints below.
> Mitsumi CDROM drive, for instance... The kernel said the drive was there,
> but how the f*** do you mount it? The howto doesn't say. I couldn't find
> anything that said.
I couldn't find anything either, using only five minutes (I perhaps could
have, had I spent longer, but that just illustrates the point, doesn't
it?). Anyway, the mount command syntax is
mount [-t fstype] [-r] /dev/devfile /dir
where [] as usual marks optional items, and fstype is the type of the
filesystem (i.e., the -t option selects the type), -r says to mount
read-only, /dev/devfile is the device file that corresponds to the
floppy or hard disk partition or whatever it is you want to mount, and
/dir is the directory where the new disk or whatever should be made
visible in the directory tree.
The available filesystem types in my kernel (1.0; I haven't booted for
45 days) are (this comes straight from the kernel sources, since I didn't
find a list):
minix
ext
ext2
xiafs
msdos
proc
nfs
iso9660
xenix
sysv
coherent
hpfs
> Configuring Xwindows - I couldn't find anything that said the config file
> was called /var/X11/lib/X11/Xconfig.
The README.Linux file that is part of the original XFree86 distribution
(and which is prominently on display in the XFree86 directory on Linux ftp
sites) points within the first 50 lines to /usr/X386/lib/X11/Xconfig,
as well as the documentation directory /usr/X386/lib/X11/etc. The names
are different because the XFree86 team uses those as the official names,
but some Linux distributors prefer to (for good reasons) put them into
different places. However, the official names should work as well, they
do in my version of Slackware.
> Configuring Xwindows again - there was NO list of the available mouse drivers.
The Xconfig man page contains one. "man Xconfig" works on my Slackware system,
but I don't know of other distributions. However, I didn't notice any
pointer to the man page, but on the other hand, I didn't look very hard
either.
> Configuring Xwindows again - I couldn't find any mention of the hot-key which
> flips between the video modes in the Xconfig list.
That is in the XFree86 man page, again, "man XFree86" works for me.
> I agree that people should RTFM, but there seems to be no index which says
> which FM to R, [...]
This would be a good thing to have. Even better, there should be perhaps
some fewer documents, so that one would not have to look in as many places.
> If anyone asked me what operating system they shoud use for their department,
> I would say that although linux seems pretty comprehensive and stable, they
> should use anything else, but NOT linux. The documentation is simply not
> sufficient for anyone other than a keen hobbyist or the very desparate.
I don't really disagree, although I find the docs better than you do.
But then, I'm more experienced.
--
Lars.Wi...@helsinki.fi (finger wirz...@klaava.helsinki.fi)
My name is Ozymandias, king of kings/Look on my works, ye Mighty, and despair!
Steven Greenland
Lars Wirzenius <wirz...@cc.Helsinki.FI> wrote:
>st...@rigel.demon.co.uk writes:
>> Mitsumi CDROM drive, for instance... The kernel said the drive was there,
>> but how the f*** do you mount it? The howto doesn't say. I couldn't find
>> anything that said.
>
>45 days) are (this comes straight from the kernel sources, since I didn't
>find a list):
>
> minix
> ext
> ext2
> xiafs
> msdos
> proc
> nfs
> iso9660
> xenix
> sysv
> coherent
> hpfs
And the man page for mount(8) lists many (but not all) of these.
It also specifically says to look in linux/fs/filesystems.c to see the
actual list of supported file systems. Is this the best way
to document available filesystems? No. Is the information there? Yes.
>> I agree that people should RTFM, but there seems to be no index which says
>> which FM to R, [...]
>
>This would be a good thing to have. Even better, there should be perhaps
Agreed. Doesn't the META-FAQ list the HOWTO's and describe what each
covers?
>some fewer documents, so that one would not have to look in as many places.
>
>> If anyone asked me what operating system they shoud
>> use for their department,
>> I would say that although linux seems pretty comprehensive and stable, they
>> should use anything else, but NOT linux. The documentation is simply not
>> sufficient for anyone other than a keen hobbyist or the very desparate.
>
>I don't really disagree, although I find the docs better than you do.
>But then, I'm more experienced.
Linux is Unix. Unix is complicated, and definitely requires more
experience/time to manage than MS-DOS. It also requires more experience/time
to use _well_ than MS-DOS, simply because it is a lot more _capable_
than MS-DOS.
BUT, there are many good intro_to_unix books out there, all quite
applicable to Linux. I don't think it's unreasonable for the Linux
developers/maintainers to expect people to go and read those books,
and devout their limited time to documenting tasks specific to
Linux.
Do some OS's come with more complete documentation? Yeah, but they
charge a _lot_ for it. Why should people contributing their free
time duplicate documents that are already out there?
The main problem with Linux is that many of the users are using it
as a single-user system, and therefore must learn how to manage
it as well as use it. I can't think of any serious operating system
that is any simpler to maintain than Unix/Linux, except possibly
MacOS (depends on whether or not you consider MacOS a "serious OS",
and I'm not interested in debating that). VMS? No way (That is, it
_is_ a real OS, but it is not any easier to manage). (BTDT!).
I've seen Unix systems that provide better _tools_ for managing,
such as AIX's SMIT, but all the tools do is help keep you from
screwing up, you still have to read/learn/experience to determine
_what_ to do with the tools.
Basically, you may not remember it, but you had to spend some
effort/time learning MS-DOS once. Unix is an order of magnitude
more complex. It's also (at least) an order of magnitude more useful,
once you learn it. Expect to put some time into learning it. In
the mean time, go out and buy some _unix_for_DOS_users_ book,
and read/experiment/learn.
(And go look in the LDP directory on sunsite. There's some good
stuff there, and it's getting better. Thanks, people.)
--
Steve Greenland | ste...@sugar.neosoft.com | '91 SHO Mocha/Mocha
Where to bad folks go when they die?
They don't go to heaven where the angels fly.
They go to the lake of fire and fry.
Won't see them again to the 4th of July!
- The Meat Puppets
Bill Reynolds
st...@rigel.demon.co.uk writes:
> UNIX IS DEAD - UNIX IS DEAD - UNIX IS DEAD
Long live Linux :-)
.
.
.
I couldn't find anything either, using only five minutes (I perhaps could
have, had I spent longer, but that just illustrates the point, doesn't
it?).
.
.
.
> I agree that people should RTFM, but there seems to be no index which says
> which FM to R, [...]
This would be a good thing to have. Even better, there should be perhaps
some fewer documents, so that one would not have to look in as many places.
I think this is a good point. I learned unix under SunOS, mostly by
reading the online docs. Once you get used to it, man(1) is pretty
durned good - on my system
$ man -k files
.
.
mount, umount (2) - mount and unmount filesystems.
.
.
unfortunately, the whatis database that man uses to give keywords is
rarely kept up to date on most systems (I try to rebuild it after
every install.man).
But this is a minor problem. The *big* problem in linux is that the
information is saved in so many different formats. Lets see, we've got
manpages, we've got info, we've got howto's, we've got FAQ's, we've
got the LDP books, we've got a zillion assorted README's in a zillion
assorted packages (XFree86 has a zillion all by itself). Some packages
chuck it all to the wind and give you some long-winded nroff/tex/info
docs (e.g. smail/dvips/dosemu). It seems to me that we need some sort
of unified documentation format (I'm not volunteering, I'm in the
middle of writing a term howto :-). Probably sgml is a good start, mdw
has put some nice tools together that can convert it to the other
formats. However, there is some history behind unix man, and it should
probably not be abandoned.
This of course opens a whole new can of worms - for example, if I'm a
new user, "man fstab" will be incomprehensible to me, I would probably
need a long-winded tutorial-like introduction. On the other hand, if I
want the flags to "ls(1)", or the format of "inittab(5)", then I don't
want to fire up info and go down twenty levels of menus - to flog a
dead horse: I like the perl info page better than the man page, but I
*hate* the libc info documentation, I'd much prefer to do a "man" for
the system calls I use.
So (donning the asbestos and hiding in the cellar) what's the best
documentation format? IMHO, we probably should keep man - perhaps with
the capability of converting it to sgml, and the LDP books are very
good too, especially for the newbie. Should an sgml smorgasbord of
docs be distributed with linux, kind of like the Sun Answerbooks? Note
that cross refs are good, but indices and keywords should also be
available. What do people think?
--
_____________________________________________________________________________
Bill Reynolds bi...@goshawk.lanl.gov |
Matt Welsh
>True. I'm figuring that someone with more experience will support the machine.
>If not then I'm squarely in your camp. Rank novices should not be doing
>adminsitration tasks. The point of contention is using the system, not
>administration.
One requires the other, as they say.
>>Unfortunately, UNIX applications often assume knowledge about the underlying
>>operating system. You can't hide the OS from the user very easily. With
>>other operating systems this isn't the case ("See, you click the mouse on
>>the little garbage can, and Oscar comes to take away your trash!").
>
>That's the interface, not the OS. X could be easily configured to do exactly
>that.
Of course; that's a simple example. But how many UNIX applications have you
run across that have interfaces that don't presume knowledge of at least
UNIX basics (e.g. filesystem structure)? The point I was trying to make is
that most UNIX programs do very small tasks, and expect to be used within
a pipeline. "cut" by itself isn't very useful, but when used in conjunction
with sed, tr, grep, and so forth is a very powerful tool. I've yet to see
a UNIX-based "file manager" make use of those tools well; it's just
impossible to construct pipelines by clicking on file icons.
>Again my contention is that the learning curve for the applications
>are about the same and as long as administration is left out the OS/
>file system learning curve also match,
With MS-DOS and Windows, you rarely need to use DOS-level commands (DEL,
COPY, etc.), while on UNIX, it's nearly expected that you do. MS-DOS
and Windows applications are pre-packaged entities that handle all aspects
of a certain task. Therefore if you know MS Word without knowing squat
about DOS, you can still write and print wonderful papers. UNIX doesn't
take that approach. You have to know how to use many different tools
in conjunction with each other---which often entails a fair amount of
knowledge about files, directory structure, pipes, and so on. The UNIX
learning curve is steeper because you have to learn more of the gritty
details to get things to work. Many MS-DOS users only know how to boot
up their machine and type "word" to get into the word processor.
>The only counter is that while there are a bunch of DOS/Windows
>books out there for rank novices, Unix seems to lag behind.
Two reasons for that. First, as above, UNIX is more complex than MS-DOS.
Most new UNIX users have had some degree of computer experience in the
past, so books for complete novices aren't really necessary.
Second reason: Until recently, UNIX wasn't a personal operating system.
And, Linux and 386BSD are the first implementations of UNIX that you
can obtain inexpensively. Using UNIX on a workstation or mainframe, where
you have gurus and manuals readily available, is quite different than
running your own UNIX system at home (especially without having prior
UNIX experience). Linux is the first instance of UNIX being used widely
for personal computing, in particular by UNIX novices. UNIX, and Linux,
just aren't ready for that audience, and may have never intended to be.
>The novice users used the menus and help heavily during the initial learning
>phase. They also learned much quicker than the control group which did not
>have the menus and help. However as these novice users progressed to
>intermediate users they used both the menus and the help less and less.
>By the time the novices reached expert status they used neither and typed
>commands directly on the keyboard.
While I believe you, I'd like to see a citation before accepting your
research results as face-value.
There is a good reason why this "novice help" system isn't popular on
UNIX systems---because until recently nearly all new UNIX users had some
understanding of computers and operating systems (such as MS-DOS). Now
you're asking to replace MS-DOS (a fairly simple OS to learn) with Linux
(a much more complex OS).
Interactive help has never been big on UNIX systems because there simply
isn't demand for it---except in the case of Linux. You can't expect the
FSF and the rest of the programmers writing applications which Linux
distributions tend to snarf to include these novice features. By and large
these UNIX applications will remain the same.
>>Look, it's a simple fact that UNIX wasn't designed for that kind of thing.
>
>Sure it was. It was designed with so much power and flexibility that
>you could cripple it. My late professor and mentor did exactly that
>but writing a shell for freshman CS majors at Tech. Limited commands,
>rewritten syntax, much help. Did the job.
I say throw new users in the deep end of the pool so they learn to swim
there, instead of letting them wade in a kiddie pool until they're ready to
do the real thing. Unlike swimming and skiing, however, it's not dangerous
to do so. Just beneficial in the long run, in my point of view. In most
cases giving novices an "easy way out" doesn't help them at all. It just
forces them to learn a crippled system which they'll eventually forget about
anyway. Why not introduce them to the real thing? When you learned to
drive, did they start you off in a bumper car? I certainly hope not!
>> UNIX applications aren't designed to be run in such an environment. They're
>>primarily text-based apps that do little bits of processing on a pipeline.
>
>Like I said this is a learned skill that novices would not attempt in the
>beginning anyway.
My point is that novices _should_ learn about some of these basic UNIX
utilities, because nearly all UNIX applications are based on them.
There are very few self-contained applications that don't require the
use of pipelines.
>>Exactly. But how do novice users become experts? By learning the ropes.
>>If you become an expert at riding a tricycle, it'll never help you to learn
>>to ride a Harley-Davidson. And there's no reason why novices can't start out
>>on the Harley---yes, the learning curve is steeper, but once they
>>overcome that, they can hit the highway.
>
>My point exactly (what violent disagreement!) I see the tricycle as DOS
>and the Harley as Linux. So teaching DOS won't really help. However I
>think teaching the Harley with a 10 MPH govenor initally will help the rider
>get confortable with the machine before moving onto the highway.
It's much easier for the user to not open up the throttle, than to limit
their power from the start.
mdw
--
Subvert the Dominant Paradigm. Use Linux.
Matt Welsh
>I, like many others, am a DOS fugitive, who installed linux with the
>intention of learning about unix. I may be no Einstein, but I don't
>scrape my knuckles on the ground when I walk. I have found serious
>problems trying to do the simplest things.
>
>The man pages are great if you know what command you want to use and
>what it does, but can't quite remember the syntax. They are useless if
>you are trying to figure out what a command does and what you might
>want it for (I have just posted a question about tar for this reason).
>Unix is not the only o/s guilty of this - I once read a VMS manual from
>cover to cover and found the same thing.
Okay, so you RTFM, but did you RTFB? Man pages, FAQs, and HOWTOs have never
been intended to be complete tutorials. You need comprehensive discussion
for that kind of thing---which is what books such as the I&GS provide.
mdw [the next version of the I&GS should be entitled "THE FUCKING BOOK"]
Matt Welsh
>But this is a minor problem. The *big* problem in linux is that the
>information is saved in so many different formats. Lets see, we've got
>manpages, we've got info, we've got howto's, we've got FAQ's, we've
>got the LDP books, we've got a zillion assorted README's in a zillion
>assorted packages (XFree86 has a zillion all by itself).
The format used depends on what you're trying to document, and how.
HOWTOs, READMEs, man pages, and FAQs are all plain ASCII.
There's no magic there. Info pages requiore the use of "info" to read
and search, and LaTeX documents (a la LDP books) require you to actually
read them. (I know, that's more than doc writers should ask for, but
we're old-fashioned.) In the future I hope that the LDP manuals will all
be available in Info format as well, so that reduces your scope to two
"formats".
What you're really complaining about is not the formats but the wide
range of the documentation out there. I suppose it would be nice to
organize all Linux-related docs into a single coherent Info tree, but
that's not feasible when you have umpteen million different volunteers
writing different docs.
>So (donning the asbestos and hiding in the cellar) what's the best
>documentation format? IMHO, we probably should keep man - perhaps with
>the capability of converting it to sgml, and the LDP books are very
>good too, especially for the newbie. Should an sgml smorgasbord of
>docs be distributed with linux, kind of like the Sun Answerbooks?
I think that's too much work. I'd like to see all HOWTOs done up in
SGML, which will give us Info at some point, and reference docs
remain as man pages. Then all you have is Info and man, which isn't
too much to worry about.
Matt Welsh
>I think there should be a CD-ROM edition of Linux bound up with the LDP
>books in one single thing you could sell at a bookstore for $ 65-75. I
>think a lot of people would buy that. I know I would, just to have a
>consistently functioning Linux along with the software in one neat package.
It's being done, too. Linux Systems Labs and number of other vendors
sell packages such as this, and SSC (publishers of LJ) are about to
release a "Linux Package" which has literally everything that you need
to start up your own Linux system: A Linux CD-ROM, printed LDP manuals
and HOWTOs, a subscription to LJ, and a case of virtual beer, if I
remember correctly. It's in SSC's current catalog, but I don't think
they're shipping it until I&GS v2.1 is finished up...
mdw
Bill Reynolds
In article <BILL.94M...@yossarian.pianosa.gov> bi...@goshawk.lanl.gov writes:
What you're really complaining about is not the formats but the wide
range of the documentation out there. I suppose it would be nice to
organize all Linux-related docs into a single coherent Info tree, but
that's not feasible when you have umpteen million different volunteers
writing different docs.
No, what I'm really complaining about is that both man and info both
fall short. man is great if you need a quick answer - command syntax,
and such. It's not so hot when the man page exceeds a few pages (try
finding the definition of ``set'' in the bash man page). info is good
if you need a coherent, in depth treatment of a utility, it sucks if
you need data quickly . Would you like to see my "info/dir"? I've got
something like 30 entries in there, I've given up on adding more. As
more stuff get's infoized, it becomes almost impossible to retrieve
anything quickly.
>So (donning the asbestos and hiding in the cellar) what's the best
>documentation format? IMHO, we probably should keep man - perhaps with
>the capability of converting it to sgml, and the LDP books are very
>good too, especially for the newbie. Should an sgml smorgasbord of
>docs be distributed with linux, kind of like the Sun Answerbooks?
I think that's too much work. I'd like to see all HOWTOs done up in
SGML, which will give us Info at some point, and reference docs
remain as man pages. Then all you have is Info and man, which isn't
too much to worry about.
Well, if you think it's too much work, it undoubtedly is :-). I'm just
wondering how bad it would be to use sgml as a common denominator. I
know people have converted the man pages to sgml. It seems you could
do the same to info, slap the HOWTOS and the LDP books in there (and
ship hardcopies of the books with your distribution), add some keyword
searches (using the indices in info and man's whatis database) and so
forth. Conceivably, you could have a bitching doc system. Is this so
crazy? Of course, somebody's got to bell the cat.
Stuart Herbert
: The format used depends on what you're trying to document, and how.
: HOWTOs, READMEs, man pages, and FAQs are all plain ASCII.
This is a good choice.
: There's no magic there. Info pages requiore the use of "info" to read
: and search, and LaTeX documents (a la LDP books) require you to actually
: read them. (I know, that's more than doc writers should ask for, but
: we're old-fashioned.) In the future I hope that the LDP manuals will all
: be available in Info format as well, so that reduces your scope to two
: "formats".
Hrm ... why use LaTeX? It strikes me as silly that the format for manuals
aimed at novices is something that a novice will not be familiar with.
In addition, Info is a nasty tool ... hardly conducive to browsing.
: What you're really complaining about is not the formats but the wide
: range of the documentation out there. I suppose it would be nice to
: organize all Linux-related docs into a single coherent Info tree, but
: that's not feasible when you have umpteen million different volunteers
: writing different docs.
What would be nice is a common front end to all the different document
formats, like Mosaic is a common front end to a lot of Internet resources.
: I think that's too much work. I'd like to see all HOWTOs done up in
: SGML, which will give us Info at some point, and reference docs
: remain as man pages. Then all you have is Info and man, which isn't
: too much to worry about.
Ditch Info, and have HTML and man as the two formats.
Lars Wirzenius
> Hrm ... why use LaTeX? It strikes me as silly that the format for manuals
> aimed at novices is something that a novice will not be familiar with.
Because the LDP is producing books. When we started, LaTeX was the
tool of choice for that. Now, there is some hope that some form of
SGML may be usable in the future. Until then, LaTeX is still the
tool of choice.
Yes, LaTeX isn't all that easy to handle for a novice. Neither are
Texinfo or troff, and neither is as good as LateX (IMHO). Plain text
is not even thinkable. HTML wasn't exactly a hot topic back then, and
isn't all that suitable for writing a book, anyway. Of HTML+ I do not know.
Proprietary word processor formats are right out.
I won't speak for the others, but producing on-line documentation is
not the primary topic for me. Producing a hard-copy book is. After
that is done, I will look into producing good on-line docs. (Those who
have been following my pace of writing will know that they shouldn't
hold their breaths.)
(This "LaTeX is bad for LDP docs" is as old as the LDP. It's more than
a bit tired as a discussion topic, too.)
David Holland
ac3...@sunc.sheffield.ac.uk's message of 8 May 1994 02:16:35 GMT said:
> Ditch Info, and have HTML and man as the two formats.
Agreed... except... why not ditch man too? I for one don't like to
keep around a big and slow program (groff) just to format man pages.
One could conceivably rig things up to have an interface very similar
to man, especially if you used Lynx as the viewer.
Anybody have a -man to HTML converter? Or a complete spec [BNF is
good] for -man and -mandoc so one can be written?
--
- David A. Holland | "The right to be heard does not automatically
dhol...@husc.harvard.edu | include the right to be taken seriously."
Timothy Murphy
>One could conceivably rig things up to have an interface very similar
>to man, especially if you used Lynx as the viewer.
Have you looked at xman?
--
Timothy Murphy
e-mail: t...@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Lars Wirzenius
> Agreed... except... why not ditch man too? I for one don't like to
> keep around a big and slow program (groff) just to format man pages.
No need for groff, man pages can be preformatted. If you don't want to
do that, try cawf, a miniscule program that does the same thing.
(I used to use it myself back when I used Xenix, and couldn't afford
the text processing package with nroff. I haven't touched it since,
however, so I'm not so sure how well it works these days.)
Getting rid of man pages means that all man pages (current and those
of software that will be ported and/or written later) needs to be
converted to some other format. Same applies to Info. A tremendous
task, but doable. However, I don't think it is worth it. It will make
it more difficult to port things to Linux. A better idea would be to
add on-line conversion to the WWW server, or something.
Byron A Jeff
Matt Welsh <m...@cs.cornell.edu> wrote:
>In article <1994May6.0...@cc.gatech.edu> by...@cc.gatech.edu (Byron A Jeff) writes:
>>True. I'm figuring that someone with more experience will support the machine.
>>If not then I'm squarely in your camp. Rank novices should not be doing
>>adminsitration tasks. The point of contention is using the system, not
>>administration.
>
>One requires the other, as they say.
Well as you point out later in this article, the advent of Unix freeware
for the PC has just really started this phenomena. There have been Unix
users for years that have not had to do one sysadmin task because the
size of the installation (mainframes and minis. Even most workstations)
dictated that there was a separate sysadm to handle administrative tasks.
So one didn't require the other until now. We agree that rank novices
shouldn't be doing the job. You say for them to stay away while I'm of
the belief that if they don't have someone to help them then they should
pay for someone to sysadm their machine.
>
>>>Unfortunately, UNIX applications often assume knowledge about the underlying
>>>operating system. You can't hide the OS from the user very easily. With
>>>other operating systems this isn't the case ("See, you click the mouse on
>>>the little garbage can, and Oscar comes to take away your trash!").
>>
>>That's the interface, not the OS. X could be easily configured to do exactly
>>that.
>
>Of course; that's a simple example. But how many UNIX applications have you
>run across that have interfaces that don't presume knowledge of at least
>UNIX basics (e.g. filesystem structure)? The point I was trying to make is
>that most UNIX programs do very small tasks, and expect to be used within
>a pipeline. "cut" by itself isn't very useful, but when used in conjunction
>with sed, tr, grep, and so forth is a very powerful tool. I've yet to see
>a UNIX-based "file manager" make use of those tools well; it's just
>impossible to construct pipelines by clicking on file icons.
This is how Unix experts use the system. Novices won't. Tell me how much
of the file system do you really need to know to read mail or news? Or
to edit a simple file? or to print said file? or to run the spreadsheet?
These are the kinds of tasks that novices will perform initially. All
of the the sed,awk,grep,wc,cut kinds of tools that we can't live without
novice users haven't a need for.
I wouldn't use a file manager. Neither would you. However novices will
find them extremely useful because it helps them perform the tasks they
want to do, not the tasks we want to do. For that audience they are
good tools for the job.
>
>>Again my contention is that the learning curve for the applications
>>are about the same and as long as administration is left out the OS/
>>file system learning curve also match,
>
>With MS-DOS and Windows, you rarely need to use DOS-level commands (DEL,
>COPY, etc.), while on UNIX, it's nearly expected that you do. MS-DOS
>and Windows applications are pre-packaged entities that handle all aspects
>of a certain task. Therefore if you know MS Word without knowing squat
>about DOS, you can still write and print wonderful papers. UNIX doesn't
>take that approach. You have to know how to use many different tools
>in conjunction with each other---which often entails a fair amount of
>knowledge about files, directory structure, pipes, and so on. The UNIX
>learning curve is steeper because you have to learn more of the gritty
>details to get things to work. Many MS-DOS users only know how to boot
>up their machine and type "word" to get into the word processor.
This is debatable. Take a simple example: LaTeXing a file. Notwithstanding
the problem of teaching LaTeX to a novice, let's examine the process:
1) Edit a file: junk.tex
2) Latex the file: latex junk.tex
3) Convert the dvi file to ps: dvips -o junk.ps junk.dvi
4) Create a printer specific file: gs ... junk.ps
5) Print the file out: lpr junk.print
Now let's see. The user needs to understand files. The user also needs to
understand that the tools translate file from one format to another to
produce something that can be sent to the printer. Directory structure: nope
everything is done in the current directory. Pipe: might cut down on some
intermediate files, but is not a necessity. While I agree that things are done
a bit differently than WordPerfect or Word, The process is not all that
difficult. The biggest problem is while there are 500 books for novices on
how to write a document in WP or word, I'd bet money there isn't one single
document anywhere that describes the process I just outlined above in it's
entirety in a single place. I know the LaTeX book doesn't describe the
whole thing. It can't. And while the above process is not Linux specific
a Linux HOWTO describing this would do a world of good.
And of course XTeXShell cuts out most of the process. But that's a different
story.
>
>>The only counter is that while there are a bunch of DOS/Windows
>>books out there for rank novices, Unix seems to lag behind.
>
>Two reasons for that. First, as above, UNIX is more complex than MS-DOS.
>Most new UNIX users have had some degree of computer experience in the
>past, so books for complete novices aren't really necessary.
>
>Second reason: Until recently, UNIX wasn't a personal operating system.
>And, Linux and 386BSD are the first implementations of UNIX that you
>can obtain inexpensively. Using UNIX on a workstation or mainframe, where
>you have gurus and manuals readily available, is quite different than
>running your own UNIX system at home (especially without having prior
>UNIX experience). Linux is the first instance of UNIX being used widely
>for personal computing, in particular by UNIX novices. UNIX, and Linux,
>just aren't ready for that audience, and may have never intended to be.
OK. This is a very powerful argument. However I think we can agree that
in it's typical groundbreaking way Linux (and the others) will start to
drag quite a few rank novices into the "personal Unix" (I like that term!)
arena. All I'm saying is that we need to be aware of this and instead
of throwing our collective hands in the air, that we need to address
these new folks with a combination of personal contact, documentation,
and on-line support.
>
>>The novice users used the menus and help heavily during the initial learning
>>phase. They also learned much quicker than the control group which did not
>>have the menus and help. However as these novice users progressed to
>>intermediate users they used both the menus and the help less and less.
>>By the time the novices reached expert status they used neither and typed
>>commands directly on the keyboard.
>
>While I believe you, I'd like to see a citation before accepting your
>research results as face-value.
Will check on it sometime this week. One of our folks got a PhD out of it.
>
>There is a good reason why this "novice help" system isn't popular on
>UNIX systems---because until recently nearly all new UNIX users had some
>understanding of computers and operating systems (such as MS-DOS).
>Now you're asking to replace MS-DOS (a fairly simple OS to learn) with Linux
>(a much more complex OS).
Matt, you've missed the point: For novices all operating systems are hard!
All we need to do is introduce enough of the OS for folks to start to
become productive. I'll use one of your own examples against you: in chapter
3 of the I&GS you describe how to use vi (The earth's most horrible editor ;-)
Now you haven't described everything (in fact I've been using vi for 10 years
and I still don't know everything) but you did document enough for a Unix
novice to edit a file. Not elegantly, mind you, but enough to get the job
done. The "novice menu-help" is precisely that, enough to get you in the
game so you can get some things done.
Another point the documentation can teach: most systems have the same
basic principals, all you need to do is ID them. Editors is one of my
favorite examples. For any editor and WP I only need to know 5 commands:
- How to get in.
- How to get out.
- How to insert text.
- How to delete text.
- How to move the cursor.
That's it. Everything else is gravy in terms of the fact that it doesn't
add any essential functionality, just a more elegant way to the 5 basic
things outlined above. This works for vi, emacs, joe, WP, EZ, DOC, WORD,
or any other document editor you care to name.
Same with file systems and directories (are there any really exotic ones
in the mainstream?). Just show the basic functions. Everything else will
follow.
>
>Interactive help has never been big on UNIX systems because there simply
>isn't demand for it---except in the case of Linux. You can't expect the
>FSF and the rest of the programmers writing applications which Linux
>distributions tend to snarf to include these novice features. By and large
>these UNIX applications will remain the same.
Nope I don't expect them to change. In fact those features would be
inappropriately placed in commands. This tool should either live on top of an
existing shell or possibly be a replacement shell (nsh?). It must have 3 very
important features:
- It should always show the user what's really happening. This is important
because before very long the user will start to enter commands without
using the help.
- It should allow the user to type to the actual command line at any time.
- It must not change the name of any command no matter how cryptic it is.
This was my professor's shell's fatal flaw. He changed the names of the
commands to a more readable format. Since the students failed to associate
the command names in the freshman shell with the real Unix commands they
didn't do very well when they were transistioned to a normal shell.
>
>>>Look, it's a simple fact that UNIX wasn't designed for that kind of thing.
>>
>>Sure it was. It was designed with so much power and flexibility that
>>you could cripple it. My late professor and mentor did exactly that
>>but writing a shell for freshman CS majors at Tech. Limited commands,
>>rewritten syntax, much help. Did the job.
>
>I say throw new users in the deep end of the pool so they learn to swim
>there, instead of letting them wade in a kiddie pool until they're ready to
>do the real thing.
>Unlike swimming and skiing, however, it's not dangerous to do so.
>Just beneficial in the long run, in my point of view.
I disagree. New users are easily frustrated getting over that first hump
and we're in a game where the first impression is critical. The danger is
that you throw them in the deep end without sufficient tools to swim. Then
when they get to the edge they'll go to the kiddie pool (DOS/WINDOWS)
and they'll never come back, missing all of the powerful goodies you get
later on if they'd just stuck it out.
My suggestion is more of a floatation device in the deep end as opposed to
moving to another spot. It allows them to get comfortable without having
to sacrifice one bit of power or compromising one ounce of power.
>In most
>cases giving novices an "easy way out" doesn't help them at all. It just
>forces them to learn a crippled system which they'll eventually forget about
>anyway. Why not introduce them to the real thing? When you learned to
>drive, did they start you off in a bumper car? I certainly hope not!
Well you were the one saying that people should practice with DOS/WINDOWS
before moving up to Linux! My counter to your metaphor is that do you
teach teenages to drive in rush hour bumper to bumper traffic? I think
not. You do use a real car (linux) but you start in a parking lot or
quite street (novice help tool). Usually you have a helpful knowledgeable
driver right there pointing out how to do things (sysadm). Soon you ditch
the quite street and move on other venues.
>
>>> UNIX applications aren't designed to be run in such an environment. They're
>>>primarily text-based apps that do little bits of processing on a pipeline.
>>
>>Like I said this is a learned skill that novices would not attempt in the
>>beginning anyway.
>
>My point is that novices _should_ learn about some of these basic UNIX
>utilities, because nearly all UNIX applications are based on them.
Of course they should learn about them. However those tools are not in
the center of a novices activity list. Take my students for example who
are now doing their work on Linux boxes. Their tool set consist of the
following:
- editing (joe)
- compiling (gcc)
- executing programs they've written
- debugging. I've shown them the basics of gdb.
- mail (elm)
- printing (lpr)
None of these are the strung together via pipe, text based filter apps
that you're referring to. Should they learn them: yes. Are they useful: yes.
Are they essential for their tool set: No. I've satisfied to let them
get comfortable with what they need to know and then show them pipelines
and filters a bit later on. I'm betting most novices will be like that.
>There are very few self-contained applications that don't require the
>use of pipelines.
I think I just named 6 or 7. The question is not few self-contained
applications there are but the percentage of those applications that
novice users use. Much higher than the rest of us.
>
>>>Exactly. But how do novice users become experts? By learning the ropes.
>>>If you become an expert at riding a tricycle, it'll never help you to learn
>>>to ride a Harley-Davidson. And there's no reason why novices can't start out
>>>on the Harley---yes, the learning curve is steeper, but once they
>>>overcome that, they can hit the highway.
>>
>>My point exactly (what violent disagreement!) I see the tricycle as DOS
>>and the Harley as Linux. So teaching DOS won't really help. However I
>>think teaching the Harley with a 10 MPH govenor initally will help the rider
>>get confortable with the machine before moving onto the highway.
>
>It's much easier for the user to not open up the throttle, than to limit
>their power from the start.
Actually I don't have the correct metaphor here. try this: a novice on a
bike that can go 150 MPH and no training is a dangerous thing. Problem is
that the novice probably can't even get the bike started. Everybody
needs help when they start something new. This is no exception. All I'm
saying is that I'd rather limit the exposure to Linux initially rather than
brushing novices off and sending them to DOS/WINDOWS.
BAJ
Matt Welsh
>Matt Welsh <m...@cs.cornell.edu> wrote:
>>Oh, vi is fun. You just have to learn to appreciate self-mutilation.
>>It's something like getting a tattoo---it's painful at first, but the
>>experience stays with you for life.
>
>I know this is tounge (sp) in cheek. vi is the mose horrible excuse for
>an editor ever written. The fact that it's the only thing I use notwithstanding
>;-)
vi dates way back, long before terminal emulation is as common and
reliable as it is now. I still use it exclusively because I'm a single-finger
typist. (I suppose that amputees can use vi for the same reason.) And
don't even mention ergonomics...
>>Books, books, books. The I&GS includes a UNIX tutorial for beginners.
>>Of course this assumes knowledge of MS-DOS or _some_ operating system.
>>I don't think that new computer users should be using Linux. That's
>>my personal philosophy: That before running Linux, a computer user
>>should go through at least two years of the same torture that I did,
>>before moving to Linux: MS-DOS.
>
>Matt this is where we disagree (sort of). I'm not talking about running Linux
>I'm talking about using it to get work done.
But _someone_ has to run the system.
>We all know that an editor is
>an editor is an editor. My take on this is not to expose new users to an OS
>that they won't use for the long haul.
Unfortunately, UNIX applications often assume knowledge about the underlying
operating system. You can't hide the OS from the user very easily. With
other operating systems this isn't the case ("See, you click the mouse on
the little garbage can, and Oscar comes to take away your trash!").
>Human nature is to stick with what
>you know and what you learn first.
Hence my adamant use of vi, but that's another story.
>If I expose my parents to DOS/WINDOWS
>once they learn how to use it, they won't feel a need to switch. That's
>why Linux is on their machine.
Why would they ever need to use Linux? DOS and Windows is certainly
sufficient for most people. My idea is that you don't need to give
people much more than they need (immediately, at least). A normal
working-class family doesn't need to drive a Mac truck to work.
I know that there are people out there who have aspirations of seeing
UNIX and Linux become the popular, common operating system for personal
computing. I don't think that UNIX was designed with this in mind,
and Linux is certainly no exception. Most personal operating systems
attempt to hide the OS and machine from the user, abstracting those
concepts heavily. UNIX makes no attempt at this. And, I don't believe
that it should.
>What I'm pointing out is that most of the documentation is for DOS refugees
>and current Unix users.
Which is, I think, the primary audience that Linux has been developed
to receive. There's just no software support for complete newcomers.
No matter how good the documentation is, Linux just doesn't boast
applications which are easy enough for people with no experience.
>What I've failed to see (and I admit I've only given
>a cursory look) is documentation for rank novices. I plan to take a look
>at my favorite computer bookstore for something but I'd gladly accept
>suggestions.
I've suggested "UNIX for Dummies" to a few people, and they seemed to
enjoy it. In fact, a friend of mine---a near computer novice---picked
up the book and by the end of the week was writing shell scripts.
But none of those books describe how to set up and maintain your own
system. And I don't think that's a task that you can reasonably expect
newcomers to do. As I mentioned above there simply isn't software support
for that kind of thing. Perhaps in the future there will be but it's
not strictly a documentation issue.
>Actually while I've been sitting here writing this message I've thought of
>a throwback to the old SLS days: menus. With the really cool dialog command
>it would be a piece of cake to throw together a simple menu to do the
>simple tasks that rank novices need: editing, printing, communications, etc.
Please, I just ate.
Look, it's a simple fact that UNIX wasn't designed for that kind of thing.
You can write as much abstraction as you want but it diminishes the power
of the system considerably. Example: I was playing with X File Manager
one day (just to see what it was like, I swear). It allowed you to select
files, as icons, and open up editor windows and so on. GREAT from the
FSAG is probably similar. But with such an interface it's impossible to
do things such as contruct command pipelines. UNIX applications aren't
designed to be run in such an environment. They're primarily text-based
apps that do little bits of processing on a pipeline. If you look at
Macintosh applications, things are quite different---applications
communicate not by pipelines but by the clipboard---something like the
X selection, only more generalized. The applications are written with
a particular interface and interapplication communication scheme in mind.
Applications are generally larger and more self-contained, because
they can't work together as easily with that interface. This is not
to say that they are less powerful, but they take a completely different
approach to doing the same thing.
You can't turn a UNIX system into a Macintosh, no matter how hard you
try. I've played with a number of systems, both free and commercial,
that attempt to do this, and they fail miserably.
>I guess I'm a bit biased because one of my Human Factors Professors was
>doing usability research in progressive systems and found that menus and
>help do a great deal for novice users but generally hinder experts.
Exactly. But how do novice users become experts? By learning the ropes.
If you become an expert at riding a tricycle, it'll never help you to learn
to ride a Harley-Davidson. And there's no reason why novices can't start out
on the Harley---yes, the learning curve is steeper, but once they
overcome that, they can hit the highway.
>I figure in the next year I'll introduce 20-30 folks to Linux. Most will
>not be experts. Most however will have some computer usage experience.
>My first book for them is always Matt's guide. However I don't have anything
>yet that'll fill the need of the rank novice.
"UNIX for Dummies" is a good place to start, or perhaps O'Reilly's
"Learning the UNIX Operating System".
>And remember we're not talking
>about sysadmin tasks, just regular old usage. Something with an explanation of
>the file organization, logging in and out, using an editor, printing, etc.
>Written from the novice perspective (i.e. assume nothing).
The I&GS tutorial covers just about all of those really basic things.
And I'm not even going to comment on the "Mouse-as-a-footpedal" story.
mdw
Stuart Herbert
: Why would they ever need to use Linux? DOS and Windows is certainly
: I know that there are people out there who have aspirations of seeing
: UNIX and Linux become the popular, common operating system for personal
: computing. I don't think that UNIX was designed with this in mind,
: and Linux is certainly no exception. Most personal operating systems
: attempt to hide the OS and machine from the user, abstracting those
: concepts heavily. UNIX makes no attempt at this. And, I don't believe
: that it should.
This is off-topic, but there is one area in which UNIX is very suited to
mass-market use, where DOS and Windows will never be able to compete without
making consessions.
I develop multi-user software. Serverless, completely distributed, and
real-time.
There is only one way to do that under DOS/NetWare, and that method is not
secure. The DOS/NetWare combination, despite being very flexible, just
isn't up to the task, and it never will be.
You *could* introduce a server, but that would mean writing a module for
NetWare. Now, this means that you also have to write all of the code to
transmit information, files, or whatever, between the server and the client.
You end up re-inventing the wheel. You also start to hammer your server.
Under UNIX, I don't need to write that server. Which means that I save
a lot of effort and grief, and performance is better.
Groupware is expected to grow and grow and grow, as application builders
start to realise what you can do with it. In my experience, UNIX is the
only platform where you can do it.
I fail to see any substance to your arguement that you can't make a
user-friendly interface to UNIX. So others have tried and failed.
That does not mean that the prize is beyond reach.
Byron A Jeff
In article <1994May5.1...@cs.cornell.edu>,
Matt Welsh <m...@cs.cornell.edu> wrote:
>In article <1994May5.1...@cc.gatech.edu> by...@cc.gatech.edu (Byron A Jeff) writes:
>>Matt Welsh <m...@cs.cornell.edu> wrote:
>>>[Leaving vi out.]
>>>Books, books, books. The I&GS includes a UNIX tutorial for beginners.
>>>Of course this assumes knowledge of MS-DOS or _some_ operating system.
>>>I don't think that new computer users should be using Linux. That's
>>>my personal philosophy: That before running Linux, a computer user
>>>should go through at least two years of the same torture that I did,
>>>before moving to Linux: MS-DOS.
>>
>>Matt this is where we disagree (sort of). I'm not talking about running Linux
>>I'm talking about using it to get work done.
>
>But _someone_ has to run the system.
True. I'm figuring that someone with more experience will support the machine.
If not then I'm squarely in your camp. Rank novices should not be doing
adminsitration tasks. The point of contention is using the system, not
administration.
>
>>We all know that an editor is
>>an editor is an editor. My take on this is not to expose new users to an OS
>>that they won't use for the long haul.
>
>Unfortunately, UNIX applications often assume knowledge about the underlying
>operating system. You can't hide the OS from the user very easily. With
>other operating systems this isn't the case ("See, you click the mouse on
>the little garbage can, and Oscar comes to take away your trash!").
That's the interface, not the OS. X could be easily configured to do exactly
that. In fact the X file managers do exactly that. So do the commander type
tools that are DOSSHELL equivalents. They are tools that give you a pretty
interface to the underlaying file system and OS. And for novice users they're
useful.
>
>>Human nature is to stick with what
>>you know and what you learn first.
>
>Hence my adamant use of vi, but that's another story.
Exactly. I too am a stauch vi user for the same reason: at the time there
was nothing else available to use. But I wouldn't subject it on anyone else.
>
>>If I expose my parents to DOS/WINDOWS
>>once they learn how to use it, they won't feel a need to switch. That's
>>why Linux is on their machine.
>
>Why would they ever need to use Linux? DOS and Windows is certainly
>sufficient for most people. My idea is that you don't need to give
I disagree. DOS/Windows unnaturally confine the activites of folks because
of the inherent limitations of the (pseudo?) OS. While rank novices will
not utilize all of the features that Linux gives them initally, they will
in time exceed the limitations of DOS/Windows. It's my contention that for
using the computer systems (not administration, that's a different issue)
that the learning curve for the applications is approximately the same.
Given that you expose new users to the system that later on will give them
the most flexibility.
>people much more than they need (immediately, at least). A normal
>working-class family doesn't need to drive a Mac truck to work.
But multitasking, multiuser OS's really do fill out the natural flow
of how people work. We've just become used to the was DOS forced us
to do things because there really was no other way to do it. That's
why Apple had to add the Multifinder and Micro$oft added Windows: both
give the illusion of being able to run multiple tasks simulteanously.
Again my contention is that the learning curve for the applications
are about the same and as long as administration is left out the OS/
file system learning curve also match, so why not just start out with
the best. The only counter is that while there are a bunch of DOS/Windows
books out there for rank novices, Unix seems to lag behind.
>
>I know that there are people out there who have aspirations of seeing
>UNIX and Linux become the popular, common operating system for personal
>computing. I don't think that UNIX was designed with this in mind,
>and Linux is certainly no exception. Most personal operating systems
>attempt to hide the OS and machine from the user, abstracting those
>concepts heavily. UNIX makes no attempt at this. And, I don't believe
>that it should.
Like I said in my last post, I was involved in a research project where
novice and expert users were tested on a computer system (In fact it was Unix)
that was instrumented with a menu command system and context sensitive help.
The system was also set up so that you could use the menu to select your
task or type it in directly.
The novice users used the menus and help heavily during the initial learning
phase. They also learned much quicker than the control group which did not
have the menus and help. However as these novice users progressed to
intermediate users they used both the menus and the help less and less.
By the time the novices reached expert status they used neither and typed
commands directly on the keyboard. The expert users of course scoffed at
the whole menu idea from the jump. But the point being is that with a little
extra help novice users learned quickly and then didn't need the help as
they progressed. I figure the same is true here: give novice users extra
help in the beginning and they'll quickly become experts without having
to chain them to a limited environment.
>
>>What I'm pointing out is that most of the documentation is for DOS refugees
>>and current Unix users.
>
>Which is, I think, the primary audience that Linux has been developed
>to receive. There's just no software support for complete newcomers.
>No matter how good the documentation is, Linux just doesn't boast
>applications which are easy enough for people with no experience.
Again I disagree. I teach classes where students are often introduced
to computers for the first time. Typically for the applications they
need (editing, compiling, printing) I can show them the Linux applications
and they can pick it up rather easily. Joe is my favorite example. I can
throw it at my classed without explanation and even the most rank novice
can pick it up pretty quickly. Why: because it's intuitive (unlike vi)
and it has built-in help that can be displayed even while you editing.
I personally picked up the sc spreadsheet in about an hour. Why: because
it had an extensive man page and builtin help. These are Linux applications
and they are up to snuff. And I'll be damned to see that joe has a manual
page! I'm going to print it out right now. An obvious example of the
power of Linux that I'm of course preaching to the choir.
>
>>What I've failed to see (and I admit I've only given
>>a cursory look) is documentation for rank novices. I plan to take a look
>>at my favorite computer bookstore for something but I'd gladly accept
>>suggestions.
>
>I've suggested "UNIX for Dummies" to a few people, and they seemed to
>enjoy it. In fact, a friend of mine---a near computer novice---picked
>up the book and by the end of the week was writing shell scripts.
Will take a look for it tomorrow. Didn't get to it today.
>
>But none of those books describe how to set up and maintain your own
>system.
Correct.
>And I don't think that's a task that you can reasonably expect
>newcomers to do.
Agreed.
>As I mentioned above there simply isn't software support
>for that kind of thing.
Agreed again. I think we also agree that the software support is needed.
>Perhaps in the future there will be but it's
>not strictly a documentation issue.
No it's not. This is definitely a software tool kinda thing. Linux will
have to settle down quite a bit before it'll be usuable. until then
either you trust the distribution maintainer to do it right or get
someone experienced enough in system administration to either do that job
for you or show you how to do it.
Once things settle down and the tool can be written then of course there
will be a need for documentation. But in any and all cases it's beyond the
scope of the rank novice. I figure that how a bunch of us will make bank
on consultant's fees showing folks how to use their Linux boxes.
>
>>Actually while I've been sitting here writing this message I've thought of
>>a throwback to the old SLS days: menus. With the really cool dialog command
>>it would be a piece of cake to throw together a simple menu to do the
>>simple tasks that rank novices need: editing, printing, communications, etc.
>
>Please, I just ate.
Sorry. But I must remind you that you're not the audience for this tool.
>
>Look, it's a simple fact that UNIX wasn't designed for that kind of thing.
Sure it was. It was designed with so much power and flexibility that
you could cripple it. My late professor and mentor did exactly that
but writing a shell for freshman CS majors at Tech. Limited commands,
rewritten syntax, much help. Did the job. I always argued with him that
the shell should have the Unix commands so folks could learn them but
he could not be dissuaded. The point being that Unix is well designed
enough that it can function in a limited capacity. But this doesn't permanently
remove all functionality, it's just temporary.
>You can write as much abstraction as you want but it diminishes the power
>of the system considerably.
Agreed. However for rank novices this is not a problem. It's the difference
in having a bike with training wheels and a tricycle. The first you're
deliberately but temporarilty limitied the complexity (and the functionality)
in order to teach how the tools are used. With the second however while
easy to used once you've learned it you're limited to what you have. With
Linux and a front end a novice user can get comfortable and later on either
add functionality to the menu system or even better discard it entirely.
With DOS when you've learned everything you're still stuck with a crippled
system underneath. [ side note: I wrote this before reading below. Interesting
that we both picked bike examples.]
>Example: I was playing with X File Manager
>one day (just to see what it was like, I swear). It allowed you to select
>files, as icons, and open up editor windows and so on. GREAT from the
>FSAG is probably similar. But with such an interface it's impossible to
>do things such as contruct command pipelines.
I know that. However as you yourself pointed out in an earlier post that
those types of skills come with experience. The problem is getting a
rank novice to the point where they can understand what a pipeline means
and how it works. A bit of help in the beginning will pay off handsomely
in the end.
> UNIX applications aren't designed to be run in such an environment. They're
>primarily text-based apps that do little bits of processing on a pipeline.
Like I said this is a learned skill that novices would not attempt in the
beginning anyway. Novices start with single simple tasks: editing, reading
mail, printing. They run single applications at a time. After getting
comfortable with they then they move on not only to other apps but how
to get the applications they know to interact. At this point pipelines
come into the game. But not initially.
>If you look at
>Macintosh applications, things are quite different---applications
>communicate not by pipelines but by the clipboard---something like the
>X selection, only more generalized. The applications are written with
>a particular interface and interapplication communication scheme in mind.
>Applications are generally larger and more self-contained, because
>they can't work together as easily with that interface. This is not
>to say that they are less powerful, but they take a completely different
>approach to doing the same thing.
But the way I see it the types of Unix applications novice users use fall
into the model (larger, self-contained) more so than the types of tools
that expert users use. Novice users will use things like editors, spreadsheets
elm for E-mail, kermit for communications, and the like. These are very
different than the tr,wc,sed,awk types of applications that we string together
all the time. The latter set is outside the scope of applications that
novice users will attempt to use. They come later.
>
>You can't turn a UNIX system into a Macintosh, no matter how hard you
>try. I've played with a number of systems, both free and commercial,
>that attempt to do this, and they fail miserably.
I think that's the wrong approach (Unix -> Mac). I was thinking nothing
so grandiose. Just a small highly descriptive text system that will allow
you to choose among a small set of commands and explain what the system
is actually doing. It's a simple get the feet wet tool.
>
>>I guess I'm a bit biased because one of my Human Factors Professors was
>>doing usability research in progressive systems and found that menus and
>>help do a great deal for novice users but generally hinder experts.
>
>Exactly. But how do novice users become experts? By learning the ropes.
>If you become an expert at riding a tricycle, it'll never help you to learn
>to ride a Harley-Davidson. And there's no reason why novices can't start out
>on the Harley---yes, the learning curve is steeper, but once they
>overcome that, they can hit the highway.
My point exactly (what violent disagreement!) I see the tricycle as DOS
and the Harley as Linux. So teaching DOS won't really help. However I
think teaching the Harley with a 10 MPH govenor initally will help the rider
get confortable with the machine before moving onto the highway. That's
what this tool I'm talking about is.
And I still contend that for the initial set of applications that the Linux
learning curve is no steeper than the DOS one.
>
>>I figure in the next year I'll introduce 20-30 folks to Linux. Most will
>>not be experts. Most however will have some computer usage experience.
>>My first book for them is always Matt's guide. However I don't have anything
>>yet that'll fill the need of the rank novice.
>
>"UNIX for Dummies" is a good place to start, or perhaps O'Reilly's
>"Learning the UNIX Operating System".
>
>>And remember we're not talking
>>about sysadmin tasks, just regular old usage. Something with an explanation of
>>the file organization, logging in and out, using an editor, printing, etc.
>>Written from the novice perspective (i.e. assume nothing).
>
>The I&GS tutorial covers just about all of those really basic things.
I have a copy in my office. However I think I'll print a copy here at home
(just got a new HP deskjet 520! YEAH!) and give it a good read.
BAJ
David H Dennis
But when was the last time you read a manual straight through? The reality
is that nobody likes reading manuals; they'd rather tinker and mess themselves
up. The real shame of this is that once they mess themselves up, the on-line
manuals on disk may be lost along with the rest of their system until the
problem is solved. :-(
I think there should be a CD-ROM edition of Linux bound up with the LDP
books in one single thing you could sell at a bookstore for $ 65-75. I
think a lot of people would buy that. I know I would, just to have a
consistently functioning Linux along with the software in one neat package.
D
Craig I. Hagan
> - editing (joe)
> - compiling (gcc)
> - executing programs they've written
> - debugging. I've shown them the basics of gdb.
> - mail (elm)
> - printing (lpr)
I question the choice of the editor, as i feel that emacs is the
most common editor ACROSS ALL systems. you can see if from
the mac to OS/2 to windows to dos, and nearly any unix system
will have it.
I would be interested in co-authoring such a book, especially
if we could leave it in such a manner that it isn't constrained
to linux, but, will cover the basics across all
platforms (I think that it is reasonable to expect
a certain level of tools on the systems, and a disclaimer
can be presented).
I like the idea of this, and i think that your concept
of a "how to get in, how to move around, how to save, how to quit"
concept plus the "how do i go from point a to point d"
is a good idea.
anyone else interested in this? i haven't seen much traffic on the doc
project channel (sorry, i am still digesting the users' guide, great
job folx).
-- craig
Dan Newcombe
>I think this is a good point. I learned unix under SunOS, mostly by
>reading the online docs. Once you get used to it, man(1) is pretty
>durned good - on my system
I remember when I first got introduced to Unix, I thought it was so cool that
the manual pages were on line :)
But as someone posted a bit ago, the man pages are horrible in one aspect.
They don't tell you what the program does. Usually, there is only a line or
two at the very beginning of the page that says what the program does, and the
rest of the page is spent on telling what each argument does.
-Dan
--
Dan Newcombe newc...@aa.csc.peachnet.edu
Clayton State College Morrow, Georgia
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"And the man in the mirror has sad eyes." -Marillion
Stuart Herbert
: ac3...@sunc.sheffield.ac.uk's message of 8 May 1994 02:16:35 GMT said:
: > Ditch Info, and have HTML and man as the two formats.
: Agreed... except... why not ditch man too? I for one don't like to
: keep around a big and slow program (groff) just to format man pages.
: One could conceivably rig things up to have an interface very similar
: to man, especially if you used Lynx as the viewer.
Not played with Lynx yet. I like the approach taken with the Slackware
distribution, where all the man pages come pre-formatted. The advantage of
man is that it's a cross-platform standard, whereas hardly anyone outside the
FSF use info, from what I've seen.
Brendan Murray
> st...@rigel.demon.co.uk writes:
> > If anyone asked me what operating system they shoud use for their department,
> > I would say that although linux seems pretty comprehensive and stable, they
> > should use anything else, but NOT linux. The documentation is simply not
> > sufficient for anyone other than a keen hobbyist or the very desparate.
The problem your departments have would probably be similar, no matter
what version of Unix they should choose. Linux is close enough, in
enough ways, that I don't have any more trouble finding my way 'round in
it than I do in HP-UX, AUX, AIX, Ultrix, OSF/1 .... but then, as Lars
pointed out
> But then, I'm more experienced.
and ( no offense ) if anyone is asking you what OS to use you aren't
qualified to recommend-or-not.
And I've been through all the same hassle with RSX and VMS and DOS and
Windows and ...... so perhaps we'd better not recommend anything to
anybody. That way our butts will be covered.
Others have pointed out the great variety of manual formats ( info,
latex, text ... ). So whats new? Sure, for Linux to be the great OS of
the future it should have really great integrated manuals that all come
in any and all formats that everyone likes, including a little pill
that you can swallow and avoid all the work. It ain't gonna happen. The
GNU people have their preferred format, man pages are pretty standard
across all Unix implementations, some people really like DEC's
bookreader, others like IBMs document reading system, some like info,
some people just can't read from a screen but they want free docs and
they can't quite master latex and postscript and text ain't good enough.
If you want good integrated docs for every application from every
source why not write an RFC and wait thirty years for everyone to
conform. In the meantime read whats there 10 or 12 times, all the way
through, figure out the real solution, and then write your own set of
nonconforming docs that are better than everyone elses and we can have
this argument again later.
David Holland
wirz...@cc.Helsinki.FI's message of 8 May 1994 21:24:12 +0300 said:
> No need for groff, man pages can be preformatted.
True. But then you lose some of the flexibility associated with
formatting them on the fly. (Not that they format for non-80 column
windows anyway...)
You still need to keep groff, or something like it, around to format
man pages when you install things, anyway. (Though there probably
isn't any way around this one in the near future.)
> Getting rid of man pages means that all man pages (current and those
> of software that will be ported and/or written later) needs to be
> converted to some other format. Same applies to Info. A tremendous
> task, but doable. However, I don't think it is worth it. It will make
> it more difficult to port things to Linux. A better idea would be to
> add on-line conversion to the WWW server, or something.
Maybe the core man pages could be converted (sections 2, 3, 4, 9, much
of 5, parts of 1 and 8) and maintained as a standard package, with
hooks set up to convert nroff documents.
This might be worth it; it would put the online documentation for
Linux at least a step above everybody else's, especially once things
were restructured a bit to take advantage of the new capabilities.
Matt Welsh
>In article <1994May7.2...@cs.cornell.edu>,
>Matt Welsh <m...@cs.cornell.edu> wrote:
>>I've yet to see
>>a UNIX-based "file manager" make use of those tools well; it's just
>>impossible to construct pipelines by clicking on file icons.
>
>This is how Unix experts use the system. Novices won't. Tell me how much
>of the file system do you really need to know to read mail or news? Or
>to edit a simple file? or to print said file? or to run the spreadsheet?
But, you're contradicting yourself. You don't _need_ UNIX to read mail
and news. My opinion is that you should learn how to use UNIX the
right way, or don't learn at all. I've always been against leading
novices astray with simplistic sugar-coated interfaces which make the
system appear to be less complex than it really is. In my opinion this
only impedes the user---you might as well start off by teaching them how to
use UNIX as it was meant to be used. Yes, the learning curve is steeper,
but in the long run they have to overcome that anyway.
Apparently you and I differ fundamentally on that point, so there's no
reason wasting more bandwidth about it.
Cheers,
Matt Welsh
>I would be interested in co-authoring such a book, especially
>if we could leave it in such a manner that it isn't constrained
>to linux, but, will cover the basics across all
>platforms (I think that it is reasonable to expect
>a certain level of tools on the systems, and a disclaimer
>can be presented).
Eventually I'll get time to include a real UNIX tutorial in the
I&GS. (In fact, you may see it sooner than you realize.) Until
then talk to Larry and Karl, authors of the User's Guide.
Matt Welsh
>No, what I'm really complaining about is that both man and info both
>fall short. man is great if you need a quick answer - command syntax,
>and such. It's not so hot when the man page exceeds a few pages (try
>finding the definition of ``set'' in the bash man page). info is good
>if you need a coherent, in depth treatment of a utility, it sucks if
>you need data quickly . Would you like to see my "info/dir"? I've got
>something like 30 entries in there, I've given up on adding more. As
>more stuff get's infoized, it becomes almost impossible to retrieve
>anything quickly.
Isee, but using SGML isn't going to solve that problem. If you need to
get quick information from Info pages you can always use the search
facilities (or write your own).
Matt Welsh
>Hrm ... why use LaTeX? It strikes me as silly that the format for manuals
>aimed at novices is something that a novice will not be familiar with.
You don't need to use LaTeX to print documents produced with it.
>In addition, Info is a nasty tool ... hardly conducive to browsing.
I understand, but I don't like that attitude. If we want to restrict
ourselves to formats that only novices can use, that leaves us one option:
Plain ASCII, which can be read on MS-DOS systems. I've tried to make most
documents available in plain ASCII (even the I&GS!) for this reason.
But there's only so much you can do for folks who can't deal with anything
other than ASCII.
>What would be nice is a common front end to all the different document
>formats, like Mosaic is a common front end to a lot of Internet resources.
SGML is a "front end" in a way, but there are limitations. First of all,
in any "front end" the underlying system peeks through, sometimes
quite a bit. For example, in the Linuxdoc-SGML <verb> element, you can't
use the string "\end{verbatim}". Why? Because a <verb>...</verb> pair
is translated to:
\begin{verbatim}
...
\end{verbatim}
in LaTeX, and an "\end{verbatim}" within the block would end the
environment prematurely. I can't think of any nice way of getting
around that in any "front end", as you put it. The underlying text
processing system will always show itself in some ways.
Sujat Jamil
Stuart Herbert <ac3...@sunc.sheffield.ac.uk> wrote:
>Matt Welsh (m...@cs.cornell.edu) wrote:
>
>: Why would they ever need to use Linux? DOS and Windows is certainly
>
>: I know that there are people out there who have aspirations of seeing
>: UNIX and Linux become the popular, common operating system for personal
>: computing. I don't think that UNIX was designed with this in mind,
>: and Linux is certainly no exception. Most personal operating systems
>: attempt to hide the OS and machine from the user, abstracting those
>: concepts heavily. UNIX makes no attempt at this. And, I don't believe
>: that it should.
>
>This is off-topic, but there is one area in which UNIX is very suited to
>mass-market use, where DOS and Windows will never be able to compete without
>making consessions.
>
material deleted...
>I fail to see any substance to your arguement that you can't make a
>user-friendly interface to UNIX. So others have tried and failed.
>That does not mean that the prize is beyond reach.
Hear hear! NeXT Step, for example, might not have been a commericial
success but certainly shows how the complexity of a Unix (like) system
can be hidden from the user. The newer X based interfaces in SGI, HP,
and Sun workstations (and probably on other Unix platforms too--I'm
not sure) (e.g. HP-Vue etc.) certainly ease the introduction or
transition to a a Unix based system.
I agree with the couple of previous posters on this thread that let's
not be elitist and say Unix is only for some people. We have to
remember that the user interface is only *one* part of an operating
system. What principally makes Unix better than the popularly used OS's
(dos/windows/mac) is it's superior resource management (pre-emptive
multi-tasking, decent file system, etc., etc., etc.). And Unix's UI
while not terribly friendly, is not *much* worse than dos, but far
more powerful. PLUS, it's alway spossible to have a better, possibly
graphical, UI running on top of Unix/X. With a free
clone like Linux, it's possible for almost anyone owning a suitable PC
to have the superior resource mangement of Unix.
>
>Stuart
>
>--
>Stuart Herbert -- S.He...@shef.ac.uk
Sujat
--
*******************************************************************************
Sujat Jamil Electrical Engineering
Graduate Research Assistant University of Minnesota
******************************su...@shasta.ee.umn.edu**************************
Stuart G Moncur
I've been reading all this stuff on the "idiot's guide to unix/linux" and was
just pondering... Aren't the newsgroups (like this) supposed to be a media for
spreading knowledge/ideas, etc. Why are newcomers told to sift through endless
ASCII, when they possibly don't know what to look for? FAQ's are great, but they
are very limited. Couldn't there be a comp.os.linux.newcommer or something where
people could learn and discuss unix in general (with more emphasis on learning)
- I'm sure it would be a lot more effective than giving people reading lists,
at least the newsgroups could give new users a starting point.
A reassuring word to all newcommers to the happy world of linux and unix:
There are no "stupid questions" - If you don't know, ask. How do we learn if we
don't ask questions?
--
--------------------------------------+----------------------------------------
"How many escape capsules are there?" | Department of Computing & Elec.Eng.
"None..." | Heriot-Watt University, Edinburgh,
"Have you counted them?" | Scotland
"Twice!" | Stuart Moncur: smo...@cee.hw.ac.uk
--------------------------------------+----------------------------------------
Dan Pop
>Hello,
>
>I've been reading all this stuff on the "idiot's guide to unix/linux" and was
>just pondering... Aren't the newsgroups (like this) supposed to be a media for
>spreading knowledge/ideas, etc. Why are newcomers told to sift through endless
>ASCII, when they possibly don't know what to look for? FAQ's are great, but they
>are very limited. Couldn't there be a comp.os.linux.newcommer or something where
>people could learn and discuss unix in general (with more emphasis on learning)
>- I'm sure it would be a lot more effective than giving people reading lists,
>at least the newsgroups could give new users a starting point.
>
>A reassuring word to all newcommers to the happy world of linux and unix:
>There are no "stupid questions" - If you don't know, ask. How do we learn if we
>don't ask questions?
It's OK to ask questions, but only after reading I&GS and the
appropriate HOWTO file and the FAQ. There is no point in asking a
question if you don't have the background required to understand the
answer.
Just my $0.02,
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Eric Jeschke
:Well, if you think it's too much work, it undoubtedly is :-). I'm just
:wondering how bad it would be to use sgml as a common denominator. I
That's a good idea. I like the man pages that have been converted
to HTML. Hyperlink cross-references are very nice. I think there
is an SGML->HTML converter floating around, but the problem would
be specifying the hyperlinks in SGML, eh?
--
Eric Jeschke | Indiana University
jes...@cs.indiana.edu | Computer Science Department
eric%mar...@moose.cs.indiana.edu |
David Fox
] I've been reading all this stuff on the "idiot's guide to
] unix/linux" and was just pondering... Aren't the newsgroups (like
] this) supposed to be a media for spreading knowledge/ideas, etc. Why
] are newcomers told to sift through endless ASCII, when they possibly
] don't know what to look for? FAQ's are great, but they are very
] limited.
Remember what the "F" in FAQ stands for. No one is interested in
answering the same question over and over, or in reading the same
answer over and over. The description "media for spreading
knowledge/ideas" is not the best description for a newsgroup -- a
better description would be an ongoing conversation. The FAQs are
the record of the interesting conclusions of that conversation up
until now. If you're not willing to look through the FAQs you're
not holding up your responsibility in the coversation.
] Couldn't there be a comp.os.linux.newcommer or something
] where people could learn and discuss unix in general (with more
] emphasis on learning) - I'm sure it would be a lot more effective
] than giving people reading lists, at least the newsgroups could give
] new users a starting point.
Who would answer the questions posed in such a group? Even the
help newsgroup is on the verge of being all questions and no
answers.
] A reassuring word to all newcommers to the happy world of linux and
] unix: There are no "stupid questions" - If you don't know, ask. How
] do we learn if we don't ask questions? --
Unfortunately USENET is a case where this is not always true.
Since none of us are being paid to read netnews we each have to
make sure we get as much out as we put in. None of us can
afford to answer the same questions over and over, at least
I can't.
--
David Fox xoF divaD
NYU Media Research Lab baL hcraeseR aideM UYN
Bill Reynolds
Isee, but using SGML isn't going to solve that problem. If you need to
get quick information from Info pages you can always use the search
facilities (or write your own).
Actually what I was thinking of was more along the lines of converting
things to html - sgml is good because it also gives your hardcopy and
ascii. It seems to me that a Mosaic or a Chimera could be hacked into
a pretty good document browsing tool.
--
_____________________________________________________________________________
Bill Reynolds bi...@goshawk.lanl.gov |
Christopher Andrew Smith
Bill Reynolds <bi...@goshawk.lanl.gov> wrote:
>
>Actually what I was thinking of was more along the lines of converting
>things to html - sgml is good because it also gives your hardcopy and
>ascii. It seems to me that a Mosaic or a Chimera could be hacked into
>a pretty good document browsing tool.
Basically what you want is "winhelp" for Linux (i.e hypertext help).
This should be fairly easy to put together, but would be incredibly time
consuming. You probably wouldn't have to change Mosaic at all, except
for the fact that it takes up lots of memory (on my system w/ 8Megs ram)
IMHO using more and grep to find help is a good exercise for when you
start writing programs and searching config files on a Linux system. :-)
--
------------------------------------------------------------------------
|Christopher Smith | With a rubber duck, one's never alone. |
|aka z1g...@ugrad.cs.ubc.ca |-- "The Hitchhiker's Guide to the Galaxy"|
------------------------------------------------------------------------
ADAM P JENKINS
: Hello,
A good idea is to have the FAQs available on the newsgroups,
as most of them are on comp.os.linux.help. Then you can direct faqs
to read them and they don't have to go far to find them. Also,
informing people of the Linux Documentation Projects books would be a
big help. Once I found those, I no longer had so many faqs.
--Adam
a...@twain.ucs.umass.edu