Getting Started

The first section is a brief introduction to a operating system as a collection of system programs that interface with the hardware and how it lies to the programmer by common abstractions.

`/sys/lib/newuser` is a rc(1) script that creates and set up the home directory for the user and create the necessary profile scripts. I cat this file to see its contents, and it is pretty straight forward at 9front.
I'm just curious about why it is at `/sys/lib/` and not at `/bin/whatever/`.

Our first interaction with rio! Damn this menu thing is awkward. I'm used to click to open the menu and then click on the selected entry (that's how I programmed πmenu to behave). But rio's menu is click-and-hold then release on the selected entry.

Now it's acme time.
Button3 click opens a file/directory or looks for a word in the current window. I found this behaviour really awkward... What if I wanted to look for a occurrence of a filename of a file that exists? Right click will open that file...

The window/widget that receives keyboard input is the one where the pointer is over, just like on Xaw/athena X applications. It's called point-to-type. I hated it.

One thing I find weird on rio and acme is how the height of the scroll bar handle changes while scrolling. After checking on the manual I found out that the height of the handle corresponds to the density of characters on the screen, not the number of lines on the window. So if you have a sequence of blank lines on the screen, the scroll bar handle will be very thin (as there are no characters on this section of the scroll), but when viewing the dump of xd that is full of characters, you will have a higher handle.

Enough acme. The next pages are on the manual. Simple file management commands (mv, cd, rm, etc) and concepts (directory, dot-dot, relative path, etc), and file content reading (plan9 uses xd(1), which is way more friendly than od(1)).

One thing I do not like in the plan 9 manuals is how everything is written in prose, rather than lists. Options are scattered through a paragraph that you have to read as a whole to understand the stuff. On some UNIX systems (OpenBSD at least), options are presented in a list using a `.TP` man macro. It is easy to spot an option for reference when they are on a list.

Then we write our first plan 9 program, using a variant of the C programming language with a plan9-specific standard library. The next pages talk about library and system calls, and how system calls work.


Programs and processes

Second chapter is about programs and the processes they generate. We begin with an overview of what a process is and how it is executed; and of the structure of a program (both in file and in memory) and how it is loaded into memory by the kernel.

The concept of program initialization is explained by the classic echo.c program. The example introduces the plan9 ARGBEGIN and ARGEND macros, which replace UNIX getopt(3).

Then comes the error handling. Plan9 has a "%r" directive for print(2) that is replaced by the error string, this directive does not require an additional argument. There is no errno(2). The system provides an err(3)-like function that both prints a message and exits: sysfatal(2). The {w,r}errstr functions write/read the error string.

Next section is about environment variables. Everything pretty simple and similar to how stuff is done on UNIX. One thing I discovered is that children processes can change the environment of their parents! (At least depending on how the processes are forked). The section about processes introduces the concepts of process id, process state, and process scheduling.

Next section explains how to debug a broken process that is still hanging around in the ps(1) table. The section introduces acid(1) and some of its commands (stk() and lstk()). To kill a broken process, run

And finally! Everything is a file! (Or that's the lie the computer tells to you). Time is a file (see /dev/time); processes are files (/proc/); environment variables are files (/env/).