Also to advocate for a specific tab size while also advocating for hard tabs is nonsense. The one flimsy claim to usefulness tabs have is that different people can use different tab sizes and all at the low, low cost of everyone having five times more work to use tabs for indentations and spaces for alignment and thus having to use visual whitespace of some kind.

And I am saying that that information you are referring to is unknown for any given CVE unless it is unlocked by some investment of effort that usually far exceeds the effort to actually fix it and we already don’t have enough resources to fix all the bugs, much less assess the impact of every bug.

Assessing the impact on the other hand is an activity that is only really useful for two things

• a risk / impact assessment of an update to decide if you want to update or not
• determining if you were theoretically vulnerable in the past

You could add prioritizing fixes to that list but then, as mentioned, impact assessments are usually more work than actual fixes and spending more effort prioritizing than actually fixing makes no sense.

I am familiar with CVSS and its upsides and downsides. I am talking about the amount of resources required to determine that kind of information for every single bug, resources that far exceed the resources required to fix the bug.

New bugs are introduced in backports as well, think of that Debian issue where generated keys had flaws for years because of some backport. The idea that any version, whether the same you have been using, the latest one or a backported one, will not gain new exploits or new known bugs is not something that holds up in practice.

The idea that it is somehow possible to determine that for each and every bug is a crazy fantasy by the people who don’t like to update to the latest version.

If you don’t have a DB or the ability to store data in general none of the open source analytics software will work either.

It is really quite simple.

Flatpaks (and Snaps, and Appimages and Docker containers for that matter) are essentially designed for app developers who grew tired of distro maintainers demands to fix certain things about their build systems and their applications that broke when their apps were used on distros other than the exact distro and version the developer was using. They are designed to take a “kill the messenger” approach to the problem and now people are wondering why the work that the distro maintainers did before doesn’t get done any more.

They are also a huge cause of extra work for the rest of the Linux ecosystem with their ancient software versions in RHEL. And the worst of it, everything you learn by doing work on those ancient versions is useless knowledge.