Comment by beowulfey
4 years ago
Running updates are only a problem on Mac or Windows. Updates on the different linux flavors I’ve used take fractions of the time, are unobtrusive (I can continue to do work), and as a bonus, never fail to make my aging self feel like a technoir hacker with all that rapidly scrolling text. It’s all whole different ball game.
Different user groups, different priorities. I had a colleague who was a seasoned C hacker and long-time Linux user (but not someone who'd be very interested in how a Linux distribution or package manager works). Their Ubuntu system indicated that there were updates. So, they started the update. However, it was taking too much time and they wanted to go home, so they shut down the machine during the update. Unfortunately, it left the system in a bad, (IIRC) unbootable state and the local sysadmin had to spend an hour to get the system in a consistent state again.
Is it reasonable to expect that you can just yank the chord during an upgrade? Maybe, maybe not. But users have the expectation that it is ok, there can be a power interruption after all.
This would never happen with a macOS update, which uses an immutable root file system and APFS containers to switch the root after an update. Or an OSTree system like Silverblue, Fedora IOT, or Fedore CoreOS. Traditional Linux packages fall flat on their face in such scenarios (unless you use a lot of band-aid like filesystem snapshots, set up GRUB to handle boot into the right snapshot, etc.)
I think it is uncharitable to assume that the people making macOS (or Windows) update are incompetent. They may just have a different set of requirements and constraints.
> This would never happen with a macOS update, which uses an immutable root file system and APFS containers to switch the root after an update.
There are still things that cannot be interrupted like flashing firmware blobs, on many devices. Before apple distributed updates using FS snapshots they would reboot the machine first and block the user with a message that it cannot be interrupted.
It's also not a completely free or well implemented solution because (even as an x-apple user) I am made patently aware of just how absurdly huge their updates are, even for the smallest patch... incremental distribution and immutable FS based updates are not fundamentally incompatible, so I guess Apple simply doesn't respect user's bandwidth or assumes all of their customers have gigabit downlinks for the exclusive use of Apple devices.
That’s a good story. I thought apt can usually recover from incomplete updates, but maybe it was in the middle of a kernel or bootloader update or something when power got killed.
> This would never happen with a macOS update, which uses an immutable root file system and APFS containers to switch the root after an update.
Hehe, oh yes you can still have data loss on macOS. See the recent article about how macOS SSDs use write-cache enabled.
Sure you can have data loss. But we were talking about updates. Most image-based systems do not update in-place, but write the updated system first and flip the switch atomically when the update is successful. macOS 11 and later cryptographically verify the new on-disk system volume and boot into the old system if the verification fails:
https://support.apple.com/en-au/guide/security/secd698747c9/...
SSV not only helps prevent tampering with any Apple software that’s part of the operating system, it also makes macOS software update more reliable and much safer. And because SSV uses APFS (Apple File System) snapshots, if an update can’t be performed, the old system version can be restored without re-installation.