Do you ever think about your toaster? No of course you don't. It turns on when you need it, toasts the bread, and then turns off. It doesn't require your attention. Ever.
Then you look at your computer and wonder what buggy hell you'll end up with if you roll the dice with the latest updates.
Something is fundamentally wrong about how we are using computers.
Computers as appliances used to be more true than it is today on significantly worse hardware.
The “instant on”- of a commodore64 is a distant thing of the past but it needn’t be.
One of the major reasons for systemd coming to prominence was boot times, so people do care.
If your machine could start and stop in 500ms flat then it would fundamentally change the way you interact with it.
Here's a summary of what happened: Firefox got a new password database format. Originally, it would write the new database file and use it if present, but leave the old one there indefinitely. A little while later, people realized this was a security vulnerability: if you create or change your master password, the old database will still let attackers in without one or with the old one. The vulnerability was fixed by having Firefox delete the old database on startup.
The code to read and write the new password database was a new feature, so Red Hat deemed it unworthy to add to their "stable" distro. The code to delete the old password database was a security fix, so Red Hat cherry-picked it into their distro.
But now the problem should be obvious: Red Hat's version of Firefox now deleted the old password database on startup, but lacked the code to write out the new version of it. As a result, as soon as you started Firefox, your saved passwords would be completely wiped from disk. This problem was inherent to the "stable" model that RHEL uses, and would have never happened with distros that just take new upstream versions and avoid cherry-picking patches, like Arch.
One backwards compatible issue in how many years, builds and packages? I would say _often_ is highly exaggerated. I've had many more issues with rolling release distros than I've ever had with CentOS, I can basically do a yum upgrade and reboot with my eyes closed and not have any issues.
And besides, it isn't just one issue. https://bugzilla.redhat.com/show_bug.cgi?id=2039993 is another example of a problem caused by incorrectly cherry-picking a security patch: OpenSSL was affected by CVE-2021-3712, which they quickly and correctly fixed upstream. But RHEL still uses OpenSSL 1.0.2, which has been EOL for more than 2 years, so Red Hat had to backport the patch themselves. When they did so, they made a silly typo (forgot the "!"), which made Web servers all crash with a double free error very shortly after every startup.
https://bugzilla.redhat.com/show_bug.cgi?id=1861977 was yet another, in which trying to fix a Secure Boot-related vulnerability rendered computers unbootable. A fourth one, which I unfortunately don't remember the bug ID for, was when a patch added to NSS in a security update made programs hang when you tried to use a smart card.
To be clear, I didn't go searching for these problems. I know about them because I was affected by them all.
Firefox is a run time environment for the UI for POS/kiosk systems. With horrific customer applications running on top. I can only imagine the internal discussions inside these distros wether to upgrade firefox/chromium or wether to backport patches.
That's why each of the profesionally backed distributions has some strategy to mix the frozen version maintained baseline with some more recent subsystems "from the future", SUSE calls it "Leap", for example.
So I'm not sure if you suggest to completely abandon frozen version supported platforms? or do you suggest improving upon the model? so fewer issues like the ones you listed occur? "even fewer" I should say, because the events are rare. painful, but rare.
you bet this thing has some little RT-OS on it, like FreeRTOS maybe?