Plan 9 open-sourced

[John Chambers]

Ken Gosier writes:
	 
	 --- Scott Lanning <slanning at buphy.bu.edu> wrote:
	 > Not Linux, but interesting to Linux users I think.
	 > http://biz.yahoo.com/bw/000607/nj_bell_la.html
	 
	 Question: in the article, they list as being one of the
	 radical ideas pioneered by Plan 9:
	 
	 "naming and accessing all system resources as if they were 
	 files"
	 
	 How is this different from what Unix does?

Nobody elese seems to have commented on this ...

Unix did have this design originally, of course, but there have  been
numerous  failures  to  follow  through.  For example, the first Unix
systems didn't have the /proc  file  system,  and  process's  address
spaces  weren't  available  as files.  This led to some rather clumsy
code for interactive debuggers before people copied the  (Bell  Labs)
/proc idea.

The BSD networking code makes an interface a special  sort  of  thing
that  isn't  accessible as a file.  This has been semi-fixed on a few
kinds of unix systems, but it is still a problem on most. I worked on
some  Ultrix  machines  a  few years ago that had a kind of interface
that was also in /dev as a special file, which was  really  nice.   A
process  could  open  the interface as a file, give it an IP address,
and read and write raw packets.  This made it possible to  put  other
devices on the internet without needing access to the kernel.

Another example is all the windows I see on  my  display.   I  did  a
project  many  years  ago on Sun's early SunView window system, where
each screen widget was in fact a file. When you created a window, you
got  back a file handle.  If you added frames or menus or whatever to
the window, each was an open file.  This had one major problem:   The
kernel limited a process to 20 open files. This seriously limited the
number of widgets you could have inside a window. They didn't seem to
be  able to see the obvious solution of upping the open-file limit to
several K; they went to a totally new window system instead.   The  X
window  system  is  also outside the file system, for pretty much the
same reason.  You can't use a windowing system unless you can  create
at  least hundreds of widgets in a window; if you want the code to be
portable, you can't use files for the widgets.

Some species of Unix now have memory-mapped files,  which  is  really
handy  for  some applications, but most Unices don't have this (yet).
So while your memory may be organized as "objects" in some languages,
these objects are usually not accessible through the file system.

Acessing a database is never done through  the  file  system,  in  my
experience.  You always go through a subroutine library that presents
you with semantics that aren't at all file-like.

Making any sort of object into a "file" is a useful design  approach.
It's too bad that the folks who have borught us Unix haven't seen fit
to do it in general.  It would simplify a lot of programming.

Reports are that the Plan 9 people took the idea seriously  and  made
pretty  much everything into a file.  It might be interesting to hear
about the good and bad things that resulted, and how thorough  a  job
they really did of it.

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).