x.Jiml%su-gsb-why.arpa@BRL.ARPA (11/06/83)
From: Jim Lewinson <x.Jiml%su-gsb-why.arpa@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 (??)) -------
gwyn%brl-vld@sri-unix.UUCP (11/07/83)
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.
bob%ucla-locus@sri-unix.UUCP (11/07/83)
From: Bob English <bob@ucla-locus> Who said Berkeley was in business? They're a university, not a software clearinghouse. When they offered to do software development, they probably didn't bargain on software support as well. I doubt the people still at Berkeley have a vested interest in having the whole world use 4.2 and don't feel any urgent need to answer questions or fix bugs for individuals. If you want that kind of support, I suggest you talk to someone who cares about such things. --bob-- P.S. Remember that when you say "Berkeley" (or "UCLA" or "MIT" or "CMU" or ...) you're talking about a group of largely autonomous faculty with their own interests and research goals. Approaching them as a unit will probably not be very productive. Find the appropriate individuals and approach them.
jsol@bbncca.ARPA (Jon Solomon ) (11/08/83)
I suspect that Berkeley is getting out of the unix development game. I heard a rumor that all their hackers left for greener pastures. (shouldn't this be in net.rumor?)
ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) (11/09/83)
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
eric@aplvax.UUCP (11/10/83)
Can anyone tell me just who is minding the store now at Berkeley? At Toronto, Mike O'Dell got up and stated that things were settling down, and that he would be in charge of 4.2. But now I hear word that he is out here on the East Coast (or is this a different O'Dell?). I guess we will find out in January, but I am kind of interested, and we have been having mucho problems with licensing, and finding out just what is on the distribution tape in the way of drivers (I will grant that ours is not one of the easiest licenses ever to be granted). The impression we got was that there really wasn't anybody with firm control right now. Just what is going on? -- eric ...!seismo!umcp-cs!aplvax!eric
mark@umcp-cs.UUCP (11/11/83)
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-Relayignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) (11/12/83)
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!ignatzdyer@wivax.UUCP (Stephen Dyer) (11/12/83)
AAuuugh! Berkeley's fee was a DISTRIBUTION fee to cover the costs of mailings, personnel, tapes, etc. From every indication, they were SWAMPED with demand, and could have done one of two things: ignored it, and remain an ad-hoc distribution with an infinite service time for requests. added additional personnel, and instrument an efficient distribution system, with a realistic fee to cover their costs. They decided on the latter, a decision which they could have easily passed on. In fact, if you'd like to get an appreciation for what the first option would have been like, just try to get a 2.9BSD tape (or more truthfully, try to have gotten a 2.8* BSD tape in the past few years.) This is no slur against the PDP-11 people at Berkeley--it just falls out as a consequence of the different style of distribution. Blaming Berkeley is a little dumb--clearly the UNIX community voted by its demand. Meanwhile, Bell did NOTHING to support the UNIX user community. Now, they come out with the hodgepodge named System V, and they expect the prodigal users to come back to its fold. No virtual memory on the VAX, though--clearly a problem out of the reach of the best at Bell Labs. Give me a break! I think, however, that we'll begin to see a re-integration of some of the best features of both systems in the next decade, as AT&T becomes more strongly committed to supporting the system. /Steve Dyer decvax!bbncca!sdyer
jlw@ariel.UUCP (J.WOOD) (11/13/83)
Steve Dyer's article makes the same semantic mistake that I have seen in many articles recently. The specific statement made is that BTL UNIX doesn't have 'virtual' memory for its VAX version. Of course it has virtual memory; what it doesn't have and what all the submitters mean is that BTL UNIX doesn't implement a paging virtual mamory system. BTL UNIX implements virtual memory meaning that the address bit pattern generated in an instruction or by some arithmetic operation in a register for example is translated by a memory management unit before a main store reference is made. On the other hand, when BTL UNIX needs some more main store, it selects a process to be deleted and ships the whole image to a swap device. When Berkeley UNIX needs some more main store it looks for a page to delete. This is more efficient than the BTL way. The other alternative which is becoming more attractive for many sites is to just buy enough memory. That runs faster than either. Joseph L. Wood, III AT&T Information Systems Laboratories, Holmdel (201) 834-3759 ariel!jlw
padpowell@wateng.UUCP (PAD Powell [Admin]) (11/13/83)
Let Laura flame. We can always use the "n" key. Patrick Powell, WATENG System Dictator Pro Tem
guy@rlgvax.UUCP (Guy Harris) (11/13/83)
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!guydyer@wivax.UUCP (Stephen Dyer) (11/14/83)
Semantic mistake?? Bah! I'll bet that EVERY knowledgable reader knew exactly what I meant. My use of the phrase "virtual memory" in this context was clear. Your argument is a feeble attempt to obscure the fact the BTL UNIX on the VAX can support a process no larger than the maximum amount of physical memory, less the space occupied by the kernel. I hope this is clearer. Sorry to flame--I feel that a response which nitpicks without addressing the primary issue raised by the news item isn't much of a response. /Steve Dyer decvax!bbncca!sdyer
thomas@utah-gr.UUCP (Spencer W. Thomas) (11/14/83)
Re: "Bell unix has virtual memory" Tell me how to run a 40Mbyte process on any existing VAX under BTL Unix. Then I'll believe it has virtual memory. =Spencer (Yes, we have done this under Berkeley unix)
mjl@ritcv.UUCP (Mike Lutz) (11/15/83)
When I was just a lad in graduate school, we were very careful to distinguish
between address mapping and virtual memory. The former simply meant that some
combination of hardware & software was able to take "logical" addresses pro-
duced by executing programs and map them onto different "physical" addresses.
However, for a system to support virtual memory, it had to maintain the illu-
sion that all of the logical address space was directly addressable, even
though some (most?) of the memory image was actually on secondary storage.
The virtual memory size has no predefined relation to the physical memory
size; if I remember correctly, the SDS940 system had a virtual address space
smaller than the physical address space. The key is the ability to run a pro-
cess with only a small part of its address space loaded.
Mike Lutz
{allegra,seismo}!rochester!ritcv!mjlshawn%mit-dspg@BRL-VGR.ARPA (11/18/83)
I think that was totally uncalled for. -- Shawn