Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!uxc!tank!mimsy!jds
From: jds@mimsy.UUCP (James da Silva)
Newsgroups: comp.os.minix
Subject: Re: job control is a bug, not a feature
Message-ID: <17958@mimsy.UUCP>
Date: 8 Jun 89 11:42:43 GMT
References: <16497@louie.udel.EDU> <11989@bcsaic.UUCP> <2775@munnari.oz> <798@gara.une.oz> <8167@boring.cwi.nl> <1989Jun7.224933.700@utzoo.uucp>
Reply-To: jds@mimsy.umd.edu (James da Silva)
Organization: University of Maryland, Department of Computer Science
Lines: 29

In article <1989Jun7.224933.700@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>Job control is a stupid, poorly-thought-out, ass-backwards excuse for a
>window system.  It's mostly just a way of interacting with multiple
>processes.  Window systems do it much better, since they provide central
>control of output as well as input, and if done well, it is transparent
>to user programs (instead of requiring ugly hacks in each and every one).

Interesting.  I often find myself using job control to stop a process
without killing it.  Or doing simple things like putting ftp,
compress, or rm into the background when they are taking longer than
expected.  How does your alternative handle things like these?  Do I
have to explicitly run each command in a separate window?

>No, you do not need a bitmapped display to do a window system.

Granted.  Do you need a fast terminal?  How do I do windows at 2400
baud without spending all my time redrawing the screen, or dividing
its 25x80 chars into tiny `windows'?

>If anyone is interested, I think I still have the scathing commentary on
>job control that Ian and I did at the time.

I'm interested.  I think you should post to comp.os.minix; Minix is
about learning OS design tradeoffs, after all.

Jaime
...........................................................................
: domain: jds@mimsy.umd.edu				     James da Silva
: path:   uunet!mimsy!jds