samhclark

Makes sense, thanks for that context. I knew that linux kernel dev happens over email, but didn't piece that together with commit signing.

I wouldn't personally want to be held accountable for a commit I'd never so much as read, so I would never sign (even locally) a commit until I'd looked at it.

I think that's reasonable. I'd say that if I push the commit, then I should be accountable for it whether I read it or not (and no one is going to see it unless I push it).

Yeah. The agent can create commits and those commits are signed (`commit.gpgsign true`).

I'm treating it like...you can hold me accountable for that commit and the commit came from my computer. That feels like the right spirit of things.

How do you do commit signing? I've never worked anywhere it was common, nor worked on a team where anyone else signed commits. I don't know how it's really used in the wild, so to speak.

Secretive (and the similar built-in functionality [1]) both allow you to require TouchID too. I found an okay balance using two SSH keys: one for commit signing (w/o TouchID) and one for everything else (requires TouchID, or PIN on Linux)

So, the actions that I really don't want the agent to take (establishing an SSH connection, pushing to a git remote) always require my manual intervention.

[1] https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...

I think that's why I like prerelease (and sealed, generally) the most of any format. For day 1 prerelease, a lot of the players are reading the cards for the first time. For sealed later on, even if you know the meta for that set, it's more about playing the best deck with the cards you've got. Knowing the meta doesn't change your pool. (As opposed to draft, where if you don't know the meta you might inadvertently pass excellent cards and miss signposts other players will catch)

Personally, I'm pretty excited for this commit which fixes the slow WiFi I've had with the combination of my ISP's modem/router and my laptop.

https://github.com/torvalds/linux/commit/711a9c018ad252b2807...

Hope it gets to Fedora soon!

Agreed with everyone else. Scrcpy is amazing and is so easy to use.

I think we agree? I can't tell if you meant this as additional support for what I wrote or as a rebuttal.

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.

Agreed.

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.

In my opinion, this was a great debunking of Benn Jordan's infrasound videos.

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.

This is a very cool project and I'm happy to see it getting traction here. I stumbled upon it when I was looking to build something similar and surveying the state of the art...then I realized you built _exactly_ what I wanted!

Thank you, great work!

Do you have any more info you could add about that topic, or a direction to point me? As far as I know, (systemd-)pcrphase is for measured boot, but I'm not sure how that interacts with signing keys.

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.

It isn't necessarily smaller. See https://github.com/PegorK/f32

Google Messages - for most of the last 8 months RCS was broken on GrapheneOS, but it's back now and Google messages is still the only option for messaging with family members on iOS.

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.

That's so frustrating with Claude. If I need to widely search the web or if I need it to read a specific URL I pasted, I always turn to ChatGPT. Claude seems to hit a lot more roadblocks while trying to navigate the web.

Personally, I've really enjoyed using bootc for both my personal laptop and my NAS.

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.

This makes sense to me. I guess I'll start hunting for the equivalent of `govulncheck` for Rust/Cargo.

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.

Depends on your workflow, I guess. I don't need to handle that case you noted and we delete the branch on remote after it's merged. So, it's good enough for me to delete my local branch if the upstream branch is gone. This is the alias I use for that, which I picked up from HN.

    # ~/.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"

You don't get a blue bubble for using RCS. That's still reserved for iMessage exclusively. (At least, on iOS 26 in the US on T-Mobile)

Yeah, this is closer to what I do, too. I was surprised not to see a Containerfile in the linked github repo in the article (https://github.com/lthms/tinkerbell)

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.

I can confirm that the Odroid H4 Plus also supports in-band ECC. If I remember right, Memtest86 showed different stats when I ran it with in-band ECC enabled/disabled though I didn't have a good way to test that an error was actually corrected.

I went to a b-sides yesterday (so: small, local, cybersecurity-focused) where someone described their feelings toward GenAI as "praying for Star Trek, but planning for Terminator." Someone else described AGI as a short term inevitability.

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.

Thanks for the reply, appreciate it.

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!

I really like this setup. I think it balances friction and usefulness in exactly the way I've been aiming for.

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!

To comment on the part about what keys Secretive uses, I looked at this recently and I think it looks like the SE will be able to do ML-KEM soon.

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.

I didn't see the author or anyone else mention TouchID yet. That was such a quality of life improvement for me that I switched from Firefox to Chrome on my work MacBook just for that. With SSO+MFA everywhere, TouchID saved me so much hassle.

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!

I think you're right generally, but I wanna call out the ODROID H4 models as an exception to a lot of what you said. They are mostly upgradable (SODIMM RAM, SATA ports, M.2 2280 slots), and it does support in-band ECC which kinda checks the ECC box. They've got a Mini-ITX adapter for $15 so it can fit into existing cases too.

No IPMI and not very many NVME slots. So I think you're right that a good mATX board could be better.

You can, but they ask that you contact them to set up a contract. It's addressed here on the site:

Anubis is provided to the public for free in order to help advance the common good. In return, we ask (but not demand, these are words on the internet, not word of law) that you not remove the Anubis character from your deployment.

If you want to run an unbranded or white-label version of Anubis, please contact Xe to arrange a contract.

https://anubis.techaro.lol/docs/funding

You mentioned a declarative package manager for Mac. I've really liked using Homebrew Bundle [1] over the last couple years. It's about the level of declarative that I've wanted and has made it really easy to bootstrap new laptop or VM (since it also works on Linux). The format for a Brewfile was pretty easy to figure out.

The way I ended up using it was that `brew install` would temporarily install something, without adding it to my Brewfile. And a little `brew add` wrapper would add the package to my Brewfile to keep it on the system permanently. That part with the wrapper could have used some love and would be a nice fit for a new brew-compatible frontend IMO. Maybe you could expand on that for Sapphire, if that also scratches your declarative itch?

[1] https://docs.brew.sh/Brew-Bundle-and-Brewfile

I agree with your concerns—at least, last time I looked.

I looked over their code, saw some things (I believed) I would do differently, and it was very easy to make my own personal spin to use.

After doing that, maintaining it, and using it daily for the last year I went back on some of my original choices. I feel much less critical of the decisions Jorge Castro made and it's probably time to compare and contribute if I can. Like, Homebrew on Linux ended up being way better than I expected. But some things I liked better my way. Say, including the signing keys for Chrome's 3rd-party repo statically instead of fetching them over the network. (Writing this from my phone I don't exactly remember how they do/did it.)

Overall, I'd recommend trying it yourself! It's been a ton of fun.