ULTRIX futures?

[Steve Summit]

When AT&T was first starting to sell Unix commercially, and the
diverging path from 4bsd was noticed, the prevailing sentiment
was that 4bsd and SysV would probably/hopefully/inevitably
converge.  I don't remember the exact reasoning, but it had to do
with the perception that both sides would be trying to
incorporate each other's good new features anyway, and that to
diverge would be suicidal.  I guess it sounds a little foolish,
today, given that the prevailing sentiment in the latest
discussion is that the two are on a terminally diverging path.

I will be accused of being hoplessly naive here, and I will admit
that there's a lot about SysV that I don't know, but I would like
to think that there is still the possibility of convergence, or
at least sustained compatibility.  The "universe" scheme,
although admittedly clumsy, is starting to make more sense to me,
at least as an interim solution.  It nicely solves most of the
"chapter 1" and "chapter 3" problems (user programs, and
subroutine libraries.)  At those levels, most of the kernel
details are hidden.

The interesting problems, of course, are in chapter 2, the system
calls themselves.  Here, too, there are an awful lot of programs
(those that do only I/O, with maybe an occasional signal catch)
that are insensitive to kernel differences, as long as they've
got open, close, read, write, and lseek; with stdio on top.
The proverbial "simple matter of recompilation" is alive and well
for these programs, and more programs could enjoy this attribute,
if people would just be a little more judicious about using the
off-the-wall system calls, and if Berkeley would quit moving
#include files around.  Just because "neat new feechurs" have
been added to the latest OS release you just got doesn't mean you
have to use them to write "cat" with.  You'd be surprised how
many programs you can write using only version 7 stuff, and which
will therefore compile and run on virtually anything even vaguely
resembling Unix.

The two really thorny problems are the terminal driver and IPC.
AT&T took a deep breath and threw away the old, unworkable
terminal driver; attempting to replace it with something
orthogonal, with individual control over each function (not
lumped together under something like "RAW" and "CBREAK") which
is what I've wanted all along.  From what I hear, their attempt
was not 100% successful, so there are some problems with the
SysV terminal driver as well.

I'd like to see a really orthogonal terminal driver, on top of
which the others (version 7, Berkeley NTTYDISC, SysV) could be
efficiently "emulated."  As I say; this suggestion will doubtless
be immediately shot down as unworkable, but I've done some work
with terminal drivers in my time, and I don't think it's out of
the question.  (The current terminal drivers are not without
their unworkable aspects, either.)

The IPC issue is just going to take a bit more time to iron out.
Berkeley has a pretty good thing going, although it's typically
bugridden.  I keep hearing about Dennis Ritchie's neat streams in
Version 8, though I haven't seen them yet.  Programs that are
heavily into IPC are, at least given today's "technology,"
extremely operating system dependent and are probably going to
need some conditionally-compiled code if they are going to be
portable to anything but the individual machine to which they were
laboriously tuned.  (Witness the continuing distress cries on
this newsgroup, some from naive users who are simply bewildered
by the insufficient and misleading "documentation," but others
from capable people who have unwittingly blundered into
seethingly strange semantic vagaries in the contortions of
Berkeley IPC.)

Compatibility is a Good Thing.  It's never easy, particularly
when things have begun to diverge, but it just gets harder as
time goes on.  Furthermore, at least as far as Unix-like
operating systems are concerned, I think that some compatibility
is better than none at all.  Just because it doesn't appear that
the programs that are pushing through the edges of the SysV and
4bsd envelopes will ever be portable doesn't mean that we should
give up on the compatibility idea entirely.

Let's be willing to compromise, and to sacrifice a bit of
backwards compatibility (which is also a Good Thing, but a
luxury) in favor of the kinds of compatibility that are
reasonably attainable.  Things like "programs that don't call
ioctl, or use IPC, will be binary-compatible between SysV+x and
4bsd+y."  Or "programs that stay away from these gray areas will
be source-code compatible, requiring recompilation but no
rewriting."  (Maybe we just need Voomfrodel and Thwick's -- or
whatever their names were -- "clearly defined gray areas.")
Given the current state of divergence, such a common model might
require losing binary backwards compatibility (things like system
call numbers and ioctl requests might have to change) but as I
said, if it's going to happen at all, the sooner the better,
because the problems will only get worse.

Sorry for rambling so.  I had intended to be more specific, but
doing so would just make this longer.  I think there is a lot of
room for constructive discussion here, as long as people stay
away from the religious arguments, which I have been astonished
to see none of in the recent discussion.  (Congratulations,
folks!  I was afraid USENET was incapable of carrying on a
non-flaming discussion!  Shame on those who have labeled Doug's
and Barry's eminently reasonable postings as "one-sided,"
though.)  I'd love to see the mood swing back to anticipation of
future AT&T/Berkeley convergence.

                                         Steve Summit
                                         tektronix!copper!stevesu