it's already not working that way in Linux, it's just that there is no rhyme or reason to it. Even on stable Debian I have to have pipx/pyenv/venv for python and juggle multiple versions of rust and go because of mismatches between software and distro versions.
This is a Python, Rust and Go issue, not a Linux issue. With "Linux" i meant the Linux kernel which does not break backwards compatibility.
Sadly, the userland does not have the same mindset as very few libraries and languages care about backwards compatibility.
However at least on Linux it is possible to do that if you care by choosing languages and libraries that do not break compatibility without worrying that the OS will break things. On OpenBSD you may write your program in C (which has strong backwards compatibility as a language) and use only libraries such as curl, cairo, opengl, openal and x11 that in general do not break backwards compatibility and yet have the OS throw all that effort out of the window.
Even on windows, it isn't usually the NT kernel that's the issue, it's the user space api's. For example, why hasn't ripgrep (and similar tools) replaced grep as a default? they're much better for performance right? (i mean on stable/mainstream distros). i get supporting old stuff, that's why there are LTS releases. But I think it is the fear of not being able to shed enough old things in new releases to displace the maintenance burden of LTS type releases that's the big issue.
Features shouldn't be ridden of just because either, there needs to be a good reason, like a better alternative.
> Even on windows, it isn't usually the NT kernel that's the issue, it's the user space api's.
On Windows the user space APIs do not change though - and Windows has a MUCH larger API exposed compared to Linux. Of course stuff does break occasionally, but considering how much software is released constantly for Windows, that breakage is incredibly minimal (and Microsoft doesn't seem to care as much about it as they used to in the past).
> For example, why hasn't ripgrep (and similar tools) replaced grep as a default?
I do not think there is a case of replacing anything here, you can use ripgrep alongside grep just fine, they are two different programs.
However there are way more people knowing grep and a ton of scripts, applications, etc, assume grep is there so it makes sense to both avoid breaking existing working stuff and take advantage of people's existing knowledge. If someone needs ripgrep's performance they can use that instead.
> i get supporting old stuff, that's why there are LTS releases.
LTS releases exist largely exactly because stuff breaks way more than it should.
> But I think it is the fear of not being able to shed enough old things in new releases to displace the maintenance burden of LTS type releases that's the big issue.
No, there is nothing about "fear" here, it is purely practical: breaking stuff that works is not a good thing. If there is some better way to do things then that is fine but 99.9999% of the cases it can be implemented alongside the existing stuff (sometimes even having the existing stuff use the new thing) instead of breaking people's code (and, even worse, forcing them to waste time learning how to use a new tool just so they can do the exact same thing they were already doing previously).
> Features shouldn't be ridden of just because either, there needs to be a good reason, like a better alternative.
No, a "better alternative" is not a good reason by itself, to get rid something you must make sure that practically nobody uses it. For example, if there was a bug on a feature or program that made it unusable and yet nobody bothered to report the bug in years, that is a good indicator nobody is using that feature / program so that it can be removed. But as long as there are people who rely on things, you should never break them.
