Re: [SAGE] Where to start?

[Trey Harris <trey@sage.org>]

In a message dated Fri, 17 Jan 2003, Anthony Howe writes:
> I have to provide in-house tutorials on Unix (Linux) systems and
> their administration to our Windows sys.admins. who know nothing
> about Unix or its variants.
> [...]

A few thoughts as someone who has a fair bit of experience teaching such
topics...

- Beg, borrow or steal a projector, if you don't already have one, and
  make the sessions demos.  Static slides will be nearly ineffectual for
  newcomers.

- If you use slides, use them as overviews, illustrations, and
  organizational tools.  Don't put any commands or code on them, as this
  will cause your students (especially since their command of English
  is apparently not 100%) to spend their time copying down notes instead
  of paying attention to the concepts discussed.

- *Do* include commands, file structures, and the like in handouts.  Pass
  them out before class so that the students will understand they don't
  need to take notes.  A student taking notes is a student not letting
  concepts sink in and not asking questions.

- If you can think fast on your feet, use likely tasks these admins will
  face as points of departure.  Use the process of gaining administrative
  rights (su or sudo) as an introduction to the concepts of UID and
  the Unix superuser.  Use ps as an example of process heirarchy (which
  can naturally, through init, lead to the boot process), and use 'ps |
  grep' as an illustration of pipelining.

- Again, if you can think fast on your feet, structure the classes with no
  set points to cover.  Instead, think of a few topics you'd like to hit
  and leave plenty of time for students' questions to lead you off in
  other directions.  This works especially well for second, third, and
  successive classes, as the students try out what you showed them in
  earlier classes and make discoveries on their own which they want to
  talk about.

- If your students are shy or bored, elicit responses from them.  First
  tactic, ask the whole class a question: "Can anyone see something
  strange in this output?"  If you get no response, start picking on
  individuals.  "Claude, why do you think this column here is twice as big
  as that one there?"  Get your students used to the class being
  interactive.  If certain students are always silent, single them out a
  few times to see if they get what you're covering.  If they don't,
  shower them with attention until they become more talkative.  If they're
  following along okay, leave them alone--they probably are just quiet
  types and will only be embarassed if you pick on them.

- Use real systems, not sanitized examples.  If you show a root directory
  with just /bin, /usr, /var, /dev, /home and /etc, your students will be
  befuddled and panicked when they login to their own systems and see
  /lost+found, /SomeRandomDirectorySomeoneLeftBehind, etc.

- Concentrate on the method behind the madness.  Unix is *not* a system of
  magical incantations, at least not in the forms beginners see it.  It is
  one of the most cohesive, understandable operating systems out there.
  Introduce files, devices, UIDs, processes, scheduling, filesystems,
  and all the other high-level concepts early, and relate everything from
  there on in terms of them.

- Break the rules to show them how things really work.  Create a user
  named "guest", UID 0, and show them what you can do with that user, and
  they will never forget that the name "root" is just convention, not
  magical.  Add a port to /etc/services, then attach that port to bash via
  inetd.conf, and telnet into it, and watch your students suddenly "get"
  how things connect together.  A good junior Unix admin knows what
  commands do what.  A very good junior Unix admin, one well on his way to
  becoming a more senior one, knows *how* they do it and what the edge
  cases and limitations imposed by the operating system are.

- If someone asks a question about a command, option, etc., don't answer
  it directly--pull up the manpage and show them how to find the answer
  for themselves.

- I don't know the scope of this class, but if it's more than six hours,
  I'd strongly recommend working scripting into it.  Perl, Python, or
  shell, whatever you're most comfortable teaching, but some scripting
  language will vastly increase the toolset your students have access to.
  You don't have to go into detail, but just showing them "type commands
  like *this*, then chmod +x the file like *this*, then run it like
  *this*" will get your students over a big psychological hurdle.  If you
  choose Perl or Python, use it as a vehicle to demonstrate
  important low-level OS concepts, like fork/exec, that aren't readily
  grasped just working with the shell.

- It's completely okay to show a few magical incantations *so long as the
  students don't need to master them*.  For instance, you can show the
  fork/exec example in Perl without having to explain that a parent gets a
  PID return, a child gets 0; just tell them that's magic and they don't
  need to worry about it.  But if it's something your students are going
  to have to type, you have to able to explain it, even if it's just by
  analogy.

- Blow up your system in realtime.  Pull the network plug, start a fork
  bomb, eat up all your memory, even pull a running disk, to show the edge
  cases.  An admin who has seen something before is an order of magnitude
  more effective.

I could go on, but I've already taken up too much space. :-)

Trey
-- 
I'm looking for work.  If you need a SAGE Level IV with 10 years Perl,
tool development, training, and architecture experience, please email me
at trey@sage.org.  I'm willing to relocate for the right opportunity.