wm: doc

ref: 7bdf748cc1e1dc6130a8648173f8acd93df9826a
dir: /9.ms/

View raw version
.TL
9

.PP
in 1970 UNIX was created as a small version of multiics on PDP-11 asm
language, few years later it got rewritten on C. one of reasons of
UNIX popularity was unified file system view, everything was on files,
hence you could use same toolbox.  as time goes, it gets replaced by
the fact that everyone uses UNIX because everyone uses UNIX.  and
started to port alien programs, using alien ways and alien interface.

.PP
however, all UNIXes share these problems, even on most modern and
advanced versions of *nix-like systems:

.IP * 4
UNIX was a multiuser system for mainframes, poorly ported to PC (i386
and amd64) platform and still doesn't fit.  and it will be worse on
Risc-V/aarch64.

.IP * 4
Research UNIX itself was about the showing all resources as files,
this is ignored by modern UNIX as there are many examples for it.  (on
graphics, networking, audio and security)

.IP * 4
networking on UNIX is most of time is done using sockets (BSD and
Linux) and STREAMS (SystemV) both apply poorly to modern networking.

.PP
No version of UNIX was able to solve these problems, as all UNIXes are
trying to do something in different ways.  Plan9 however, doesn't try
to be a UNIX.  it doesn many stuff on UNIX such as (sym, hard)links,
sockets, X11, sh, chroot, NFS, teletype terminals, sysctls, daemons,
ssh, dynamic linked programs, /etc, dotfiles and root.

.PP
Instead of all of those features on UNIX, Plan9 solves problems with
two key ideas:


.IP * 4
9p: a unified protocol for programs to create do file operations, on
userland, which solves many problems about files and makes a unified
UI. which makes usage of everything is file possible by the 
.BI whole
system.


.IP * 4
private namespaces: which allows each process has it's own view on
file system, which solves many problems about security and makes
extending system without touching it possible.

.PP
for example let's say you have your httpd and you want to do chroot on /var/www for httpd. on OpenBSD it would be like: 

.IP 1) 4
copy all files needed to run httpd to /var/www/
.IP 2) 4
chroot
.IP 3) 4
httpd
    
.PP
if you have ever bothered to it, you know how hard it is to do.
thanks to magic of dynamic linked programs.  on Plan9 it can be done
in two ways:

.IP 1) 4
bind /var/www to /
.IP 2) 4
httpd
    
.PP
This one will be more like classic chroot, besides that there is no
dynamic linked httpd to annoy you it's same.  all sub-process will see
/var/www as / and there is no way to escape it, all other procs will
work as expected.  however, the magic will happen on other way:

.IP 1) 4
bind everything you don't need to a empty place. 
.IP 2) 4
httpd 

.PP
This will be more like unveil, OpenBSD used it as easier way for users
to handle this problem.  the drawback of unveil is it will need some
serious hacking around the program, binds don't have this problem.

.PP
another example: let's say you don't want to have /secret-data folder to be visable by httpd. 

.P1
% mkdir empty
% bind empty/ /secret-data 
% httpd
.P2
    
.PP
httpd will never know what is really on /secret-data, it just will see
whatever is on empty/ all other procs (besides httpd forks), will see
/secret-data as is.