SVR3.0 vs BSD4.3

[Doug Gwyn]

In article <2423 at bsu-cs.UUCP> dhesi at bsu-cs.UUCP (Rahul Dhesi) writes:
>In article <7499 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
>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.