Re: [9fans] no job control; thank you!

Re: [9fans] no job control; thank you!

[forsyth]

>>Systems like TOPS-10 had a nifty feature whereby one could start
>>a job on one terminal, detach the terminal, and log in elsewhere
>>and reconnect to the detached job.  Not "job control", but in the
>>same vein.

it was a long time ago, but i vaguely recall that particular feature was
precisely the one that was adapted to form `job control' on `unix',
which also explains why `job control' was the term used
in a system that had no `jobs'.  it was probably designated by
Mrs Malaprop.

Re: [9fans] no job control; thank you!

[David Gordon Hogan]

>> I have an Inferno app that monitors /dev/draw and remembers enough state
>> to reproduce the display (actively) on the /dev/draw of any client that connects
>> to it on a network port.  The clients can connect at any time.
>> It does need a real local /dev/draw to do the grunge and maintain the images.
> 
> post it!  i've wanted that for plan 9 for a while.

This sounds similar in spirit to what consolefs does...

Re: [9fans] no job control; thank you!

[Russ Cox]

> I have an Inferno app that monitors /dev/draw and remembers enough state
> to reproduce the display (actively) on the /dev/draw of any client that connects
> to it on a network port.  The clients can connect at any time.
> It does need a real local /dev/draw to do the grunge and maintain the images.

post it!  i've wanted that for plan 9 for a while.

Re: [9fans] no job control; thank you!

[rog]

> Suppose you start some long-running task but soon realize that it's
> going to run out of disk space.  It is very useful to be able to
> temporarily stop the task, rearrange files on the disks to make room,
> then resume the task.  Some form of control over an executing process
> is required for such things.

is there any reason one couldn't send a "stop" message to
a rio window just as an "interrupt" message is sent currently?

> Systems like TOPS-10 had a nifty feature whereby one could start
> a job on one terminal, detach the terminal, and log in elsewhere
> and reconnect to the detached job.  Not "job control", but in the
> same vein.

there's no essential reason why you couldn't do that under plan 9,
i think. just put a level of indirection above the draw device.

i used to like that feature of "screen" - i could keep several programs
going in one session and remain logged in for days despite
logging in from several different terminal rooms.

acme dump is ok, but has certain lacks.

i think rob's got some ideas on this...

  rog.

Re: [9fans] no job control; thank you!

[Sam]

> > Suppose you start some long-running task but soon realize that it's
> > going to run out of disk space.  It is very useful to be able to
> > temporarily stop the task, rearrange files on the disks to make room,
> > then resume the task.  Some form of control over an executing process
> > is required for such things.
>

It sure would be nice to have this control built into one of the mouse
button menus similar to how the backdrop shows hidden windows.  I can't
imagine it being very clean without mouse submenus, though.

Sam

Re: [9fans] no job control; thank you!

[matt]

> there's no essential reason why you couldn't do that under plan 9,
> i think. just put a level of indirection above the draw device.

I have been mulling something over and this seems the appropriate time to
mention it.

I notice that plan9 now has the vncserver: vncs

One useful attribute of vnc on unix is that it can act as a XFree display.
You don't need a VGA card configured to run X at all. You run vncserver and
connect with a vncviewer and a new XFree session is waiting, log off and
it's still running. log back in later and it's how you left it.

I was thinking that this would make a very useful addition to plan9. By
opting for vnc-vga one can avoid vga hell to get an auth/cpu server up and
running. One of the set-up problems is that you might need two computers so
that you can edit plan9.ini or edit/compile the $vga_driver.c

I was thinking that a pseudo VGA driver would pretend that there was VGA
hardware running and running vncs would expose it.

Downside is the lack of authentication possible if one continued to use the
system in such a state but at least you would / could be using it.

M

Re: [9fans] no job control; thank you!

[Lucio De Re]

