Right, if Bluesky ever does do something hinky with your PDS, the operation will be signed with their key and persisted in the operation log which they're unable to touch. You can outright remove Bluesky's key if you want, though I think that only works within some number of days of creating it.
If the JSON backend parses the payload as JSON without verifying the content type, then yes, it's a way through. There's no affirmative logic of "payload looks like json, so let it through" going on, it's just "parse this json without looking at content-type, and assume it was already subject to cross-origin restriction because it's json, right?" (same thing, just different intentions). And as we can see, that assumption fails to hold if you don't actually check the content-type.
My apps speak only JSON, so one of the first things I do is create a middleware that requires any POST/PUT/PATCH request to be application/json and reject everything else with a 415 error. That's so I can turn off the CSRF protection mechanics in the framework completely, but the two concerns are related.
Kubernetes' YAML problem stems from its CLI tooling, and yes it was an atrocious choice once templating came in and visited horrors like helm on us. Internally, the the k8s api speaks only JSON, and you can already stuff whatever json you like in a yaml file.
Most "immutable" distro flavors do something like this. Back when I ran Aurora, it was rpm-ostree for the core system packages and homebrew in a devbox container for the rest. One incentive for maintaining the layer separation was that rpm-ostree was slow.
I've since moved my desktop box to NixOS, where everything is just flakes, but my mac runs circles around it so it's just there for Steam nowadays.
As a PHP developer, I found mise's support to be pretty sub-par compared to Shivam Mathur's packaging work for homebrew. Most of my projects are using Docker anyway, the local PHP is for stuff like static analysis that doesn't need it. And I've got a couple using Nix, which laughs at everything else (but damn, the overall UX is still even more hostile than git).
The most interesting evolution of my agent workflow over the past year is that I've dropped all the language gimmicks: I used to use particular emoji to mark parts of code as hints to the AI, I structured planning docs in very rigid language for different types of instructions, and generally optimizing my language for machine consumption. That's all gone now: all my comments, directives, plans and so on are just plain and clear English, nothing more. They're direct and unceremonious, but no longer bullet points that were nearly caveman-speak. It just works better that way.
Any particular plugins you'd recommend? For orchestration I gave pi-subagents a try, and didn't care for it, ended up with hung agents sticking around forever and I wasn't even doing anything terribly fancy. Claude's subagent control is annoying and clumsy, but it works.
It's just a hardwired list of targets, and doesn't support the fun combination of bucky bits that I remap capslock to (in lieu of an actual hyper key, which macOS has no concept of). Also, when I tap capslock as opposed to holding it, it sends an ESC, which I'm pretty sure I would need Karabiner for.
For sure, I'm saying that vi stuck with its design rather than follow the trend of other modal editors that converged on one insert mode, and so did its follow-ups like vim.
I just tried out helix and I'm really liking the features like its single insert mode. Still taking some getting used to, since it's selection-first, not command-first, so `dd` just deletes two chars and not the line. And shift-V doesn't select lines... grr.
What I did when I introduced my very non-technical partner to a mac was leave it at "natural" scrolling, show her the two-finger scroll gesture, let her try it out, then I turned off natural scrolling and asked her which she liked better. She picked the latter hands down. I knew there's a reason I'm with her :)
It's totally a matter of personal taste, both are objectively right depending on what one thinks the thing being manipulated is.
I must be the only person in the world who actually likes pointer acceleration. Karabiner is a must though: I use it solely for "remap capslock to hyper/esc", but that's still reason enough.
I have a mac, and I wouldn't mind a fn-lock feature, but only from a different key combo, maybe fn+capslock. The behavior of fn (media keys or function keys) is a control panel setting, so I could probably whip up something with hammerspoon. But right now I just remap most things in my IDE so they don't require function keys.
Anyway, keyboards have needed drivers since we stopped using BIOS to read them, and fancy keyboards with macros tend to need at least a userspace daemon, but yeah this kind of thing should be as much a commodity as a VGA framebuffer is, something you just shouldn't have to fuss with. Far as I know though, USB and the *HCI zoo pretty much are that, so along with the OS's own built-in support, it should support the basic functionality of any keyboard, and provide standard means for extension. I believe the main reason any company ships a 1GB keyboard "driver" these days is the bundled shovelware and spyware.
Whereas I cut my teeth on emacs in the early 90's, so modal is what felt awkward. I wouldn't dislike vim's modes so much if it just had one combination insert/append mode that worked like every other editor out there (including a couple other modal editors I've used), but even after adding various hacks to my vimrc to help unify the two modes, I still stumble over the behavior differences in other places.
I really like the composable shorthand of vim's command set though, even if the only one I have in muscle memory is <esc>:wq
For managing dependencies in Perl, it was originally a similar story to Python: everything was system-installed, but many people would install things to their home dir and set PERL5LIB in their .bashrc. The cpan client was smart enough to detect and use the home install when writing its initial config, so you could call it a day. Later there was local::lib which fiddled @INC for the use of a project-local directory, and cpanminus defaulted to using it, and then Carton came around which is more or less a clone of Bundler from Ruby, also using local::lib under the covers.
I thought I'd given sufficient clues that I actually do in fact know what virtualenv is. I was hip-deep into python when it was introduced, and thought it was a clever hack, but it's relying on python being compiled to find its libraries in a path relative to the python binary, so rather than use something sensible like a launcher that sets PYTHONPATH to a local dir like every other language does, it hardlinks the python install into the local dir in order to pretend everything is a system-wide global install. I always figured that hack was a temporary workaround, but it's going on a couple decades now.
As for the screaming, I'm talking about pip, which has the unique property of just refusing to work by default unless you use --user (what most other package managers now call "global") or are in one of these pretend-global environments. Ultimately it's just a paper cut, not a show-stopper, but it points to not just a failure to address the pain points of the package ecosystem, but a seeming refusal to do so.
But none of the runtime benefits of having static types in the compiler, since the runtime still can't trust the types. Still, half a loaf is better than none.
Python the language is pretty nice. It has its warts, but I make my living in PHP which is practically made of warts. But the python ecosystem still seems to be trying to figure out this whole package management and project setup thing. In most languages I can do some form of `$blub install` where $blub is the language's official package manager or some close equivalent. It's just python that always screams at me that I have to set up and "enter" a virtualenv. I get what venv is for, but it's still a weird hack of hardlinks and relative paths that no other language seems to need, and a clumsy two-step dance of a UX that hasn't improved in like 20 years.
Part of it is due to the clunky `_NoArg.NO_ARG` business for optional params. Pretty-printing it would also go a long way, but that technology seems too advanced for any language circa 2026.
AI generates code that mimics the existing code. If your code is terse and comment-free, then the agent’s code is too. The times I’ve seen Claude drift into a default “house style” it generated like 1 comment for every 10 LOC or so. It’s a far cry from the GPT-3 days that littered every line with the journals of Captain Obvious.