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!jeff
From: j...@rlgvax.UUCP (Jeffrey Kegler)
Newsgroups: net.lang.c
Subject: strncpy()
Message-ID: <1020@rlgvax.UUCP>
Date: Fri, 19-Aug-83 13:10:54 EDT
Article-I.D.: rlgvax.1020
Posted: Fri Aug 19 13:10:54 1983
Date-Received: Fri, 19-Aug-83 17:01:54 EDT
Organization: CCI Office Systems Group, Reston, VA
Lines: 74
As most of you know, the UNIX philosophy is to have everything have
explicit terminators, instead of being terminated by counts.
In strcpy() this has raised the complaint that a slight error in an
argument to strcpy() can result is destruction of a considerable amount
of data. This could happen when the string to be copied is not
properly terminated, or is a bad pointer, or is just overlong. One can
say that it is really up to the programmer to check for these things.
Another part of the UNIX philosophy is, wherever something might be
seen as either a protection or a restriction of the programmer,
depending on point of view, to assume it is a restriction.
For those of us who do desire to be protected from our own lapses,
especially when these lapses may lead to a core with its stack
destroyed, strncpy() exists. It takes a third argument which gives an
explicit maximum length to the string. However, for some strange
reason, it still does not guarantee its result will be null terminated
if it is overlong. Instead it puts characters right up into the last
permitted location. Always writing
strncpy(string1, string2, n);
string1[n] = '\0';
solves the problem, but whenever I see this in code, I wonder why
UNIX's string copy of explicitly n characters does not always result in
a string of n characters.
Further, it always copies a string of the length specified, adding
nulls once the source string has been terminated. I can think of
situations where this is useful, but one has never occurred to me, and
far more often I wind up copying a string whose maximum length is 5000
and whose average length is 10. So as a byproduct of this feature, I
would get an average of 4990 extra trips through the loop.
Finally, strncpy() is far less efficient than it could be. Its main
loop maintains and updates both a string pointer and a count, and each
character copied requires a comparison to n, which is not is a
register. I would get more into its behavior, but I do not know if the
code is public domain, unlike strcpy(), 4 versions of which are in K&R
on pages 100-101.
Below is the code for my rewrite of strncpy(), which never accesses
anything except a register in its main loop (if your compiler supports
this sort of thing), has a main loop one instruction shorter on the VAX
(all claims are for code generated by the C optimizer), guarantees the
copied string will be a legal string, even where the original was not,
and does no copying beyond the end-of-string. The main efficiency
improvement does not depend on my changes from the behavior of
strncpy(), and scpy() could be rewritten to simulate strncpy()
exactly.
===========================
/*
* Copy a string in a fail-safe manner.
*/
void
scpy(s1,s2,n)
register char *s1,*s2;
{
register char *eos = s1+n-1;
while(*s1++ = *s2++)
if (s1 >= eos) {
*eos = '\0';
return;
}
}
==============================
One could argue that the above is not as fail-safe as it should be, because
if n is zero or negative, the byte before s1 is zeroed, and a check for
such an n could be placed before the main loop.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site whuxlb.UUCP
Path: utzoo!linus!decvax!harpo!gummo!whuxlb!mash
From: m...@whuxlb.UUCP (John Mashey)
Newsgroups: net.lang.c
Subject: Re: strncpy()
Message-ID: <1283@whuxlb.UUCP>
Date: Sat, 20-Aug-83 08:05:17 EDT
Article-I.D.: whuxlb.1283
Posted: Sat Aug 20 08:05:17 1983
Date-Received: Sat, 20-Aug-83 10:20:06 EDT
Organization: Bell Labs, Whippany
Lines: 7
strcpyn() (before it was renamed strncpy(), was originally
written specifically t odeal with directories, accouting records,
and various other places in UNIX that expect fixed-length fields
containing varaible length strings padded with nulls.
There used to be numerous instances of slightly different code to
do the strncpy/strncmp functions in-line.
-mashey
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!philabs!seismo!rlgvax!jack
From: j...@rlgvax.UUCP (Jack Waugh)
Newsgroups: net.flame
Subject: Re: Unix philosophy (from net.unix-wizards)
Message-ID: <1156@rlgvax.UUCP>
Date: Tue, 13-Sep-83 11:06:12 EDT
Article-I.D.: rlgvax.1156
Posted: Tue Sep 13 11:06:12 1983
Date-Received: Tue, 13-Sep-83 23:09:59 EDT
References: <2540@umcp-cs.UUCP>
Organization: Computer Consoles
Lines: 16
Let's write portable code, and leave the kernel alone.
That way, the benefits of writing a program will be
multiplied by a higher number of systems that can run
the program.
Some of us out here in the commercial world have to write code and
transport it to many UNIX and UNIX-like systems. Often, neither we
nor the customer can get hold of the kernel source. This situation
is bound to continue, i. e., there will be plenty of binary licenses
sold. The only way the industry can reliably supply programs for
such systems is if these systems follow some well-known standard, such
as the Seventh Edition UNIX Programmer's Manual, or the UNIX User's
Manual Release 3.0, and for developers to write their programs under
a kernel that also follows one of those well-known standards.
Jack Waugh
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>
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!duke!unc!mcnc!idis!mi-cec!dvk
From: dvk@mi-cec.UUCP (Dan Klein)
Newsgroups: net.unix-wizards
Subject: Unix IPC
Message-ID: <154@mi-cec.UUCP>
Date: Mon, 19-Sep-83 11:16:59 EDT
Article-I.D.: mi-cec.154
Posted: Mon Sep 19 11:16:59 1983
Date-Received: Mon, 19-Sep-83 22:30:24 EDT
Lines: 15
Clearly, the signalling mechanism currently in Unix is far from optimal
for anything other than the most simpleminded IPC. The mailbox approach
is reasonable, but tricky, since you need to have a way of passing the
names of the mailbox (for which you need IPC already), or just making it
an open file which gets transferred via exec.
There is one advantage to signals which cannot be overlooked in this
discussion: they have the ability to interrupt you. Pipes do not. Perhaps
having a VMS style AST to interrupt you on file/terminal activity is the
way to go. This way you get notice when a communicating process has something
to say, or you can simply poll things. This makes useful programs (like
multi-player interactive games) easy to write. They just do their real-time
things until the player changes some state by issuing a command.
(Sorry for the stream of consciousness...)
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!decvax!tektronix!tekmdp!bronze!stevesu
From: stevesu@bronze.UUCP (Steve Summit)
Newsgroups: net.unix-wizards
Subject: IPC and Unix philosophy
Message-ID: <760@bronze.UUCP>
Date: Tue, 20-Sep-83 18:40:35 EDT
Article-I.D.: bronze.760
Posted: Tue Sep 20 18:40:35 1983
Date-Received: Wed, 21-Sep-83 23:13:46 EDT
References: rlgvax.1171
Lines: 37
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
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