[gentoo-user] Re: Epic list of total FAIL.

[Grant Edwards]

On 2015-08-21, Alan Grimes <ALONZOTG@×××××××.net> wrote:
> Grant Edwards wrote:
>> On 2015-08-21, Alan McKinnon <alan.mckinnon@×××××.com> wrote:
>>
>>> Earlier I saw segfaults in gcc, and another poster pointed it out.
>>>
>>> When gcc segfaults, it is always suspicious mostly because the compiler
>>> is an app where we know the devs take extraordinary measures to prevent it.
>>>
>>> The most common cause is faulty hardware (most often memory) as gcc
>>> tends to use all of it in ways no other app does. The usual procedure
>>> at this point is to run memtest for an extended period - say 48
>>> hours, or even 72 for an older slow machine.
>> That is definitely good advice.  I've run into this situation several
>> times.  A machine had bad RAM that didn't seem to cause any problems
>> under "normal" operation.  But, when trying to compile something large
>> like gcc, I would see non-repeatable segfaults (it wouldn't always
>> segfault at the exact same point).  In those cases, I could often run
>> memtest for several passes and not see an error. But, _eventually_
>> ramtest would catch it.  Run memtest for a few days.  Really.
>
> Yeah, I know there's a single bit error out at the end of RAM that
> will appear on the third or fourth pass...

And you're still using it?  And when it doesn't work, you blame
blaming _us_?

**PLONK**

> It just doesn't seem reasonable to demand that every bit in a 32
> gigabyte memory bank be absolutely perfect....

Idiot.

Of _course_ software expects memory to work.  Why don't you stop
bothering us and go write an OS that doesn't depend on RAM working
properly.

-- 
Grant Edwards               grant.b.edwards        Yow! Now KEN and BARBIE
                                  at               are PERMANENTLY ADDICTED to
                              gmail.com            MIND-ALTERING DRUGS ...