UNIX Futures

[COTTRELL, JAMES]

/* Dagwynn sez:
> Wayne Hathaway's question can be generalized:
> 
> What lies in the future for vendors who have been
> providing Berkeley-based kernels?  Do they track
> 4.nBSD as it continues to diverge from AT&T's
> UNIX product, do they convert to follow AT&T, or
> do they offer a choice of systems?  After all,
> there is a limit to how much System V compatibility
> you can squeeze out of a Berkeley kernel, and this
> limit unfortunately excludes several really useful
> System V features.

Divergence? Who renumbered the manual sexions? Who made
INIT, LPR spooling, the TTY driver look alien? OK, so maybe
SV's tty driver is `better' than BSD's, but why didn't they
keep the old names? Like CBREAK. And just how much BSD
compatibility can you squeeze out of the SV kernel.
Sometimes I think TPC is *trying* to be different
just to kill off BSD.

> It appears that the major market demand will be for
> AT&T-compatible systems.  This does apply a lot of
> pressure to the Berkeley system vendors.  Of course,
> if Berkeley would conform to the SVID, this would
> not be such a significant issue, but recently
> reported quotes make this appear unlikely.  Too bad.
> (Actually, if BSD usage dwindled to just research-
> oriented sites, that would probably be a Good Thing
> for everyone concerned, in the long run.)

It seems to me that SVID is like the intersexion of most
*ix's out there. If they want the other vendors to conform,
it can't be *too* much work, or no one would do it.

> Barry has made some very good points, most of which I agree with.

Yer darn tootin!

> 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

Well it's about time! I guess if Berkeley had releases all the time
they would have some neat new stuff too. It's been four years now,
while TPC put out abominations like SYS III. On my SV tapes
(gotta have 'em to run BSD, plus we have a Motorola SV.0 port)
they *finally* included vi (what did they use before, ed? The
Rand editor?), no pager, no new shells (same old sh), and a lot
of weird stuff (LP, INIT, TTY, etc) i had to relearn.

> In many ways, UNIX System V is already more useful than 4BSD,

Name three.

> 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.

So those wimpy manager types are scared because BSD is `unsupported'.
Big deal. Software support is a joke anyway. Fill out a form and
wait for unusual weather conditions in Hades. Better to publish
the source & let 'em fix it themselves. Or subscribe to the net.

> Several federal agencies now mandate UNIX System V, for example.

NBS doesn't.

> 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.

Primitive? I suppose you prefer SCCS over RCS? Jeez!
OK, so `make' has been enhanced. What else?

> 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.)

Don't get me wrong, we appreciate your efforts. I just didn't
realize your motives until now.
 
> Besides better user-mode libraries and utilities, which 4BSD could
> pick up, 

Could they? What would TPC if Berkeley wanted to include, say SCCS?
Or the nifty new shells TPC has developed? At what price?

> there are also many aspects of the UNIX System V kernel
> that are better designed and implemented than in 4.2BSD; 

Examples please.

> memory management is one notable example.  

Took them long enuf.

> 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.  

Just what we need, lots of different ways of doing things.

> Gee, I could have had a V8!)

Could you? Who *has* V8? Outside Bell Labs, that is.

> 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.

Like I said, I think TPC has been making that difficult.
 
> 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)

One thing you Gurus have been strangely silent on is *my* model
for memory sharing. That is, after a fork, *just duplicate the
stack and let parent & child live in the same data space*!!!

> 	4BSD provides networking support
> 		- I agree that UUCP and 3Bnet don't qualify

Yeah, but guess who rakes in the bucks on phone calls!

> 		- SVR3 streams will be a boon to networking

Probably.

> 		- 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)

I hear that too.

> 	4BSD has vi, termcap, and curses
> 		- System V picked these up, and improved termcap
> 		into terminfo (which really is better)

Did they pay Berkeley? What did they give in return?

> 	4BSD has csh
> 		- In many ways, the SVR2 Bourne shell is better

How so?

> 		- One can run ksh, which is Bourne shell compatible
> 		and offers more than csh (except for job control);

That's a *big* exception.

 		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 just read about it yesterday. I agree.

> 		- I use a 5620 DMD, what do I care.  DMDs are great!

Great. How much do they cost? What extra software do they need?

> 		- As usual, Berkeley implemented the wrong thing;

Explain.

> 		I thought those guys were supposed to talk with the
> 		folks at Murray Hill (maybe they don't listen)

Which *they*?

> 	4BSD has dbx
> 		- System V's sdb is comparable

BSD has sdb too.

> 		- I hope pi will arrive with SVR3.n (for small n)

Pascal? YUK!

> 	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

Touche!

> 		- AT&T has substantial development resources

I agree. Bill Joy & Mark Horton probably get paid better
in the real world.

> 		- I agree that AT&T moves more deliberately
> 		- That can be a Good Thing too

You forgot:

	4BSD comes with better games & Rogue.
		- yeah but you can port Hack to System V
		- most of System V's games suck.

> 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.

Mostly because they had a longer way to go to catch up.
 
> 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..

I don't believe it. In a project as big as an operating system,
there are bound to be bugs. Both in SV & BSD. The only difference
I see is that TPC publishes their bug list ("MR's fixed") *after*
they are fixed, while "the BSD bug list" floats around the net
*while* they are still bugs.
 
> ..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.

You may be right, but there are *lots* of us diehards out there.
IBM because of their corporate size, influences the market greatly,
but seldom produces anything you or I would wish to deal with.
Unfortunately, marketplace considerations often override technical ones. 

	jim		cottrell at nbs
*/
------