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.
> ...every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar.
Applying non-vanilla flavor (patches) to libraries in able to make new packages work with old packages. (It's not just a library thing of course--I've run into packages on Debian where some component gets shimmed out by some script that calls out to some script to dynamically build or download a component. But I digress.)
Maybe I'm just out of the loop here, but I'm not aware of this being a general practice in Fedora. Yes, Fedora does a lot of compatibility work of course, but afaik the general practice isn't to add Fedora-flavored patches.
> 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.
It sure sounds very Debian-ish, at least. I’m a Fedora user, and Fedora stays veeeery close to upstream. It’s not rolling, but is very vanilla.
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.
"Vanillaness" is exactly what's in-scope here:
> ...every package having several dozen patches trying to make a brand-new application release work with a decade-old release of libfoobar.
Applying non-vanilla flavor (patches) to libraries in able to make new packages work with old packages. (It's not just a library thing of course--I've run into packages on Debian where some component gets shimmed out by some script that calls out to some script to dynamically build or download a component. But I digress.)
Maybe I'm just out of the loop here, but I'm not aware of this being a general practice in Fedora. Yes, Fedora does a lot of compatibility work of course, but afaik the general practice isn't to add Fedora-flavored patches.
`crote` claimed:
> 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.