> To my knowledge this is pretty close to how updates work today.
But isn't the key advantage of coreOS's model, a sort of green/blue deploy model for the OS — i.e. that it can write out the new updated OS release in the background while the previous release of the OS is running; and then, when it's done, "update" by just rewriting the EFI boot list to default to the new release — without even needing to reboot to perform the update, instead just saying "the next time you reboot, you'll be booting into the new release"?
There's no reason that an "OS update" under this model, should ever be a thing that takes over your whole computer, and then sits around with an "updating" progress bar, blocking startup. But that's what macOS does.
I think your intended meaning, was that the current model involves a binary diff that gets used to patch the OS volume, while the OS is booted into the recovery volume. Which, yeah, uses kind of the same abstractions — but doesn't give any of the key advantages.
But isn't the key advantage of coreOS's model, a sort of green/blue deploy model for the OS — i.e. that it can write out the new updated OS release in the background while the previous release of the OS is running; and then, when it's done, "update" by just rewriting the EFI boot list to default to the new release — without even needing to reboot to perform the update, instead just saying "the next time you reboot, you'll be booting into the new release"?
There's no reason that an "OS update" under this model, should ever be a thing that takes over your whole computer, and then sits around with an "updating" progress bar, blocking startup. But that's what macOS does.
I think your intended meaning, was that the current model involves a binary diff that gets used to patch the OS volume, while the OS is booted into the recovery volume. Which, yeah, uses kind of the same abstractions — but doesn't give any of the key advantages.