I swear I really wish there were a way to output an entire OS's "diff" from default settings. Every preference pane, every terminal setting, every changed system file.

So that you could both discover, in cases like this, what's changed -- but also simply so you could export your settings in a space-efficient way and (selectively) re-import on a new OS install.

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.

I just spent the last week diagnosing catastrophic Wi-Fi issues at a client location. 90% of macs wouldn’t connect to Wi-Fi, when they would association would take 45 seconds. Sometimes you couldn’t route or ping the gateway. When you could you’d get disassociated within a minute. Turning off the airdrop/anirplay interface fixes it instantly. sudo ifconfig awdl0 down

It took us 5 days to figure it out. We had no less than a dozen professionals on it. Each with at least a decade of experience. We combed the Wi-Fi and network config repeatedly to figure out what we did wrong. (It wasn’t till we had the hint that it was client side that we sniffed the nic to see the packet of death)

So I’m going to respectfully disagree. Articles like this are important. If I’d seen this last Monday it’d have saved me a week of hell and saved my client a week of vastly diminished productivity. Not to mention the tens of thousands of dollars spent diagnosing it and the millions of dollars of lost revenue from the deals they couldn’t close because calls kept dropping in the office (because enough people were on hotspots to saturate cell service in the area)

Information is important, but this post didn't have enough technical information about how to tell if this is your problem. How many people would say they haven't experienced “slow internet connection” or “drops in Zoom calls”? “entirely losing a WiFi connection” is less common but does that mean “it happened once and then it came back” or something like the hell you're describing.

That's important for the reasons the person you're responding to mentioned. I too have seen many problems caused by this kind of thing where someone had something they didn't like, made a ton of low-level config changes based on random blog posts, and then forgot about that when it broke something else.

I work at Meter.

We’ve seen this repeatedly across different types of spaces and have had teams spend similar amounts of time to get to know what’s going on underneath.

Sounds like a good argument for Ethernet and wired docks? I mean if millions are on the line why wouldn’t you ensure there is that backup there?

Apple makes weird changes that impact docks too. Something changed in Ventura where certain display modes just don’t work anymore.

Was it happening to M1/M2s like the article states? Because I’m experiencing very similar issues with a 2019 model.

I work at Meter.

It does happen to older models as well with an updated MacOS but not as acutely as with M1/M2 Macs.

Couldn't have said it better.

That script will be hanging around on people's laptops for years, if not decades (for people that migrate their macOS installations to new machines) at the end of the long tail.

This is a good point, we’ll make sure to update the post to note that the advice is no longer needed once Apple fixes things on their end. The script will get killed with a simple restart, so the odds of this hanging around are low.

For companies that decide to implement this or a similar solution using MDM, `sudo pkill -f /tmp/disable_awdl.sh && sudo ifconfig awdl0 up` will also disable the effects of the script.

The problem is this is a real legit problem that I experience daily. I was having this issue where video and audio calls on my MacBook were degrading super badly. I’d reset the modem, I reset the router, reset everything.

Reconfigured everything I could. Nothing helped.

I ran a packet loss test online. Link below.

It was showing huge delays in packets.

I came across an article somewhere. Forget where now. Disabling the awdl0 interface fixed the issue entirely for me. Packet loss tests worked perfect every time.

Turn the interface back on? Problem reappeared immediately.

That said, I manually turn it on and off as needed and don’t set things up to disable all the time. But it’s a real issue that was causing me a great deal of problem at work. So it’s not just some bug to me. It’s a serious one and you seem to be saying it’s not and people turning it off and forgetting is a big deal. I suppose it could be but don’t reject that it does fix a real issue.

don't forget all the cargo-cult of people stumbling on this article with unrelated wifi issues!

Including all the tech-savvy computer people with decades of experience, who figure the modern hardware and software has so many complex interactions that it's often better to try any plausibly looking solutions first, and only then figure out why it worked (or revert it if it didn't).

I mostly agree. But the article isn't the main problem, the sloppy script is. When I install such hot fixes, I have them check if the cause still exists (e.g. still running under Monterey?) and, additionally, add a timeout based on a date.

If you simply disable the nic apple helpfully reenables it 15 min later. There’s blame to be assigned here. Pretty sure it belongs to apple.

I messed with my Switch's netwotk settings based on a random Tweet some years ago for Smash, maybe something about packet size. So did a lot of other people. I wonder if I aught to clear that. Doesn't seem to hurt though.

From the first to the last day I worked in computer networking I encountered otherwise capable people who thought that if they randomly rebooted things… the problem was with the last thing they rebooted before “it worked again”.

It was an endless discussion about how restarting things can have second order effects, including impacting the equipment that really was the cause.

No-one should run these shell scripts unless they're 100% sure that they know what they're doing. The problem lies in the fact that anyone can run shell scripts which can break the OS or make the OS work.

Unfortunately, there's a very thin line between making it work and making it break.

Well then Apple shouldn't have shipped this bug then. Why blame individuals rather than the $2.3 trillion dollar corporation which can't get its act together.

People in the know are aware that this is just the tip of the iceberg with macOS bugs. Wifi bugs that everyone has to work around, APIs that promise Unicode NFC but aren't actually NFC, quadratic performance bugs caused by various always-on Apple services that trigger under mysterious circumstances, regressions every other minor version, the list goes on. Linux, which has orders of magnitude less money behind it, is somehow so much more robust.

But Apple won at capitalism, and the dream of most startup founders is to also win at capitalism, so this forum is filled with sycophants.

back in the day i used to support microsoft's ISA product (layer 7 firewall)

customers would just not know what configuration they had made. so we had a bit of VBScript that would dump the entire config into a text file. amazing how many customers had left themselves open in bad ways in production systems and also how their perspectives of what was configured did or did not match reality.

That product was the worst. I remember they had a client that people wanted to install for some reason. In one case, the client would bypass some configuration that was supposedly critical and I got stuck in the middle of some crazy argument between security, network ops and support.