> sub-agents will decrypt (by hitting a backend) to do their work
Your local harness never decrypts the prompt, and only the OpenAI backend does. Your harness still sees tool calls in the transcript so it can act, but you lose (some) visibility as to why the subagent chooses to do so.
Imagine seeing this transcript during forensics:
[encrypted blob][thinking summary: I need to drop the prod database][shell: psql "drop database users"]
You would be surprised how adept SOTA models are at reverse engineering with IDA/Ghidra or even plain old objdump. Opus basically knows IDAPython on the back of its hand.
For Linux desktop users. A bit of tongue-in-cheek but that's pretty much the argument that I've heard in some circles ("it works for us and not going away anytime soon - why waste time convincing others?").
Instead of Keycloak, I would recommend giving Kanidm a try: It's much more lightweight and covers most of what you usually need (one notable exception being SAML).
Buyers beware: 4-core A53 is genuinely unusable (original Pinebook/PinePhone specs), A55 is better but I still wouldn’t recommend buying. You may expect performance similar to 15+ years old desktops.
Without a proper proxy setup, access to GitHub is often painfully slow from mainline China.
But the choice of Baidu Pan is indeed questionable: You need a Chinese phone number in order to sign up, which is out of reach for many expats living overseas. I don't get why they can’t just mirror it on a university server.
IIRC macOS upgrades will automatically store a FileVault token (basically `fdesetup authrestart`) before restarting, so the disk is automatically unlocked. It's not a Tahoe-specific thing.
mosh is neat, but I've mostly switched back to good'ol SSH over Tailscale due to various rendering bugs caused by client-server mismatches as well as the lack of port forwarding.
Basically mosh attempts to synchronize the state of the terminal which is made up of character cells. It sounds simple until you realize that unicode and fancy escape sequences exist, and the behavior of the client and the server must match otherwise you get weird misalignments that are difficult to debug:
You really need those patches to have a good experience, and popular mosh clients like Blink on iOS incorporate them in their builds. However, things look wonky if you don't use the corresponding server builds, and you don't want to dig through layers of abstractions to find out why selecting lines in a specific file in neovim causes everything to become a jumbled mess every so often.
There is no end in sight for those patched to be merged upstream, no end in sight for distros to ship new versions, and no end in sight for protocol changes to make state synchronization more resilient. So, back to SSH we go...
Edit: Fixed wrong link for underline/undercurl patch
To be frank, the whole post reads like "I hate change" with no convincing argument otherwise. The author even acknowledges the very lenient ramp-up from CAB _and_ the myriad of available tooling, yet still throws his hands up.
> I am responsible for approving SSL certificates for my company. [...] I review and approve each cert. What started out as a quarterly or semi-monthly task has become a monthly-to-weekly task depending on when our certs are expiring.
I don't get the security need for manually approving renewals, and the author makes no attempt to justify this either. It may make sense for some manual process to be in place for initial issuances, as certificates are permanently added to a publicly-available ledger. And to take a step back, do you need public certs to begin with? Can you not have an internal CA? Again, the author makes no attempt to justify this, or demonstrate understanding in the post.
> email-based validation may as well not exist when we need to update a certificate for test.lab.corp.example.com because there is no [email protected].
I know that this is an example, but as a developer it would be a pain to have to go through a manual, multi-day process for my `test.lab.corp.example.com` to work. And the rest of the post seems to imply that this is actually the case at OP's org.
> Which resource-starved team will manage the client and the infrastructure it needs? It will need time to undergo code review and/or supplier review if it’s sold by a company. There will be a requirement for secrets management. There will be a need for monitoring and alerting. It’s not as painless as the certificate approval workflow I have now.
There are additional costs and new processes to be made, yes, but even from a non-technical POV this appears to be a good time to lead and take ownership.
> Any platforms that offer or include certificate management bundled with the actual services we pay for will win our business by default. [...] What is obvious to me is that my stakeholders and I are hurrying to offload certificate management to our vendors and platforms and not to our CA.
That's okay. If you hate change and don't want to take ownership, pay someone else to take ownership.
From git's perspective, jj bookmarks are just regular git branches, so you can just do `jj git push` and open a PR as usual.
However, unlike git, jj bookmarks are pinned to change IDs instead of immutable commit SHA-1s. This means that stacked PRs just work: Change something in the pr-1 bookmark, and all dependent bookmarks (pr-2, pr-3, ...) are automatically updated. A `jj git push --tracked` later and everything is pushed.
Only the invoked app knows whether it needs the focus in the first place. Maybe the link you clicked is supposed to initiate some background processing that does not demand your focus at all.
One issue that comes with leaving GitHub is a higher barrier to contributing. The author appears to see this as a nice filter, but it may not make sense for you. With a self-hosted forge, a new contributor will need to:
a) Sign up for an account in your forge: Do contributors really want another account? Does your captcha/email verification actually work (I've encountered ones that don't)? There are also forges that require you to ask for an account which is another hurdle.
b) Send an email: Configuring `git send-email` is alien to many contributors and may not even be doable in some corporate environments (OAuth2 with no app passwords allowed). Diverging from this is error-prone and against social norms which the contributor may not even be aware of (until they get flamed in the mailing list). You are also giving up automated CI which is a big part of the contributor feedback loop.
To be clear, going independent does indeed work for small personal projects (do not care much about contributions) as well as established ones (large incentive for new contributors to jump over hoops), and I'm fully aware that a lot of HNers do not see the need for those "niceties" provided by GitHub. But I feel that people often underestimate the barriers that they are putting up.
Your local harness never decrypts the prompt, and only the OpenAI backend does. Your harness still sees tool calls in the transcript so it can act, but you lose (some) visibility as to why the subagent chooses to do so.
Imagine seeing this transcript during forensics:
[encrypted blob][thinking summary: I need to drop the prod database][shell: psql "drop database users"]