Path: utzoo!mnetor!uunet!husc6!bu-cs!bzs From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.unix.wizards Subject: Re: SVR3.0 vs BSD4.3 Message-ID: <20790@bu-cs.BU.EDU> Date: 21 Mar 88 17:23:52 GMT References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> <2423@bsu-cs.UUCP> <7514@brl-smoke.ARPA> Organization: Boston U. Comp. Sci. Lines: 30 In-reply-to: gwyn@brl-smoke.ARPA's message of 21 Mar 88 13:37:04 GMT 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