Users browsing this thread: 1 Guest(s)
pkal
Long time nixers
The perspective, and thus what has to be understood is relevant. Are you teaching Unix as a operating system among others, thus you need to compare it to how Multics, DOS, VMS, NT, etc. do/did things. Then you have to take a far more abstract perspective, and let the person contemplate what an OS needs to do, and how Unix tries to solve the problems.

Or are you teaching Unix as a work-environment? As an alternative to a desktop driven (Windows, X11, Quartz, ...) or high-level programmable environment (Emacs). Since the shell is central to the classical Unix-UX, take a historical perspective! Lots of what we have nowadays in the results of many good, many not-so-good historical accidents, so for understanding what seem arbitrary ("what the hell is a 'grep'? Is that legal?"), one has to have some idea where (and when) it came from.

This video gives a good starting point, I think: https://youtu.be/JoVQTPbD6UY?t=88, where D. Riche says:

Quote:The Unix operating system is basically made up of three parts.

The kernel, or operating-system-proper, is the part that manages the control of the machine and supervises scheduling of the various user programs.

The shell, which is the name we give to the command interpreter looks after the communication between the user and the system itself.

The third part, which is actually the largest, is the various utility programs, which perform specific tasks, like editing a file, or sorting a bunch of numbers, or making a plot. In other words, all the other programs that are not provided directly as part of the operating system kernel.

With this overview, and maybe a few hints on terminology, documentation self-sufficiency and core concepts as single-root file systems, pipes and signals, a user has a stable framework and fundamental to experience what unix is beyond words, graphs and anecdotes (whatever that is).

Another, very basic, thing is opening a terminal from a regular X11 file manager (on modern *nix'es) and showing how they basically deal with the same thing: the shell presents itself at first as a kind-of programmable file manager. Create a file using the mouse, you'll see it with ls. Remove it with rm, and the UI will change! Move up a directory, and rename something in the parent directory, and maybe even kill the file manager using kill/xkill.

This might be a "fun" (for certain definitions of "fun") example that is very visual. It's the first step in translating thoughts from a mouse-centered, to a command centered UI. It has to be made clear, that as with any regular language, the goal is to overcome the need to "translate", and instead operate on the terms of the actual environment. You shoudln't want drag-and-drop, you should take a step back and reconsider what you're doing.

My final point would be to not mythologize. I remember a math teacher once told us "there are 12th grades who don't get fractions!" and that scares you when you're in 6th grade. Similarly, if you make Unix, the shell or anything else to be "so brilliant", people will be scared away. They'll think to themselves "I won't get it" or "I'm certainly going to struggle with this a lot", and then their beliefs will become reality, because they relived it. That's why is consider statements like "Unix is so simple, it takes a genius to understand it", or the "Unix Philosophy" to be harmful, especially when first encountering the subject. It's all managable, it just requires a bit of re-thinking. It's different, but for everything you'll loose, you'll hopefully win something too. Keep it down-to-earth, and people will appreciate it.

---

Also

(01-02-2019, 01:46 PM)venam Wrote: . Not to count university courses that plunge way too fast into things the students are expected to memorize instead of understand.

As someone who has been helped with university-introductions, mostly to programming, but also to the unix, I can't confirm that this is the case. The basics (cd, ls, mv, vi/nano, ...) are covered quickly, but depending on the subject, they're needed so much that you'll simply end up understanding it in one form or another, by sheer need. Just memorizing would be counterproductive, even for the most uninterested students.


Messages In This Thread
Teaching Unix - by venam - 01-02-2019, 01:46 PM
RE: Teaching Unix - by jkl - 01-02-2019, 03:49 PM
RE: Teaching Unix - by pkal - 01-02-2019, 05:56 PM
RE: Teaching Unix - by venam - 02-02-2019, 06:46 PM
RE: Teaching Unix - by budRich - 02-02-2019, 10:03 PM
RE: Teaching Unix - by jkl - 03-02-2019, 03:34 PM
RE: Teaching Unix - by budRich - 03-02-2019, 05:19 PM
RE: Teaching Unix - by jkl - 03-02-2019, 05:26 PM
RE: Teaching Unix - by budRich - 03-02-2019, 05:44 PM
RE: Teaching Unix - by jkl - 03-02-2019, 08:37 PM