I don't know why people are dismissing this as non-viable or complex.

For example, a typical Windows deployment is 15-20GB after being extracted from an ISO image that's essentially static. There's monthly updates, which are also monolithic multi-GB patches that wholesale replace system files.

This is basically like a Docker image, but with the Kernel and drivers included in the base layer...

.. but without any of the niceties of dockerfiles, such as precisely tracking what differences have been applied!

The Windows registry could be split into a "system base hive", a "patch hive", and then a "customisations hive" on top.

Similarly, Linux filesystems could keep a base copy of the "/etc" directory and then any changes on top in something like a unionfs or docker image like overlayfs.

Modern phone operating systems more-or-less work like this, so it's definitely possible.

In the distant past of 40MB hard drives, this approach would have been wasteful. In the era of 5GB patches... does it really matter?

This is especially true on macOS Catalina or later with SIP enabled. The entire operating system is mounted read-only [1] and your local changes are effectively contained within your user directory.

[1] https://support.apple.com/en-us/HT210650

Just an update for curious to bare windows OS size

  9.0G Oct 27 06:54 win2016_core.qcow2
  12G  Oct 27 06:30 win2016.qcow2
  7.4G Oct 27 06:31 win2019_core.qcow2
  12G  Oct 27 07:02 win2019.qcow2
  6.9G Oct 27 07:03 win2022_core.qcow2
  11G  Oct 27 06:56 win2022.qcow2

This has gotta be some sort of HN meme at this point but... NixOS gives you this (with the tradeoff of course of a really steep learning curve and very opinionated packaging structure)!

Tbh in the hypothetical scenario where all of a company's configuration were handled via nix, you'd be staring at tens to hundreds of thousands of lines of company-custom .nix files where one single line might cause the bug you are encountering.

Right, but at least anyone could look into it in the company repo, instead of needing to poke at the actual machine (or an image of it)

The asymptote for NixOS approaches -infinity.

Once it actually is usable, sure, I'll take a look.

I compare previous to current settings using a pattern like this.

  # backup defaults to a file in the home directory with the current timestamp
  alias backup.defaults='defaults read > ~/.backups/defaults_$(date +%Y%m%d-%H%M%S).txt'

  # compare the most recent defaults backup file to the current defaults config
  alias diff.defaults='diff -u <(cat ~/.backups/$(ls -1 ~/.backups | grep defaults | tail -1)) <(defaults read) | delta'

This reminds me of the general idea behind Tripwire[1] for macOS. I last looked into it back in 2005 (we went with other approaches), so it may have changed since then, but it monitors for changes, and allow you to revert them or deploy them to other computer (as in a lab, etc).

[1] https://github.com/Tripwire/tripwire-open-source

This would be great. In principle, this should be a `diff -ur` of /etc against the default /etc of the OS. Some complications ensue as the user’s own dotfiles might override some things, too.

Not a full OS-diff, but there is a way to dump all the packages installed on a machine:

    $ mpm --output-format json installed > installed.json

Source: https://github.com/kdeldycke/meta-package-manager/

With regular snapshots you can at least eliminate new installed software as the root cause of an issue. Doesn't solve the issue with preferences though.

Wow, I've been using MacUpdater but `mpm outdated` seems very useful for e.g. globally installed yarn/npm stuff too!

The amount of changes that your OS goes through (downloading applications, applications creating files, applications changing files) is too much to update on a diff file.

Although, for the major changes I feel the major OS's should add the ".diff" file called updates.diff and describe the major updates in your laptop.

This should also happen each update, we need to know what updates are going to be installed, and what is the purpose of doing this?

That's honestly the main thing that made me fully switch to Linux - I use a tool called aconfmgr to do (the equivalent of) that on Arch, or NixOS would be even better now that exists.

(The main or second main thing now would be window management, the period I was using both made me like i3 now sway more and more, and grow to find macOS even with yabai or similar much more difficult and messy to use.)

This should definetly be possible to write for macOS, since the recovery partiton contains the base OS

With the sealed system volume modern macOS uses, shouldn't this relatively doable? (It'd be a long long diff of XML plists I guess)

Most macOS settings are saved under the current user home directory, which isn't sealed.