On Thu, Jul 18, 2002 at 05:19:09PM +0100, matt wrote:
> 
> I was thinking that this would make a very useful addition to plan9. By
> opting for vnc-vga one can avoid vga hell to get an auth/cpu server up and
> running. One of the set-up problems is that you might need two computers so
> that you can edit plan9.ini or edit/compile the $vga_driver.c
> 
Yes, that's certainly an interesting and intriguing option.  I
haven't really looked at vncs yet, but the possibility ought to
exist...

> I was thinking that a pseudo VGA driver would pretend that there was VGA
> hardware running and running vncs would expose it.
> 
A VMware-like VGA device, hiding behind the framebuffer, hiding
behind the VNC protocol.  Where do we sneak in the fileserver?

> Downside is the lack of authentication possible if one continued to use the
> system in such a state but at least you would / could be using it.
> 
Authentication can be promoted to factotum, I'm sure; if memory
serves, the VNC protocol is extensible.  It would be nice to be
able to pick your session by user id, if the system is willing to
collaborate.

++L

Re: [9fans] no job control; thank you!

[Chris Hollis-Locke]

I have an Inferno app that monitors /dev/draw and remembers enough state
to reproduce the display (actively) on the /dev/draw of any client that connects
to it on a network port.  The clients can connect at any time.
It does need a real local /dev/draw to do the grunge and maintain the images.

Having a draw device with a plain memory (as opposed to video adapter) based
frame buffer, you could have a real thin-client / perpetual desktop server.
Also many clients can attach to the server at the same time - quite useful for
collaboration.

Interposing at the /dev/draw level tends to result in less bandwidth than shipping
frame buffer updates around, which is what would be required if you interposed at
the VGA adapter level.
There is an initial cost at connection, certain images have to be shipped across to
the client, using standard /dev/draw operators.  After that the server just has to
re-write image ids in the draw messages.

Re: [9fans] no job control; thank you!

[rob pike, esq.]

> I'd like to thank all the Plan 9 developers for keeping job control
> out of Plan 9.  I've just had a close encounter with job control after
> many years away from Unix (hey, somebody has to clean the sewers), and
> the complexity and botched implementation(s) of that bad idea are
> mind-boggling.  I finally gave up.

I never liked job control; it seemed like the wrong answer to the
problem of managing multiple processes.  When I first saw windows,
even though the system they were on didn't have processes, a light
bulb went off in my head: *that* is the right answer.  And it was.

-rob

Re: [9fans] no job control; thank you!

[Douglas A. Gwyn]

"rob pike, esq." wrote:
> I never liked job control; it seemed like the wrong answer to the
> problem of managing multiple processes.

"Job control" a la csh is certainly messy; we added job control to
the BRL Bourne shell and while I leave it enabled, I almost never
use it, while I do use multiple windows..  However, they're not
really the same thing.  Suppose you start some long-running task
but soon realize that it's going to run out of disk space.  It is
very useful to be able to temporarily stop the task, rearrange
files on the disks to make room, then resume the task.  Some form
of control over an executing process is required for such things.

Systems like TOPS-10 had a nifty feature whereby one could start
a job on one terminal, detach the terminal, and log in elsewhere
and reconnect to the detached job.  Not "job control", but in the
same vein.

[9fans] no job control; thank you!

[Geoff Collyer]

I'd like to thank all the Plan 9 developers for keeping job control
out of Plan 9.  I've just had a close encounter with job control after
many years away from Unix (hey, somebody has to clean the sewers), and
the complexity and botched implementation(s) of that bad idea are
mind-boggling.  I finally gave up.

Re: [9fans] no job control; thank you!

[Chet Ramey]

In article <723315de1376d3aa7b828f93a205fe5b@collyer.net> you write:
>I'd like to thank all the Plan 9 developers for keeping job control
>out of Plan 9.  I've just had a close encounter with job control after
>many years away from Unix (hey, somebody has to clean the sewers), and
>the complexity and botched implementation(s) of that bad idea are
>mind-boggling.  I finally gave up.

What were you looking at?

Chet


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
( ``Discere est Dolere'' -- chet )

Chet Ramey, CWRU    chet@po.CWRU.Edu    http://cnswww.cns.cwru.edu/~chet/