Kernel core dumps (was Re: out of swap space??)

Andrew Valencia vandys at sequent.com
Mon May 6 02:26:48 AEST 1991


mike at bria.UUCP (mike.stefanik) writes:
>Where is this mythical beast that SCO has given birth to?

	Hmmm, interesting.  If you've had bad experiences, then I'm
very sorry to hear about it.  My experiences with their products over the
years have been very good.  When you go try to put a system together, my
experience is that the Microport's, ESIX's, or vanilla AT&T releases just
can't be used as a problem-solving tool the way SCO's product can.  Lower
quality (yes, more crashes), less support, inferior documentation.

>There is never any good excuse for any operating system to be without
>the ability to dump itself when it crashes.  It is laziness, pure and simple.

	In the particular case of my comments, I noted that ESIX DOES
have crash dumping, though it isn't very elegant.  Could someone with the
latest SCO release let us know if they took it out?

	Speaking as a kernel developer, I can give you a better guess than
"laziness" for why certain things get left out (or even taken out).  It
usually ends up being time and quality trade-offs.  Would you rather have
crash dumping than, say, multi-screen with graphics?  Would you rather have
a really good crash dumping system with crashes once a week?  Or a mediocre
one with one crash a month?  Or one crash a year but you get your release three
months later?  Would you give it up entirely if your own "pet peeve" bug
could be fixed instead?  Now imagine one developer with several thousand
people pulling him in several thousand mutually exclusive directions.  That's
what it's like on the "other side."  Nobody sitting around and deciding not
to do anything for the next release out of laziness--not in my experience.

						Regards,
						Andy Valencia
						vandys at sequent.com

Disclaimer: I speak only for myself.



More information about the Comp.unix.sysv386 mailing list