From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 5 Apr 1995 06:15:10 -0400 From: forsyth@plan9.cs.york.ac.uk forsyth@plan9.cs.york.ac.uk Subject: plan 9 and linux Topicbox-Message-UUID: 0a9a7164-eac8-11e9-9e20-41e7f4b1d025 Content-Type: text/plain; charset=UTF-8 Message-ID: <19950405101510.3S-fhHxnsESfySt6Elbl26HfihgwyzLg4rDUpg5ft9k@z> >>How is it compared to Linux? apples and galaxies. they do different things. linux is a self-contained operating system that can attach to a network. plan 9 really is a distributed system. Linux now seems to attempt to track Posix closely, with all that that entails. by contrast, although plan 9 has useful ansi/posix emulation environments -- and that's certainly convenient when importing or exporting Unix programs -- it's definitely not the most sensible way of using plan 9. it isn't a `leaner unix'. indeed, if you approach it that way, you will probably be disappointed. plan 9 provides a number of components that can be put together on a network to form one (secure, distributed) computing system; even an apparently `standalone' plan 9 system at home can link itself smoothly to the name space -- and thus processors, devices and network interfaces -- of a bigger system. although linux does very well -- the leanest and most effective unix-like system on a PC -- in my experience, plan 9 easily is less demanding of hardware than other general purpose operating systems on any given platform. for instance, at work my terminal is a 386sx/16 with 4mbytes with an ET4000 ISA graphics card and NE2000 card. i have a small slow seagate IDE disc for booting & paging, but it doesn't page much. at the moment this pathetic machine is running 30 processes including the window system 8½, seemail, `cpu' to the cpu server samterm (to remote sam on the CPU server), a local 8½ window for commands, dossrv (makes DOS file systems on disc & floppy visible in the plan 9 name space), and supporting commands (eg, kernel protocol processes, exportfs exporting the terminal's name space to the cpu server). (by the way, i can access the terminal's diskette device and/or DOS file system transparently from the cpu server, just as i access the terminal's keyboard, mouse and screen.) here is a ps: forsyth 1 0:00 0:00 40K Wait init bootes 2 0:00 0:00 0K Wakeme alarm bootes 3 0:06 0:00 0K Wakeme ether0kproc bootes 4 0:00 0:00 0K Wakeme tcpack bootes 5 0:00 0:00 0K Wakeme tcpflow bootes 7 0:00 0:00 0K Wakeme ilack forsyth 8 0:00 0:00 0K Idle pager forsyth 9 0:08 0:25 352K Read 8½ forsyth 13 0:01 0:02 48K Read cs forsyth 17 0:00 0:00 0K Wakeme floppy forsyth 23 0:00 0:00 704K Read dossrv forsyth 26 0:00 0:00 40K Read arpd forsyth 28 0:00 0:00 0K Wakeme uart0 forsyth 36 0:00 0:01 196K Read 8½ forsyth 38 0:00 0:01 196K Read 8½ forsyth 47 0:00 0:00 132K Read samterm forsyth 49 0:00 0:00 20K Read rx forsyth 52 0:00 0:00 124K Read samterm forsyth 53 0:00 0:01 124K Read samterm forsyth 54 0:00 0:00 124K Read samterm forsyth 55 0:00 0:00 124K Read samterm forsyth 58 0:00 0:00 20K Read rx forsyth 59 0:00 0:00 108K Read seemail forsyth 65 0:00 0:00 28K Wait cpu forsyth 66 0:00 0:01 332K Read exportfs forsyth 67 0:00 0:00 332K Rendez exportfs forsyth 68 0:00 0:00 332K Read exportfs forsyth 70 0:00 0:00 104K Wait rc forsyth 75 0:00 0:00 32K Read ps is it paging frantically? term% cat /dev/swap 374/416 memory 92/4000 swap no: in fact the pager is currently idle. presumably it has turfed out most of dossrv since i'm not using it. (the memory sizes above can't just be added up: there's a lot of shared text & data there.) now, you definitely don't want to compile much on this thing -- for one thing it hasn't got a floating-point unit -- and it's certainly not as snappy as a bigger 486 at home with more memory and a reasonable graphics card. nevertheless: try getting an X server to run on a similar configuration with several xterms, rlogins (inadequate substitute for `cpu'), a mail monitoring window, and samterm. it's certainly true that you'll stand the best chance of doing it with linux, though, compared (say) to solaris/486. although i haven't made a complete study of linux, i'd say the system interfaces in the plan 9 cpu/terminal kernel are simpler yet more general than those in Linux; perhaps more importantly, the plan 9 kernel was intended to be portable, and support multiprocessors from the start. aside: there's currently a lot of ignorant hype in the media about the brilliance of having a Hardware Abstraction Layer in making a certain o/s portable, but it's really no big deal. like older portable operating systems, plan 9's portability interface is a small collection of functions and data structures. no fuss. outside the kernel, linux -- reasonably enough for a unix/posix clone -- simply uses all the freely available software for Unix-like systems that anyone can be bothered to port. a lot of that is Big and Complicated. by contrast, although many of the older Unix commands are in Plan 9 at least in name, Plan 9's commands are freshly written. (the few things left from the ancien régime -- notably `troff' -- have at least had a facelift.) a lot of crufty crud has been left behind. after all, as andrew hume once put it: ``crud that isn't paged in is still crud''. still, that's old stuff; worthy but dull. the really interesting bits are the new things, including: the protocol 9P that binds everything together the file server, and its `dump' file system per-process name space union mounts Unicode user-level file servers shared memory multiprocess servers, using lean (threadbare?) processes cpu the window system 8½ Acme (is that named after the Acme Construction Co. in the Roadrunner cartoons?) FAST C compilers; simpler C library interface, and every compiler is a cross compiler simple support for multiple target architectures the concurrent programming language Alef acid for the administrator: a coherent approach to describing a network, and best of all from my point of view, it hasn't got BIND. if you want a fairly conventional X11/Unix environment on your PC, Linux is a reasonable choice. Plan 9 has different aims.