Time for the book club discussion.

Chapter 5 and 6 were interesting because they started to give an overview
of the decoupled, decentralized, architecture of Plan 9. They also
emphasize the strong enforcement of "everything is a file".


## Chapter 5


This one was about the shell and redirection in general.

The virtual descriptor, /fd/0 and /fd/1 were new to me, interface to
file descriptors.

The redirection to different file description is done using square brackets.
That's cleaner than Unix usual shells.


One interesting point, that is well covered in the book, is that pipes
preserve write boundaries, unlike Unix.
Another unusual feature that enforce cleanliness, is that Plan 9 kills
processes that only use the write end of the pipe.

rc, shell execute command like this:



The concept of notes to process wasn't obvious at first because of
the name, but making the comparison with Unix signals, it started to
make sense.
Similarly, like signals, they can be caught with a notification handler
(atnotify).

Plumbing is pretty cool, it has ports to dispatch messages to
applications. It's kind of like mime-open and xdg-open in a way.



## Chapter 6

This chapter was about networking.

The network is a file on the disk, as with everything else. Somewhat
like linux proc/net/tcp which was inspired by Plan 9. Namely on Plan 9
we can have files such as /net/ether0.

One thing that feels a bit awkward is to send text as commands to files.

I kind of think that it can be flimsy, unless there is a way to list
all the possible commands/notifications that a process can handle and
to limit processing unknown commands.

We also see the concept of translation of human readable names to
addresses/ports.
It reminds me of this but I hadn't covered Plan9 in it.

The network database, ndb in /lib/ndb/local is like NSS.
The equivalent of getent on Plan 9 is csquery. CS stands for "connection
server".

The socket programming style is novel, different than BSD sockets,
and much simpler.

We get to also talk about registering services and running them.
We see /rc/bin/service which is kind of like an inetd if I understood
properly.

Lastly, we get reminded that the architecture is decoupled and that
commands are actually executed on a CPU server. We can explicitly do
that using rc command.