[rescue] Oracle making just a little harder to keep old machines in use

[Patrick Finnegan]

On Thursday 06 May 2010, Carl R. Friend wrote:
>     On Thu, 6 May 2010, hike wrote:
> > that should be "SOME old farts".  i have been recommending/pushing
> > linux in the data center for at least 6 years--since red hat
> > enterprise linux.  it is a mistake to lump all the "old farts"
> > together.

I didn't realize so many of you would so wilfully call yourself 'old 
farts'.  Obviously I didn't mean everyone old hates Linux.

>     Linux gets quite a few things right, or at least it used to.
> I tried, successfully, to install CentOS on a rather new IBM PC
> I have at home recently and came away apalled from the experience.
> Linux used to be a streamlined OS that one could install on most
> "old" hardware and it'd outperform anything from Redmond -- this
> last experience tells me that the Linux folks are getting to be
> more about "splash and flash" than about performance and economical
> use of hardware resources.  It took TWO DAYS to get CentOS to install
> on a system with 96MB of mainstore -- an embarrassment considering
> what was standard a few years ago.

For reference, in 1999, Purdue (where I now work) had 256MB of ram 
standard in its computer lab desktops.

It's been over a decade since 96MB ram was "large" on a PC.

>     OK, you can bash me on my "modest" iron, but I happen to be one
> of those folks who happens to try and "tread lightly on Mother
>  Earth", and I don't like having to upgrade my hardware every 18
>  months because the OS keeps bloating to the point where it won't run
>  on anything less than {mumble} gigs of memory -- down that path lies
>  madness!

How about once in 120 months? :)  For what it's worth, if you drop the 
GUI, it's easy to fit useful Linux system image in less than 96MB.

Heck, my cell phone has more than 96MB of RAM in it, and it came out 
about 3 years ago.

>     So, do I support Linux atop x86?  Yes, and I have done so quite
> publically at prior a job where I was all about supporting local
>  tool- sets that local administrators were comfortable with, so long
>  as the tools adhered well to well-known standards -- and Linux DID
>  (and does).  No problem.  My issue is the inclusion of too bloody
>  much in the kernel, and from the looks of things with Linux at the
>  moment, the sky's lhe limit!

If you want a small kernel, just configure stuff out, or use an older 
kernel.  Any project where there's as much development progress as what 
Linux has will grow in size.

>     On Linux in the infrastructure of a computing environment: I
>  still like Linux, but what worries me is x86, and Linux, whether one
>  likes it or not, is almost inextricably wedded to x86.  I do not
>  like mono- cultures, and, put bluntly, the Intel monoculture bothers
>  me; one, just one, cross-OS virus that can access deep code has the
>  potential to brick vast swathes of the computing infrastructure that
>  makes our modern lives possible.

People run linux on a lot more than just x86.  ARM and PowerPC just to 
name two very popular choices.

>     But, what I *really* like about operating systems like Solaris
> is how they behave when things go wrong.  I've seen more "kernel
> oops" messages from Linux when a memory system goes wonky than I
> like to remember.  Solaris gets it right -- it retries the operation
> a number of times, if it can correct the error it does -- and writes
> the correct data back to memory -- logs it an continues; if it can't
> correct it, it aborts the process in question, flags the *page* bad
> (unlike "chip-kill"), and continues.  I've heard it said that to
> really produce production-grade software, one spends 80% of one's
> effort in figuring out what to do when things go wrong; knowing
> what to do when things go right is easy.

ECC and Chip-kill avert most memory-related problems.

If you're developing uncorrectable ECC errors in the main data pathways 
of your system, there's no reason to expect the machine to function 
properly.   What happens on Solaris if the RAM the scheduler or other 
kernel code bits live in develop double-bit errors that ECC can't 
correct?

Pat
-- 
Purdue University Research Computing ---  http://www.rcac.purdue.edu/
The Computer Refuge                  ---  http://computer-refuge.org