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: <7514@brl-smoke.ARPA> Date: 21 Mar 88 13:37:04 GMT References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> <2423@bsu-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 109 In article <2423@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <7499@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) >writes: >[arguments why SVR3 is as good as 4.3BSD on all counts] I said on all MAJOR counts. There are lots of small items on each system that the other could benefit from. I named some, you named some, and there are lots more. > job control (stop/restart jobs, get status of jobs and know > one is stopped for tty input) As I mentioned, the System V equivalent is "shell layers", which is not quite as nice from the user's perspective but it sure disrupts the system internals less than the 4BSD approach (which has been revised one way or another at least five times that I am aware of and still occasionally causes us problems). The 4BSD scheme for various reasons does not readily fit into System V; I think the scheme worked out for IEEE Std 1003.1 will probably be included in a future release of UNIX System V. > intelligent echoing to screen (SVR3 seems to blindly echo > everything or nothing, can mess up screen, won't redraw > partially-typed line, won't align tabs on char erase) I mentioned this. There is no particular reason most of these features could not be added to the System V terminal handler, and it would be useful if they were. Except for the user interface, the System V terminal handler is clearly superior for most applications, as the Berkeley developers have acknowledged; I think they've developed a POSIX-compatible replacement terminal handler but I don't know how you can get your hands on it. > intelligent mail handling -- sendmail, MH, biff, vacation Doesn't matter to me; we use MMDF, $MAILPATH, sysmon, etc. > "script" for recording terminal session "Script" screws up the application running under it sometimes. It could be implemented almost trivially with STREAMS. Somebody should do so. > "ul" for underlining when printing on various printers Another one we don't use. MDQS's line-printer spooler does a much better job, and our other printers know how to underline. > one complete KWIC index for all manuals That might be handy, but UNIX System V is intended to be distributed as a set of packages, many of them optional, so it is hard to see how to prepare such a merged index that would be maximally useful. > symbolic links Probably coming in a future release. As discussed previously, they do bring some problems, but are nonetheless probably worth having. > long filenames This is tied to the disk filesystem format, and unlike Berkeley, AT&T chose not to invalidate their customer's existing filesystems. However, the FSS now provides a mechanism for graceful migration to an improved filesystem in which longer names would be possible. I don't know if they're working on it, but undoubtedly it would come out of the AT&T/Sun merged-UNIX project. > a user can be in multiple groups Probably coming in a future release. I hope they fixed the Berkeley bug that kept me from logging in when the system administrator added me to my ninth group! > user information lookup ("finger", "lastcomm", "last") I don't use these, so no comment. > UUCP over TCP/IP links Supported by UNIX System V, last I heard. > support for multiple command interpreters with #! as first line of script This is totally unnecessary; if all scripts are executed by a Bourne shell, it is easy to simulate the #! feature, in fact to generalize on it. Nevertheless I think AT&T may be adding this kludge to the kernel exec code in a future release, alas. > dbm library--fast /etc/passwd and /usr/lib/news/history access etc. There are other ways to speed up /etc/passwd access that don't have the drawback of maintaining a separate index file. A good, standard ISAM would be useful, but dbm ain't it. > context diffs from diff This could be added easily enough, and I considered adding it to my System V emulation package but decided it wasn't particularly useful. > smarter, friendlier "at" program Another thing I don't care for; we use MDQS "batch" facilities. System V has user (non-superuser) crontab support that seems nice. >A note about UUCP: Although theoretically HDB UUCP is the equal of the >4.3BSD UUCP, ... Wrong; theoretically it is superior to 4.3BSD UUCP.