[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Evans wrote: > > Problem is that in order to understand this fully needs quite a bit of > the history of copyright and proprietary licensing explaining. But > starting a "computer course" with a history lesson might well upset many > of the students.. Depends if they want introduction to Linux, with the intent of using or administrating it, or to know why it is like it is. Most business users don't care why it is like it is, although history is a useful teaching aid, especially where like the password storage it has changed through time (otherwise why the wacky password field in /etc/passwd, and why is it called "passwd". I still think of it as where the passwords are stored, although I probably haven't used a box with passwords in the /etc/passwd file for 5 or 6 years). >>4. The shell (bash or whatever) and when to use different shells Shell scripting is a minority activity, and anyone who needs can RTFM, learn "info", "apropos", "man". Teach a man to fish. Similarly other shells (other than Bash, or Posix compliant shells) are very esoteric, with the possible exception of Perl. >>5 text editing, and creating scripts, perfer to use a neural editor e.g >>joe to avoid any vi/emacs wars. Depends on audience again. If they are learning sysadmin type skill they learn basic "vi", enough to edit key files. It isn't a part of the editor war, even die hard Emacs users, probably expect to have to use "vi" or "ed" occaisonally when piecing a Unix system back together. The editor wars were about what you chose to use, system recovery is about what you are likely to have available. Although my Redhat box doesn't seem to have a statically linked "vi" clone - hmm, in fact no statically linked editors at all as far as I can see. Oh well been there before, recovering a system with no file editor (and no ls command!), it ain't so bad, for as long as "echo" is built into the shell, or available ;-) > At a more basic level than this issues such as the filesystem, > permissions, system calls, processes, etc need explaining. Especially > where things differ from the Windows way of doing things. I always took the view if students on the Unix system admin course I use to teach could explain the meaning of each element in the /etc/passwd file, and what /etc/inittab does, they could work the rest out for themselves given enough time. But you need only minimal understanding of permissions, groups, and processes to be a user. Strangely some seem to have real trouble with the idea that "disks" don't appear to users. The system admins use to have fun with the concepts on modern disk management systems, but then some of them are getting pretty involved, and on big *nix systems it can take a little while to map out how the physical disks relate to file systems. Trust me it is quite hard enough to teach Unix system admin skills to those who need it, introductory, or end user courses can skip as much of these as possible. HP use to do a Unix fundamentals course which covered like how to use HP-VUE, how to customise your toolbar, how to read the help, how to login, how to logoff, and why to lock the screen when you step away. Plus some basic commands for file manipulation, and how to navigate the file system, and that was your lot. Coming from cold that is about a two day course at average user pace. How quickly we forget how slow the learning process is, you need to acquire a basic vocabulary of terms and ideas, before it becomes easy to pick new ones up. I dare say these days people are more "computer literate" so may pick up the GUI elements quite a bit quicker, but it is easy to underestimate how hard it is to break existing habits, and mindsets. -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/W8aFGFXfHI9FVgYRAtLIAKCsGPfHjMJqFJdaRiYc+Qi5Z8IXxwCgkCjL eUmGjgGIbmR3TKnqLpqgwIE= =Ir79 -----END PGP SIGNATURE----- -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.