People would assume there is a serious problem, turn off a bunch of services, run a bunch of random-ass shell scripts, and then forget that they'd done all that and at some random point in the future discover that some feature wasn't working, and blame me.
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.
Once it actually is usable, sure, I'll take a look.
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?
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.qcow2Although, 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?
$ mpm --output-format json installed > installed.json
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.
(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.)
# 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'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)
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.
It does happen to older models as well with an updated MacOS but not as acutely as with M1/M2 Macs.
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.
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.
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.
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.
It was an endless discussion about how restarting things can have second order effects, including impacting the equipment that really was the cause.
Unfortunately, there's a very thin line between making it work and making it break.
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.
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.