Berkeley terminal driver user interface

[Erik E. Fair]

> From: boyd at basser.SUN (Boyd Roberts)
> Subject: Re: Berkeley terminal driver user interface
> Date: Fri, 13-Apr-84 10:04:56 PST
> Organization: Dept of C.S., University of Sydney
> 
> >   I think more praise is due the user interface.  It is a
> >   good thing for a computer program to be simple outside
> >   (specification) and simple inside (implementation); but
> >   a computer is used best when a program is simple outside
> >   but complex inside--the user sees the simplicity, and
> >   the computer takes care of the complexity.
> 
> How can you say that the Berkeley terminal driver (i.e. job control) 
> provides a simple outside world?  Do you not have to fix things
> like vi, more and (of all things!!) the shell to understand
> about what the terminal driver is likely to do?  However only C-shell
> was fixed (C-shell too slow).
> 
> What do you do when your program dies on a SIGTINT or somebody
> you fork hits you with a SIGTTIN or SIGTTOU?
> 
> But Berkeley told you it was ok, so there's no worries.
> 
> 
> Boyd Roberts			...!decvax!mulga!boyd:basser

YOU MISSED THE POINT! Let's forget the internal implementation for a
moment, which we all seem to agree is rather unfortunate. The point the
gentleman was trying to make is that the Berkeley tty driver (job
control most certainly NOT included) is a pleasure to use. There is
no ambiguity as to what exactly you typed at any time. From the user's
point of view, the Berkeley tty driver is far superior to the Bell tty
driver, v7 OR System III/V. This I assert, as a USER.

Job control is a separate issue, for which the Berkeley tty driver was
modified to provide another set of signals bound to user settable
characters.  Again, as a USER, the job control stuff is wonderful to
use. It allows me the flexibility to change my mind after I have
started something. The number of times under non-job control systems
that I have started a program running, and then wished I had shoved it
in the background to begin with is beyond counting. The `tostop' stuff
solves a long standing problem with the v7/sIII/sV tty driver, namely,
when there are two programs contending for tty input, which one do you
give the next character/line to? Prior to Berkeley, it was whoever was
run by the scheduler next. With Berkeley's tty driver and job control,
you stop the process group that is in the background.

Now, let me change hats here...
(I know I have my wizard's cap in here somewhere... Ah, here it is)

As a UNIX systems programmer, I agree with what you have said. The
internals of the Berkeley tty driver are horribly convoluted, and the
job control stuff complicates matters beyond reason. BUT! Unlike Bell,
the Berkeley CSRG took the time and trouble to modify the affected
programs, so that you didn't have to, when you got 4.1BSD. This is
considerably more than I can say for Bell, who, when they dropped
System III on us with a completely new tty driver, still had stty/gtty
calls in a significant number of important programs (e.g. getty).

I suggest two rules for making Kernel mods (as distinguished from
additions):

	1) If you're going to break something, break it ALL the way.
		Don't leave vestiges of the old world lying around
		for people to trip on.

	2) Be sure to go back and fix all the affected software.
		If you don't have the guts to do so, the original change
		wasn't important enough to you and you shouldn't have made it.

Now, just what have you done for UNIX lately, Mr. Roberts? I have respect
for Rob Pike when he complains about UNIX, because in his realm, he did
something about it. He didn't like the UNIX tty driver or Berkeley job
control. So he (and presumably others) designed the BLIT, which we all
know (well sort of) as the TTY 5620, as an answer to that. It so happens that
I disagree with some of what Mr. Pike has to say, but the TTY 5620 stands as
his counter proposal as `the right way to do things'.

Without that kind of counter proposal, your criticism becomes no more than
informed whining.

	Erik E. Fair	ucbvax!fair	fair at ucb-arpa.ARPA

	dual!fair at Berkeley.ARPA
	{ihnp4,ucbvax,cbosgd,decwrl,amd70,fortune,zehntel}!dual!fair
	Dual Systems Corporation, Berkeley, California