matja

Well, you're lucky that your equipment doesn't use the Ethernet channel in HDMI 1.4 then :) you can put a piece of Kapton tape over the HEC pin to make sure that doesn't happen.

    MULTIOS=1 > file

    <ext4> I have no proof it was false data
    <zfs> YOU HAVE NO PROOF IT WAS CORRECT DATA!

    openat(AT_FDCWD, "file", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3

    O_TRUNC
        If the file already exists and is a regular file and the
        access mode allows writing (i.e., is O_RDWR or O_WRONLY) it
        will be truncated to length 0.
        ...

<Commander Powell> Talk to the bomb.

<Doolittle> But I have been talking to it, sir. And Pinback's talking to it right now.

<Commander Powell> No, no, Doolittle. You talk to it.

<Commander Powell> Teach it phenomenology

Even modern C compilers for "modern" 8051-derived MCUs work like this :)

I think this is half of the problem: SDHC does not require wear-leveling at all, I am unsure of SDXC. But regardless, the wear-levelling algorithm the SD card firmware does is completely invisible, from some vendors it might do a decent job, from some it might be a no-op, we have no way to tell.

The only way to know you're getting wear-levelling is to do it at an OS level, e.g. UBIFS stacked on MTD emulation - but there's a bunch of assumptions there which make it unsuitable for SD cards.

    json = {};
    json["foo.bar"] = true;
    json["foo[0]"] = true;

So did you bite the bullet and get ECC, or are you just waiting for the next corruption caused by memory errors? :)

That's what DKMS is for, which most distros use for ZFS. Install and forget.

Maybe some P2P applications will magically start working or have lower startup time because of no need for STUN/TURN/ICE for NAT traversal.

My Gentoo ARM SBC based on an even more ancient armv4 arch has been chugging along just fine with the latest gcc/clang updates:

    grep CTARGET /etc/env.d/gcc -r
    /etc/env.d/gcc/armv4tl-softfloat-linux-gnueabi-11.3.0:CTARGET="armv4tl-softfloat-linux-gnueabi"

I've never tried or noticed this before until you mentioned it, but this makes my tinitus noticeably worse. It's not really louder, but seems to add "harmonics".

    uint64_t x = 0x7ff0000000000000ULL;
    printf("%f\n", *(double *)&x);

    inf

    $ host -c ch -t txt version.bind glass.its.utexas.edu
    version.bind descriptive text "9.11.36-RedHat-9.11.36-11.el8"

    $ host -c ch -t txt version.bind ns1.yahoo.com
    version.bind descriptive text "Yahoo"

Or, one can take the ZFS approach and assume the hardware often lies :)

ATAoE ("aoe" in the Linux kernel) is nice because it is very lightweight in both terms of code to implement it (~2-3kloc, basically just stuff an ATA packet in an ethernet frame), low network overhead, and ease to setup (no IP addresses).

Kind of, there's multiple "internal clock"s. Windows (in)famously uses localtime instead of UTC by default for the RTC (stored in CMOS) which has caused many bugs (would list them all but my old bookmarks to MS KB pages were all broken by MS's site redesign), and setting the (unsupported) HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal registry key causes yet more bugs.

A hilarious one was Windows getting stuck in a loop continuously changing the time back to 01:00 every time it reached 02:00 because it couldn't persist the "InDST" flag.

    [    0.338594] Memory Encryption Features active: AMD SME