Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!
whuxlm!akgua!gatech!seismo!brl-smoke!smoke!wa...@wilbur.arpa
From: wa...@wilbur.arpa
Newsgroups: net.unix-wizards
Subject: ULTRIX futures?
Message-ID: <703@brl-smoke.ARPA>
Date: Thu, 6-Feb-86 22:40:57 EST
Article-I.D.: brl-smok.703
Posted: Thu Feb 6 22:40:57 1986
Date-Received: Tue, 11-Feb-86 05:46:30 EST
Sender: cr...@brl-smoke.ARPA
Organization: /usr/local/lib/news/organization
Lines: 6
A random question from an interested but uninformed observer:
What with 4.3BSD and System V Release 3 making their debuts,
anybody got any idea what is in ULTRIX's future?
Wayne Hathaway wa...@ames-nas.arpa
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!
whuxl!whuxlm!akgua!gatech!seismo!brl-smoke!smoke!g...@BRL.ARPA
From: g...@BRL.ARPA
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <707@brl-smoke.ARPA>
Date: Thu, 6-Feb-86 22:44:14 EST
Article-I.D.: brl-smok.707
Posted: Thu Feb 6 22:44:14 1986
Date-Received: Tue, 11-Feb-86 05:46:45 EST
Sender: cr...@brl-smoke.ARPA
Organization: /usr/local/lib/news/organization
Lines: 21
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.
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.)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!
harvard!seismo!brl-smoke!smoke!bzs%bostonu.cs...@csnet-relay.arpa
From: bzs%bostonu.cs...@csnet-relay.arpa
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <737@brl-smoke.ARPA>
Date: Fri, 7-Feb-86 14:19:07 EST
Article-I.D.: brl-smok.737
Posted: Fri Feb 7 14:19:07 1986
Date-Received: Tue, 11-Feb-86 06:05:29 EST
Sender: n...@brl-smoke.ARPA
Lines: 135
Doug Gwyn says that the future of UNIX is SYSV, and that is good.
The images in my crystal ball are not so clear:
Although several vendors have committed to some form of SYSV, we
see several major vendors (DEC,SUN, much of the workstation market
and near-supercomputing) showing development based upon 4.2bsd.
This is not an insignificant portion of the community. Although
IBM is toying with all possibilities there is a decided leaning towards
SYS/V (the PC/RT for example already has both SYS/V and 4.2bsd but
it looks like the SYS/V may be the only official release, in their
mainframe business almost exactly the same thing occurred but nothing
official has been released.) On the other hand, it is not at all clear
that IBM will ever be a significant factor in the *UNIX* market as
they continue to rabidly push MVS as the only serious O/S available
for their machines (I have spoken with people within IBM about this
and this message comes through loud and clear.) The IBM behemoth
is probably not a significant factor in this issue, at least not
for a few years (if you think what happens with PCs in general is
significant then I disagree fundamentally ['you' here is not Doug,
but you the reader, I believe Doug agrees with me on this.])
As we all should know by now, SUN has signed significant agreements
with AT&T to come to some sort of resolution of this issue, rumors are
that we should know what that means as early as the summer. Obviously
SUN cannot throw out 4.2 (I guess obviously, at least they would have
to modify SYS/V to the point that it may as well be 4.2 to continue
their architecture.) I think AT&T is similarly not ready to throw out
SYS/V so the only good guess I can come up with is some compromise on
adding a lot of 4.2 function to SYS/V (and vice versa), a hybrid
offering, although I agree this is very optimistic.
Digital, as far as I know, is not likely to undo their current 4.2
based effort in ULTRIX. Most rumors to the contrary appear to actually
be referring to their acceptance of Doug's SYS/V emulation under
ULTRIX as a standard product, good for everyone involved. I believe
here this commitment is not insignificant to DEC, they must develop
a UNIX identity (as they should/could have years ago). Their VAX
line is destined for only a few more years (rumors from within the
company of a project referred to as 'The Last Vax' are already
circulating.) This leaves VMS entirely in the lurch (fantasies from
VMS fanatics aside of somehow porting the largely machine coded O/S.)
They can't make it cheap and they can't make it fast (if you think
otherwise you are looking at the world through vax-colored glasses,
an 8650 is not a good price-performer in today's market, neither is
a microvax II. I/O architecture on both machines may be their ultimate
downfall.)
This leaves DEC with only one choice: Release a new architecture
(rumors of this development effort have been con/persistant) and leave
VMS behind (remember TOPS-20...) This points towards a desparate need
to develop a solid image of their ULTRIX product which will lead them
into this new market (with 'transition aids', note the offering already
of VMS/Fortran under ULTRIX, these popular and profitable applications
will be a lot easier to port than the underlying VMS O/S.) I doubt
very much DEC is about to undo what they have so far established at
this critical junction in their history (the company without a product?)
The underlying implication in this whole argument is that somehow
AT&T, by virtue of the fact that they own the concept of UNIX, is
pre-destined to become the industry leader in delivering UNIX systems
to the world. Oweing to this leadership position they will thereby
succeed in proliferating their SVID as a standard. Obviously their
raw perceived size as a corporation is also a large factor in this
prediction.
I for one disagree. We are one of the gift sites for 3B2 and 3B5
systems and have been running these for over a year. I have been
in contact with many other gift sites and several other customers.
There seems to be a lot of agreement (not unanimous, but nearly
so) that ATTIS in fact is one of the most mediocre vendors you
can get involved with. Their systems are unreliable and unexciting
being mostly slow and very limited in function. The organization
itself is nearly impossible to deal with, even when it's in their
own best interest (eg. calls to try to find out about upgrades get
unanswered, field service people appear untrained and of an attitude
that putting a system down a few days to work out a problem is fine.)
Worse, their product pricing is confusing at best, in fact many consider
it abusive (unbundling pieces like t/nroff with each new release,
people find they have received systems wherein the standard release
lacked even a C compiler.) They act as if you have no choice (a
situation with a familiar 'ring' to it...We're the phone company,
we don't care, we don't have to, we're the only game in town...)
My very typical story is I am in the 12th month and waiting for
delivery of pieces of my system, things do not get resolved.
Further, promises of some proliferation of applications has failed
to develop. In the field of networking, for example, most people I
have spoken to find 3Bnet 'a joke', not to be taken seriously (it
basically consists of one command, no application interface, imagine
a subset of uucp over ethernet and you are close.) There are promises
of an 'RFS' but again one cannot help but notice that any homogeneous
networking solution (ie. 3B only) is not destined to be very popular
(remember all those Vaxes and IBM mainframes out there, they're not
going away overnight, not to mention workstations.)
If we remember other corporate giants who decided to enter computing
as a business (General Electric, Exxon, Xerox/XDS, RCA, Raytheon)
we see a clear pattern of initial assumptions that of course such
a large, well backed adventure will make an impact, in fact all of
these ventures failed. There have been exceptions to the contrary
in recent history (of course IBM and Burroughs might be used, but
their entries were so early that they virtually monopolized their
areas quickly) but they are few and far between (name 3.)
It is not at all clear to me, at this point in history, that ATTIS
will not in fact start to realize how difficult it is to actually
run a business in computing, coming out with products, service and
support in a timely fashion. Their massive bureacracy seems to hinder
them by making products which people have never even heard of come out
badly supported, expensive and with no clear identity in the marketplace
(WHY would YOU buy a 3Bx given all the other choices on the market? If
it's only for recursive reasons [it's from AT&T] you are destined to
a hard lesson about product assessment.)
I think it very likely that they will fall back into their traditional
role in telecommunications (PBXs etc) where they find acceptance and
know how to compete and leave the very fast paced, competitive market
of small to medium sized computing systems to the lean and mean startups
and the very few corporate giants with established bases to fall back
on.
This would mean a waning in interest from ATTIS and hence dominance
by the current giants in the UNIX market (DEC, SUN et al.)
I guess what I am trying to say is: The emperor may very well have
no clothes.
As I have said over and over again, it's still a lot better than
anything else...except 4.2...
-Barry Shein, Boston University
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!
harvard!seismo!brl-smoke!smoke!g...@BRL.ARPA
From: g...@BRL.ARPA (VLD/VMB)
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <755@brl-smoke.ARPA>
Date: Sat, 8-Feb-86 00:35:34 EST
Article-I.D.: brl-smok.755
Posted: Sat Feb 8 00:35:34 1986
Date-Received: Tue, 11-Feb-86 06:07:44 EST
Sender: n...@brl-smoke.ARPA
Lines: 149
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.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!
harvard!seismo!brl-smoke!smoke!bzs%bostonu.cs...@csnet-relay.arpa
From: bzs%bostonu.cs...@csnet-relay.arpa
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <761@brl-smoke.ARPA>
Date: Sat, 8-Feb-86 15:11:24 EST
Article-I.D.: brl-smok.761
Posted: Sat Feb 8 15:11:24 1986
Date-Received: Tue, 11-Feb-86 06:08:27 EST
Sender: n...@brl-smoke.ARPA
Lines: 72
I have for a long while now wanted to start a moderated list on
this and other similar topics called INFO-PROGNOSTICATIONS (nah,
too long, something like that.)
Although I suspect the unix-wizards audience is a close subset of
the people who should be interested in such topics (many others
also outside the unix community) it is really not quite the right
forum for such discussions.
I would like to feel this out from the community. Without being
overly prescriptive I am proposing a mailing list to loosely
cover the following sorts of topics:
1. First and foremost, trying to put events in the computing community
into some sort of perspective such as emergence of new products and
vendors with attempts to extrapolate their impact. Absolute strictness
about computing is not mandatory but some theme is probably necessary
to maintain interest. Obviously theoretical and research developments
are of equal merit.
2. Speculative assessment of the impact of new technologies on
computing. Obvious candidates at this point in history would be
CD roms, Multi-mip PCs, fast falling memory prices (faster than the
last time someone said that phrase), inexpensive super-computing...
3. Trends in operating systems especially in terms of their wide-spread
impact (such as the current 4.2/SYSV discussion.) Networking etc etc.
4. Trends in software (such as ugh bletch ADA) and applications
(can UNIX really ever support as personal an interface as a MacIntosh,
or does anyone even want that? what does that mean to each?)
5. Trends within companies (will DEC drop VMS? will the world drop
PR1ME? will IBM add JCL to UNIX before they feel comfortable with it? :-)
6. Strong rumors within these areas.
To prevent being misunderstood, the point is reasoned extrapolation
into the near future as it affects our decision making.
Of course what might make it a big boor would be wild speculation
except perhaps by some peculiarly talented individuals. This is one
reason to make it moderated.
What I am soliciting here is:
a) Is there interest in such a discussion? Or is it better
handled by existing groups allowing things to fall into
their apparent topical catagories?
b) What would it be called, suggestions welcome though I
do not think this is too critical (INFO-FUTURES?)
c) Does it exist already to your satisfaction?
RESPOND BY MAIL to the addresses below. USENET USERS: THIS IS NOT a
proposal for a new newsgroup but rather a mailing list, it could
conceivably become a group but the experimental nature of the
discussion should be tested in a less widely distributed audience,
there is no basis to make a usenet group out of it by common
guidelines, whining publicly ('I WANT') always sheds more heat than
light. I have direct access to ARPA, CSNET, UUCP and BITNET so most
anyone that participates in these discussions should be directly reachable.
I will create a summary of responses.
-Barry Shein, Boston University
CSNET: bzs@bu-cs
ARPA: bzs%bu-cs@csnet-relay
UUCP: ...harvard!bu-cs!bzs
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!genrad!panda!talcott!
harvard!seismo!brl-smoke!smoke!davest%lumiere%tektronix.cs...@csnet-relay.arpa
From: davest%lumiere%tektronix.cs...@csnet-relay.a (David C. Stewart)
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <763@brl-smoke.ARPA>
Date: Sat, 8-Feb-86 20:27:45 EST
Article-I.D.: brl-smok.763
Posted: Sat Feb 8 20:27:45 1986
Date-Received: Tue, 11-Feb-86 05:31:42 EST
Sender: n...@brl-smoke.ARPA
Lines: 26
<Groan>. Here they go again, folks. The Shein/Gwyn Unix debates
round 10. This seems to come up about once every 6 months or so. You guys
really should square off at a Usenix BOF some time and we can vote on the
winner.
In minimal fairness to both sides, nobody really knows the future
of Unix (although both of these guys will try to convince us that they do)
and trying to predict based on current trends is a shakey endevour. For
each of these letters, grep -v 'is better than' and you're on your way.
There is so much value-judgement and emotional weighting that you can't
really see the forest for the trees.
NOW - with that off my chest - let's get back to discussions that
we have some hope of resolving, ie of a technical nature. (And please
don't give me that "well, there WERE technical issues raised in those
letters," business. The technical issue that has "is better than" as the
sole proof is specious.)
Dave
Tektronix Unix Support
PS: My manager worked with Doug for a while at the P1003 meetings and tells
me that he is 100% anti-BSD in person as well. Notice that both of these
gentlemen work in a "mixed" environment of BSD/SV. Maybe oil and water
don't mix? How about it Pyramid? DCS
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!brl-smoke!gwyn
From: g...@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <775@brl-smoke.ARPA>
Date: Sun, 9-Feb-86 07:08:17 EST
Article-I.D.: brl-smok.775
Posted: Sun Feb 9 07:08:17 1986
Date-Received: Tue, 11-Feb-86 06:36:08 EST
References: <763@brl-smoke.ARPA>
Reply-To: g...@brl.ARPA
Organization: /usr/local/lib/news/organization
Lines: 16
>PS: My manager worked with Doug for a while at the P1003 meetings and tells
>me that he is 100% anti-BSD in person as well. Notice that both of these
>gentlemen work in a "mixed" environment of BSD/SV. Maybe oil and water
>don't mix? How about it Pyramid? DCS
Your information is not entirely correct. If I were 100% anti-BSD
you can bet I would not be running 4.nBSD on my systems. At the
P1003 meeting (singular) that I have attended so far, I was one of
the few people who were being particularly careful that the draft
POSE standard be phrased so that 4BSD-based kernels could meet the
specifications without doing violence to cherished improvements
such as reliable signals, sockets, etc. I am also clearly not 100%
pro-System V, as those who have read my comments when I post bug
reports know. I am one of a small number of people in a position
to evaluate both UNIX variants from both a technical and a marketing
viewpoint, and I call `em like I see `em. Sorry you don't like that.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!sun!chuq
From: c...@sun.uucp (Chuq Von Rospach)
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <3228@sun.uucp>
Date: Mon, 10-Feb-86 12:40:34 EST
Article-I.D.: sun.3228
Posted: Mon Feb 10 12:40:34 1986
Date-Received: Wed, 12-Feb-86 20:09:54 EST
References: <763@brl-smoke.ARPA>
Organization: Third Person, Omniscient
Lines: 35
> You guys
> really should square off at a Usenix BOF some time and we can vote on the
> winner.
Hmm... Maybe Unix Review could get one of them to interview the other...
> PS: My manager worked with Doug for a while at the P1003 meetings and tells
> me that he is 100% anti-BSD in person as well. Notice that both of these
> gentlemen work in a "mixed" environment of BSD/SV. Maybe oil and water
> don't mix? How about it Pyramid? DCS
This is a cheap shot. I might as well say "My barber talked to Dave's barber
at a convention and he has dandruff". A typical attack. If you don't like
what a person is saying, attack the person.
Gwyn is in a (relatively rare) position to know the techie details of both
versions of Unix. I find it amusing that people who take a preference of one
system or another out of ignorance (simply because they haven't or won't
work with the other side) attack him for learning both and making a choice.
Something backwards there...
Frankly, any preference between SVRx and 4.x is religious. Either system
should be able to do most jobs more or less as well. These kinds of
backstabbing 'debates' make as much sense as the 'emacs' versus 'vi' jihad's
that go on. Unfortunately, people seem to enjoy them, since the spend a lot
more time arguing techie religions than they do technical stuff.
chuq
--
:From catacombs of Castle Tarot: Chuq Von Rospach
sun!c...@decwrl.DEC.COM {hplabs,ihnp4,nsc,pyramid}!sun!chuq
FidoNet: 125/84
My uncle told me all of this. It must be true, because I know my uncle, and he
is as honest as me.
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 (USS@Tek, v1.0)
based on 4.3bsd-beta 6/6/85; site copper.UUCP
Path: utzoo!linus!decvax!tektronix!teklds!copper!stevesu
From: stev...@copper.UUCP (Steve Summit)
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <188@copper.UUCP>
Date: Mon, 17-Feb-86 22:50:00 EST
Article-I.D.: copper.188
Posted: Mon Feb 17 22:50:00 1986
Date-Received: Wed, 19-Feb-86 20:16:01 EST
References: <755@brl-smoke.ARPA>
Organization: Tektronix, Inc., Beaverton, OR
Lines: 105
Summary: let's not give up on compatibility...
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
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!bu-cs!bzs
From: b...@bu-cs.UUCP (Barry Shein)
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <186@bu-cs.UUCP>
Date: Fri, 21-Feb-86 11:39:49 EST
Article-I.D.: bu-cs.186
Posted: Fri Feb 21 11:39:49 1986
Date-Received: Mon, 24-Feb-86 07:16:27 EST
Organization: Boston Univ Comp. Sci.
Lines: 53
Steve Summit makes some good points about convergence/divergence. One
thought that has bothered me is the "unstoppable force meets immovable
object" effect [concept stolen from a Superman comic of my childhood.]
An excellent example is the csh/sh 'divergence' flamage. Almost everyone
who gets to describe UNIX in broad terms (such as a text) speaks with
pride that UNIX' shell is just a user level program that is easily replaced
to suit needs, it really should be a source of pride and is an excellent
example of some of the generalities that permeate the system's design.
Yet, often in the same text, the incompatibilites of the two shells are
mourned.
The unstoppable force, technological development, and the immovable object,
standards/compatibility, are constantly at odds in these issues. One can
argue that csh just wasn't progress over sh, but that borders on playing
the art critic, it's largely a matter of taste, both are widely enough
in use that their success is self-evident.
The point is, the shell was made replaceable, exactly one major variant
shows up, and wars start. Something is wrong, either with the original
concept or with people's sense of humor. (I know there are other variants,
consider that statement for the purpose of discussion, I am well aware of
uucico.)
Unix lends itself to this, even without sources one can extensively
customize the system and explore alternatives. With the sources you
can start a computing revolution from your own garage (maybe even w/o.)
We must have standards, we do have standards, they're just not perfect
(and may never be.) The syntax and semantics of an operating system are
a little more complicated than FORTRAN66 and we just don't understand
things like distributed operating systems at the level that we do, say,
arithmetic. Everyone agrees we can do better in the standards area,
probably the compromise will be an extension of the standard that has
always been there: There will be a core of very capable features which
if adhered to will provide massive portability. From that secure point
the pioneers may head out to find out where the next standards need to
be, and will wave shouting /* Sorry, only runs on XYZ Unix Ports */.
Put little Venn diagrams in your head, draw the universal set, draw
SYSV, SYSIII, BSD4.2, BSD4.1, V7, V6...
Now add MVS, VMS, AOS/VS, PRIMOS, CP/M, RSX, CMS, MS/DOS...
I think you get my point, enough.
-Barry Shein, Boston University
P.S. INFO-FUTURES, where this discussion will probably travel to, is
being set up, the requests are coming in by the scores (30 yesterday
alone) and I am waiting for things to settle down in a few days (I
hope it settles down!)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!caip!im4u!jsq
From: j...@im4u.UUCP (John Quarterman)
Newsgroups: net.unix-wizards
Subject: Re: ULTRIX futures?
Message-ID: <771@im4u.UUCP>
Date: Fri, 21-Feb-86 16:09:31 EST
Article-I.D.: im4u.771
Posted: Fri Feb 21 16:09:31 1986
Date-Received: Mon, 24-Feb-86 07:28:52 EST
References: <755@brl-smoke.ARPA> <188@copper.UUCP>
Reply-To: j...@im4u.UUCP (John Quarterman)
Organization: U. Texas CS Dept., Austin, Texas
Lines: 56
In article <1...@copper.UUCP>:
>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.
Many of us called for some sort of convergence, but I never
met anybody who believed that the two branches would meld
indistinguishably. BSD does research systems. ATTIS does
commercial ones. The goals are not the same and the systems
will never be identical.
By the way, the PWB/USG/USDL/System III/System V stream diverged
from the V6/V7/Research/V8 stream long before Berkeley got into it.
I doubt Version 8 and System V will ever be identical, either.
>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.
Both systems have been incorporating features from each other
for quite some time. Vi, termcap, mailx, many device drivers,
and lots of other stuff in System V came from Berkeley.
One of the main reasons that System V is a more viable alternative
to 4.2BSD than System III was to 4.1BSD) is the number of things
AT&T picked up from Berkeley.
<Don't bother to flame me about which is an alternative for which, Doug.>
The current forms of open(2), fcntl(2), and getopt(3) in 4.3BSD
came from System V. Of course, Berkeley has had a bigger problem
in incorporating AT&T stuff than the reverse because many of their
licensees can't afford AT&T System V source licenses, which means
that Berkeley can't incorporate System V source code into their systems.
Both incorporate Version 8 features, too. I hear that System V Release 3.0
will include streams. The Berkeley people have said on a number of
occasions that they intend to reimplement streams in some future 4.nBSD.
Some of us today are hoping that the P1003 standard will become
the standard programming interface on both System V and 4BSD
(and other systems) while allowing unresolvable differences
to remain.
Meanwhile, Doug Gwyn's System V-on-4.2BSD package and Pyramid's
universe idea have gone a long way towards reducing many of the
conflicts between the systems. Though not far enough, it's true.
Nonetheless, the bottom line is that research systems and
commercial systems have different goals and will never be identical.
--
John Quarterman, UUCP: {gatech,harvard,ihnp4,pyramid,seismo}!ut-sally!im4u!jsq
ARPA Internet and CSNET: j...@im4u.UTEXAS.EDU, j...@sally.UTEXAS.EDU