[bitwize]

It's not a matter of "could". Apple DID this in the past.

In the mid-2000s, GCC switched C++ ABIs. Apple pushed out an update to Mac OS X 10.3 which replaced the static libstdc++ using the old ABI with a dynamic libstdc++ using the new ABI. This broke C++ compilation under Mac OS 10.3. They did not bother to update the compiler to use a new ABI; they had decided that if developers still wanted to compile for 10.3, their supported path -- compiling using the latest Xcode (available for 10.4 and up only) in its 10.3 backward compatibility mode was good enough. People still using 10.3 who wanted to build e.g., GNU software were just too niche a use case to warrant any kind of support.

Lesson learned: if you intend to build software on Apple systems, always have the latest shiny, or you risk being left in the lurch.

[ahefner]

Not even the last time they did something that. Just in the past six months, I noticed I was no longer able to link against certain C++ libraries being installed via Homebrew, because some change in the ObjC runtime meant that whatever I was running was unable link libraries built with newer compiler versions (various ObjC symbols would be missing) - presumably the binaries installed by Homebrew had been built on a newer system - and the current Xcode tools wouldn't install on Monterey, you had to upgrade to Ventura. Meh.

[asveikau]

g++ ABIs changing in the 2000s was pretty painful on linux too.

But I think there is a fair point that arch linux probably doesn't care much about what breaks on its rolling updates to shared libs. I would guess you'd get less of that on, say, Debian.

[nmnmnmnmnm]

>arch linux probably doesn't care much about what breaks on its rolling updates to shared libs.

This is a misconception. I'm not saying it never happens, archlinux is run by volunteers, resources are limited, but contrary to popular belief it isn't always the place that gets updates the fastest and when things break it's because upstream really screwed up and let something bad in that went unnoticed. If anything is noticed at all, arch will play the conservative card.

Bash is still on 5.1.x on archlinux because Bash 5.2 (that was released, by the way, almost a year ago!) introduced compatibility issues with older scripts that abused some bashisms (this makes a very solid case for only writing shell scripts in pure posix. Use shellcheck and checkbashisms.) Meanwhile almost every other distros jumped on 5.2 by now.

Arch will upgrade to the latest and greatest when changes are minor. We get the official upstream point releases that fix bugs and security issues fast. It does not mean Arch doesn't pay attention when it matters.

Most often when something break on archlinux it is because people aren't following the instructions from the arch-announce mailing list when there is a major transition, because arch is not a distro that automates processes. When grub broke for some users recently, it was because they didn't run grub-mkconfig, which should always be done when upgrading grub because grub has a very funky configuration file format (the config file you write is like a "source" for it to generate another, different config file that gives you NO guarantee about its format staying stable). Note that upgrading the grub package does not, in any case, ever upgrade grub itself, because archlinux is a distro that does not automate things for you. So people who had a broken grub did this to themselves, they ran grub-install but didn't run grub-mkconfig. Anyway, I would recommend systemd-boot to any user on modern EFI systems because it was written by much saner people.

Arch Linux's core philosophy isn't really about having the absolute latest packages. There were times when a Fedora came out with the latest Gnome before the latest version reached the stable repositories in Arch.

Arch's philosophy is to give you a Keep It Simple, Stupid system. There is no automation beyond what the software packaged provide. There is no splitting packages into many tinier packages like other distros that are very annoying with their -doc, -dev and so on packages (disk space is so cheap, why would you NOT want the documentation to be present??). You don't have to hunt for funky names of dev packages when you need to compile software, if you already have the dependencies installed, they also come with what you need to build against them. The arch packaging format is the simplest of all distro, with the exception of slackware which does not have dependency management. What few system tools exists to manage the distro are all written in shell scripts (mkinitcpio, arch-chroot, pacstrap, pacdiff, mkarchiso..) except for the package manager, pacman, being in C. You could say that being a rolling release is a side effect and not the main purpose. Since there is no automation and it is a simple system on an architectural level (not as in "user friendly"), adapting to gradual changes is much less painful than doing major releases every once in a while like debian stable because with the KISS philosophy it would compress a serious amount of work to do on the side of the user to handle so many transitions at once on their own.

Debian's care about whether things break or not, that you mention, depends on which edition of debian we're talking about. Debian stable cares a lot about breakages and upgrading from a stable to another is always a smooth process. They go to painstaking lengths to make it work.

Debian unstable on the other hand.. I've had times when they introduced new library versions that broke many other packages and I found myself unable to install software I wanted to try because the repositories were broken in that way. Debian unstable is not the "rolling" alternative some people think it is. If you want a rolling distro, use a rolling distro. Ever since I tried arch many years ago, I left unstable and never looked back. A library that breaks many packages that are part of the arch repositories will not leave testing. They can however break things that are from the AUR, there is no official support for the AUR pkgbuilds.