Hello fellow nixers,
This thread is about sharing ideas and thoughts on the methods to gradually teach Unix.


These days I'm more often faced with a situation where I have to explain a Unix related topic to someone. However, this sometimes lead to a rabbit hole of ideas. Most of the time I slowly get used to finding a better and simpler way to approach the concept than to link to an online article or throw them off with the RTFM type of reply.

I've seen so many books supposed to be introduction to Unix, yet they're more advanced than what I would see the beginners I'm interacting with would be able to handle. Not to count university courses that plunge way too fast into things the students are expected to memorize instead of understand.

Thus the reason for creating this thread. I'm intrigued by how the members of this community would handle those kinds of situations. Have you ever been faced with one?

Personally, I find it better to start from an anchor point that is already well known to the person and then continue in a story-like manner. I can't access how efficient this is but it does seem to make it less boring. Moreover, lots of overview graphs seem to help. Same as with metaphors, but metaphors hit the limit pretty soon.

The question that remains is how to handle the teaching from scratch and how to move from one topic to the other.

It mostly depends on the recipient, honestly.

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.

(01-02-2019, 05:56 PM)zge Wrote: My final point would be to not mythologize.

This one very important point you bring here. It's hard to get through the perception someone has of a concept, especially if they are afraid of it.

One thing I found especially hard to explain are abstract concepts that don't make sense outside of the Unix world, or even the computing world. Say for example a question such as "What's a file", "What's a daemon", "What's a process", "What's a program", "What's a shell", "What's a kernel". Those all have nice answers you can simply search online but the tricky part is to actually explain them to a total beginner. Maybe you are right when bringing up operating system theories to start with. Doing a general overview of what operating systems are and their possible components to then tackle the particularities of Unix, but this is so tedious.

I would go with a history lesson as the first, understanding the origin (AT/T, mega monopolized telephone network company, multics, Bell Labs). Unix was the first operating system programmed in a "high level" language, C (just show a slide of C and assembly and anyone will understand that they are different and one is easier to work with). The C language made it easy for others to understand and help with the source code, which probably shaped the design of the system quite a lot. Same people who created C created Unix. Timesharing. Textbased input via real terminals was the "only" way to "use" it the first 10 years, and the shell is not that much different today, unix philosphy. It is probably good to try to have someone new understand the problems the license caused during the 80's, POSIX, and the relation between "Unix", "Linux" the "GNU" and the BSD's. And for someone "completely new" (venam, it sounds like your want to teach unix to someone who have never seen a computer) or not that tech oriented, more or less all of the stuff above can be explained more as history then tech specs. 40 year old specs can't be that important anyways, right ;)

Ah, it's time for my favorite part of this forum again: Nitpicking about computer history.

(02-02-2019, 10:03 PM)budRich Wrote: Unix was the first operating system programmed in a "high level" language, C (...).

That is not quite right.

For example, Multics - the collaboration between General Electric, the MIT and the Bell Labs which was still actively being developed when Ken Thompson started his then-unnamed Unix project - was written in PL/I, which I would consider a "high-level" language. Granted, there was some assembly code somewhere in Multics, but that was and is also true for Unix. DTSS, another operating system that predates Unix by a few years, was reportedly written in BASIC, ALGOL et cetera.

I think that these two examples are enough for now ... :-)

(02-02-2019, 10:03 PM)budRich Wrote: Same people who created C created Unix.

Yes and no.

Unix was first designed and implemented by Ken Thompson who also derived the B language from BCPL which would later become C. A couple of other people from the Bell Laboratories, notably Douglas McIlroy and Brian Kernighan, joined his efforts. C was mostly invented by Dennis Ritchie in 1972, the fourth Unix version was the first one that was rewritten in it.

It was one team - but not everyone worked on everything at the same time.

(02-02-2019, 10:03 PM)budRich Wrote: Textbased input via real terminals was the "only" way to "use" it the first 10 years

Personal note: And I think we should finally take it to the next step.

@jkl Yeah you are right, but still, that Unix was written (mostly) in C and maybe more important being compiled with the C compiler, making it very much more portable then any other OS prior. Is very important to how Unix was designed, and developed.
This interview with Brian Kernighan, is probably the source of where my first statements came from (also confirming jkl s corrections):
https://www.youtube.com/watch?v=de2Hsvxaf8M

I think that understanding the environment (Bell Labs), where Unix (and C) was developed, is good to know to "understand" Unix (I barely know what it is myself, and i have read many books and binged similar youtube clips for years..). Especially for people not from the US, i guess that AT&T and Bell Labs is common knowledge in US, but few know about it in the rest of the world (those who know probably have a good understanding of Unix already).

I would also try to explain the principles of "pipes" , which also is something that have shaped unix a lot.

(03-02-2019, 05:19 PM)budRich Wrote: being compiled with the C compiler, making it very much more portable then any other OS prior.

"The C compiler" had exactly one platform when it was built, which was Unix. There were much more portable languages/compilers before that. Efforts to make C "portable" were not finished before the end of the 1970s (src).

I meant that it, Unix, could be compiled for other hardware much easier then other OS prior to Unix. source the link i posted earlier.

edit.
also

Quote:Unix's use of C and its consequent portability to a wide variety of machines was important in the system's success.

(src)

jkl i see you don't have an avatar, may i suggest this image: http://i.imgur.com/DpQ9YJl.png

(03-02-2019, 05:44 PM)budRich Wrote: I meant that it, Unix, could be compiled for other hardware much easier then other OS prior to Unix.

In theory, porting Multics would have been relatively easy as well. Sadly, nobody really bothered, so it only ran on two different architectures when Unix rose.