IPC and Unix philosophy

[Steve Summit]

So far, I haven't found pipes to be too deficient for passing
messages between processes.  I have a replacement for "cu" with a
pipe between the transmit and receive processes, so that the
transmit process, which is under the control of the user, can
send messages to the receive process, telling it to open a local
file for writing, etc.  (In the generic cu, this information must
come from the remote device, in a painful syntax involving
the '~' character, which many big mainframes don't have.)
It works like a charm.  I'm sure there are more complicated
applications out there where pipes and signals break down, which
is what prompted this discussion, but I haven't had to deal with
them yet.  (No flames about my naievete, please.)

I'm getting tired of people complaining that "unix doesn't have
IPC," "unix doesn't have file and record locking," etc.  These
deficiencies are an acknowledged part of the "unix philosophy,"
as described in the "UNIX Time-Sharing System" paper by Ritchie
and Thompson.  (Everyone should read this article two or three
times before posting an article mentioning "unix philosophy." 
It's right there in volume two of your unix manual.)

It's big, hairy features like IPC and record locking that turn
operating systems into hard-to-use dinosaurs.  Of course, those
features are occasionally useful, but I like to see unix stay
"small and beautiful."

I know I'm going to get flames from people who say that operating
systems have to grow and respond to new needs and ideas. 
(Actually, that's in the unix paper too, and is one of the
reasons unix was developed in the first place.)  However,
elegance and simplicity are virtues that are often not
appreciated.  Our pals at Berkeley have already contrived a
number of pieces of software that are a bit on the "big and ugly"
side.  (Take a look at csh, or vi, or the new tty driver.)

				Steve Summit
				textronix!tekmdp!bronze!stevesu