I will say that 26.4 beta 2 was the first time I've regretting using betas since Sonoma beta 2. The Sonoma beta ruined the firmware on my machine and Apple had to replace the logic board; the latest Tahoe beta broke all networking on my machine and I had to erase the installation to fix everything. I've since dropped off the beta train for the time being.
I already left the beta train on my iPhone because I had too many issues getting my grocery apps to allow me to place orders without going to my laptop and doing it in a web browser.
I had never heard about this app. I thought the era of advertisements taking over the lock screen ended back in the Android 4.x days!
But also, thinking from the business perspective, it's difficult to make phones meet such a low price point without either significantly compromising their performance or stuffing them full of ads to subsidize the price.
I assumed it did something like that, but I honestly don't even know what it actually does, because the moment it gets loaded or anything like that the phone locks up and has to be manually reset using an obscure power button combination.
To add insult to injury it re-installs the app if you remove it and re-enables the app if you disable it. This is done by the carrier/mfg specific application which cannot be removed.
While I generally agree with your sentiment, these tools aren't bad ones:
- Santa is a very common tool used by macOS admins to lock down binary and file access privileges for apps, usually on managed machines
- Disk Inventory X and GrandPerspective are well-known disk space usage tools for macOS (I personally use DaisyDisk but that requires a license)
- WizTree and WinDirStat are very common tools from Windows admin toolkits
The only one here I can say is potentially suspect is ClearDisk. I haven't used it before, but it does appear to be useful for specifically tracking down developer caches that eat up disk space.
One of the important reasons that it works so well is because it uses the Hexagon DSP in the Snapdragon processors to catch the events. That's why it's so hard to replicate. It's possible to do it entirely in software, but it chews through battery if you do it that way. I can't find it now, but there was an article a few years ago that explained how the feature worked.
And there's no way to program the DSP without being the creator of the device because Qualcomm requires DSP programs to be signed, as far as I'm aware, and the key has to be trusted by the device vendor.
Wild. Thanks for the keywords to search-engine this with. I found "Reverse engineering the Motorola Sensorhub: Part 1"[0]. To this point I hadn't thought about how they might have implemented the feature. That article sheds some light on it.
That's the right chip. The other comment shows off the article. I forgot that it was called the "sensor hub", that's why I couldn't find the post showing how it works.
Damn that's scary. I like that guy. He said everything necessary to that topic.
Never rely on something you've found working for your case but not designed to be used like that.
Dell likes to pull this stunt on other devices too. Like their 1L desktops in the OptiPlex line that I managed for many years. Even though we were using genuine Dell power adapters, if they became slightly unplugged but remained powered, they would enable PROCHOT.
This was fine until the machines randomly started setting PROCHOT on genuine power adapters that were fully plugged in. Eventually I just deployed a configuration with PDQ to all the machines that ran ThrottleStop in the background with a configuration that disabled PROCHOT on login.
Unfortunately, I couldn't get it to consistently disable PROCHOT pre-login, so students and teachers in my labs would consistently wait 3-4 minutes while the machines chugged along at 700 MHz as they prepared their accounts.
I've made a feature request there to add another GitHub Actions bot to auto-close issues reporting errors like this when an outage is happening. Would definitely help to cut through the noise.
I would normally do something like that; however, we opted to open an AppleCare Enterprise case for it, since it gets an engineer to look into the issue.
Both our Mac IT manager and I are thinking that it's the AV engine (Microsoft Defender) seeing fragments of YAML in the PSI tree and then blowing up after trying to parse the next line (which is not a truly valid YAML tree, it's a YAML tree with all the semantic details produced by IntelliJ). That in and of itself shouldn't be an issue, but I guess they weren't expecting random fragments of YAML to be copied and pasted.
We're still not sure why it only triggers in terminal emulators, though. That one is a total mystery.
I already left the beta train on my iPhone because I had too many issues getting my grocery apps to allow me to place orders without going to my laptop and doing it in a web browser.
reply