Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!sdcsvax!darrell
From: chris@mimsy.umd.edu (Chris Torek )
Newsgroups: comp.os.research
Subject: Re: No More BSD?
Message-ID: <4176@sdcsvax.UCSD.EDU>
Date: Tue, 27-Oct-87 02:15:33 EST
Article-I.D.: sdcsvax.4176
Posted: Tue Oct 27 02:15:33 1987
Date-Received: Fri, 30-Oct-87 00:04:08 EST
Sender: darrell@sdcsvax.UCSD.EDU
Lines: 93
Approved: mod-os@sdcsvax.uucp

In article <4164@sdcsvax.UCSD.EDU> chet@mandrill.CWRU.EDU (Chet Ramey) writes:
>I had heard rumors that 4.4 would be the last BSD Unix ....

It seems to me that a few years ago, I heard rumours that 4.3BSD
would be the last BSD Unix.  If the pattern holds, ten years from
now we will be hearing that 4.9BSD will be the last BSD Unix.
At any rate, onward:

>Does anyone have opinions (or concrete knowledge, that would be
>even better) about why this is so?  I can think of a few myself:

(Change `is' to `might be'.)

>1. The principal UNIX researchers in the C.S.R.G. want to move on to
>some other topic of interest.

I cannot speak for them, but why should not other research topics
include changes to 4BSD similar to those made between 4.1 and 4.2?

>2. DARPA has discontinued the funding that resulted in 4.2 BSD, so the
>sources of money are drying up.

DARPA grants tend to live for five years, then move on.  I gather
that 4.2BSD was primarily funded by a DARPA networking grant.  Yet
the lack of any one grant does not mean that the project base will
not continue to be used (as I have seen with a number of projects
here at Maryland).  More often, a project dies because the person
or persons driving the whole thing move elsewhere.  Whether and
when this might happen, I cannot say.

>3. Another thing that Darrell mentioned:  DEC isn't really cooperating
>with Universities and researchers like they used to ...

(Did they ever?  I have heard so many stories of reverse engineering.
Yes, you can buy hardware descriptions of the 750 ... now.)

>... aren't releasing specs to the new BI bus machines (8200/8300...),
>so BSD won't run on any of them.  I saw that Chris Torek ported (or
>is/was in the process of porting) 4.3 to the 8250,

Did; works; is not right yet (config needs much work; and see also
my `one last thought' at the end of this).  In any case, I did not
have time to install it while I was at Berkeley last week.  (We
ran into a few bugs in their then-current Vax code....)

>perhaps this could result in versions of BSD running on the 8200
>and 8300 series,

The 8300 should be easy, being just a second CPU: Purdue has had
master/slave processor code for years.  Also, one UCB CSRG interest
is in cleaning up the kernel for symmetric multiprocessing, to do
which Berkeley would have to port 4BSD to a symmetric multiprocessor.
This could conceivably lead to 8700/8800 support.  [No promises
though.]  One problem with 8200 support is best described as `who
wants 8200s?'

In article <4167@sdcsvax.UCSD.EDU> kludge@pyr.gatech.edu (Scott Dorsey)
writes further that
>I know that Berkeley is starting to phase out their own Unix.  The
>new vaxen that they are getting all have Ultrix, to maintain compatibility
>with their workstations.  This is a bad sign...

A rumour I heard says that (1) not everyone in UCB's Computing
Center (which is separate from UCB CSRG) is happy with Ultrix, and
(2) the person who ultimately decided to use Ultrix has moved
elsewhere.  Hence it is possible that UCB CC might not continue
using Ultrix.  I doubt it matters.

I should also point out that you cannot boot a Microvax without
getting Ultrix.  We needed Ultrix for our 8250s so that we could
bring them up far enough to copy 4.3 onto the disks and reboot.
(Actually, as it happened, DEC never sent us boot media, and I had
to construct an RX50 floppy `by hand' after figuring out how to
use the 4.3 tape boot code to boot some standalone code I copied
onto 9 track tape.  We could only do that because someone else here
had Ultrix binaries that worked on 8250s.)

One last thought, before I move on to real work:

The Computing Center here is considering using Ultrix on machines
to be used by undergraduates.  For all the arguments I could use
against Ultrix on our research machines, I really cannot say that
CSC would be doing the wrong thing.  Ultrix is a supported product,
and there are people who want supported products.  I am not one
such: I want things that *I* can fix, enhance, or alter in wierd
and wonderful ways.  But as I see it, the major difference between
a commercial system and CSRG's work is that in commercial systems,
the externals are the most important thing; in CSRG's work, the
internals are the most important.  If you intend to support 10 000
undergrads all bashing away, do you care whether the innards are
elegant, or is the only thing that matters `does it work for them'?
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris