Out of curiosity, were the other distros that the pages displayed correctly on the same or on different machines?
On Thu, Aug 15, 2024 at 1:49 PM Keith Lofstrom <[email protected]> wrote: > 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] >
