Regardless, yeah, I don't think that's wrong or misleading. I only meant to say that because there are exceptions now, there might also be more exceptions in the future. Which, to me, means it's important to evaluate each new local DC individually.

And your point about setting my priors is exactly what I'm saying, too.

I think my takeaway from the water usage deep dive was about the scale of the numbers and a better intuition about water usage, but also that you really need to consider each data center uniquely. He'll say in broad strokes that data centers are fine, and then mention the few exceptions (in the infrasound article, that's the xAI DC). That's fine for the moment when he wrote the article, but if I'm evaluating a proposed data center in my local area, I don't know what bucket it falls in. Is it the exception or the norm? Still, because I read that deep dive, I feel better equipped to make that evaluation.

When I first saw his videos, they didn't quite sit right with me. I was reminded of the arguments people made about WiFi and 5G. But I couldn't put my finger on the flaws in the logic, or the specifics of it. I also didn't feel like I had the time to dig in and research all his claims myself, so I just kinda left them feeling skeptical.

Reading this article felt great. Admittedly, it confirmed my biases so I tried spot checking it here and there. What little I did check seemed right and I trust Andy Masley's previous reporting.

I only have two criticisms of the article. First, the few cheap digs he took at Jordan (e.g. the CO2 emissions from his long drive) which I agree with but are unrelated to the overall argument. Second, some of the paragraphs had a strong "written by AI" tone. Maybe they were, maybe they weren't, but that made me trust those specific paragraphs slightly less.

Thank you, great work!

As someone who stores my SSH keys in my TPM, and has struggled with picking the right PCR values for Secure Boot in the past, I'm interested in learning more.

I'm glad to hear that's finally fixed. That was my only pain point with GrapheneOS, but it got so bad I bought an iPhone when the 17's came out.

If the deal with Motorola helps GrapheneOS get better integration with the carriers, get a heads up about RCS changes ahead of time, get help fixing it, I'd happily switch back. I loved using GrapheneOS and iOS frustrates me daily.

I really like the NAS use case because I can build the ZFS kmods for that specific version of Fedora CoreOS in CI/CD. If there's any compatibility failure, then my NAS doesn't get an update and I get the CI/CD failed email. No downtime because of some kernel incompatibility.

For the laptop though, I feel like there's a better way that I haven't found. Some way not to require CI/CD, to build the next image and switch to it all locally. I haven't gone down that path yet, but it looks kinda like that Option 2 the author described. Maybe it's really just that easy.

I've really been enjoying this space.

Separately, I love the idea of the `geomys/sandboxed-step` action, but I've got such an aversion to use anyone else's actions, besides the first-party `actions/*` ones. I'll give sandboxed-step a look, sounds like it would be a nice thing to keep in my toolbox.

    # ~/.gitconfig
    [alias]
        gone = ! "git fetch -p && git for-each-ref --format '%(refname:short) %(upstream:track)' | awk '$2 == \"[gone]\" {print $1}' | xargs -r git branch -D"

I found working with normal `dnf` and normal config files much easier than dealing with Ignition and Butane. Plus, working with your image in CI/CD instead of locally fixed my ZFS instability. When Fedora kernel updates, but ZFS doesn't support that version yet, now it fails in GitHub Actions and the container is never built, so there's no botched update that my NAS mistakenly picks up.

Not many others addressed it directly. The vibe I got from offhand remarks was that people felt it was a thing being forced upon them that they are resistant to use.

Both of your answers sound workable for me!

Even if I couldn't restore the whole profile from backup while traveling (which seems natural), at least it's still possible to restore some data. Which should be enough in the short term.

And that's perfect that I could manage it from a different Mac. That totally works for me. I worried there would be something which prevented that. I'm imagining a parent using this for parental controls, but then the kid disabling it at a friend's house who has a Mac. Works better for my scenario though!

Still, I have a couple questions about it, since I don't own an iPhone but am considering buying one soon.

1. How does this affect backup and restore? Could I still restore from a backup on a new phone, if needed? I've lost my phone while traveling before and buying a replacement was pretty seamless.

2. Is the ability to disable the profile bound to the Mac you use Apple Configurator on? I don't own a Mac, but if I could use a friend's Mac when I need to make changes this could maybe work.

Great writeup, thanks for posting it!

https://developer.apple.com/documentation/cryptokit/secureen...

Not totally sure that I'm reading it right, since I've never done MacOS development before, but I'm a big fan of Secretive and use it whenever possible. If I've got it right, maybe Secretive can add PQ support once ML-KEM is out of beta.

Also, I must've been using UBO wrong all these years cause I switched to UBOL and didn't notice a difference. So, thanks to the author, I've got a bunch of new settings to try!