Possible Distributions quote of the year

> This is such a weird view that only really seems to exist in industries where safety isn't taken seriously and natural constraints are less obvious.

...excuse me?

Safety-critical (and to a somewhat lesser extent, financial) environments epitomize this more than anyone else.

Any code change risks _new_ bugs being introduced. So only change the absolute minimum that is necessary to achieve what you need. So fixes are backported (if not outright re-implemented) instead of wholesale update to "the latest".

As for your "comparisons":

> A plumber wouldn't say the customer is correct if they want pipes that are half as strong as the water hammers occurring will need to contained or made out of cardboard or some other material that couldn't contain water.

Or... you could use the pipes that are already there, and only add/alter what you need instead of ripping out the whole building's plumbing every time a faucet needs replaced? (you know, the "LTS" approach that your example was claiming to refute)

> An engineer wouldn't say a city mayor is correct if they want a bridge that weighs half as much as it needs to be structurally sound.

Uh... this is _new_ construction? By definition you can't re-use anything that exists. Meanwhile, what you're actually describing is the classic engineering priority tradeoffs that apply in _any_ field of endeavor.

And your example is quite flawed in other ways -- instead of stone they could use steel (or something more exotic) that is much lighter while being more than capable of withstanding the design loads. Perhaps that lower weight is necessary due to site considerations (eg ruinously high transport costs) but those other materials may cost more. Again, classic engineering tradeoffs.

> An apple farmer wouldn't say the customer is correct if they want apples that don't spoil for ten years.

Code doesn't "spoil"; it meets the design requirements to which it was written tomorrow as well as a decade later.

(Hint: a change in runtime environment is a change in _requirements_)

Every time I get into my vehicle, my life depends on nearly forty-year-old software (on 30-year-old hardware!) operating as designed. The reason it can do that is because its runtime environment is truly _fixed_.

> And yet software companies regularly promise their customers things that are impossible to deliver and just hope the customer isn't competent enough to notice or won't come back by the time they notice.

Red Hat's (and Ubuntu's, and heck, even Microsoft's) continued corporate existence begs to disagree.

Things don't ahve to be _perfect_. They just have to be _good enough_ to get what you actually care about accomplished.

Given how much of the current trend in politics is "stop spending money on the elderly", all this sounds more like a life hack than stupidity. Can't blame them for not paying for healthcare if the target audience can't ask for it.

Of course this is about one platform, the title of the page is "Distributions quote of the week", and it is talking about a specific distribution, and a specific issue. So yeah, that's what matters. Practicality matters, and academic dicussions are academic. You can have them if you want, but what matters here, today, is reality, not abstract discourses. And the practical reality is that glibc has had a stable ABI for the past 20 years and the Rust stdlib can't even go 20 minutes without breaking its own. And that matters in practice when building a distribution, no matter what purely abstract-level arguments one can concoct about the language(s) in general.

> So what you're saying is that if someone accepts your definitions of what "C" is (after all, the standard library is part of C), then by your definitions, C has a stable ABI, as long as I limit myself to a single platform.

It's a stable ABI if you don't update it. See? Very easy!