But the ideal solution would be a copy-on-write filesystem supporting snapshots, rather than A/B partitions.

NTFS is already that via Volume Shadow Copy. They just don't use it in the way we're discussing, but the tech is there.

That doesn't sound like how much Windows is actually using for itself. How much of it is \Windows\Installer\?

I know in the past, any Windows updates would be cached in your windows directory forever and there was no safe way to remove them. That would gradually grow the windows directory size forever. Also, it seems there are a lot of files that get thrown in there when you start installing multiple versions of SQL Server or Visual Studio.

Disk Clean-up.

Clean-up System Files.

Windows Update Clean-up (and Temporary Windows installation files).

Ok. Ok.

Enjoy.

I assumed it WinSxS related as the other reply mentions, and upon investigation found that it is 9GB alone! I don't run Windows outside of work so I've just never really bothered looking into it, but if it continues to balloon I guess I'll have to.

Baseless speculation: I suspect that they were referring to Apple making use of the ability to spin up a new temporary APFS volume to store the Update packages + Staging environment and blessing it for boot.

It makes a certain amount of sense to push out a static staging environment to then run the requisite OS updates and firmware updates from that controlled environment. That way you can reboot as many times as is required for the updates in the point release and still come back to the staging environment ready to go to the next stage - only needing to touch the User Data Volume when absolutely necessary.

While not nearly as 'clean' as an atomic update on a read only root filesystem, this method could be significantly more controllable and more 'clean' than doing it live on the User's Data Volume.

I suspect with iOS Software updates - it's a transactional atomic update as those machines all use read only root filesystems regardless.

On the flip side, with WSL windows 10 can now pretty much run any POSIX compliant code anyway.

Microsoft never needed to buy into that; Microsoft set its own standards with MS-DOS long before that, and Windows further cemented Microsoft's position. Where all the UNIXes and UNIX clones were in dire need of standardisation, MS-DOS and Windows were and still are the Microsoft standard.

Even in modern times, POSIX compliance doesn't necessarily mean much when a lot of recent software is being designed Linux-first, with support for other POSIX systems sometimes relegated to third-party or distribution-specific patches. Not to mention all the various implementations of POSIX compliance come with their own little quirks that make things different enough to still require manual checking for this or that.

Additionally, there are plenty of libraries that are compatible with both POSIX-compliant and non-POSIX platforms. Targeting these libraries produces perfectly usable software.

Therefore, POSIX compliance isn't the be-all and end-all of computing. Somehow or other we've managed to muddle through the years without it in Windows, and Nazis aren't riding dinosaurs on blood-soaked streets just yet.

You're making fun of unicorns, but treating 'POSIX' like a magic word.

So it doesn't help you if you want to, say, write a cross-platform library in C that needs threads, and that can be used from both Unix console apps and Win32 desktop apps. For that, you actually need a cross-platform threading API. In C++, that actually exists, in form of std::thread and friends. In C, you have to rely on third-party libraries, and those libraries have to wrap the various platform-specific APIs - so your program is only as portable as those third-party libraries. If you could just #include <pthread.h> everywhere, it would have been so much easier.

Because of fork() you will never be able to arbitrarily use NT objects unconstrained in WSL apps, but there are lots of options. You can launch both windows and Linux programs arbitrarily from the shell now so the decision to choose one or the other is slowly coming down to preference.