Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!
x.Jiml%su-gsb-why.a...@BRL.ARPA
From: x.Jiml%su-gsb-why.a...@BRL.ARPA
Newsgroups: net.unix-wizards
Subject: Berkeley Flame
Message-ID: <13388@sri-arpa.UUCP>
Date: Sun, 6-Nov-83 15:55:26 EST
Article-I.D.: sri-arpa.13388
Posted: Sun Nov 6 15:55:26 1983
Date-Received: Tue, 8-Nov-83 21:24:19 EST
Lines: 19
From: Jim Lewinson <x.Jiml%su-gsb-why.a...@BRL.ARPA>
Berkeley seems to be uninterested in doing anything anymore. We tried to
get some information from them about how much it would cost us to get
4.2, but they didn't bother to return any messages left on their
answering machine.
It seems to be possible to remain in business while ignoring your current
customers (you have their money), but you tend not to make too much by
ignoring prospective customers.
Does anyone know why they are doing this??
Jim Lewinson
Codex, Inc.
(ARPA: Jiml@Score)
(UUCP: ...!Shasta!Jiml%Score (??))
-------
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!gwyn@brl-vld
From: gwyn%brl-...@sri-unix.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Berkeley Flame
Message-ID: <13390@sri-arpa.UUCP>
Date: Sun, 6-Nov-83 17:27:40 EST
Article-I.D.: sri-arpa.13390
Posted: Sun Nov 6 17:27:40 1983
Date-Received: Tue, 8-Nov-83 21:26:04 EST
Lines: 11
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld>
Berkeley has indicated a desire to get back to research instead of
a tape distribution operation. You will please note that they are
not operating as a software "company"; several commercial vendors
are now or in the near future distributing 4.?BSD-based systems.
Such vendors are in a position to offer customer support whereas
UCB is not.
You will probably hear some "official" word from UCB on this if I
have misrepresented their position.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1exp 11/4/83; site ihuxx.UUCP
Path: utzoo!linus!decvax!harpo!floyd!clyde!ihnp4!ihuxx!ignatz
From: ign...@ihuxx.UUCP (Dave Ihnat, Chicago, IL)
Newsgroups: net.unix-wizards
Subject: Re: Berkeley Flame
Message-ID: <585@ihuxx.UUCP>
Date: Tue, 8-Nov-83 19:41:14 EST
Article-I.D.: ihuxx.585
Posted: Tue Nov 8 19:41:14 1983
Date-Received: Thu, 10-Nov-83 01:28:05 EST
References: <13415@sri-arpa.UUCP>
Organization: AT&T Bell Labs, Naperville, Il
Lines: 63
Ah, ahem. I'm afraid I have an opinion on this...please note that
it's my opinion, and not that of AT&T Bell Laboratories or Analysts
International Corporation.
No, I strongly suspect that Berkeley didn't expect to go into the
software business. I doubt strongly whether that was in their mind
when they first started hacking the heck out of Unix(Tm); nor, when
they graciously agreed to sell the first copy of BSD...oh, legally, of
course, and only to legally licensed sourceholders. (I can well
imagine the academic pride in showing how nifty this mod was, or that
enhancement...we all feel it from time to time.) And I certainly
don't believe that they consciously set about to split the Unix world.
But they did. In case you haven't noticed it, there are two large,
armed camps out there in the real world. There are the USG Unix
people, clinging to the hope that some sort of standard will be
imposed on the world. And there are the BSD people, with a flavor of
Unix based on a USG release that is ancient history, which does some
interesting things, some nice things, and some not-so-nice things.
(There is a third camp--the Unix look-alike vendors--but, in general,
they attempt to emulate one of these two major products.)
Now, no one is a villain. AT&T didn't really market Unix,
actually; it's been more described as "Here are some source tapes,
some manuals, and our best wishes. Have fun!" However, as much as
was possible, the AT&T version was the standard. If something was fed
back to AT&T, it would eventually, probably, make it into the next
release of Unix in some form or another; but the informality of the
process, the time delays, and the ease of hacking Unix make the
evolution of the Berkeley system understandable. But we now have
systems with fairly different sets of utilities, kernels that
behave--and look--decidedly different in several ways, and the problem
of portable code being not-really totally portable, but hey, it's
better than assembler, right?
And it now appears that the institution that fostered one of these
major branches of the family is leaving. Where does that leave the
BSD system people? Darn if I know. Fortunately, AT&T (Actually, now
it's Western) Unix is picking up many of the features that people
found attractive in BSD, so perhaps there will be a "standard" Unix
in the future; but the legacy of the split will be with us for a long
time.
What's the point of this article? Simply that I can't defend
Berkeley's action. Not intending to do something doesn't relieve you
of responsibility for it; and while there was no *legal*
responsibility to support BSD, continued distribution out-of-house
certainly seems to impart some sort of ethical responsibility. More
importantly, I guess I'm just trying to put out a cautionary tale to
other universities, companies, groups of demented hackers in
dimly-lighted basements, or what have you: If you want to meddle in
the code, then think about what you're loosing on the world. If you
really want package XYZ to change, but don't intend/want to support
it, then fer cripes' sake, do the change in-house; tell the world
about it, if you wish, and make the vendor track your change. But
remember--it's a small world, really; and that code you modify today
on an insignificant mini operating system may be floating around in
the bowels of a Cray-I next year!
Tired of changing BSD ioctl calls,
Dave Ihnat
ihuxx!ignatz
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site decvax.UUCP
Path: utzoo!linus!decvax!aps
From: a...@decvax.UUCP (Armando P. Stettner)
Newsgroups: net.unix-wizards
Subject: Berkeley Flames and ihuxx!ignatz
Message-ID: <272@decvax.UUCP>
Date: Wed, 9-Nov-83 15:12:14 EST
Article-I.D.: decvax.272
Posted: Wed Nov 9 15:12:14 1983
Date-Received: Thu, 10-Nov-83 10:38:47 EST
Organization: DEC UNIX Engineering Group
Lines: 111
To: ihuxx!ignatz (Dave Ihnat, Chicago, IL)
Regarding: Your Article-I.D.: ihuxx.585
Ah, ahem. I'm afraid I have an opinion on this...please note that it's
my opinion, and not that of AT&T Bell Laboratories or Analysts
International Corporation.
Noted. These are my opinions and not necessarily those of DEC.
No, I strongly suspect that Berkeley didn't expect to go into the
software business. I doubt strongly whether that was in their mind
when they first started hacking the heck out of Unix(Tm); nor, when
they graciously agreed to sell the first copy of BSD...oh, legally, of
course, and only to legally licensed sourceholders. (I can well
imagine the academic pride in showing how nifty this mod was, or that
enhancement...we all feel it from time to time.) And I certainly don't
believe that they consciously set about to split the Unix world.
But they did. In case you haven't noticed it, there are two large,
armed camps out there in the real world. There are the USG Unix
people, clinging to the hope that some sort of standard will be imposed
on the world. And there are the BSD people, with a flavor of Unix
based on a USG release that is ancient history, which does some
interesting things, some nice things, and some not-so-nice things.
(There is a third camp--the Unix look-alike vendors--but, in general,
they attempt to emulate one of these two major products.)
(Please note that Berkeley started with UNIX/32v which did not come
from USG; it came from Research (HO) and it did nothing nice other than
to get UNIX onto VAX in the simplest, most straight forward means,
emulating PDP-11 style of memory management. 32v did give UNIX partial
swaps, though.)
No, Berkeley did not get into the software business; the VAX community
forced them into manufacturing tapes and documentation.
Now, no one is a villain. AT&T didn't really market Unix, actually;
it's been more described as "Here are some source tapes, some manuals,
and our best wishes. Have fun!" However, as much as was possible, the
AT&T version was the standard. If something was fed back to AT&T, it
would eventually, probably, make it into the next release of Unix in
some form or another; but the informality of the process, the time
delays, and the ease of hacking Unix make the evolution of the Berkeley
system understandable. But we now have systems with fairly different
sets of utilities, kernels that behave--and look--decidedly different
in several ways, and the problem of portable code being not-really
totally portable, but hey, it's better than assembler, right?
What you have to realize is that at the time Berkeley people started
"hacking" UNIX, the only UNIX on VAX was 32v. Not capable, not
flexible, and not fast. I seem to recall that 32v jobs were only about
1.25 times those of V7 or UNIX/TS (UNIX 1.0). Also note, that BSD has
been around for a long time. 3BSD, the first Berkeley UNIX was around
since January of 1980. System III (UNIX 3.0) was available in side the
Bell System after June of the same year and did not hit the streets out
side until January 1982, 1.5 years later. In January of 1983, System V
(UNIX 5.0) was announced. The only things from Berkeley in System V
was some table hashing and active entry linked lists, and Vi. (A
reliable source has told me that Vi was an after thought; someone
forced USG to put it in or System V would not be "competitive".) All
this makes me wonder about your statement saying that ATT would
"probably" put something into the next release. (Actually I understand
that UNIX 4.0 had the kernel table enhancements.)
And it now appears that the institution that fostered one of these
major branches of the family is leaving. Where does that leave the BSD
system people? Darn if I know. Fortunately, AT&T (Actually, now it's
Western) Unix is picking up many of the features that people found
attractive in BSD, so perhaps there will be a "standard" Unix in the
future; but the legacy of the split will be with us for a long time.
Now, I know that everybody does not use VAXen (don't know why...) but
would you, as an owner of a VAX, want to run System III or System V on
it when it does not support half of the peripherals available from the
vendor (not to mention third parties) or a system that will not support
certain devices on one cpu but will on another?? Now, I am not
pushing the autoconfiguration stuff in 4.1 (or 4.2) but it is nice
in an emergency when you have to bring up a crippled hardware. System V
(and System III) do have nice things (KMC tools, messages, SCCS to name
most of them; some people also like the tty ioctl's).
What's the point of this article? Simply that I can't defend
Berkeley's action. Not intending to do something doesn't relieve you
of responsibility for it; and while there was no *legal* responsibility
to support BSD, continued distribution out-of-house certainly seems to
impart some sort of ethical responsibility. More importantly, I guess
I'm just trying to put out a cautionary tale to other universities,
companies, groups of demented hackers in dimly-lighted basements, or
what have you: If you want to meddle in the code, then think about
what you're loosing on the world. If you really want package XYZ to
change, but don't intend/want to support it, then fer cripes' sake, do
the change in-house; tell the world about it, if you wish, and make the
vendor track your change. But remember--it's a small world, really;
and that code you modify today on an insignificant mini operating
system may be floating around in the bowels of a Cray-I next year!
Have I missed something? Has Berkeley said that they are no longer
going to distribute BSD? "Make the vendorr track your change"?? What
are you saying here? Are you implying that Bell is a "vendor" of
UNIX/32v (or any UNIX, for that matter)?? Do they support it? Yes;
they support System V but only to those people who are willing to invest
in a source license. How does this kind of support help the non-kernel-
hacker people who wish to use UNIX? Not much, I should think. My point
is this: Berkeley does not need any defense; they were (as I understand
it) fulfilling a contract to DARPA to provide a UNIX system that other
ARPA contractors could use as a base for (common) development; a
flexible (pick a defination) base. The rest of the VAX BSD users simply
benefited from their work by getting a reasonable and evolving UNIX
for VAX.
Tired of changing BSD ioctl calls,
Dave Ihnat ihuxx!ignatz
Tired of this,
Armando Stettner decvax!aps
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!floyd!clyde!ihnp4!zehntel!hplabs!hao!seismo!
rlgvax!guy
From: g...@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: Berkeley Flames and ihuxx!ignatz
Message-ID: <1383@rlgvax.UUCP>
Date: Thu, 10-Nov-83 10:57:25 EST
Article-I.D.: rlgvax.1383
Posted: Thu Nov 10 10:57:25 1983
Date-Received: Tue, 15-Nov-83 02:43:49 EST
References: <272@decvax.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 25
There are rumors that 4.3BSD will require a System V license, and as such it
may have a lot of the USG UNIX tools (SCCS and the like). The USG tty ioctls
are a clean-up of the V7 ones; they permit you to do things you just can't
do with the V7/4.xBSD ones. Since Berkeley has been trying to clean up other
old kludges in 4.2BSD perhaps they should either do the USG ioctls or a new
set which are a superset of both (they are very similar in general concept
so this wouldn't be too big a set) and implement both the V7/4.xBSD ones
and the USG ones as subsets. They've already picked up the USG "open" call
(superior to the old V7 one) and the USG "fcntl" call (which is USG cleaning
up a lot of old kludges), so perhaps something like this with the TTY driver
would be nice.
In effect, 4.xBSD is "V7 (32/V, actually) muchly cleaned up, with virtual
memory". 4.2 is quite a bit more of a radical departure from V7/32V than
4.1 was, but I suspect a lot of programs go over without major change.
If 4.3BSD were "System V (System VI) muchly cleaned up, with
virtual memory", with no more incompatibility between it and USG than there
currently is between 4.2BSD and V7/32V, and with some backward compatibility
stuff for V7/32V/4.1BSD (USG UNIX doesn't have any stuff for backward
compatibility with the stuff that changed from V7, which is sometimes a
nuisance), that would probably make both camps as happy as is possible. It
wouldn't be perfect but I suspect perfection isn't possible here.
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 umcp-cs.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!mark
From: m...@umcp-cs.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Berkeley Flame
Message-ID: <3728@umcp-cs.UUCP>
Date: Fri, 11-Nov-83 03:24:39 EST
Article-I.D.: umcp-cs.3728
Posted: Fri Nov 11 03:24:39 1983
Date-Received: Sun, 13-Nov-83 04:29:57 EST
References: <13415@sri-arpa.UUCP> <585@ihuxx.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 29
Ignatz again makes the same strange statement we heard from
Laura a while ago--you should not change Unix at all ever,
even if you are a research University doing research in operating
systems. Or if you do change it, you should keep it a secret,
or if you don't keep it a secret you should refuse to ever, ever
let anyone else use the change you made.
I'm afraid to my mind this amounts to stifling research and preventing
the free flow of scientific information among researchers.
If someone does something interesting to an operating system,
even if they write an interesting paper about it, I like to
see it for myself, try it out, before forming a definite opinion
about it. One cannot really resolve the merits of languages,
or operating systems, without trying them oneself for a decent
period of time.
So what is the poor researcher to do when the calls and/or tapes
come in from across the country requesting copies of the system
just described in the xyz journal? If you say no, you are
tarnishing your reputation and unethically hindering scientific
research. If you say yes Ignatz and Laura will flame at you.
I'll say yes.
--
spoken: mark weiser
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs
ARPA: mark.umcp-cs@CSNet-Relay
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1exp 11/4/83; site ihuxx.UUCP
Path: utzoo!linus!decvax!harpo!floyd!clyde!ihnp4!ihuxx!ignatz
From: ign...@ihuxx.UUCP (Dave Ihnat, Chicago, IL)
Newsgroups: net.unix-wizards
Subject: Re: Berkeley Flame
Message-ID: <591@ihuxx.UUCP>
Date: Fri, 11-Nov-83 23:43:48 EST
Article-I.D.: ihuxx.591
Posted: Fri Nov 11 23:43:48 1983
Date-Received: Sun, 13-Nov-83 12:38:55 EST
Organization: AT&T Bell Labs, Naperville, Il
Lines: 71
Your article follows:
Newsgroups: net.unix-wizards
Subject: Re: Berkeley Flame
References: <13415@sri-arpa.UUCP> <585@ihuxx.UUCP> <3728@umcp-cs.UUCP>
Ignatz again makes the same strange statement we heard from
Laura a while ago--you should not change Unix at all ever,
even if you are a research University doing research in operating
systems. Or if you do change it, you should keep it a secret,
or if you don't keep it a secret you should refuse to ever, ever
let anyone else use the change you made.
I'm afraid to my mind this amounts to stifling research and preventing
the free flow of scientific information among researchers.
If someone does something interesting to an operating system,
even if they write an interesting paper about it, I like to
see it for myself, try it out, before forming a definite opinion
about it. One cannot really resolve the merits of languages,
or operating systems, without trying them oneself for a decent
period of time.
So what is the poor researcher to do when the calls and/or tapes
come in from across the country requesting copies of the system
just described in the xyz journal? If you say no, you are
tarnishing your reputation and unethically hindering scientific
research. If you say yes Ignatz and Laura will flame at you.
I'll say yes.
--
spoken: mark weiser
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs
ARPA: mark.umcp-cs@CSNet-Relay
Oh, come now. Read what I said, not what you wanted to hear.
Unix(Tm), in even its best form, is an immature operating system at
best. It certainly needs development, study, and, yes, papers and
code distribution--in the academic community. But I quite certainly
feel that *licensing* the system--not just requiring the purchaser
have a source license for the original AT&T product, but selling the
system for money--is another step entirely. This certainly implies
not just a research system, but a commercial product. This
implication was borne out when the system was sold--and not for the
trifling sum that universities pay for it, either--to commercial houses
for incorporation into product lines. At that point, academic freedom
took a back seat to a financial enterprise. But, in fact, because of
those self-same academic ethics and reputation, I expect a University
Computer Science department to be more rigorous about enforcing the
portability and commonality of Unix than a purely commercial concern.
Remember that code and system portability are ostensibly at the heart
of the Unix concept. If you want to defend their right to disseminate
the results of academic research, then they should have GIVEN copies
to any legal AT&T source license holder, for only the cost of tapes
and mailing--such as has been done in a number of cases. (ICON,
Gosling's EMACS). And why not especially forward the stuff to the
people who originally developed the system? Keep some sort of standard?
But if not, please warn every one that whatever you call it, it isn't
fully compatible with the system of the same name, from the people who
first developed it.
Do your work for DARPA. Disseminate your results. Yelp all you want
to. But I can still take code from v6, v7, System III, and System IV
and get it going with a minimum of fuss. BSD to any of the others is
a pain, and that's what contributed to my even opening my mouth. Drop
the issue, everyone; I'm going back to try to convert some more ioctl
calls, etc. Responses to the standard place.
Dave Ihnat
ihuxx!ignatz
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: Berkeley Flame
Message-ID: <1399@rlgvax.UUCP>
Date: Sun, 13-Nov-83 15:52:02 EST
Article-I.D.: rlgvax.1399
Posted: Sun Nov 13 15:52:02 1983
Date-Received: Mon, 14-Nov-83 09:27:43 EST
References: <591@ihuxx.UUCP> <18957@wivax.UUCP> <518@ariel.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 9
Unfortunately, I believe there are applications where "buy enough memory"
is either impractical or impossible. I believe a lot of the applications
that 4.2BSD is being used for simply require more address space than you
can provide purely with the physical memory attachable to a VAX; the
VLSI design and image processing software that has been mentioned as
prime applications for VAXes and 4.2BSD may fall under this heading.
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 beta 3/9/83; site dual.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxl!houxm!ihnp4!zehntel!dual!fair
From: f...@dual.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Berkeley Flames and ihuxx!ignatz
Message-ID: <149@dual.UUCP>
Date: Wed, 16-Nov-83 02:26:48 EST
Article-I.D.: dual.149
Posted: Wed Nov 16 02:26:48 1983
Date-Received: Sun, 13-Nov-83 11:13:32 EST
References: <272@decvax.UUCP>
Organization: Dual Systems, Berkeley, CA
Lines: 9
I might add to Armando's comments that one of the reasons that Berkeley
might be slacking off, so to speak, is that the industry keeps hiring away
its best talent. Bill Joy is at SMI, Sam Leffler now works for LucasFilm,
I have no idea where Mike O'dell ended up, but I think you get the picture.
Late of UCB, and soon to return,
Erik E. Fair {ucbvax,amd70,zehntel,unisoft}!dual!fair
Dual Systems Corporation, Berkeley, California