Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!research!dmr
From: d...@research.UUCP
Newsgroups: net.unix
Subject: Marketing Unix
Message-ID: <1034@research.UUCP>
Date: Sat, 30-Jun-84 03:07:15 EDT
Article-I.D.: research.1034
Posted: Sat Jun 30 03:07:15 1984
Date-Received: Sun, 1-Jul-84 06:38:24 EDT
Lines: 28
Remarks are already rolling in on the LA Times article quoted by Will
Martin; here's a reaction from one who observed the process.
1) It's a fact that fees for universities for all licenses through 32V
(and thus through 4.2BSD) are negligible, and though lawyers and pedants may
cringe at the phrase "give away thousands of copies ... to students"
this was the effect. System III and V educational licenses are a lot more,
but still, I think, pretty cheap. "Dozens" of universities understates;
"hundreds" is more accurate.
2) There can be little quarrel with the assertion that this licensing
policy was essential to the market success of Unix.
3) To suggest that the popularity of Unix (let's ignore the past year
or so when national ads began to appear) owes to clever
marketing is sheer lunacy. Imagine the fate of the hot young marketeer
who advises "Well, let's test it for 8 years in the universities at
below-cost prices. Think of the brand loyalty we'll build."
The fact is that we had to fight every step of the way to get Unix
out the door. The usual argument against each release was: if this
stuff is really good, our competitors (yes, AT&T saw competitors even
well before divestiture) will take it and use it against us!
As it happened, the sensible people mostly won. However, any resemblance
between the actual process and what is commonly thought of as marketing
is distinctly coincidental.
Dennis Ritchie
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!dual!fair
From: f...@dual.UUCP (Erik E. Fair)
Newsgroups: net.unix
Subject: Re: Marketing Unix
Message-ID: <651@dual.UUCP>
Date: Thu, 5-Jul-84 20:04:08 EDT
Article-I.D.: dual.651
Posted: Thu Jul 5 20:04:08 1984
Date-Received: Sat, 7-Jul-84 00:36:56 EDT
References: <1034@research.UUCP>
Organization: Dual Systems, Berkeley, CA
Lines: 15
I'm waiting for the collective screams of those estimated 150,000
professionals and programmers when they realize that System V on
[insert random machine] isn't as good as 4.1/4.2 BSD on their alma
mater's vaxen...
``What do you mean, ^Z and ^W don't work here?
Why doesn't this UNIX act like the VAX at Podunk U?''
Wow! I coulda had a V8!
Erik E. Fair ucbvax!fair f...@ucb-arpa.ARPA
dual!f...@Berkeley.ARPA
{ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair
Dual Systems Corporation, Berkeley, California
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site pegasus.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!pegasus!cmf
From: c...@pegasus.UUCP (Chuck M. Fingerman)
Newsgroups: net.unix
Subject: Re: Re: marketing unix
Message-ID: <1475@pegasus.UUCP>
Date: Tue, 10-Jul-84 09:04:23 EDT
Article-I.D.: pegasus.1475
Posted: Tue Jul 10 09:04:23 1984
Date-Received: Wed, 11-Jul-84 00:54:51 EDT
Organization: AT&T Information Systems, Lincroft NJ
Lines: 8
TO Erik E Fair,
I have not personally used BSD unix so I can't make any speed claims,
BUT how upward compatable is 4.1 to 4.2??
All AT&T BTL Unix's are upward compatable.
Chuck Fingerman
pegasus!cmf
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 beta 4/12/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!houxz!vax135!cornell!
uw-beaver!tektronix!hplabs!hao!seismo!rlgvax!guy
From: g...@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix
Subject: Re: Re: marketing unix
Message-ID: <2098@rlgvax.UUCP>
Date: Wed, 11-Jul-84 22:33:50 EDT
Article-I.D.: rlgvax.2098
Posted: Wed Jul 11 22:33:50 1984
Date-Received: Sat, 14-Jul-84 01:30:22 EDT
References: <1475@pegasus.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 77
> TO Erik E Fair,
> I have not personally used BSD unix so I can't make any speed claims,
> BUT how upward compatable is 4.1 to 4.2??
> All AT&T BTL Unix's are upward compatable.
I presume you're referring to the article which read
> I'm waiting for the collective screams of those estimated 150,000
> professionals and programmers when they realize that System V on
> [insert random machine] isn't as good as 4.1/4.2 BSD on their alma
> mater's vaxen...
> ``What do you mean, ^Z and ^W don't work here?
> Why doesn't this UNIX act like the VAX at Podunk U?''
(although there was no "References:" line in your article, and you didn't
bother including any relevant text from the article you were replying to -
as was done above), but "isn't as good as" refers to several things here:
1) BSD UNIX supports the VAX-11 hardware far better than System V. For
one thing, it correctly handles Translation Not Valid faults. The OS isn't
supposed to panic when that happens, it's supposed to fetch the missing
page from the disk. There are applications out there that *need* virtual
memory (or, at least, run better with it than without it).
2) BSD UNIX supports most of the (conventional) devices that can be attached
to a VAX-11, even those that the BTL UNIX developers don't like. Furthermore,
it supports more {Uni|Mass}bus adaptor/device configurations than System III
did (S3 was particularly dismal in this); S5 may actually realize that a
user may want to have more than two MBAs and put some disks on one and some
on another, or have two UBAs, or... but S3 sure didn't.
3) BSD UNIX's terminal driver has a superior user interface than do any
of the BTL UNIXes (including V7) - the point made in the quote above. Why
can't System V properly erase tab characters in ECHOE mode? Furthermore,
the System V Release 2 "job control" mechanism is inadequate, because 1)
there's no way to notify a program that does "funny things" to the terminal
(screen editing, putting it in graphics mode, putting the keypad in application
mode, etc.) that it's having control of the terminal taken away from it (so
it can clear the screen, or put the terminal back in a "standard" mode that
the program to whom the terminal is being given can use it) or that it's
getting control of the terminal returned to it (so that it can redraw the
screen or put the terminal back into the mode it was in when it left) and 2)
there's no way to stop a job - all you can do is take the terminal away from
it. It'd occasionally be useful to stop a job, examine it or correct an error,
and restart it - which the BSD job control mechanism lets you do.
4) 4.2BSD UNIX supports networking sensibly. System V doesn't. And if the
USDL people are as Berkeleyphobic as it has been claimed they are, System V
isn't likely to in the near future. The Berkeley networking implementation
*works*, and at least seems well designed for supporting multiple protocols
(which is going to be a necessity for the forseeable future).
5) In some ways, 4.2BSD has better administrative facilities than System V.
The auto-reboot stuff and "fsck -p" for preening file systems is nice, and the
disk quota mechanism will come in very handy for some sites, to name two
examples.
I also think there are some things that System V does better. The System III/
System V "open" and "fcntl" calls are nice; so did Berkeley, as they adopted
them for 4.2BSD. The shared memory is useful, although Berkeley plans to add
it at some point. I personally prefer the System V "init" because it's more
flexible than the old-style "init" (it's nice to be able to control arbitrary
daemons from "init", and it's nice not to have to run "getty" as the login
program on every terminal). The added functionality in the libraries and some
of the commands are useful. "Terminfo" and Mark Horton's new "terminfo"-based
"curses" are supposed to be superior to "termcap" and the earlier "curses".
So how about declaring a truce, and both sides picking up the good ideas from
each other? (Or developing a system which picks up the best of both worlds.)
These sort of debates can be fun, just like the UNIX vs. VMS debates, but
adopting the good ideas from other systems is generally more productive than
playing NIH games and defending your favorite system when right and when wrong.
(Are you listening, USDL?)
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site sftig.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!mhuxm!sfjec!sfmag!sftig!jpl
From: j...@sftig.UUCP
Newsgroups: net.unix
Subject: Re: Re: marketing unix
Message-ID: <441@sftig.UUCP>
Date: Mon, 16-Jul-84 09:35:45 EDT
Article-I.D.: sftig.441
Posted: Mon Jul 16 09:35:45 1984
Date-Received: Tue, 17-Jul-84 01:46:58 EDT
References: <1475@pegasus.UUCP>, <2098@rlgvax.UUCP>
Organization: AT&T Bell Laboratories, Summit, NJ
Lines: 17
"Paging Mr. Harris, paging Mr. Harris, please come down to earth."
Readers will recall from the last referenced article that one of
Guy's major point's was that adopting other people's ideas is a
useful and sensible thing to do. Quite so. However, this
entails evaluating the ideas and the particular instantiation
of those ideas, and not just swallowing them whole.
Also, in future, when Mr. Harris plays the Great Reconciler,
will he please refrain from baiting USDL (? Unix System Development Lab ?)
members? They are certainly NOT -- what was the phrase? -- Berkeleyphobics.
Au contrair, they generally seem capable of building on the best ideas
for UNIX enhancements, whether originated at UCB or other universities,
internal or external research labs, or even the occaisional original
idea.
jeff lankford sftig!jpl
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix
Subject: Re: Re: marketing unix
Message-ID: <4103@utzoo.UUCP>
Date: Tue, 17-Jul-84 15:56:02 EDT
Article-I.D.: utzoo.4103
Posted: Tue Jul 17 15:56:02 1984
Date-Received: Tue, 17-Jul-84 15:56:02 EDT
References: <1475@pegasus.UUCP>, <2098@rlgvax.UUCP>
Organization: U of Toronto Zoology
Lines: 89
In response to (some of) Guy Harris's comments:
> 1) BSD UNIX supports the VAX-11 hardware far better than System V. For
> one thing, it correctly handles Translation Not Valid faults. The OS isn't
> supposed to panic when that happens, it's supposed to fetch the missing
> page from the disk. There are applications out there that *need* virtual
> memory (or, at least, run better with it than without it).
Although AT&T still has not gotten its finger out and added virtual memory
to System V, other people have. The HCR people, in particular, gave a nice
presentation about it at Usenix. They pointed out that virtual memory, done
*right*, is nowhere near as complex as that awful mess inside 4.xBSD.
> 2) BSD UNIX supports most of the (conventional) devices that can be attached
> to a VAX-11, even those that the BTL UNIX developers don't like. Furthermore,
> it supports more {Uni|Mass}bus adaptor/device configurations than System III
> did (S3 was particularly dismal in this); S5 may actually realize that a
> user may want to have more than two MBAs and put some disks on one and some
> on another, or have two UBAs, or... but S3 sure didn't.
Berkeley is still guilty of being parochial about device support, although
I admit they aren't nearly as bad about it as AT&T. Even in 4.2, one can
find drivers marked "never tested, beware", which probably means that they
don't work. Claims to support device X should not be taken at face value.
> 3) BSD UNIX's terminal driver has a superior user interface than do any
> of the BTL UNIXes ...
Oh really? I'm sure the people at Research snickered about this. Real
windows are about 10000% better than Berkeley's awful "job control".
(This is not to say that the folks at AT&T have done much better; neither
4.2 job control and V.2 layers is a real window system, even though that's
what is *really* wanted.)
> the System V Release 2 "job control" mechanism is inadequate, because 1)
> there's no way to notify a program that does "funny things" to the terminal
> (screen editing, putting it in graphics mode, putting the keypad in application
> mode, etc.) that it's having control of the terminal taken away from it (so
> it can clear the screen, or put the terminal back in a "standard" mode that
> the program to whom the terminal is being given can use it) or that it's
> getting control of the terminal returned to it (so that it can redraw the
> screen or put the terminal back into the mode it was in when it left) ...
Programs should not have to know these things, ever. The right way to do
disciplined interaction with multiple processes (which is what it's all
about, folks) is that the programs should never have to know *any* of
this stuff, any more than an ordinary program has to know whether it's
printfing to a pipe or a disk file. The multiplexing of user interaction
should be a centralized function, not something that's distributed over
every program that ever expects to participate in it!
Yes, this means that screen redraw has to be centralized. This is the
key item that AT&T missed. No credit to Berkeley, though, since they
botched it much more badly.
> there's no way to stop a job - all you can do is take the terminal away from
> it. It'd occasionally be useful to stop a job, examine it or correct an error,
> and restart it - which the BSD job control mechanism lets you do.
Adding suspension and restart to a Unix kernel should be a one-hour hack,
if you don't get it confused with multiplexing/windows/job-control/whatever.
Doing it right would also fix some of the dreadful botches in the BSD stuff,
like being able to suspend, say, passwd(1) in the middle of an /etc/passwd
update.
> 4) 4.2BSD UNIX supports networking sensibly. System V doesn't. ...
"Supports networking", yes. "Sensibly", well... Many people have, uh,
strong opinions on that subject. The lack of networking support in
System V is definitely a defect, but emulating 4.2 is not necessarily
the way to go.
> So how about declaring a truce, and both sides picking up the good ideas from
> each other? (Or developing a system which picks up the best of both worlds.)
> These sort of debates can be fun, just like the UNIX vs. VMS debates, but
> adopting the good ideas from other systems is generally more productive than
> playing NIH games and defending your favorite system when right and when wrong.
Dumping the *bad* ideas from each is at least as important as picking up the
good ideas, and I see no sign that anyone is prepared to do that. The AT&T
people seem bent on the "lots more features, union of all possible wishlists"
approach to Unix development. And Berkeley's claim to fame seems to be
based on quantity of new ideas rather than quality. "4.2BSD does everything
UNIX does, only differently."
I want V8.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!dual!fair
From: f...@dual.UUCP (Erik E. Fair)
Newsgroups: net.unix
Subject: Re: Re: marketing unix
Message-ID: <697@dual.UUCP>
Date: Thu, 19-Jul-84 22:12:09 EDT
Article-I.D.: dual.697
Posted: Thu Jul 19 22:12:09 1984
Date-Received: Fri, 20-Jul-84 07:27:24 EDT
References: <1475@pegasus.UUCP>, <2098@rlgvax.UUCP> <441@sftig.UUCP>
Organization: Dual Systems, Berkeley, CA
Lines: 65
After being quoted so widely (and defended very well; Thanks Guy & friends),
I feel somewhat obligated to respond. Guy Harris expanded on my terse jab
eloquently, but the following pokes a *very* sore spot:
>> From: j...@sftig.UUCP
>> Date: Mon, 16-Jul-84 06:35:45 PDT
>> Organization: AT&T Bell Laboratories, Summit, NJ
>>
>> "Paging Mr. Harris, paging Mr. Harris, please come down to earth."
>>
>> Readers will recall from the last referenced article that one of
>> Guy's major point's was that adopting other people's ideas is a
>> useful and sensible thing to do. Quite so. However, this
>> entails evaluating the ideas and the particular instantiation
>> of those ideas, and not just swallowing them whole.
>>
>> Also, in future, when Mr. Harris plays the Great Reconciler,
>> will he please refrain from baiting USDL (? Unix System Development Lab ?)
>> members? They are certainly NOT -- what was the phrase? -- Berkeleyphobics.
>> Au contrair, they generally seem capable of building on the best ideas
>> for UNIX enhancements, whether originated at UCB or other universities,
>> internal or external research labs, or even the occaisional original
>> idea.
>>
>> jeff lankford sftig!jpl
Mr. Lankford,
I have seen more evidence of an epidemic class case of
the famous ``Not-Invented-Here'' syndrome in the people who bring us
System V than any other. I have never met anyone (at least not
knowingly) who works for USG/USDL/(whatever-they're-calling-it-this-week)
but I read their C code both in the Kernel and in the utilities. It is
sloppy. It is in some cases unportable (a very important thing where I
work; we do UNIX on a 68000, not a VAX or a 3B20). It does not often
pass lint unscathed. But worst of all, it reflects a disturbing
thing: that these people don't know how to complete something
properly (e.g. the System III/V tty driver changes from V7: they
changed the kernel, but they didn't do a complete conversion of the
utilities, so they left a horrid compatability hack for stty(2) and
gtty(2) in the kernel & C library, which didn't always work.
Fercrissakes, ``getty'' still had stty/gtty calls in it!)
I'm terribly afraid that AT&T is turning into IBM in the sense that they
do backward compatability forever, and are terrified of fixing anything
that is broken, just because it has always behaved that way. I cite the
4.2 BSD signal mechanism (although the implementation is messier) is the
*right* way to do signals, and they should have been done that way in the
first place. I very much doubt that USG/USDL will ever try to fix it. I
echo the doubt of others that System V will ever do networking decently.
Will they ever fix the filesystem? (and so on...)
And if they're not Berkeleyphobic, then why don't System V VAXEN page?
They've had three years to evaluate it...
(flame off!)
Erik E. Fair ucbvax!fair f...@ucb-arpa.ARPA
dual!f...@BERKELEY.ARPA
{ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair
Dual Systems Corporation, Berkeley, California
P.S. I wish I could see the look on their faces when IBM announces 4.2BSD
for their entire line of computers...
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site sftig.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!mhuxm!sfjec!sfmag!sftig!jpl
From: j...@sftig.UUCP
Newsgroups: net.unix
Subject: Re: Re: marketing unix
Message-ID: <442@sftig.UUCP>
Date: Fri, 20-Jul-84 14:29:55 EDT
Article-I.D.: sftig.442
Posted: Fri Jul 20 14:29:55 1984
Date-Received: Sat, 21-Jul-84 04:07:31 EDT
References: <1475@pegasus.UUCP>, <2098@rlgvax.UUCP> <441@sftig.UUCP>
<697@dual.UUCP>
Organization: AT&T Bell Laboratories, Summit, NJ
Lines: 29
Although this may be just adding more tempest to the teapot, i feel
obliged to respond to Eric'c article. I hope to avoid covering old ground.
Why doesn't Brand X have option Y?
This seems to have something to do with economics
(I'll have to tread lightly here, as i'm no expert).
The advantages and disadvantages of providing and supporting
option Y are weighed in economic terms and a decision is then
made (or should be). Additional factors come into play as well
(should option Y' from brand Z be borrowed directly, should
it be "improved", how long will it take, etc).
These are all business decisions.
The folks of CSRG at UCB don't do business,
they do technical research.
AT&T is in business for profit;
hence, business decisions are therefore
likely to be more marketing oriented,
and probably somewhat less technically oriented.
The distiction between business and technical decisions
is not always as clear as i have implied
(perhaps we are talking at cross-purposes?)
Apologies to Guy; apparently it was someone else who was lost in space.
jeff lankford sftig!jpl
PS. As for inefficient code, well it appears about anywhere
one may care to look, doesn't it?
PPS. Perhaps we should move on to a less "religious" issue?
Have we flogged this subject sufficiently?