FW: OT: broken/useless ansi - console driver??

[John Esak]

I don't know... really.  Maybe he is doing something with kill -1 and/or
inetd... I don't care anymore. :-)  I just know his original message to me
indicated that the new behavior of clobbering running binaries bothered him
in lots of ways. His examples weren't mine.  I merely tested with clobbering
rclerk while it was active. I just think this is not right... And you know
what... my guess is... if you tracked down the reasoning for it and the
original designer/implementer of it... you would find some person who
doesn't even work at SCO anymore... who did it by accident... and since
everyone is just learnging about it now... there decision is to say it is
supposed to be that way... when no one there could possibly give a good
reason for that behavior. Just a guess, I could be wrong.  You know what...
imagine I am completely wrong and there is a person somewhere... nay, a
committee of 25 world qualified kernel engineers somewhere that all stand up
and give thoroughly excellent reasons for this behavior... I *still* would
think it is utterly stupid. Nothing outweighs the sanctity of a running
binary, other than specifically killing it, or a shutdown to lower level or
off. See how stubborn I am? :-)  My wife gives me grief over it, too.

JE


> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Fairlight
> Sent: Tuesday, October 25, 2005 8:29 PM
> To: Fplist (E-mail)
> Subject: Re: FW: OT: broken/useless ansi - console driver??
>
>
> Top-posted for ya, John.
>
> It's what was described that confused me.  I'm not saying you
> don't have to
> recompile and replace it.  I'm trying to figure out how it's problematic
> that a -test- server crash with clients connected, as opposed to having
> a clean shutdown, if all you're going to do is test a new compile.  You
> need to disconnect all clients to test the new server binary
> anyway, unless
> you're running it on a different port.
>
> The implication that it was -especially- problematic for him to have the
> server crash was that he might have actual users (as opposed to test
> clients) connected to the server whose binary was being replaced.  In
> that case, it would be more of a production machine than a test machine,
> and all the rules of administration say, "Don't do that."  And given his
> years of experience, I would expect he'd be following good practises.
>
> I mean, if it's just a test server with test clients, and you have to take
> connections down anyway so you can reconnect to the newly
> compiled version,
> it doesn't really make much difference if it exited with a bang or a
> whimper.
>
> Maybe he's using different ports.  I don't even know what kind of
> server it
> is, so it's possible.  But if that's the case, he'd still not be able to
> replace the binary without shutting down the old server manually under the
> old (proper) scenario of "text file busy", which apparently he has been.
>
> Which brings me back to:  "Why is one exit any worse than another
> if you're
> just going to shut it all down anyway--unless it's a production machine?"
>
> Guess what's confusing me is the lack of context, which isn't my business
> anyway. :)
>
> mark->
>
>
> Is it just me, or did John Esak say:
> > I think you've lost me on this one... I have no idea what you
> are talking
> > about. Production machine??  This is a developer who is writing
> new code on
> > a development machine... and various connected via tcp/ip
> outlying clients.
> > How do you develop if not by compiling and re-compiling and
> trying the new
> > binary... over and over until it all works?  It's the way I do
> it. I don't
> > know any other way. :-)
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list