[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A thought about some things in es.



Scott Schwartz writes:
:
: Not having job control at all in my Plan 9 kernel makes me more happy
: than I can say.  Maybe it is time to port es finally? :-)
:


Now _this_ is a sentiment that is hard to comprehend.

I can understand someone not using (the available) job-control
features in a system, because they find another route more
convenient.  I can also understand someone wanting an
implementation of job-control that is different from the one they
actually have.

But why would anyone be _more_ happy that a kernel does not
provide any support for job-control?  Does not providing job-
control make the kernel design any cleaner (in a manner visible
to programmers and/or users)?  Faster?  Or is it something else
altogether?


I use job-control all the time, even though I am on a windowing
system.  Very often, it is much more convenient for me (in terms
of keystrokes and response time) to suspend an editor, do a
"make", and jump back to the editor, all in the same window.

I know I can get along quite ably without job-control but is
there some set of _objective_ reasons why job-control is a "Bad
Thing"?  Or have people been bitten by early bad implementations
of job-control that they are never willing to trust that word
again?


I know that this issue almost never dies (the `es' and `rc' mail
archives are a testimony to that).  But as someone who has
painfully gone through those archives many times looking for a
proper answer to this question, I am sorry to say that I came
across more heat than light.

Please feel free to enlighten me via a non-group reply if you
wish.  I really am interested in knowing why kernels without
job-control are better than kernels with.  I am also willing to
post a summary of replies I get to the list if enough people are
interested.

--Krishna