Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!decvax!decwrl!sun!tut
From: t...@sun.uucp (Bill Tuthill)
Newsgroups: net.unix-wizards
Subject: UNIX Futures
Message-ID: <3289@sun.uucp>
Date: Mon, 24-Feb-86 19:04:17 EST
Article-I.D.: sun.3289
Posted: Mon Feb 24 19:04:17 1986
Date-Received: Wed, 26-Feb-86 07:35:36 EST
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 24
Let's not lose perspective by emphasizing differences between 4 BSD
and System V. The two UNIX variants are at least 95% similar. It's
not overly difficult to write software that will run on both (the more
complicated the software, the harder it is, though). What's really
good about UNIX was implemented by Thompson and Ritchie in the early
days, and described in the famous CACM paper. The good stuff hasn't
changed substantially since then.
Just think of all the things that work on both 4.2 and SV: | > < cc,
to name just a few. Adherents of 4 BSD think of themselves as rebels
fighting evil Darth Vader and the Death Star, but in the real world,
the distinction between good and evil isn't as clear as in the movies.
Some people I know at a prestigious west-coast university just finished
implementing alternatives to "cut" and "paste"; had they been familiar
with System V, this wouldn't have been necessary. I can't help but
form similar opinions about AT&T's networking efforts.
I regularly use both 4 BSD and System V, and find the transition even
less difficult than driving someone else's car. The main thing that
bothers me about System V is the lack of word erase (^W) in the tty
driver. It's like driving a car with no windshield washer. Others
no doubt have different pet peeves.
Bill Tuthill
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!
seismo!mcvax!ukc!cstvax!scott
From: sc...@cstvax.UUCP (Scott Larnach)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <67@cstvax.UUCP>
Date: Thu, 27-Feb-86 08:45:38 EST
Article-I.D.: cstvax.67
Posted: Thu Feb 27 08:45:38 1986
Date-Received: Sun, 2-Mar-86 19:37:40 EST
Reply-To: sc...@cstvax.UUCP (Scott Larnach)
Distribution: net
Organization: Unix Support, Edinburgh Regional Computing Centre
Lines: 14
The one and only real thing which bugs me about system V is the
total lack of job control. e.g. in the mail program and having to check
something out .. fancy being faced with either writing your mail
out (and later having to read it in again), or having to fork up
another shell. With a big load up either of these options can be
painful. The functionality of ^Z and fg is tremendous!
Come on, AT&T, give me job control and I'll be a believer.
--
Scott Larnach Janet: sc...@uk.ac.ed.cstvax
Edinburgh Unix Support Arpa: sc...@cstvax.ed.ac.uk
Tel: +44 31 667 1081 x2629 Uucp: sc...@cstvax.uucp
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84; site maynard.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!genrad!panda!
talcott!wjh12!maynard!campbell
From: campb...@maynard.UUCP (Larry Campbell)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <257@maynard.UUCP>
Date: Sun, 2-Mar-86 18:06:46 EST
Article-I.D.: maynard.257
Posted: Sun Mar 2 18:06:46 1986
Date-Received: Tue, 4-Mar-86 02:20:32 EST
References: <67@cstvax.UUCP>
Distribution: net
Organization: The Boston Software Works Inc., Maynard, MA
Lines: 39
> The one and only real thing which bugs me about system V is the
> total lack of job control. e.g. in the mail program and having to check
> something out .. fancy being faced with either writing your mail
> out (and later having to read it in again), or having to fork up
> another shell. With a big load up either of these options can be
> painful. The functionality of ^Z and fg is tremendous!
>
> Come on, AT&T, give me job control and I'll be a believer.
> --
> Scott Larnach Janet: sc...@uk.ac.ed.cstvax
> Edinburgh Unix Support Arpa: sc...@cstvax.ed.ac.uk
> Tel: +44 31 667 1081 x2629 Uucp: sc...@cstvax.uucp
Job control is pretty neat, if all you have is a dumb terminal. But an
even better solution is virtual consoles, or windows. I have perhaps
one of the most modest Unix configurations imaginable: a DEC Rainbow
personal computer running VENIX (a V7 port). To this I have added
virtual consoles, so rather than typing ctrl-Z and messing up my
terminal screen and having my mail session scroll off the page while I
check something out -- I just touch a function key and a different
console appears. I can do whatever I like, then touch another key to
zap me back to the (undisturbed) mail job. This happens at memory
speeds -- i.e., instantaneously -- and required changes only to the
console driver, not to the tty driver or kernel.
Virtual consoles are a standard feature of VENIX when running on IBM gear,
and also of XENIX I believe. I only had to roll my own because VenturCom
doesn't provide it for Rainbows.
I've never used a Sun, but I'm sure their windows are even nicer.
The nice part about virtual consoles or windows is that they don't
require special Berkeley-esque signals and terminal drivers and whatnot.
Programs are completely unaware anything is going on; you don't have
to hack your screen editor to repaint the screen when you reenter it.
--
Larry Campbell The Boston Software Works, Inc.
ARPA: maynard.UUCP:campb...@harvard.ARPA 120 Fulton Street
UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!umcp-cs!chris
From: ch...@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <33@umcp-cs.UUCP>
Date: Mon, 3-Mar-86 04:22:42 EST
Article-I.D.: umcp-cs.33
Posted: Mon Mar 3 04:22:42 1986
Date-Received: Tue, 4-Mar-86 04:12:10 EST
References: <67@cstvax.UUCP> <257@maynard.UUCP>
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 16
In article <2...@maynard.UUCP> campb...@maynard.UUCP (Larry Campbell)
writes:
>Job control is pretty neat, if all you have is a dumb terminal.
>But an even better solution is virtual consoles, or windows.
... and goes on to describe how wonderful it is.
It is nice indeed: I have a Sun here with windows. But then, it is
also nice to have job control so that I can do similar things from
home. (Or could, if I had a phone....) `Get better equipment' is,
to many, an unacceptable answer, alas.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: ch...@mimsy.umd.edu
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ulysses.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ggs
From: g...@ulysses.UUCP (Griff Smith)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <1199@ulysses.UUCP>
Date: Mon, 3-Mar-86 10:04:32 EST
Article-I.D.: ulysses.1199
Posted: Mon Mar 3 10:04:32 1986
Date-Received: Tue, 4-Mar-86 05:33:01 EST
References: <67@cstvax.UUCP> <257@maynard.UUCP>
Distribution: net
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 32
>
> Job control is pretty neat, if all you have is a dumb terminal. But an
> even better solution is virtual consoles, or windows. ...
...
>
> The nice part about virtual consoles or windows is that they don't
> require special Berkeley-esque signals and terminal drivers and whatnot.
> Programs are completely unaware anything is going on; you don't have
> to hack your screen editor to repaint the screen when you reenter it.
> --
> Larry Campbell The Boston Software Works, Inc.
> ARPA: maynard.UUCP:campb...@harvard.ARPA 120 Fulton Street
> UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109
Sigh. Just what we need to convince AT&T that their (our) imitation of
job control is all we need, or that when windows come it will be
completely unnecessary. I have a 5620, a nice 8.5 x 11 bit-mapped
display with mouse and windows; I still use job control once in a
while. For one thing, it's easier to move something to the background
instead of drawing a new window.
It's also nice to be able to stop things some times. If I have just
gotten part way into a "make" and I remember that I missed something, I
just stop the "make" while it fix the problem. I also like having the
option of stopping a suspected run-away process instead of blowing it
out of the water. Would you drive a car without brakes?
--
Griff Smith AT&T (Bell Laboratories), Murray Hill
Phone: (201) 582-7736
Internet: g...@ulysses.uucp
UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amdahl.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!amdahl!andrew
From: and...@amdahl.UUCP (Andrew Sharpe)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <2864@amdahl.UUCP>
Date: Mon, 3-Mar-86 15:28:39 EST
Article-I.D.: amdahl.2864
Posted: Mon Mar 3 15:28:39 1986
Date-Received: Wed, 5-Mar-86 04:21:07 EST
References: <67@cstvax.UUCP>
Distribution: net
Organization: Amdahl Corp, Sunnyvale CA
Lines: 21
Summary: whats wrong with using shl?
In article <6...@cstvax.UUCP>, sc...@cstvax.UUCP (Scott Larnach) writes:
>
> The one and only real thing which bugs me about system V is the
> total lack of job control.
>
> Come on, AT&T, give me job control and I'll be a believer.
Uhh, excuse me, but what about shell layers ( shl ) ? It does not
give you job control, per se, but it does allow you to break out
of a foreground process, to 'do something else'.
--
Andrew Sharpe ...!{ihnp4,cbosgd,hplabs}!amdahl!andrew
***************************************** ___________
* The views expressed above are solely * ,/| _____ |
* my cat's opinions, and do not reflect * | | |___ /| |
* the views of the employees, nor the * | | | | | |
* management, of Amdahl Corporation. * | | | | | |
* * | | |__| | |
* * | | / | | ,|
* * | ~~~~~ |/
***************************************** ~~~~~~~~~~~
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83 based; site homxb.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!homxb!gemini
From: gem...@homxb.UUCP (Rick Richardson)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <1307@homxb.UUCP>
Date: Tue, 4-Mar-86 09:12:51 EST
Article-I.D.: homxb.1307
Posted: Tue Mar 4 09:12:51 1986
Date-Received: Wed, 5-Mar-86 05:25:50 EST
References: <67@cstvax.UUCP> <257@maynard.UUCP>, <1199@ulysses.UUCP>
Organization: PC Research, Inc.
Lines: 62
>
> Job control is pretty neat, if all you have is a dumb terminal. But an
> even better solution is virtual consoles, or windows. ...
...
>
> The nice part about virtual consoles or windows is that they don't
> require special Berkeley-esque signals and terminal drivers and whatnot.
> Programs are completely unaware anything is going on; you don't have
> to hack your screen editor to repaint the screen when you reenter it.
> --
> Larry Campbell The Boston Software Works, Inc.
Let me point out the "poor man's window system" which comes with VENIX SVR2.
They used a slight hack to the console driver on an IBM PC; it allows four
FULL SCREEN login sessions on a CGA, plus one more if you also have the
monochrome adapter attached. Potentially, an EGA adapter could have
eight such login sessions. You switch sessions by pressing Alt-1 through
Alt-4 for the CGA, and Alt-5 for the monochrome.
Now, for the way I typically use UNIX as a programmer, I submit that this
approach provides the most functionality for the least cost.
1) I can log in as ANY user, on ANY screen (except root can only
login on screen 1).
2) I always have a full 25 x 80 to work with.
3) I can instantly switch screens. No delay while screen is repainted.
4) I don't have to pay for expensive large screens, either in
dollars or in space.
5) I can still do graphics, but if I do, I lose the current
displays on other screens. Not a huge loss, since I rarely
use graphics.
A typical usage for me might find:
screen 1 root Just in case I need a kill, or to
install something.
screen 2 me Using editor or compiling
screen 3 me "Hack" ready to play during long compiles
screen 4 me Terminal emulator running to host.
(yup, lots of times I download software to
the PC/AT to compile it there during
development - it compiles MUCH faster than
the (unamed) super-mini compiles it)
What am I missing? To my mind, nothing, really. I felt some amount
of mouse envy a year ago. So I got one, wrote a mouse driver with pop
up menus, and tried using it with the editor, spreadsheet, shell, hack,
etc. Guess what - cobwebs all over the poor little thing now. I found
it was only usefull with "PAINT" programs. If I could change anything,
I'd go for a display with (more) lines of 132 columns.
It seems to me that the memory (screen and program) necessary for a real
window system is being poorly utilized for a great percentage of us. Even
if the display hardware doesn't support multiple pages, the kernel could
simulate this by keeping the pages in kernel memory and just block moving
them out to the screen on a session change. My point is that while
huge displays and window systems are fun, for most of us they are
an unecessary waste of (money, CPU cycles, memory). One page on one
screen wasn't enough, to be sure, but the "in vogue" solution of large
displays and massive window systems is overkill.
Rick Richardson, PC Research, Inc. (201) 922-1134
..!ihnp4!houxm!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!!!
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <6468@utzoo.UUCP>
Date: Wed, 5-Mar-86 15:25:05 EST
Article-I.D.: utzoo.6468
Posted: Wed Mar 5 15:25:05 1986
Date-Received: Wed, 5-Mar-86 15:25:05 EST
References: <67@cstvax.UUCP> <257@maynard.UUCP>, <1199@ulysses.UUCP>
Organization: U of Toronto Zoology
Lines: 10
> It's also nice to be able to stop things some times...
The ability to stop processes is quite independent of all the other goo
in job control, in concept at least. Adding something like this to SysV
would probably be a five-minute hack (given sources!). You need to have
another context around before you can actually do anything to stopped
processes, but a window system is just right for that.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!
talcott!harvard!seismo!mcvax!enea!chalmers!myab!lars
From: l...@myab.UUCP (lars)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <137@myab.UUCP>
Date: Sat, 15-Mar-86 23:47:40 EST
Article-I.D.: myab.137
Posted: Sat Mar 15 23:47:40 1986
Date-Received: Wed, 19-Mar-86 05:30:18 EST
References: <67@cstvax.UUCP> <2864@amdahl.UUCP>
Reply-To: l...@myab.UUCP (lars)
Distribution: net
Organization: Myab Gothenburg, Sweden
Lines: 39
>In article <6...@cstvax.UUCP>, sc...@cstvax.UUCP (Scott Larnach) writes:
>>
>> The one and only real thing which bugs me about system V is the
>> total lack of job control.
>>
>> Come on, AT&T, give me job control and I'll be a believer.
>
>Uhh, excuse me, but what about shell layers ( shl ) ? It does not
>give you job control, per se, but it does allow you to break out
>of a foreground process, to 'do something else'.
We have ported 'csh' to SVR2 using shell layers. Result:
A program started with '&' runs in background. If it want to
do tty input, it will hang until put in foreground.
A background program can be put in foreground with the 'fg' command.
A forground program can be stopped with the '^Z' key. Csh will then
type 'blocked' and not 'stopped', because only tty io is blocked and the
program continues.
Typing 'bg' to a 'blocked' will enable output to tty for the blocked
program.
A maximum of 7 programs can be executed simultaneously.
A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its
screen.
Csh reads 'type ahead' characters back from a blocked sxt and inserts them
into the current input line. Otherwise, type ahead wouldn't have worked.
Despite these limits, it is much better than 'shl' (which creates one
new 'sh' for each "job").
--
______________________________________________________
Lars Pensjo
{decvax,philabs}!mcvax!enea!chalmers!myab!lars
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site psivax.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!hplabs!sdcrdcf!psivax!friesen
From: frie...@psivax.UUCP (Stanley Friesen)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <1072@psivax.UUCP>
Date: Wed, 19-Mar-86 11:02:32 EST
Article-I.D.: psivax.1072
Posted: Wed Mar 19 11:02:32 1986
Date-Received: Fri, 21-Mar-86 07:18:06 EST
References: <67@cstvax.UUCP> <2864@amdahl.UUCP> <137@myab.UUCP>
Reply-To: frie...@psivax.UUCP (Stanley Friesen)
Distribution: net
Organization: Pacesetter Systems Inc., Sylmar, CA
Lines: 14
In article <1...@myab.UUCP> l...@myab.UUCP (lars) writes:
>
>A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its
>screen.
>
When this is fixed I will admit that shell layers are a
workable substitute for full job control! What good does it do to stop
a job if I cannot restart it transparently?
--
Sarima (Stanley Friesen)
UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ttidca!psivax!frie...@rand-unix.arpa
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <6534@utzoo.UUCP>
Date: Sat, 22-Mar-86 22:28:20 EST
Article-I.D.: utzoo.6534
Posted: Sat Mar 22 22:28:20 1986
Date-Received: Sat, 22-Mar-86 22:28:20 EST
References: <67@cstvax.UUCP> <2864@amdahl.UUCP> <137@myab.UUCP>, <1072@psivax.UUCP>
Organization: U of Toronto Zoology
Lines: 21
> >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its
> >screen.
>
> When this is fixed I will admit that shell layers are a
> workable substitute for full job control! What good does it do to stop
> a job if I cannot restart it transparently?
What good does it do to be able to stop and start jobs if every program
has to know about it to redraw the screen? Also, what do you do about
output from (say) grep, which prints output and terminates rather than
sticking around to redraw the screen on request?
The fact is, *both* job control and shell layers are brain-damaged. Both
do the easy part of multiplexing -- centralized input administration --
without the hard part -- centralized output administration. Programs should
not have to redraw the screen themselves, when they have done nothing to
mess it up! Job control and shell layers are both cheap plastic imitations
of real window systems.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!cuae2!ltuxa!we53!wucs!nz
From: n...@wucs.UUCP
Newsgroups: net.unix-wizards
Subject: Re: UNIX Futures
Message-ID: <1524@wucs.UUCP>
Date: Sun, 30-Mar-86 11:56:42 EST
Article-I.D.: wucs.1524
Posted: Sun Mar 30 11:56:42 1986
Date-Received: Wed, 2-Apr-86 01:59:19 EST
References: <67@cstvax.UUCP> <2864@amdahl.UUCP> <137@myab.UUCP>, <6534@utzoo.UUCP>
Reply-To: n...@wucs.UUCP (Neal Ziring)
Organization: Washington U. Engineering Computer Lab
Lines: 55
Summary: job control has its place
In article <6...@utzoo.UUCP> he...@utzoo.UUCP (Henry Spencer) writes:
> > >A program cannot catch '^Z'. This implies that 'vi' doesn't redraw its
> > >screen.
A program can catch ^Z, by ``signal(SIGTSTP, stop_handler)''.
Further, the program can also catch the continue -- which lets it redraw the
screen or print a message or change its state or whatever. I have several
programs which do both.
> > When this is fixed I will admit that shell layers are a
> > workable substitute for full job control! What good does it do to stop
> > a job if I cannot restart it transparently?
You can.
> What good does it do to be able to stop and start jobs if every program
> has to know about it to redraw the screen? Also, what do you do about
> output from (say) grep, which prints output and terminates rather than
> sticking around to redraw the screen on request?
Since when does EVERY program have to redraw the screen? I stop and start
compiles, makes, news-readers, mail, etc. and none of them do screen refreshes.
> The fact is, *both* job control and shell layers are brain-damaged. Both
> do the easy part of multiplexing -- centralized input administration --
> without the hard part -- centralized output administration. Programs should
> not have to redraw the screen themselves, when they have done nothing to
> mess it up! Job control and shell layers are both cheap plastic imitations
> of real window systems.
> --
> Henry Spencer @ U of Toronto Zoology
Job control is a helluva lot more than a cheap imitation of a window system.
It is a general method of allowing some user control of system features --
time sharing and resource sharing. Remember that ^Z is only a character hook
to the rather general SIGTSTP signal! The ability to stop a process is a
very nice features that is NOT unique to BSD Unix (TOPS-10 and TOPS-20 had it).
Further, I think window systems are just fine, but they require VERY special
hardware to give acceptable performance. Job control frees up system resouces
by allowing processes to be swapped out. Window systems leave processes lying
around, and clutter the system even more with a window managing process!
The fact that a job can catch or not catch the SIGCONT as it pleases is a very
useful FEATURE! I would be very annoyed if somebody put screen control into
the kernel (!) and forces a screen update (expensive at 1200 baud) every time
I jumped into and out of a process.
Don't clutter this group with off-the-cuff opinions and snorts! Both job
control and window systems have their place, and they can even work together.
--
...nz (Neal Ziring at WU ECL - we're here to provide superior computing.)
{seismo,ihnp4,cbosgd}!wucs!nz OR n...@wucs.UUCP
"You could get an infinite number of wires into this !*$$#!?! junction
box, but we usually don't go that far in practice"
-- Employee of London Electricity Board, 1959
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: he...@utzoo.UUCP (Henry Spencer)
Newsgroups: net.unix-wizards
Subject: to job control or not to job control (was UNIX Futures)
Message-ID: <6571@utzoo.UUCP>
Date: Mon, 7-Apr-86 17:41:22 EST
Article-I.D.: utzoo.6571
Posted: Mon Apr 7 17:41:22 1986
Date-Received: Mon, 7-Apr-86 17:41:22 EST
References: <67@cstvax.UUCP> <2864@amdahl.UUCP> <137@myab.UUCP>, <6534@utzoo.UUCP>,
<1524@wucs.UUCP>
Organization: U of Toronto Zoology
Lines: 72
> > > ...What good does it do to stop
> > > a job if I cannot restart it transparently?
> You can.
If it is prepared to be restarted, i.e. to redraw its screen. This is not
what is usually referred to as "transparent", since every program has to
know about it.
> Since when does EVERY program have to redraw the screen? I stop and start
> compiles, makes, news-readers, mail, etc. and none of them do screen refreshes.
And therefore you lose their screen output when you restart them. This is
a bug, not a feature. Agreed that sometimes redrawing the output would
incur unneeded overhead when you don't particularly care about the output,
but this is like saying that SVR0 doesn't incur the overhead involved in
providing virtual memory -- yes, it's cheaper, but at the cost of not
providing a valuable and important capability.
> Job control is a helluva lot more than a cheap imitation of a window system.
> It is a general method of allowing some user control of system features --
> time sharing and resource sharing. Remember that ^Z is only a character hook
> to the rather general SIGTSTP signal!
Name three other uses of SIGTSTP.
> The ability to stop a process is a
> very nice features that is NOT unique to BSD Unix...
Agreed, it's not unique to BSD; V8 has it too, in a much cleaner form.
Furthermore, it is a feature that has nothing much to do with the rest
of job control. It's easy to envision putting it into a window system --
just have a way to stop all processes run from a particular window. Not
send a signal to them, but simply freeze them instantly. This does mean
you need to have another window so you can do something with them once
they are frozen, but that's reasonable enough.
> Further, I think window systems are just fine, but they require VERY special
> hardware to give acceptable performance.
I know people who would dispute this. That aside, though, cheap plastic
imitations are usually cheaper than the real thing. You get what you pay for.
> Job control frees up system resouces
> by allowing processes to be swapped out. Window systems leave processes lying
> around, and clutter the system even more with a window managing process!
There is no obvious reason why a window system can't let processes be
swapped out when they are stopped. Of course, it also gives you the freedom
to let them continue running, if that is what you want. As for a window
management process, once again you get what you pay for. Surely it is
wasteful to have a shell cluttering up the system while you're using an
editor, and hence Unix is inferior to a system with the command interpreter
wired into the kernel. Right?
> The fact that a job can catch or not catch the SIGCONT as it pleases is a very
> useful FEATURE! I would be very annoyed if somebody put screen control into
> the kernel (!) and forces a screen update (expensive at 1200 baud) every time
> I jumped into and out of a process.
It's a feature when you don't want to bother with the screen update. It's
a bug when you want that screen update but can't get it. Especially when
the only way to get it is to modify a tremendous pile of programs that
otherwise wouldn't need that complexity.
> Don't clutter this group with off-the-cuff opinions and snorts! Both job
> control and window systems have their place...
That is itself an off-the-cuff opinion, and one that I snort at. :-)
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!
glacier!well!hoptoad!gnu
From: g...@hoptoad.UUCP
Newsgroups: net.unix-wizards
Subject: Re: job control, scheduling, and signals
Message-ID: <726@hoptoad.uucp>
Date: Tue, 22-Apr-86 03:36:28 EST
Article-I.D.: hoptoad.726
Posted: Tue Apr 22 03:36:28 1986
Date-Received: Wed, 23-Apr-86 23:53:54 EST
References: <1097@psivax.UUCP> <198@desint.UUCP> <897@umcp-cs.UUCP> <205@desint.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 28
In article <2...@desint.UUCP>, ge...@desint.UUCP (Geoff Kuenning) writes:
> In article <8...@umcp-cs.UUCP> ch...@maryland.UUCP (Chris Torek) writes:
> > (It also seems to me desirable to allow processes to be marked as
> > noncontextual. It is hardly worth restoring the full context of
> > a `bc' session, especially at 1200 baud.)
>
> While I don't deny the pain of working at low baud rates (I had to dust
> off my 300 modem the other day), I would hate to add another feature
> to a system to handle a problem as obviously transient as this one...
The obvious solution, rather than "marking" a process, is to let the
process decide whether or not to repaint, and how much is worth
redrawing. "Marking" a process as repaintable or not sounds
suspiciously like the TopView "config" files that you need to build to
tell it how brain damaged each application that runs under it is. Why
not do it like everything else and hand the decisions off to the
process itself, e.g. by a signal? (This also allows for novel
decisions about repainting to be made by individual programs -- without
modifying the job control code/shl program/kernel.)
Sun used the same model when it came to window systems; if your window
is resized or uncovered (or created in the first place), you get a signal,
which you can ignore (most programs do), catch and notice the changed
size (curses and such do this for you), catch and repaint (terminal
emulators, Emacs, graphics programs that write to the bitmap, etc do).
The decision is yours.
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilm...@lll-crg.arpa