NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/wizards/4822

Text File | 1992-11-20 | 3.6 KB | 79 lines

Newsgroups: comp.unix.wizards
Path: sparky!uunet!cs.utexas.edu!newsfeed.rice.edu!exlogcorp!mcdowell
From: [e-mail] (Steve McDowell)
Subject: Re: Changing the owner of a process
Message-ID: <[e-mail]>
Keywords: process ownership
Sender: [e-mail] (Steve McDowell)
Organization: EXLOG, Inc.
Date: Sat, 21 Nov 92 02:28:33 GMT
Lines: 67

In message <[e-mail]>[e-mail] (Chris Torek) writes:
>
> I will make you a deal:  If you do not try to tell us how to do O/S
> research,

Calm down Chris, there's no need for a personal exchange here. You don't
know me or what my background is, so be very careful before you presume
the wrong things.

I'm sorry if I stepped on your toes; I didn't realize how close you were
to bsd4.4. But this forum is for the exchange of ideas from whomever
presumes to present them. The research community really should listen before
flying off the handle and the ideas will continue to flow and that will
be a good thing for everyone.

> I will not try to tell you how to sell commercial systems.

But you don't understand, I wish you would -- we really do need the help....

> If the counts are goofed up, either the hardware is broken---the 4.4BSD
> development line is not intended to be able to handle this situation,
> although if it recurs predictably we will probably hack around it---or
> (far more likely) there is a bug in the kernel source.  An immediate
> panic gives us a much better chance of finding and repairing the bug
> than a syslog-and-reset.

Or, in the case that my original article was in response to, you have a user
who fancies himself a "system programmer". I'm a big believer in the
condom approach to end-user computing -- let a user stroke himself all
he wants to but don't let his results impregnate the integrety of my
operating system.

In the lab, I agree with you completely. I keep the error correction in my
own code disabled until very late in the game.  But the code is there, and
that's my point.

In the real-world, in a critical application, I'd much rather have a
syslog-and-reset than a panic that's going to have to be called in to a
support group while the dump sits cluttering up somebody's dasd. If there's
a situation that can be recovered from, then recover. I really don't see
how you can argue against this.

> Commercial vendors are free to replace various panic()s with the
> appropriate recovery code.  For our purposes, recovery is not only
> unnecessary, it is in fact *in*appropriate.

Of course, for your purposes developing an operating system is a means
unto itself. You don't have to worry about irrelevant things like
"customers" and "applications". I wish I didn't.

I hope that vendors do replace panics where they can. The problem becomes that
commericial vendors don't always take the time to get it right. Too many vendors
simply port the code they get from USL or CSRG or CMU to get compatable
functionality; that makes it simple to integrate new releases and keeps the
lead time to market short. That's not the research community's problem, that's
a problem for everyone else.

This is all moot, though. From what I understand, not too many commercial
vendors are interested in porting bsd4.4 and selling the result. I hope my
information on this is wrong because I'd hate to see all that hard work not
turn a profit for somebody.

--
Steve McDowell             . . . . o o o o o         Opinions are
Exlog, Inc.                      _____      o         mine, not my
[e-mail]      _____====  ]OO|_n_n__][.        employers..
               [_________]_|__|________)<