henry@utzoo.uucp (Henry Spencer) (05/29/88)
Having posted some articles which might be interpreted as saying "OSF is
a good thing", I should clarify my position a bit. Especially since I
think there is a big, important issue that everyone is missing.
In abstract, I think OSF is a fine idea. AT&T and Sun badly need some
competition: they have been thinking and acting like a monopoly, with a
divine right to dictate standards to the rest of the world. AT&T has
been doing this for a long time, of course, but nobody got too unhappy
about that because AT&T's attempts to become a competitor in the computer
business were so clearly a joke. For all practical purposes, AT&T was in
the software business, and by and large treated all the hardware vendors
with equal contempt. Not an ideal situation, but tolerable. Their recent
actions, and in particular their alliance with a big, dangerous competitor
in the hardware business, have changed the situation radically. It does
not really matter whether AT&T really intended to be open-handed and just
botched the job; appearance is as important as reality in such things,
and AT&T made no attempt to give an appearance of impartiality.
In practice, I have grave doubts about OSF. The list of founding members
does not exactly build confidence in its ability to do a good job on Unix.
All the more so when one hears about plans to use major items of software
from said members, much of which is wretched sludge. Yet worse are clear
indications (well, they seem clear to me) that OSF is going to be an army-
of-ants operation run by committee; this is the very antithesis of the
sort of organization that would produce clean, high-quality software.
And this brings me to the heart of my current unhappiness. Because to
someone interested in clean, high-quality software, there isn't a whole
lot of difference visible between "AT&Sun" and OSF. The former is openly
committed to supporting the union of all wishlists rather than being
selective. The latter almost certainly will go the same way; it could
avoid this only if it were run by a few strong-minded people with the
courage, technical strength, and stubbornness to resist the promise-the-
customer-everything attitude of the marketing bozos... and as near as I
can tell, it's not.
Consider the merged Unix of the AT&Sun group. It will support two sets
of system calls, System V and BSD/Sunnix. It will support two different
network file systems. It will support everybody's wishlist of network
protocols, including the OSI ones that haven't even been invented yet.
This was what provoked my remark at the Dallas Usenix: "the people who
talk about closing the gap between different Unixes aren't talking about
narrowing the gap, but about filling it in."
Here we pause for a word from our sponsors: "...the kernel should make
as few real decisions as possible. This does not mean to allow the user
a million options to do the same thing. Rather, it means to allow only
one way to do one thing, but have that way be the least-common divisor
of all the options that might have been provided." (Ken Thompson, 1978)
Remember those words? A long time since you've seen anyone acting on
that principle, isn't it? Do you really expect AT&Sun or OSF to do so?
The people who talk about "setting the future direction of Unix" have
already abandoned the basic philosophy that made Unix successful. Mostly
they're proud of it, too. It's all downhill from here. Anyone want to
bet on how long it will be before the size of the Unix documentation
exceeds that of the OS/370 documentation? OS/370 has a head start, but
Unix is gaining fast as everyone enthusiastically adds features to it.
The system whose reputation was built on simple, powerful elegance has
already lost those virtues.
OSF could reverse this. Make the technical director someone along the lines
I mentioned above: high technical qualifications, a loud voice, no fear,
firm commitment to independence and portability, and fierce dislike for
unnecessary complexity. Have him pick a small team of very good people,
and set up defences to keep the marketdroids and the mismanagers off their
backs. Give them the resources, and the time, needed to do the job right,
rather than having to accept existing botches in the interests of expediency.
The result probably wouldn't be 100.0% compatible with current systems, but
porting to it shouldn't pose difficulties greater than those we live with
today. And it would be far superior as a base for future development, even
with the constraints imposed by having to be pretty much Unix-compatible.
Unix has accumulated a lot of warts over the last decade; there is plenty
of room for simplification and unification without introducing massive
compatibility problems. A small team couldn't address all the problems
of porting to 57 different machines, talking to every conceivable network,
and so on. But hard work and insight could produce sufficiently clean and
flexible interfaces that these chores could be entrusted to more orthodox
development processes without risking devastating results.
OSF could do this. But *will* it? I'd be very surprised. And that's why
I think OSF is a side issue. It may well make a positive contribution by
shaking some of the smug arrogance out of AT&Sun. But it won't solve the
real problem: the steady degeneration of a clean, powerful system into a
huge, complex, warty mess. That would take a minor miracle. Both AT&Sun
and OSF are physically capable of producing one. But neither will.
--
"For perfect safety... sit on a fence| Henry Spencer @ U of Toronto Zoology
and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henrychris@mimsy.UUCP (Chris Torek) (05/30/88)
In article <1988May29.014006.4964@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >... the real problem: the steady degeneration of a clean, powerful >system into a huge, complex, warty mess. Can *you* say `entropy'? :-) I think it might be helpful to note that V6 had its warts, and V7 had a few, and no doubt V8 and V9 have their share. The important thing is that the warts in V6 were excised in V7, having been replaced by something cleaner. The battle cry of `compatibility' (which Henry himself has raised against some of the things Berkeley has done) serves to hinder the replacement or removal of misfeatures. `Gratuitous incompatiblity' is a different issue, but Henry and I often disagree as to what is `gratuitous'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
henry@utzoo.uucp (Henry Spencer) (06/01/88)
> ... The battle cry of `compatibility' (which Henry > himself has raised against some of the things Berkeley has done) serves > to hinder the replacement or removal of misfeatures. Agreed, but it does not make it impossible, necessarily. It's an additional and often annoying constraint on the process, but cleverness can still get the job done much of the time. The obvious method is the one that was used in the V6-V7 transition, which Chris alluded to, to support the V6 stty() and gtty() system calls even though V7 used ioctl() instead: define the new interface carefully and then implement the old one in terms of it. Eventually you can consider removing the old interface, but the important thing is that people can start doing it right without having all their old software suddenly break. It's not always possible to do this -- the V6-V7 ioctl business was admittedly a favorable case -- but much can be done if one tries. (My complaint about Berkeley is that they seldom try.) One does also need the courage (and backing) to break things now and then. My belief is that it would be possible to produce a much cleaner system that one could port to without experiencing *more* trouble than one does going between variants today. Note that I'm not saying it would be totally painless, just that it would not require exceptional effort. -- "For perfect safety... sit on a fence| Henry Spencer @ U of Toronto Zoology and watch the birds." --Wilbur Wright| {ihnp4,decvax,uunet!mnetor}!utzoo!henry
dupuy@douglass.columbia.edu (Alexander Dupuy) (06/04/88)
In article <1988May29.014006.4964@utzoo.uucp>, Henry Spencer writes: > In abstract, I think OSF is a fine idea. AT&T and Sun badly need some > competition: they have been thinking and acting like a monopoly, with a > divine right to dictate standards to the rest of the world. This brings up something I thought of when I first read about the OSF announcement: what we are seeing here is a classic example of the dialectic (as in the Marxist concept of "dialectical materialism"). Just as the first major divergence of Unix (BSD vs. USG) is finally nearing it's resolution in the SunOS/SysV merge, we are about to see a new divergence, between the merged "Enhanced System V" and what ever the OSF plans to call their Un*x variant. At some point in the future (perhaps in 10-15 years or so) these two will be resolved into a merged Unix, and a new variant will diverge, and start a new cycle. This is not necessarily a bad thing. In fact, by having two mainstream variants of Unix, different approaches can be tried, and can compete against each other, and the best features of each will be merged into the next stage. At his talk at SUG last December, Bill Joy even said something to the effect that the point of merging BSD and System V was so that the basics could be standardized, and innovators could go ahead and work on the new problems, like integrating AI or expert systems or object oriented systems into Unix. And having two main variants is ever so much better than having 3, or 4, or N, different versions. Things like HP-UX, and dual universe ports like Pyramid's or Masscomp's Un*xes make porting a real hassle, because systems have some features but not others, or worse, have all the features, but you can only use one or another subset at one time. It would be far more interesting than speculating on the motives of the various players in this drama, if people would discuss what they think the basic dialectic conflict between the ESV and OSF camps will be. Some have characterized the conflict between BSD and USG as one of featured, but baroque complexity (and gratuitous changes) versus stripped down redesign. While this isn't completely true (AT&T has made their share of gratuitous changes, and some parts of System V are almost as baroque as BSD) it is a useful generalization. > OSF could reverse this. ... pick a small team of very good people, > and set up defences to keep the marketdroids and the mismanagers off their > backs. Give them the resources, and the time, needed to do the job right, > rather than having to accept existing botches in the interests of expediency. > ... > Unix has accumulated a lot of warts over the last decade; there is plenty > of room for simplification and unification without introducing massive > compatibility problems. Perhaps, as Henry Spencer posits, the spare and lean vs. complex and featured conflict will be the new dialectic, as well as the old. As he notes later, probably not. I'm not familiar enough with AIX or Apollo's NCS to guess where OSF might go with their Unix. But it should be interesting to watch. And eventually, ESV and OSF will be merged (perhaps in a IEEE standard? :-). Then will come the _real_ dialectic: IEEE-ESV/OSF vs. GNU. That's a battle I won't want to miss. @alex -- inet: dupuy@columbia.edu uucp: ...!rutgers!columbia!dupuy
mash@mips.COM (John Mashey) (06/07/88)
In article <5668@columbia.edu> dupuy@columbia.edu (Alexander Dupuy) writes: >Just as the first major divergence of Unix (BSD vs. USG) is finally nearing >it's resolution in the SunOS/SysV merge, we are about to see a new divergence, >between the merged "Enhanced System V" and what ever the OSF plans to call >their Un*x variant. At some point in the future (perhaps in 10-15 years or so) >these two will be resolved into a merged Unix, and a new variant will diverge, >and start a new cycle. 1) It's hard to categorize "major divergences", except in retrospect, when they're coming back together. UNIX is always diverging/converging. Here are a couple examples: 2) There was at least one major divergence inside Bell Labs in the mid-70s: the convergence was getting USG + PWB + (others) back together, synchronized around Edition 7, and the UNIX/TS 1.0, PWB/UNIX 2.0, System III, 4.0, and System V stream. (Of course, this was at the same time as Lab 127 was off doing Edition 8 & later...:-) 3) I'd suggest that XENIX divergence was another major one. 4) The BSD/System V split is at least the 3rd; note that many vendors already offer merged versions, so the split is not as bad as it might be. 5) The mutation/selection cycle is more like 6-8 years, although it's fuzzy, because it's clear that it's starting to happen long before it's finished. None of this is new: the battles inside BTL amongst UNIX variants (+ MERT, too) were pretty fierce, and for all of the same reasons: a) Take UNIX because it's at least close to what you need. b) Modify it because it is'nt 100% what you really need. c) Lobby like crazy to get your goodies accepted as part of the next standard version, so YOU don't have to continually retrofit your necessary changes into every new version, and so you don't get somebody else getting their [similar, but not as good as yours] feature in there, causing you to have to change... The fundamentals of this game haven't changed much in 10+ years, just the size of the playing field and the number of players :-) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086