Well sorry, I was not clear. The only part that I generalize to the whole “industry” is the fact that a major bug in production is not acceptable. Yet, what I was saying is probably true for a lot of “physical industry” like @juleskers highlight it. His examples are exactly what I have in mind. We are creating safety critical software in the sense that a major bug may lead to humans to be harmed or worst (in real life, with all the existing protections, you need a lot of critical bugs to see something harmful happen, hopefully no-one will never see it).

juleskers: juleskers: Ironically, this paralysis also means many bugs are never fixed, leading to medical security nightmares (media.ccc.de), such as rickrolling actual heart rate monitors, or crashing the million-dollar MRI by running a port scan on the guest WiFi…

This is also very true…

About the ESR subject, we can (and it is what we do for some compilers) stick to an old certified version with its known list of acceptable bugs. The kind of bugs that we want to have fixed are not always security ones but more any kind of bug that may lead to unexpected hazardous behavior (I remember this example of a compiler optimization (I have no reference on it) that would lead to unexpected result if the sum of two compared variable overflows on 32bits. This was very specific to a target but for us this kind of bug need a new version with a new certification)

skade: skade: I mean, the huge advantage of ESR is usually that it moves on a known base (e.g. same version of LLVM and such).

Well, in my opinion, from usual software development point of view, having a known base, the base you rely on, is still true if you change your compiler version as long as you rely on stable functions and standards language feature (this is very true for C and ADA, less for Rust with the “unstable” features). I do not think that staying on the same version of LLVM really matter. Changing a gcc version shall not change the compiled program behavior or the way you use the compiler (ESR or not). However, the new gcc version may introduce a new optimization mechanism in some context that you exactly have in your software, or maybe new feature that you are not using. You, and many other, may think that cannot bring any issue, but when making safety critical software it has to be proven. This where we would have a lot of work to demonstrate that this potential issue does not matter. For my point of view this is where ESR is interesting.

skade: skade: what’s more interesting is finding out what would be direct ways of making the situation better for people at specific places.

I think that ESR is one thing that help because it allow to use something we know will gain maturity with less risk of regression. Another thing that help is the ability to easily list (or extract a list) of the known bug applicable to a given version (even very old).

However, I have never worked for the certification of a compiler, this will be new for me. All project I worked on before already had their certified compilers (some have more than 10 years). I will talk about this with someone more experienced to have his insight. All of what I said is my personal opinion and my coworkers may have a different one.

Note: Firefox ESR is supported for one year so less than the time we may take from the start of specification to the release of a version of our software. (Our product are then supposed to run 30 years but without software update in most case). So one year of support, feels almost like a minimum to me.