Fraid so.
Nope, if it really was essential, it would be readily available.
Nothing is "really essential". Want an optical drive? I
can claim it isn't essential and if nobody will sell you
one, where are you going to get it? Not having one wouldn't
diminish the usefulness of having it.
He's always had a mindless bee in his bonnet about ECC.
.... and he's right, any serious use system should have it,
but unfortunately the industry was too concerned about
buyers not perceiving the significance and only saw they
could produce a system for a couple dozen dollars less w/o
ECC. It became less popular, lower volumem sales and that
also contributed to higher prices... pricing itself outside
of what most people deem it worth, for artificial reasons,
not for the intrinsic value. There are lots of other areas
in systems where someone tried (did) save a dollar here or
there and these things end up problematic for many users
too, like low quality fans or PSU.
Because it isnt as essential as he mindlessly claims.
By a similar token we could claim a CPU's cache doesn't need
parity or ECC protection, but there it is. Perhaps you
don't feel you need it, and discount anyone else having a
use for this extra protection against memory errors.
Could just be you want cheap without consideration of any
possible side effects. Lots of people build systems that
way, buy a cheap case or keyboard or whatever, but in the
end in is an inferior system in total. "Essential"?
Subjective term in this case.
Nope, certainly not.
They are if its due to a damaged file damaged in the way he claimed.
Nope, as I'd already mentioned you can easily take a hex
editor and flip some bits in an application file and NOT
easily reproduce the error as you suggest. In theory there
might be a reproducible way to cause an error as a result,
but ever determining that method is not presumed easy... all
a matter of what in particular was changed.
Really no point in your arguing about this, as I suggested
twice now you can edit a file yourself and see the proof.
It will crash completely reproducibly when
that particular op affected is executed.
In theory, but you're trying to presume only one isolated
operation and nothing more. Lots of codepaths in some apps,
it may not be so clear and you could go years inbetween
errors without being able to realize it was a bug in code,
or corruption (instead of placing blame elsewhere). That's
a long way from any reasonable presumption of reproducing
it, as-in, actually reproducing it.
Never said it would. But if it does crash when doing a
particular op due to that sort of corruption, that will be
completely reproducible when that op is invoked etc.
IF you can reproduce it like this, you can backtrack and
make the claim. That's not the same thing as being able to
always attribute a crash to corruption. You're also
entirely ignoring other problems besides crashes. If a
calculation went awry, or a graphical element is wrong, you
might not notice or assume you entered data wrong or myriad
other scenarios and potential conclusions. It is not at all
presumable that you have such a simple single operation
resulting in a repeatable crash to backtrack.
It has to with the particular op thats been damaged by the corruption.
Not in a way that you'd necessarily notice, and if there is
ongoing corruption do you expect it to magically stop
happening? Isolating one repeatable op failure is not at
all going to be easy if there is (the liklihood of) ongoing
further damage to that app, other windows apps, etc.
If you saw several apps crashing and the OS, would you
presume each and every file was corrupt or some other
problem? It's not just one op in one app then, it "seems"
random.
You dont need to do that. The op thats got corrupted will
completely reproducibly go flat on its face whenever its executed.
Your argument only works when ignoring all the possible
variables. If you could somehow fix all these variable, yes
you would be able to reproduce it, and check some files.
Without fixation of the variables, show us people who have
found this fault. We can assume there are people with
instable memory but what percent actually DO find this
fault? That's the whole point of ECC, you don't have to FIX
a problem like this, don't have to wonder if there's a error
you will find, or will remain hidden. I can assure you I
could edit some files on your system and you would not know
based on using the application, but it might effect the data
you produce, or the reliability of the system when it
matters. Continually finding problems and fixing them is a
far worse alternative than not having any.
