AT&T/Sun merged UNIX

[Barry Shein]

Posting-Front-End: GNU Emacs 18.41.4 of Mon Mar 23 1987 on bu-cs (berkeley-unix)



(Responding to a note from Eric Roskos)

Actually, I disagree.

>In terms of the "modern needs" above, how much of that is *really*
>necessary?  For example, for remote file systems you'd ideally like them
>to look, to the user, like a local filesystem (with possibly a small number
>of maintenance services added, but independent of the normal filesystem
>services).  Likewise for windowing (an opinion based on experience with
>the Macintosh, although I am expecting that discussion of this issue
>will reemerge when OS/2 and its Presentation Manager come out, given
>experience also with programming under Windows).  If you accidentally
>standardize a lot of low-level features that turn out to be unnecessary,
>you end up severely limiting future growth.

Remote file systems are a tough example because their goal of course
is transparency (ie. support all Unix system calls precisely as the
local disk does.)

Unfortunately in practice there are these "little" nits (eg.
statelessness vs statefulness, perhaps new error codes or mount
options), I suppose one could come up with an abstract super-set, so
let's leave all that for a moment.

The real issue is from the vendor's point of view. Sure I can deliver
any reasonably transparent remote file system software, ok, here I am
with my WHIZBANG1000 just out of hardware engineering. Which remote
file system do I put on it? If I want to support a remote file system
I have to pick one, the fact that they're all roughly alike and don't
interoperate is a problem, not a solution. If one is standard and is
even right on the source tape, hmm, maybe...

Windowing I think is an easy issue to respond to. It's critical.
Again, you're a vendor, you're planning an interactive software
product which could use windows effectively. What do you choose to
code? You don't want to code all of them, you have to choose one. To
improve marketability you want to choose something standard. In fact,
this particular issue is so bad that the truism going around (which
may very well be true, I don't know) is one reason you don't see
products like Excel on Unix workstations is simply that they're
waiting until Unix presents a standard window interface so they can
port their code once and just sell it, not port it over and over again
to everyone's new idea on how to arrange little boxes of 1s and 0s on
a tube. Absolutely critical.

>As for networking, issues of protocols should not show up in a mainline
>Unix standard, should they?  This is not to say someone should not 
>standardize network protocols (and of course that is being done), rather
>that they should not tie in with Unix at the level the current standards
>groups are working.

Why not? In the first place, a standard just says you should support
this to claim you are standard, not that you don't have anything else,
so it shouldn't limit anyone other than the time and trouble to get
the standard working correctly (if it's truly a successful standard
the effort should be worthwhile.)

Something like networking ripples to other parts of the system, like
remote file systems and windowing software (although most can work
with any byte stream, they still need to use a standard stream
interface to interoperate, you still have to pick one.)

What's the problem anyhow? TCP/IP is a de facto standard, almost all
vendors offer it as a primary product anyhow, it's available, it works
etc.  Let's put it into the standard and onto the source tape and go
on to other things. If something else comes along we'll argue about it
then. You're not burning bridges with standards, you're saying there
is a way across the river even if a better bridge comes along later.

	-Barry Shein, Boston University