(Optimization: hash tree, figure out which specific files are broken and download only those.)
To emphasize, this isn’t really a serious issue for most users, I’d imagine. I just wouldn’t want to see this as the model for improved Mac updates.
I bet that changing the compression used by apt would need a little study of libapt, than understand the process to send the patch... in the specific case of apt, you'll have to write unit tests and persuade developers to accept your changes.
If it is accepted you'll may have to wait maybe even 3 years for it to finally reach an Ubuntu LTS when it will finally be deployed to end users who limit themselves to LTS versions by OEM vendors.
In the end, I understand them. A good balance between stability and new features is needed.
The dpkg patches required to add zstd support for .deb packages are pretty small, but they've also languished in Debian for a couple years.[1] But Debian's bureaucracy seems especially slow to move, and in general this kind of issue (inefficient compression in a packaging format) is not the kind of issue Linux distros suffer the worst from.
Ubuntu, Fedora, Arch, NixOS, GuixSD, Solus, and Void Linux are all already using zstd compression for OS installation, packaging, or both. That pretty much covers your bases for downstream distros and also oddball, niche things. openSUSE will presumably switch to using zstd compression for packaging when they change defaults from zypper to dnf for their high-level package manager.
A lot of Linux package managers just use FreeBSD's libarchive for all of their compression needs, which covers a ton of formats. Presumably Apple could do the same with their imaging tools.
—
So, fix it. Let it be fixed, and then no longer an issue. But because it won't be deployed until a year out, it's not going to be fixed. That's just dumb.
As if you could do that for a random distro you've used? Good luck trying to get them to change how they compress updates upstream, accept your patches, and so on.
More realistically you could just change to another distro with a different method of updating.
But then again if your issue was not with something distro-dependent, but something like a core tool you want to use (regardless of distro, say, Wayland, Gnome, or GIMP, or GCC), you'll again either have a hard time getting into the community, sending patches, and having them accepted and integrated, or a hard time maintaining them on your own branch.
There are issues with Gnome for example, with thousands of user complaints, that haven't been touched for years (e.g. preview in file picker, iirc is a classic example).
Fun detail - newer IBM mainframes enable all cores (including the ones that are there but you didn't pay for) during the boot process to reduce downtime.
Since doing this, I've gone through a few security updates and was expecting the udpates to find that the original .plist files were missing and put them back in, but alas they did not as they remained as is.
It's understandable Windows updates take longer because Windows offers the guarantee that a file path will always point to the same while the machine is running, as opposed to Unix environments where they only guarantee your file pointer will point to the same file. This makes upgrading a running machine a bit more complicated than replacing files from under running processes. I'm not even sure how I would implement such a thing. Probably file system overlays and collapse them on reboot.
Still, it’s crazy when compared to the sister box that’s identical but runs Ubuntu, which remains usable through the whole upgrade process (and takes a lot less time unless it’s a full OS upgrade)
(Both Windows and macOS spend a lot of time in indexing your files - processes which can also be done post-installation - and doing all sorts of on-device analysis on your files to provide some specific feature, for example facial recognition on photos. And both collect a lot of your data during this process.)