Debian 12 seems not to error-correct corrupted animation files associated with html web pages.
Weeks ago, I kvetched about screen tearing on Debian 12 - web pages displayed weirdly-patterned pixellated garbage with Firefox and Brave browsers. Those pages displayed properly on Debian 11, and on (Much) older Ubuntu and Redhat distros. My "cure" emerged by accident; I noticed that the Ethernet switch in-line with the "hot side" (feeding the firewall machine) of my Ethernet connection was MUCH slower than I expected after my Comcan't to Ziply internet connection change (pro tip - if you can, move to Ziply PRONTO). Connection speed slowed MORE during a 60 second Ethernet speed test. The speedometer graphic pointer, displayed on a hot-side after-switch connected, fast "sacrificial" Chromebook, dropped from 60 mbps to 40mbps. Something was warming up and getting worse, seemingly inside the hot-side Ethernet switch. Connecting the Chromebook (running ChromeOS) directly to the Ziply optical network terminal, bypassing the Ethernet switch (and disconnecting my house network from the 'net), resulted in a 250 mbps speed test. So, on a hunch, I replaced the suspect Netgear 308 Ethernet switch with a new-out-of-box Netgear 308 ... and I got 250 mbps on both sides of the switch. After that, the pixelated screen artifacts on web pages vanished on the Deb12 machine. Finding and fixing my problem still leaves me with a vexing question - why does Deb 12 display corrupted images if fed a corrupted data stream, when Deb 11 and other distros do error correction, and (more slowly) display good images? Sadly, this realization occurred AFTER I "destructively diagnosed" the failed crap-packet-spewing switch. In the capable hands of a Debian kernel guru, a stream of crap packets (with some good ones) might help debug the error-detection-and-correction code that FAILS in Deb 12. I fixed my corrupted-data-stream problem by replacing the hardware that corrupted it. I can afford to, and afford to keep new-in-the-box ready spares waiting on the shelf. In a more-fragile network environment, replacing the hardware may not be an affordable option. I imagine a rural third-world village with an intermittent data connection, using old hardware culled from first-world e-waste. They won't have a noiseless connection and perfect hardware for comparison debug. They might blame Debian 12, then switch to bootleg Windoze instead. Their kids don't learn Debian, we lose some future gurus. I should have kept the borked Ethernet switch; a noisy packet generator might help developers write and debug and test more robust code. In the wrong hands, hell on Earth. On the other hand, a machine built and coded to produce INTENTIONAL and REPEATABLE corrupted packets might help design more robust future versions of Linux. If "Corrupter" was open-source code, it might also help marginally-equipped people become Linux adepts and future contributors. I'm probably over-thinking this. However, the first step towards more robust, data-defect-tolerant Debian 13, 14, etc. is more-complete automatic testing before release. An upgradable device designed to intentionally create calibrated defective data might be a lucrative product and test instrument for professional coders everywhere. Keith L. -- Keith Lofstrom [email protected]
