Mishkin@YALE.ARPA (12/21/83)
From: Nathaniel Mishkin <Mishkin@YALE.ARPA> I notice that several recent issues of WorkS have been filled with discussions and surveys of various Unix (4.2 and other) -based workstations. Before the notion that Unix is the best and only software for workstations becomes entrenched in the minds of the readers of this list, I'd like to suggest that people attempt to broaden their outlook when thinking about software for workstations. Unix is essentially a small-system (i.e. PDP-11) operating system whose ideas were interesting 5 or more years ago. But Unix is seriously flawed (an opaque user interface and no good tools to control the use and sharing of virtual memory are 2 of its more serious problems). When starting in the new world of workstation computing, I think we would do well to learn from the Unix experience, but not produce a copy of Unix. Yet despite its problems, Unix appears to be becoming a standard. Why? I suspect for a number of reasons. Conservatism -- despite being a high tech and rapidly evolving field, computer science (take this phrase to encompass more than academics) is filled with a large number of people who become very set in their ways very easily. I think we must work hard to overcome this tendency to ossify. Compatibility -- "everyone's using it, and I want to be able to share programs with other people". Clearly this is a desirable goal, but one that has to be put in perspective. Why aren't you using Fortran (the most compatible programming language in existence)? Presumably, because you have realized that there is a price to be paid for that level of compatibility and you are unwilling to pay it. Besides, it's not clear what "Unix compatibility" is going to mean. Already there is divergence. I suspect that within a few years the only compatibility you're going to find is between systems produced by the same company. This will be "Pascal compatibility": everyone will have realized that the base is not enough and will extend it in multiple incompatible ways. And if you think that systems hackers are the types that restrain themselves to writing in compatible subsets, I think you're wrong. The point here is that if you're choosing between a "Unix" (the mythical standard) system and a non-Unix system that supports some level of Unix emulation, don't simply assume that the emulator is in the long run going to be less compatible with "Unix"; once you've made the fair comparison, take a look at what the non-Unix system has to offer that the "Unix" system doesn't and add that into the equation. Price -- Unix is "cheap" and you get all sorts of software from other people "for free". Whenever I hear this sort of argument, I am reminded of the "Russian soldiers are 10 feet tall" argument. People "out there" (the Russian soldiers) are rarely doing such great things that importing their software is free. Too many times, I have gotten software from "out there" that doesn't really work, or doesn't really do what I want, and I realize that I would have been better off writing it myself. And if I am going to do it myself, I damn well want the best environment to do it in, not the one that is simply compatible with everyone else's.
henry@utzoo.UUCP (Henry Spencer) (12/29/83)
Nathaniel Mishkin asks:
...despite its problems, Unix appears to be becoming a standard.
Why? I suspect for a number of reasons...
He then cites conservative designers, possibly-imaginary compatibility
with other Unix systems, and seemingly-low cost. He has missed the three
biggest reasons:
1. It runs on everything. (Well, nearly.) Why spend man-decades
building your own new system when a few man-months of effort will
suffice to port Unix? Sure, it isn't the answer to everyone's
prayers, but the cost/benefit ratio is still most impressive.
I suspect this is the major reason for its use on many oddball
gadgets like the Cray-2: it's the easiest way to get a decent
operating system.
2. We need a standard, even if it only serves as a point of
departure for future work. Unix is the obvious candidate, with
wide enthusiasm and respectable functionality.
3. (The Big One) It's one of the best things going. Like Algol
and Pascal, it's an improvement not only on most of its predecessors,
but also on most of its so-called successors. Of course it has
flaws, but it's an appealing mix of simplicity and power. Systems
like that are uncommon, and deliberate attempts to improve on them
seldom capture the same magic elegance.
I agree that better things are possible, although I have grave doubts
about most of the current attempts to produce them. Sooner or later
somebody will come up with something strikingly better and it will then
start to replace Unix. But it really will take something *strikingly*
better, and that will probably be the result of new insights rather than
attempts to "patch" Unix. Until then, remember that most of the other
possibilities are worse. Sure, you can do better than Unix for a
workstation. But you can easily -- very easily -- do a lot worse.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryMishkin@YALE.ARPA (01/04/84)
From: Nathaniel Mishkin <Mishkin@YALE.ARPA>
From: decvax!linus!utzoo!henry @ Ucb-Vax
Nathaniel Mishkin asks:
...despite its problems, Unix appears to be becoming a
standard. Why? I suspect for a number of reasons...
He then cites conservative designers, possibly-imaginary
compatibility with other Unix systems, and seemingly-low cost.
He has missed the three biggest reasons:
1. It runs on everything. (Well, nearly.) Why spend man-decades
building your own new system when a few man-months of effort
will suffice to port Unix?
I wasn't suggesting that you go out and build a new system. Rather,
I was suggesting that you shouldn't reject out of hand some already
developed non-Unix system.
2. We need a standard, even if it only serves as a point of
departure for future work. Unix is the obvious candidate,
with wide enthusiasm and respectable functionality.
Standards are a good thing. Again, my point was not that you shouldn't
use Unix but rather, that your Unix might be satisfied on a system
that has some sort of Unix emulation in the context of a larger, cleaner
and more interesting and useful system.
3. (The Big One) It's one of the best things going. Like
Algol and Pascal, it's an improvement not only on most of
its predecessors, but also on most of its so-called successors.
Of course it has flaws, but it's an appealing mix of simplicity
and power. Systems like that are uncommon, and deliberate
attempts to improve on them seldom capture the same magic
elegance.
This is exactly the sort of statement that led me to suggest that
people actively attempt to widen their horizons. Look at some other
systems; read their manuals; be critical; get a demo and use it for
a month; do all this before dismissing a non-Unix system. If you
think you don't have the time, consider the time that users will lose
if you buy a system that is not the best they could have had.
Anyone who has seen and recalls any of my past submissions to "WorkS"
knows that I am an Apollo fan. I do not want to hide my biases. I
can list numerous ways in which the Apollo improves upon Unix in both
user and programmer interfaces without sacrificing elegance and
simplicity (although the Apollo is not Unix and is not in any sense
"based" on Unix, it was clearly influenced by Unix ideas and as such
can be considered an improvement *on* Unix rather than a completely
separate, incomparable system).
It's hard to learn about other systems. It's hard to look at things
in an unbiased way. If I listed a few things about the Apollo that
I thought made it better than Unix, I'm sure I wouldn't convince anyone.
Such opinions are formed only after using a system for months. Consider
it a testimonial -- I've used both Unix and the Apollo (and TOPS-20
and OS/MVS and VM/CMS and RT-11 and who knows what else) extensively
and I'm saying "give the Apollo and other non-Unix systems a very
close look -- they may have something to offer for you".mike%rice@sri-unix.UUCP (01/04/84)
From: Mike Caplinger <mike@rice> One major advantage to running 4.2 Unix on our Suns is that we are then compatible with all the software we develop on our VAX systems. This is a terribly important consideration if you want to easily develop a network composed of different machines, and yet have it appear homogeneous to the user. As more manufacturers announce "4.2 Unix" for their new machines, this will only get more important. (One can only hope that they will be compatible with each other. So far, SMI and Berkeley are.) I'm sure that Aegis and other new operating systems approach networks and workstations more elegently that Unix does, but as a proprietary system it seems unlikely that Aegis will run on anything but Apollo machines. If that's all you have, fine, but many are not in that position. Unix emulations, as we at Rice know all too well, are nearly always not close enough to do a lot of good. I don't know of any that can emulate the full range of 4.2 networking on an Apollo. Unfortunately, I think most workstation manufacturers who are offering Version 7 or System III ports of Unix are doing everyone a grave disservice; neither of those systems even knows what a network is, and the plethora of incompatible extensions is no help at all. 4.2, on the other hand, has a good chance of providing the needed functionality.
Tague%pco@CISL-SERVICE-MULTICS.ARPA (01/05/84)
I agree with Randy Saunders' remarks about the Unix system and its
becoming a standard. Unix is not a bad operating system. Perhaps its
most remarkable feature is that there are so many other systems that are
much worse. I guess since the chance of getting a system worse than
Unix is still pretty high, to say that one has Unix is to say that one
meets a certain minimum standard.
I also agree that it would be better to define a standard set of
features, rather than a standard piece of code. Who knows with a little
work the standard may even reach to the level of Multics itself. Then
we could talk about all the Multics look alikes instead of the Multics'
little brother (Unix) look alikes. Someday.
Michael TagueRSaunders.TCSC%HI-MULTICS@sri-unix.UUCP (01/10/84)
[flame on] I think that Mr. Spencer missed the mark in his reply to Mr. Mishkin. It is important to consider more than just the quick-and-dirty solution to a problem. > Why spend man-decades building your own new system when a few man-months > of effort will suffice to port Unix[(tm)] ? Why bother to do anything if the existing stuff is so cost-effective? One of the major items of discussion in this digest is what sort of workstations we will need in 5 years and how to get them. I will admit that if I was playing catch-up ball getting into the workstation market I would port Unix(tm) and try to get some business. However, in the search for a "standard" workstation OS stopping at Unix(tm) is taking the first thing you find. > It runs on everything. [...] (The Big One) It's one of the best > things going. I would suggest that the two statements above are simply not addressing the proper question for a standardization effort. If it runs on everything then it makes use of nobody's features. This implies that the PDP-11 is the ultimate in computer architectures, not a widely held opinion. Standardizing on "the best thing going" is a mistake for two reasons. Being better than something else is a VERY subjective decision. I can say "Multics is THE BEST thing going". Since I have used both and you may not have do you consider the issue redecided in favor of Multics? I would think that the way to standardize things is to define a standard set of functions and their effects. This would mean that as long as all the subroutine calls worked the same two unrelated operating systems could be considered "compatible". This is the approach taken by most(?) Unix-compatible people. I would consider the normal Unix(tm) subroutine interface library less than minimal as far as a standard. Items such as segmentation support, process protection, and multi-processor synchronization are desparately needed in a work station OS of the future. The last thing we need to do is immortalize a particular piece of code. Sorry for the flaming. Randy Saunders RSaunders @ HI-Multics