Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <7511@brl-smoke.ARPA>
Date: 21 Mar 88 12:25:47 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> <20768@bu-cs.BU.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 40

In article <20768@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
>What's the issue here? Just a matter of time or is there some real
>objection to adopting the BSD file system?

I don't think there is any real problem with providing the 4.2BSD
style of disk file system in UNIX System V via the file system
switch.  Implementations that currently support the old-style disk
file system will probably continue to do so in order to avoid
forcing the customer to rearrange existing disks when upgrading.
Note that several UNIX System V implementations already use a
different style of disk file system; for example, Silicon Graphics
has an extent-based scheme.  The nice thing about the FSS is that
it provides a relatively painless way to migrate from one style to
another, or to provide a special format, e.g. real-time data files,
which may have different needs from general timesharing files.

My evaluation of the 4.2BSD cluster approach is that it works best
if the processor has cycles to spare, and may not be a good choice
for small systems.

>Also, adopting a standard and top-notch TCP/IP implementation with
>several of the needed utilities bundled in is critical to many of
>us and would force our hand if lacking.

Unfortunately, the implementation you probably have in mind is
tightly coupled to sockets.  Wollongong developed a STREAMS-based
TCP/IP for AT&T; I don't know how good it is but there is no a
priori reason that a STREAMS implementation couldn't be as good as
one based on sockets.

One thing that a totally-STREAMS version of UNIX System V would
achieve is transparency over "pseudo-tty" channels, so that terminal
ioctls would work right.  I've needed this many times on our 4.2BSD
systems and have had to punt on it.

>I would have to suspect that the ATT/SUN merger is going to resolve
>these issues...

Certainly most of us hope so.  AT&T is definitely evolving UNIX far
faster than they used to.