Hacker News Reader

Comment by warent | Hacker News Reader

I'm by no means a low-level OS developer but I can't help but wonder, wouldn't it be possible for Windows to partition off part of the disk to copy system-critical files and then quietly stage updates in the partition (all of this with minimal thread priority so that if some other process demands resources/threads, it will pause/defer itself!). When the staged update is complete, it gives you a friendly notification "You have a new update available!" which you can then complete as fast as your disk can copy files (or even just set some flag to toggle the partition in use... The old partition then becomes the new staging partition)

Does that make sense at all or is this an unrealistic idea? EDIT: Maybe this is how updates already work, I'm not sure

View on HN

> wouldn't it be possible for Windows to partition off part of the disk

This is what ChromeOS and Android do. At least on Android Pixel phones, there's A and B partitions for each of the boot, system, and vendor partitions. The bootloader tracks whether A or B should be booted. Userspace downloads the updates and writes to the opposite-than-booted partition. On reboot, the bootloader boots the latest partition. Downsize is these partitions are now double the size, so less space for the user partition.

This is also how microcontrollers like the ESP32 do over-the-air updates while keeping a "safe" factory firmware version.

https://www.quora.com/How-do-you-shut-down-a-Windows-10-comp...

So when Windows says you have an update available, the design is that it did all the work that is possible and all that's left is (in theory) the copy bit that's left.

My completely ill-informed guess is that there are exceptions to this rule by teams that aren't fully aware of how updates work under the hood and as a result upgrading takes longer than it really should. As time goes by those teams get hit with a stick and they fix things, but the upgrade team probably plays a fair bit of wack-a-mole.

The original devs for WinNT and NTFS made some interesting decisions with file locking. Hard locks in the Windows world are pretty difficult to identify, much less release.

The update stage all the files that need to be change and complete the release process on boot before any system processors are allowed to lock anything.

I'm pretty sure this is how ChromeOS' update system works.

Are you sure? Because ChromeOS is just a Gentoo fork where google replaced the package manager to support their binaries instead.

Programs running in memory just stay running, even if you update the files that are those programs. This is how Linux works. Restart them when you need the new version.

Its clean. Its easy. I kept watching netflix as firefox compiled (~30 mins), and got to close the browser after the next episode was done, and open the latest Firefox to monkey with the new settings.

I didn't know that (Gentoo user). I suppose it has more in common with Sabayon as a binary jobbie. The full Gentoo experience is not for the faint of heart but when you have spend hours watching compiler etc output and fixing breakage that would bring most users of an OS to their knees, you lose the dread inherent in OS updates.

You are nearly (and generally) correct about programs just stay running even when overwritten but of course programs generally consist of more than one file and might run more than once and if you update part of this and something reloads or whatever, you can end up in a world of hurt. That said, it is behaviour that I have relied on more often than I can count and so have you with your Firefox anecdote. I've done some remote Gentoo updates with systems in quite the broken state - it keeps IT interesting! I once had to get Puppet to install telnetd on some systems so I could repair sshd.

Several years ago I remember reading on stack overflow about how someone had managed to rm the ls program on a Linux system. Your anecdote reminded me of the fix. I’ll do some googling and see if I can find it. If I can, I’ll post it here.

Hats off to people like you. You’re what we mere mortals aspire to, and it’s always encouraging to hear that someone else has attained a level of mastery. Makes it seem more achievable!

> Are you sure? Because ChromeOS is just a Gentoo fork where google replaced the package manager to support their binaries instead.

Yes, and that's a gross oversimplification. Android got the idea from ChromeOS.

I suspect it's possible to reload the OS in place with kexec, but haven't proposed it yet.

Eventually the kernel has to be updated, which you want to reboot for. Plus ensuring that the entire userland is running the same new versions of base system libraries isn't much less disruptive than simply rebooting.

Anyway, ChromeOS swaps the system and kernel between 4 partitions [1] - automatic update effectively installs a new system into the system partitions you're not booted from, then tells the boot loader to boot from the other ones next reboot.

[1] https://www.chromium.org/chromium-os/chromiumos-design-docs/...

> google replaced the package manager

Google uses portage: http://www.chromium.org/chromium-os/packages/portage

It would make more sense for Google to be using Portage to make/install their binary packages. Emerge and quickpkg can both make binary packages: https://wiki.gentoo.org/wiki/Binary_package_guide#Creating_b...

This is how some versions of android work. If a new update partition fails to boot, it falls back to the old one automatically.

Or maybe they can implement some overlay FS and updates will be stored in FS overlays. Writing to overlay would be possible even when Windows is running. Effectively shortening time when computer cannot be used due system updates. Basically the only disrupt would be just simple reboot to activate the FS layer due Windows file locking.

I dont think this is the problem itself. A lot of the problem is the user directory is a mess of both user created data and system data all jumbled about.

File copy speed itself is rarely the problem. IOPS, where hundreds of thousands of small read and write operations in the registry and other small files dominate the process.

This is how embedded devices do firmware upgrade - I'm not aware of any other sane & safe way to upgrade.

Reply on news.ycombinator.com