Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utcsstat.UUCP
Path: utzoo!utcsrgv!utcsstat!laura
From: la...@utcsstat.UUCP (Laura Creighton)
Newsgroups: net.unix-wizards
Subject: Re: Unix philosophy
Message-ID: <1075@utcsstat.UUCP>
Date: Sat, 17-Sep-83 08:31:06 EDT
Article-I.D.: utcsstat.1075
Posted: Sat Sep 17 08:31:06 1983
Date-Received: Sat, 17-Sep-83 09:53:16 EDT
References: <4897@sri-arpa.UUCP> <1029@utcsstat.UUCP>, <2540@umcp-cs.UUCP>
<1052@utcsstat.UUCP>, <2605@umcp-cs.URe: Unix philosophy
Organization: U. of Toronto, Canada
Lines: 33
Interprocess communication is perhaps the greatest weakness of unix.
Most people try to use signals for interprocess communication. this
is like trying to use a wrench to hammer nails home. it will work in
a fashion, but not terribly well, and if you do something wrong you
will break a perfectly good wrench.
everybody and his dog seems to have their own way of dealing with
interprocess communication. these days, I think that tunis is
maybe the way to go. interrupts are converted to messages, and
there is message handling in the kernel. Unfortunately, this is
not unix. It is too bad that interprocess communication was a very
new idea when Dennis Ritchie and Ken Thompson were designing the
first unix.
All the other attempts to get interprocess communication seem like
the proverbial 'tacking a bag on the side of a ...' Very ugly.
I think that interprocess communication is going to be very important
in the future, but boy do I want one general way of doing it! Not
hundreds. And I do not know the best way to do it. A friend and I ...
no, lets be fair, Geoff Collyer came up with this, i just helped criticise
it until it came into its present form... came up with a rather elegant
and simple way to put semaphores into any unix kernel. (we think. there
hasn't been time to test it, alas.) But if it does not get used by
the people at Berkeley and Bell and HP and DEC and whereever else
unix development work is being done then it is just a local kludge,
even if it is more elegant and pleasing than the official solutions.
And all local software that uses it will be an albatross on somebody's
neck in the future, something i would not like to inflict on anyone.
laura creighton
utzoo!utcsstat!laura
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site wivax.UUCP
Path: utzoo!linus!wivax!dyer
From: d...@wivax.UUCP (Stephen Dyer)
Newsgroups: net.unix-wizards
Subject: Re: Unix philosophy--semaphores, message passing
Message-ID: <18677@wivax.UUCP>
Date: Sat, 17-Sep-83 18:09:32 EDT
Article-I.D.: wivax.18677
Posted: Sat Sep 17 18:09:32 1983
Date-Received: Sun, 18-Sep-83 04:59:21 EDT
References: <4897@sri-arpa.UUCP> <1029@utcsstat.UUCP>, <2540@umcp-cs.UUCP>
<1052@utcsstat.UUCP>, <2605@umcp-cs.URe: Unix philosophy
Organization: Wang Institute, Tyngsboro, Ma. 10879
Lines: 9
Note that UNIX System V has semaphores, message passing, and shared
memory implemented as system call primitives. We have just received
our tapes and are wading through the masses of documentation, so I
can't yet judge the facilities critically. Still, it seems that if
there is anything resembling a "standard" this is (will be) it.
/Steve Dyer
decvax!wivax!dyer
sdyer@bbn-unix
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site csd1.UUCP
Path: utzoo!linus!decvax!harpo!floyd!cmcl2!csd1!condict
From: cond...@csd1.UUCP (Michael Condict)
Newsgroups: net.unix-wizards
Subject: Re: Unix philosophy
Message-ID: <117@csd1.UUCP>
Date: Sun, 18-Sep-83 16:40:07 EDT
Article-I.D.: csd1.117
Posted: Sun Sep 18 16:40:07 1983
Date-Received: Mon, 19-Sep-83 00:54:18 EDT
References: <1075@utcsstat.UUCP>
Organization: New York University
Lines: 50
I'm no expert on the requirements and applications of interprocess
communication (IPC) but I do know that any reasonable definition of what
constitutes an IPC mechanism would include the now widely acclaimed Unix
pipeline. Therefore it depresses, even saddens, me to hear so many people
talk about ways to do IPC in Unix without any discussion of pipelines (except
to immediately dismiss them as too weak). If there are any remaining adherents
of the original Unix philosophy of Parsimony and Elegance in Design out there
besides me, please make your voices heard! Surely there must be a reasonably
simple way to remove the heredity constraints on pipelines, so that arbitrary
processes can connect to and disconnect from one another, and an upward-
compatible way to add the necessary concurrent processing features to pipelines
(do we need more than a few things like mutually-exclusive read/write access,
flexible permission codes and the ability to find out the number of processes
that have a pipe open or the number of unread bytes sitting in a pipe?).
If we really cannot generalize the pipeline construct adequately, then let us
at least have the courage to throw it away, and replace it with your new-fangled
IPC system. But please, please let us not allow Unix to grow fat and ugly,
but rather taller and more powerful. No matter what gross iniquities are
done to it in the name of progress, Unix will be around to help or haunt us
for many years. It has become the FORTRAN of operating systems with respect
to the number of different processors it runs on, the variety of tasks
to which it is applied and (because of the former two) its longevity. We need
to be very careful that we do not let the analogy extend any further than this.
Michael Condict ...!cmcl2!csd1!condict
Courant Inst., New York U.
P.S. Here's a concrete proposal (someone must have already thought of this).
Why not let pipelines have names that appear in the file system as a new kind
of directory entry in addition to files and directories. Then they can
live and die independently of processes and any process that knows the name
of a pipeline and has the right permission can read or write to it. This is
the VMS approach, with its mailbox devices, which are nothing more than a
generalized pipeline of the sort I'm proposing (actually it's less, because
the VMS designers forgot to make these mailboxes accessible at the command
level for connecting processes together easily, but that does not argue against
the utility of mailbox devices as an IPC). Of course we would preserve the
current behavior of pipes with respect to shells creating them automatically
upon seeing "|" in a command; only the explanation of what goes on internally
would change. Actually, this proposal simply amounts to having a new kind of
file, in which things are deleted as they are read and which is inherently
sequential (seek is not allowed). Of course we would expect the kernel to go
out of its way to store most or all of this kind of file in main storage, for
efficient access. As for the concurrent processing features, like mutual
exclusion, we can benefit from having these features available for pipes, files
and devices alike, so there is no particular reason to associate them only
with pipes.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rlgvax!guy
From: g...@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Unix philosophy
Message-ID: <1171@rlgvax.UUCP>
Date: Mon, 19-Sep-83 02:09:26 EDT
Article-I.D.: rlgvax.1171
Posted: Mon Sep 19 02:09:26 1983
Date-Received: Mon, 19-Sep-83 08:51:46 EDT
References: <1075@utcsstat.UUCP>, <117@csd1.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 68
In reply to several points on interprocess communication:
But sometimes the kernel must be changed, because there are certain
things that one just can't do in a subroutine library (although
it is amazing to me that Newcastle implemented a fully distributed
file system better than Sun's 4.2 without touching the kernel).
The best example is interprocess communication.
4.2BSD already has what seems to be a fairly decent IPC mechanism, with its
sockets.
everybody and his dog seems to have their own way of dealing with
interprocess communication. these days, I think that tunis is
maybe the way to go. interrupts are converted to messages, and
there is message handling in the kernel. Unfortunately, this is
not unix. It is too bad that interprocess communication was a very
new idea when Dennis Ritchie and Ken Thompson were designing the
first unix.
I'm not sure it was really that new an idea; several real-time minicomputer
operating systems had message send/receive facilities in the mid '70's.
Unfortunately it is true, though, that we have a proliferation of IPC
facilities. I suspect the 4.2BSD and USG 5.0 mechanisms can be twisted enough
to be based on one common system if someone wants to work hard enough (start
by taking the 4.2BSD system, add a new domain where the socket address is the
32-bit unique identifier used by 5.0, and add in whatever stuff is needed to
support the 5.0 facilities. The 5.0 system is based on an "IPC descriptor"
which is like a file descriptor, sort of, so the 4.2BSD descriptors may be
usable here.).
I'm no expert on the requirements and applications of interprocess
communication (IPC) but I do know that any reasonable definition of
what constitutes an IPC mechanism would include the now widely acclaimed Unix
pipeline. Therefore it depresses, even saddens, me to hear so many
people talk about ways to do IPC in Unix without any discussion of
pipelines (except to immediately dismiss them as too weak).
P.S. Here's a concrete proposal (someone must have already thought of
this). Why not let pipelines have names that appear in the file system
as a new kind of directory entry in addition to files and directories.
Then they can live and die independently of processes and any process
that knows the name of a pipeline and has the right permission can read
or write to it.
Somebody did think of that; System III and later USG releases of UNIX implement
pipes as a new type of inode - a "fifo". A pipe is just a fifo made up on the
fly with no directory entry pointing to it. You connect to a fifo by opening
it like a regular file.
However, the inability for unrelated processes to use pre-S3 pipes isn't pipes'
only problem. They cannot function in a record-oriented (i.e., message-
oriented) fashion; any record separators or lengths must be provided by the
process writing to the fifo. This means a malicious or deranged process can
foul up everybody else by writing an incomplete record to the fifo; I don't
know whether there's a protocol which guarantees this won't happen, but even
if it does exist it would probably add overhead. Furthermore, multiplexing
several communications over a fifo is difficult.
4.2BSD took the opposite tack from generalizing pipes. They added a new IPC
mechanism and implemented pipes as a special case of it.
The System V message queues are different beasts from pipes entirely. They
are message-oriented (rather than stream-oriented) and support multiple readers
and writers (you can put a "tag" on a message when you send it and can ask for
only messages with certain tags when you receive a message from a queue).
Guy Harris
{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!tektronix!ogcvax!omsvax!hplabs!sri-unix!gwyn@brl-vld
From: gwyn%brl-...@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Unix philosophy
Message-ID: <11817@sri-arpa.UUCP>
Date: Mon, 19-Sep-83 13:52:11 EDT
Article-I.D.: sri-arpa.11817
Posted: Mon Sep 19 13:52:11 1983
Date-Received: Fri, 23-Sep-83 23:12:07 EDT
Lines: 10
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld>
Bell UNIX (System V) does include IPC in the form of semaphores,
shared memory, and message passing. Berkeley UNIX (4.2BSD) includes
sockets. The problem I see is that no one known form of IPC or
process synchronization mechanism is best for all applications.
A "semaphore" device driver was distributed long ago on a USENIX
tape; this seems like the simplest semi-portable addition one could
make to a deficient UNIX in order to give it semaphores.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!gwyn@brl-vld
From: gwyn@brl-...@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Unix philosophy
Message-ID: <11915@sri-arpa.UUCP>
Date: Wed, 21-Sep-83 16:28:33 EDT
Article-I.D.: sri-arpa.11915
Posted: Wed Sep 21 16:28:33 1983
Date-Received: Mon, 26-Sep-83 08:15:57 EDT
Lines: 19
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld>
The important thing about pipes is that for ordinary purposes a process
does not have to be concerned whether a file descriptor it is using is
attached to a file, a pipe, or a special file (device). This is not
true of many other IPC schemes.
Another nice thing about pipes is that they are file system entities,
so fstat() works on them. However, 4.1cBSD (and I am told 4.2BSD)
changed pipes to be socket pairs and return a bogus (struct stat) on
pipes. This needs to be fixed, at least to the extent that (device,
inode) is unique for each pipe.
I actually liked pipes that were genuinely part of the file system;
named pipes (FIFOs) and pipes are integrated into UNIX System III and V
very cleanly. It would seem that with good block buffer handling this
would still be a good scheme even in the presence of other IPC
mechanisms. I think Berkeley had in mind piping between processes on
separate CPUs when they changed to socket pairs.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!wert.rice@rand-relay
From: wert.rice@rand-re...@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Your flame about Unix philosophy...right on target.
Message-ID: <11957@sri-arpa.UUCP>
Date: Thu, 22-Sep-83 11:32:12 EDT
Article-I.D.: sri-arpa.11957
Posted: Thu Sep 22 11:32:12 1983
Date-Received: Tue, 27-Sep-83 02:19:35 EDT
Lines: 29
From: Scott Comer <wert.rice@rand-relay>
Hear now, what are you complaining about? Don't you enjoy using a system
that is buggy, flaky, and downright unreliable? Doesn't your heart just
go pitty-pat at the prospect of digging into the kernel code for the
answer to yet another annoying "problem" (read that as Undocumented
Feature and/or Restriction)?
I find it strange that Unix is the computer scientists system, but
its design philosophy flys in the face of most of the time-honored
rules of software design, implementation, and documentation. We
daily commit the sin of not practicing what we preach, by telling
our beginning computer science students about the virtues of
structured design and the importance of good data structures, while
forcing them to use a system that is held together only by the
considerable efforts of 3 systems programmers and lots of bubble
gum and bailing wire.
I realize this is heresy to say things like this. You'll probably point
out that I wouldn't have even be able to read your message if it wasn't
for fine Unix software. On the other hand, I will point out that many
systems are capable of Unix-like functionality, except that they are
lacking a certain sexy user interface. On the other hand, they are
reliable, well documented, maintainable, and supported. By a responsive
and responsible group of people. THEY answer their telephone, which is
more than I can say for Berkeley.
How long is this community going to put up with this utter piece of
software trash?
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!tektronix!ogcvax!omsvax!hplabs!sri-unix!edhall@rand-unix
From: edhall%rand-u...@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Your flame about Unix philosophy...right on target.
Message-ID: <11984@sri-arpa.UUCP>
Date: Thu, 29-Sep-83 02:56:00 EDT
Article-I.D.: sri-arpa.11984
Posted: Thu Sep 29 02:56:00 1983
Date-Received: Wed, 28-Sep-83 19:54:22 EDT
Lines: 61
I quote from your letter:
>> I realize this is heresy to say things like this. You'll probably point
>> out that I wouldn't have even be able to read your message if it wasn't
>> for fine Unix software. On the other hand, I will point out that many
>> systems are capable of Unix-like functionality, except that they are
>> lacking a certain sexy user interface. On the other hand, they are
>> reliable, well documented, maintainable, and supported. By a responsive
>> and responsible group of people. THEY answer their telephone, which is
>> more than I can say for Berkeley.
>>
>> How long is this community going to put up with this utter piece of
>> software trash?
My first reaction is to ask you why in the world you wish to make such
complaints in `Unix-Wizards'? Seems a bit out of place, no?
It's a bit late, and your miasmal letter just rubbed me the wrong way.
I'm still trying to figure out if you merely want to vent your spleen
over something--anything--or if you really do have some valid criticisms.
In the former case, I guess it's better than kicking the dog. But if
you really feel that UNIX is so very, very bad that it mystifies you
as to how any sentient being can tolerate it, let's hear some specifics.
Here is a list of questions for you:
1) Is the UNIX software really that unreliable compared to other systems?
1a) Which systems are better?
(Your experience here seems atypical--I've seen 4.1BSD systems run for
weeks, even months, continuously without breakdown or problem.)
1b) What are some of these bugs that have bitten you so bad?
2) Is UNIX *that* unstructured?
2a) What do you mean by `structured'?
2b) Which systems are better structured?
3) Is the UNIX documentation so incredibly worse than other systems?
3a) Which other systems?
4) Did you really expect Berkeley to provide free consulting?
4a) What vendors/systems provide such free consulting?
(If you have a System III/V -flavored UNIX you can pay for full support
from AT&T. Other consulting firms support BSD UNIX. Berkeley is a
University, not a software vendor/consultant.)
...and so on and so forth. Constructive criticism is appreciated more
than the other kind. I'll leave it to others to answer you point-by-
point, if they find anything more than innuendo. I don't have the time.
-Ed Hall
edhall@rand-unix
decvax!randvax!edhall
|