IMO, one way to retain the power user crowd is to do the hard parts that they might have skipped themselves. For a couple examples:
- after selecting your observability apps, every _other_ app could automatically configure centralized logging, its own dashboard of metrics, etc
- the host OS could ask the user simply for the backup destination (S3 url creds, attached local disk, SMB share, etc) and every app is again automatically configured with backups
- the host could have a control panel to roll back apps between versions (maybe it's FS snapshots or something)
- everyone can use containers, but if the project went through the extra effort to make each app its own VM instead, that could be worth something
- if there was a companion Android/iOS app for management and (importantly) alerting?
---
That doesn't really solve the monetization issue you described, but I do think you can still get powerusers on board if you handle even harder problems than they'd want to take on themselves. Or...harder problems than they'd risk taking on themselves if their family uses what's being hosted, for example. Less tolerance for downtime
This is neat! I've been building something very similar for personal use. I may lift a little bit of the app manifest part.
I'm a little surprised that there's just one backup app, instead of each app coming with its own backup sidecar. To backup Immich, for instance, requires coordinating between its four different programs. I guess I'll read more about how that backup app works too ha
It's weirder still because you often don't actually have to register with a party, even to vote in the primaries like other commenters have mentioned; it depends on which state and which party. [0]
For example, I just voted in the Minnesota primaries. Ours are open primaries, so you don't need to register with any party and the ballot has every party on it. Though, it spoils your ballot to vote in multiple parties' primaries. So you gotta choose, but you do that privately.
Funny timing! I just finished migrating my NAS containers all to be rootless last weekend.
"Migrating" because secrets management was a bit of a pain. I ended up with pretty close to the same design as this article though. (I put an extra layer of complexity in mine, we'll see if I regret it)
Along with the other folks in this thread, I don't think we can stop at rootless in 2026. But I'm optimistic that dropping in libkrun as the runtime will be an easy next step, given its integration with podman (--runtime=krun).
If the author tackles that next, I'd be interested in reading about it
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.
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.
> I don't know how it's really used in the wild, so to speak.
Commit signing primarily exists because linux kernel development happens via email, which isn't a secure channel.
In that context, signing is used to prove provenance; a commit signed by someone with merge rights gets included, and if you repeatedly sign bad code you'll have your right to merge revoked.
> you can hold me accountable for that commit
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.
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).
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)
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.
I don't think saying "as a general rule, data centers don't use remotely enough water to be any kind of significant threat, when you see through the accounting games, media hype, and look at things in a proper context" is made wrong or misleading by admitting that there are a few exceptions.
> 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?
It does help you set your priors though, and not fall for the "all AI guzzles water, and DCs are dehydrating every town they're in and are always bad, without doing the research" rhetoric that's driving DC bans around the country right now.
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.
- after selecting your observability apps, every _other_ app could automatically configure centralized logging, its own dashboard of metrics, etc
- the host OS could ask the user simply for the backup destination (S3 url creds, attached local disk, SMB share, etc) and every app is again automatically configured with backups
- the host could have a control panel to roll back apps between versions (maybe it's FS snapshots or something)
- everyone can use containers, but if the project went through the extra effort to make each app its own VM instead, that could be worth something
- if there was a companion Android/iOS app for management and (importantly) alerting?
---
That doesn't really solve the monetization issue you described, but I do think you can still get powerusers on board if you handle even harder problems than they'd want to take on themselves. Or...harder problems than they'd risk taking on themselves if their family uses what's being hosted, for example. Less tolerance for downtime
Edit: formatting
reply