I made my own subagent implementation in a couple of hours using Pi itself. It aligns with my needs better than any existing plugin, none of which seems to be what I was looking for.
You don't _need_ to use someone else's plugin if you don't want to, and for simple functionality, you can get pretty good resulting rolling your own.
Yeah, adding CAs to the store sucks. On Linux it needs to be in /etc/ssl/certs (this varies slighly per distribution), which is only writable by root. A single user can't trivially trust a CA, and a great deal of applications/libraries don't support overriding the store's path.
Personally, I use a custom local CA with name constraints so that it can only sign domains for The .internal TLD. This is the most important bit: because if the cert is ever leaked, it cannot be used to MITM connections to other domains.
I have to secure the CA's key, but I also have to secure all the keys for the certificate it signs, both being a similar level of challenge.
For personal use, or for very small organisations, using a passphrase-protected Yubikey as a "cheap HSM" should suffice.
It's kinda crazy that they're releasing an improved version only in places where it's mandatory by law. You'd think it's cheaper (and definitely better PR) to just release the new version everywhere.
I have enormous respect for dot matrix printers. They're easy to repair and service, the tech is relatively simple, it's cheap, it's parts are cheap, its supplies are cheap. It's way more sustainable than any other printer: both the printer itself in its manufacturing and the ribbons themselves. The waste they produce is also much less polluting than any other printer.
I think iOS has lots of refinement and polish, but still lots of ugly bugs and crappy UI. The others have the same crappy UI, but with no refinement and polish at all anywhere.
Indeed, it's also great economics for them. Remember the old rule: commoditise your compliment. If you make these kind of accessories highly affordable and people can even refine on them, your product suddenly increases in value.
The other big problem is that all your processes continue running, but your disk is unmounted. I can't imagine how you'd avoid everything crashing horribly.
I mean, I can imagine an implementation where the system pauses all processes related to the user session _except_ the screenlocker, and have a custom screen-locker which can supply the credentials to luks…
But that the screen locker is a desktop application, so the compositor itself needs to stay alive too, but then compositor might try to talk to other applications, and those are frozen. So wouldn't it consider them crashed and disconnect them? Now your compositor needs to understand that the system is in a "disk unmounted and processes frozen" state too.
Not even sure how you'd deal with logs from its stdout, since the file descriptor to the log files is invalidated too.
If anyone is actually using such a setup, I have so many questions. I know that theoretically all this is feasible, but all the existing components don't seem to be ready for just unmounting the encrypted disk at runtime like that.
> No idea why Docker is still so much more popular than Podman. Podman is obviously the better implementation.
docker-compose is one big reason. The networking aspect of it still isn't feature-compatible compared to using docker. I keep trying podman+docker-compose again every 6–9 month, and there's also some issue that makes it unfeasible for my use case.
Its IPv6 implementation is also broken, and connections from the host to the container are dropped if the host doesn't have a public IPv6 address (WTF!?). I reported this in June 2024 (#22959). Not being able to reach an HTTP server on a podman container from my host when I'm offline is ridiculous.
Lots and lots of tiny little bugs and quirks which are a nuisance to deal with. With docker, everything just works.
Another recent bug I hit was that the value of the environment variable TMPDIR and XDG_RUNTIME_DIR is persisted to disk with podman's internal state. After a reboot, if either of those has changed, nothing works because podman tries to use directories that don't exist. This… seems to be due to workarounds for wildly broken setups.
I've reported many of these bugs, and have a backlog of a lot more that I haven't bothered to report yet.
What honestly really surprises me is how many people actually manage to use podman for work despite all its issues.
It's also the fact that it forces each citizen to pay a few hundred Euros to companies which then campaign against their very rights.
Citizens get no support of any kind in case of issues, and has to enter a contractual agreement which is ridiculously asymmetrical, where the company has little to no responsibility of any kind, but has very ample rights to track the other party in extremely creepy ways.
Realistically, there's not any other company selling wireless noise-cancelling earbuds with these features _and_ including documentation for folks to use those feature outside of some locked ecosystem.
E.g.: Bose, Sony, etc don't include any documentation for any non-basic features, and the only way to even enable them is via the proprietary app which run on limited environments (notably: not Linux).
I don't defend the practice at all, but no matter which hardware they picked, the practices are still the same.
People mention these tools each time AirDrop comes out, and they're not at all compatible.
AirDrop allows two devices to find each other and establish a temporary network to exchange data.
LocalSend and all similar tools require that you first set up a network, have both devices join it, _and then_ handles the final portion of the exchange. The key aspect of AirDrop is that it automates all the overhead.
The open/standard equivalent for AirDrop is Wi-Fi Aware (aka: Neighbor Awareness Networking), which still lacks software support.