SVR3.0 vs BSD4.3

[Barry Shein]

Well, I would agree with both Doug and Rahul on those point-by-points,
they seem to fall into two cases, those that are effectively provided
already or soon to be and those which really are applications which
could be ported (eg. finger, we had our finger running under SVR1, I
don't remember any great pain in moving it over.)

One point that has been perhaps missed is that a critical reason for
wanting the 4BSD file system is, besides performance, integrity,
backups etc, semantics across remote file systems. What exactly
happens when you copy a file with a long name to a SysV remote file
system? I've heard truncation (that's no good, could conflict or cause
various problems) and I've heard error returns (also less than
desireable.) The reverse shouldn't be true, so the option of running
all 4BSD file systems would be very desireable.

Most of the other points seem non-important (job control is important,
but there's no reason dbm couldn't be ported, for example, it's user
level, I'm sure it's been ported, and providing a good ISAM etc
library and migrating to it would be a good idea, as long as no one
makes the mistake other vendors did and shoves it in the kernel or
starts making utilities use it that have no business using it, that
is, most of them, I remember running RUNOFF on VMS once and saving the
output to a file to edit a few things only to find that EDT would not
edit a RUNOFF printer format file because it was stored in some wierd
record format! Outrageous, I won't even tell my IBM horror stories
where a "cp" command is non-existant for this reason.) I'm sure the
Unix community has more common sense than that.

	-Barry Shein, Boston University