@MSGID: <wwvedizk7us.fsf@LkoBDZeT.terraraq.uk>
b97f2fd5
@REPLY: X4qqz@news.chiark.greenend.org.uk>
a553293e
@REPLYADDR Richard Kettlewell
<invalid@invalid.invalid>
@REPLYTO 2:5075/128 Richard Kettlewell
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<wwvedizk7us.fsf@LkoBDZeT.terraraq.uk>
1@dont-email.me>53kqz@news.chiark.greenend.org.uk> i.fsf@LkoBDZeT.terraraq.uk> 1@dont-email.me><wwvpm2jgagf.fsf@LkoBDZeT.terraraq.uk>
1@dont-email.me>X4qqz@news.chiark.greenend.org.uk>
@TZUTC: 0100
@PID: Gnus/5.13 (Gnus v5.13) Emacs/27.1
(gnu/linux)
@TID: FIDOGATE-5.12-ge4e8b94
Theo <theom+news@chiark.greenend.org.uk> writes:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> Tell me in what way a corrupted - say - libc file, or a faulty bit of 
>> memory would show up in the kernel logs?
>
> Well, it could be a cosmic ray.  The Pi doesn`t have ECC memory to it`s
> possible to bit-flip in RAM or storage without it noticing.  I don`t know
> which part of the galaxy you inhabit, but cosmic rays are rare enough down
> here that random bit flips like this don`t happen often - ballpark once a
> year for a server (which has a much greater surface area to absorb them than
> a Pi).

I`ve seen one inarguable random bit flip in several decades. In that
case the behavior was deterministic - chiark`s /bin/ls had got a
single-bit error, and caching meant it crashed _every_ time anyone ran
it.

Maybe TNP has taken a trip to Sizewell?

-- 
https://www.greenend.org.uk/rjk/
--- Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
 * Origin: terraraq NNTP server (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441