The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.
And when it inevitably leads to all kinds of weird issues the packagers of course can't be reached for support, so users end up harassing the upstream maintainer about their "shitty broken application" and demanding they fix it.
Sure, the various language toolchains suck, but so do those of Linux distros. There's a reason all-in-one packaging solutions like Docker, AppImage, Flatpak, and Snap have gotten so popular, you know?
> The counterpoint of this is Linux distros trying to resolve all global dependencies into a one-size-fits-nothing solution - with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar. They are trying to fit a square peg into a round hole and act surprised when it doesn't fit.
This is only the case for debian and derivatives, lol. Rolling-release distributions do not have this problem. This is why most of the new distributions coming out are arch linux based.
Agreed, but I don't think that has to do with either it's "vanillaness" or the 6 month release schedule. Fedora does a lot of compatibility work behind the scenes that distros not backed by a large company more than likely couldn't afford.
> with every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar.
Quite frankly, as someone started distro-hopping around ~2009 & only stopped around 2020, I have experienced a lot of Linux distributions, as well as poked at a lot of maintainer pipelines — it is simply categorically untrue for the majority of non-Debian derived Linux distributions.
It used to be that a decent number of Linux distributions (Slackware, Debian, RedHat, whatever) put in a lot of work to ensure "stability", yes. However "stability" was, for the most part, simply backporting urgent security fixes to stable libraries and to their last three or so versions. The only system that is very well known for shipping "a decades old version" of a system library would be Debian (or its biggest derivative, Ubuntu), because it's release cycle is absolutely glacial, and most other Linux distributions do give somewhat of a shit about keeping relatively close to upstream. If only because maintaining a separate tree for a program just so you can use an ancient library is basically just soft-forking it, which incurs a metric shitton of effort and tech-debt that accrues over time.
One of the reasons I switched to and then ran at least one single Arch Linux installation for the back half of the 2010s (and used other computers or a dual boot for distrohopping) was partly for the challenge (I used to forget to read the NEWS before upgrading and got myself into at least one kernel panic that way lol), and partly because it was the only major rolling-release distribution at the time. In the last 6 years that's changed a lot, and now there's a whole slew of rolling-release distributions to choose from. The biggest is probably Steam's Holo distribution of Arch, but KDE's new distribution (replacing Kubuntu as the de-facto "KDE Distro") is based on Arch as well, along with I think Bazzite and CachyOS; Arch has always had a reputation (since before the 2010s) for keeping incredibly close to upstream in it's package distributions, and I think that ideology has mostly won-out now that a lot of Linux software is more generally stable and interacts reasonably well (Whereas, back when Pipewire was a thing... that was not the case).
Now, sure, I'm not going to the effort of compiling my decade+ experience of Linux into a spreadsheet of references of every major distribution I tried in the last ten years, just to prove all of this on an internet forum, but hopefully that write-up will suffice. Furthermore, as far as I can see, the burden of proof is not on me, but on `crote` to prove the claim they made.
Also, I get how if you've only ever used Debian-derivatives, all of this may appear to be incorrect. I would suggest, uh, not doing that — if only because it's a severely limiting view of what Linux systems are like. Personally, I've been a big fan of using Alpine's Edge release since before they had to drop linux-hardened and it's a really nice system to use as a daily driver.
The real kicker is when old languages also fall for this trap. The latest I'm aware of is GHC, which decided to invent it's own build system and install script. I don't begrudge them from moving away from Make, but they could have used something already established.
That's where I stopped.
Toolchains on linux distributions with adults running packaging are just fine.
Toolchains for $hotlanguage where the project leaders insist on reinventing the packaging game, are not fine.
I once again state these languages need to give up the NIH and pay someone mature and responsible to maintain packaging.