Hmm:<div><span class="Apple-style-span" style="font-family: Arial, Verdana, Helvetica, Georgia; font-size: 12px; "><h2 class="page_title3" style="font-family: Arial, Verdana, Helvetica, Georgia; font-size: 18px; padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; color: rgb(0, 51, 153); font-weight: bold; ">
<span>Kingston ValueRAM 4GB PC3-10600 DDR3 SDRAM ECC Kit (2 x 2GB)</span></h2></span>...or $40/GB at Memory Express (special order, though). Is that reasonable? Do people generally trust Kingston for RAM?</div><div><br></div>
<div><br><div class="gmail_quote">On Fri, Feb 19, 2010 at 9:07 AM, Kevin McGregor <span dir="ltr"><<a href="mailto:kevin.a.mcgregor@gmail.com">kevin.a.mcgregor@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
While we're on the topic, what sort of desktop-PC motherboards are available that support ECC memory? I've never really paid attention, so for all I know, ECC support is common.<div><div></div><div class="h5"><br>
<br><div class="gmail_quote">On Thu, Feb 18, 2010 at 9:09 PM, Daryl F <span dir="ltr"><<a href="mailto:wyatt@prairieturtle.ca" target="_blank">wyatt@prairieturtle.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Personally I find there is another aspect of data security that is often<br>
overlooked: data accuracy. As the owner of valuable data I want it<br>
protected from loss and private but I also want it to be correct.<br>
<br>
There are many who believe that an application always crashes when there<br>
is an undetected memory error but that is not always the case. One of the<br>
most difficult problems to track down is caused when data resides in flaky<br>
RAM and then is written to disk where it is faithfully recorded<br>
inaccurately forever.<br>
<br>
Hardly anyone writes code to see if their spreadsheet adds 2+2, comes up<br>
with 4, then saves it to disk as a 5 via a DMA transfer from bad RAM.<br>
Eventually some program blows up executing from the bad RAM and it is<br>
finally replaced but now we have some amount of bad data floating around<br>
on durable media.<br>
<br>
I'm constantly astonished by the amount of corrected ECC memory errors I<br>
see over time in the servers I care for. The DIMMs eventually fail but I<br>
feel more secure knowing corrupt data was never transferred from place to<br>
place.<br>
<br>
While auditors may have convinced their customers it is really important<br>
to have data security and data durability have you ever heard any of them<br>
ask their customers if they are OK with data inaccuracy?<br>
<br>
I think non-ECC memory should be illegal. Somebody's gonna lose an eye and<br>
it won't be funny any more.<br>
<font color="#888888"><br>
-Daryl<br>
</font><div><div></div><div><br>
<br>
On Thu, 18 Feb 2010, Sean Walberg wrote:<br>
<br>
> What you say is not untrue, but the larger issues (IMHO) are that:<br>
><br>
> 1. Most people design such that they avoid trouble and confrontation.<br>
> 2. Most IT auditors have no IT experience.<br>
><br>
> For #1, most people have lost the ability to rationally assess risk. No one<br>
> wants to be the guy to say "I saved $xxxxx by specing a lower box that will<br>
> still handle the load" or some variation of that when that's the first<br>
> decision that's going to be looked at if there is a problem. In most cases<br>
> the IT department has lost touch with the business value they provide. So we<br>
> get this proliferation of redundant servers and network gear that sits idle.<br>
><br>
> There is an aspect of hardware to it, though. Developers tend to assume they<br>
> are writing to a machine that executes commands in zero clock cycles, has<br>
> infinite memory, and has a network with zero latency and infinite bandwidth.<br>
> Rather than try and correct these misunderstandings, IT will throw money at<br>
> the problem to make it run and not get blamed.<br>
><br>
> For #2, I'm not sure what else has to be said. I have only met one auditor<br>
> who I respect and actually gets these kind of discussions. He explained to<br>
> me that he understood some of these things made no technical difference, but<br>
> the problem was to convince every other auditor. Sometimes it's easier just<br>
> to bite the bullet and do things sub-optimally rather than having to spend<br>
> several hours explaining it each time the (new) audit team comes around.<br>
> Back to #1, the cost of being right is high and the benefits are almost nil.<br>
><br>
> With respects to your arguments you're mixing data durability and data loss<br>
> prevention. They are both aspects of security (eg, mitigating risk), but I'm<br>
> sure that most IT departments would agree that they are more worried about a<br>
> critical Excel spreadsheet getting in the hands of the media or competition<br>
> than they are having Excel crash because of a memory error. The cost<br>
> and likelihood of the former dwarf that of the latter.<br>
><br>
> Sean<br>
><br>
> On Wed, Feb 17, 2010 at 10:20 PM, Adam Thompson <<a href="mailto:athompso@athompso.net" target="_blank">athompso@athompso.net</a>>wrote:<br>
><br>
>> <soapbox><br>
>> That's because we don't, collectively, think about hardware. And we don't<br>
>> think about hardware being buggy. And we especially don't think about<br>
>> "hardware" having inherent security flaws.<br>
>><br>
>> (OK, yes, the security folks who crossed over *into* IT do. They aren't<br>
>> auditors, for better or worse.)<br>
>><br>
>> A Cisco router is "software" enough (and has had enough bugs :-) that it<br>
>> crosses into our conscious awareness regarding security, but their switches?<br>
>> Nah. Mature product, all hardware (despite running an OS), no bugs.<br>
>> Either works or it doesn't.<br>
>><br>
>> Bullshit.<br>
>><br>
>> Show me a hardware-accelerated device and I can show you half a dozen ways<br>
>> it could fail unnoticed, (potentially) compromising security as it goes.<br>
>><br>
>> Notice that we install local firewalls on every PC but don't use ECC memory<br>
>> to guard against random bit errors. (I do, BTW - even on my PC. It's one<br>
>> small part of why I don't have a laptop.) A HERF gun is a better DoS tool<br>
>> than any virus or worm, by several objective measurements.<br>
>><br>
>> The entire IT industry has its head stuck up... you know where, in so many<br>
>> different ways.<br>
>><br>
>> Yet, this isn't surprising. Humans want instant gratification, a free<br>
>> ride, and the illusion of control. Those things are all way easier with<br>
>> software than with hardware. (Contemplate the difference between "soft" and<br>
>> "hard", if you will, for a moment.)<br>
>><br>
>> Do I expect this to change any time before the heat death of the universe?<br>
>> No. But I sure wish auditors took a wider view of the world.<br>
>><br>
>> "Never attribute to malice that which can be adequately explained by<br>
>> stupidity." - Hanlon's Razor (among other attributions)<br>
>> </soapbox><br>
>><br>
>> -Adam<br>
>><br>
><br>
><br>
</div></div><div><div></div><div>_______________________________________________<br>
Roundtable mailing list<br>
<a href="mailto:Roundtable@muug.mb.ca" target="_blank">Roundtable@muug.mb.ca</a><br>
<a href="http://www.muug.mb.ca/mailman/listinfo/roundtable" target="_blank">http://www.muug.mb.ca/mailman/listinfo/roundtable</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br></div>