ULTRIX futures?

[VLD/VMB]

Barry has made some very good points, most of which I agree with.
ATTIS *has* made an unfavorable initial impression on the UNIX
technical community, for example (although the recent 3B2/400
appears to be significantly improved over earlier models, and the
next major release of UNIX System V is slated to incorporate
substantial improvements, beyond what 4.3BSD can match.  In
many ways, UNIX System V is already more useful than 4BSD,
although it does currently lag in networking support).  By the
way, Barry, I was told that RFS can link disparate machines, but
given UNIX code quality to date, I am skeptical.  I really hope
AT&T will make an effort to teach their programmers how to code
more portably.

The main reason I think UNIX's commercial future lies primarily
along the System V path is not so much that AT&T is pushing it;
rather, it's because the *customers* are starting to demand it.
Several federal agencies now mandate UNIX System V, for example.
Even more significantly, in my estimation, is the fact that the
standardization efforts for both UNIX and C follow System V semantics
very closely.  (I even technically agree with this; every time I
find myself working in a native Berkeley environment, it is not
long before I start cursing their primitive software development
tools.  The main motivation of the BRL UNIX System V emulation
project was to provide the nicer, uniform, System V environment
everywhere I have to work.  Many of my users appreciate it, too.)

Besides better user-mode libraries and utilities, which 4BSD could
pick up, there are also many aspects of the UNIX System V kernel
that are better designed and implemented than in 4.2BSD; memory
management is one notable example.  This is not to say that there
are not problems with UNIX System V; Guy Harris and I have posted
perhaps a hundred bug reports and there are many others we have
fixed without telling the net.  It is important to realize that
the same thing would have been observed for 4.2BSD, except I avoid
improving it because I don't use much of their user-mode software.
(What I do use often suffers from the famous "Berkeley Brain
Damage", which I attribute to the designers deciding on a single
usage model and doing a lot to help that particular usage, to the
detriment of other more general possible uses.  Gee, I could have
had a V8!)

The reason that this issue is drawing increasing attention is that,
unless AT&T really botches it, the next major release (3.0) of UNIX
System V will be significantly better than any previous publicly-
available version of UNIX (although it may be some time before this
becomes generally apparent), and some of the new features will be
difficult to fit into 4BSD-based kernels without major overhaul.
What one would hope is that the folks at Berkeley would be willing
to change their system to closely track UNIX System V, except in
those cases (if any) where it is clear that a major loss of
functionality would result.

It was mentioned that DEC's Ultrix product was based on 4.2BSD and
had attained some degree of System V compatibility through the use
of the BRL UNIX System V emulation package.  Actually, the current
situation is somewhat different, in that DEC (like most of the other
major 4BSD-based kernel vendors) has felt the pressure from the
marketplace for System V compatibility, and they have been
responding.  Many (maybe even most) of these vendors obtained the
BRL UNIX System V emulation package and used it as a base for
their initial System V compatibility offering.  (No, I will not
disclose names.  Just name one; they're probably included.)  The
trouble with the BRL UNIX System V emulation is that I could not
emulate all aspects of UNIX System V semantics perfectly without
making changes to the 4.2BSD kernel, which was off-limits for the
purposes of my project.  The 4BSD-based kernel vendors, however,
do not have such a constraint, and what many of them have done is
to incorporate into their kernels those System V features that
are hardest to do in user mode, leaving the rest to a compatibility
library very much the way I did the whole emulation.  This approach
has allowed 4BSD-based kernel vendors to provide System V
functionality (yuck, I hate that word -- is there a better one?)
to those customers who want it.  DEC, for example, now advertises
Ultrix as meeting all the specs of the System V Interface
Definition (AT&T's official published System V semantic
specification); I have no idea how much (if any) of my original
work is still in the Ultrix product (I hope the bug fixes are).

The problem with such a hybrid system, or even with a parallel-
universe one such as Pyramid and Apollo offer, is that it gets
progressively harder to maintain a split personality as the two
base systems diverge.  There are already possible security
problems due simply to the different ideas the two UNIX variants
have about such things as chown, process groups, terminal ioctls,
signals, etc. if both semantics are provided on the same system.
(Remember, security is an aspect of how everything fits together.)
Merged systems have a similar problem; we use one here, and both
the 4BSD and System V camps have found its behavior irritating.

On a strictly functional basis, which version is better?
For a long time, 4BSD adherents claimed:
	4BSD supports demand-paged virtual memory
		- So does System V, more cleanly, and shared
		memory is provided (and is rumored to even work)
	4BSD provides networking support
		- I agree that UUCP and 3Bnet don't qualify
		- SVR3 streams will be a boon to networking
		- TCP/IP is available for System V; soon with
		AT&T's blessing (I don't know if a stream-
		based TCP/IP will be released; Wollongong may
		provide essentially the Berkeley implementation)
	4BSD has vi, termcap, and curses
		- System V picked these up, and improved termcap
		into terminfo (which really is better)
	4BSD has csh
		- In many ways, the SVR2 Bourne shell is better
		- One can run ksh, which is Bourne shell compatible
		and offers more than csh (except for job control);
		there have been (unsubstantiated) rumors of ksh
		being supported in a future release of UNIX System V
		- I don't put shl in the same class as job control
		- I use a 5620 DMD, what do I care.  DMDs are great!
		- As usual, Berkeley implemented the wrong thing;
		I thought those guys were supposed to talk with the
		folks at Murray Hill (maybe they don't listen)
	4BSD has dbx
		- System V's sdb is comparable
		- I hope pi will arrive with SVR3.n (for small n)
	4BSD is faster
		- UNIX System V is at least as fast for typical
		loads
		- The 4.2BSD fast file system is indeed faster
		under some circumstances, at the cost of other
		resources (CPU cycles and main memory)
	4BSD has universities developing software for it
		- AT&T has Bell Labs, so there, nyaah, nyaah
		- AT&T has substantial development resources
		- I agree that AT&T moves more deliberately
		- That can be a Good Thing too
In other words, these arguments used to be mostly valid (that's
why we chose to run 4BSD on the BRL VAXes), but UNIX System V
has rapidly improved -- faster than 4BSD is improving.

If any die-hard 4BSD hackers have read this far, I would be glad
for you fellows to keep playing around and coming up with useful
ideas.  I like good ideas.  But I sure don't want you using me,
as a commercial *user* of the system, as your guinea pig.  The
production folks really do want improvements, but they want them
introduced in a controlled manner, to minimize operational
headaches.  So far, AT&T has done a much better job of that than
Berkeley has..

..but nobody's perfect

Finally, a plea:  Let's not start one of those pointless
"My system is better than yours" debates.  The topic is,
where is UNIX headed in the near future?  I say: clearly
System V, so far as the commercial marketplace is concerned.
Feel free to dispute this, based on facts or perceptions.