> I don't have any other marketable skills. My coding skills were barely marketable to begin with.

Hot take: moving is more about interview skills than coding skills. Whether you leave or not, start interviewing now. You might end up finding a better place sooner than you hoped.

Yes, it's about how you think about yourself. Identity matters just as much as experience, sometimes moreso.

Very happy to have mostly de-Googled, I don't miss the AI-forward product decisions. I only use Google now for occasional searches and interacting with other Google users (e.g. Docs).

agents + EXA has replaced almost all of my search now, except when I muscle memory it

I've been thinking of making an event platform like Partiful, but only for personal use because it's also the perfect platform for spam (send emails and texts to people with attacker-controller content).

Wax-style earplugs like you describe are the only kind that a friend of mine uses. The foam ones never fit them.

Even though it's a meaningless comparison, I'd be interested to see how performance compares (max requests per second?) for this compared to fully-featured web servers.

Honestly haven't benchmarked it, but I would imagine ymawky would be considerably slower than most fully-featured web servers. ymawky uses fork-per-connection, which is fundamentally slower than what production servers like nginx or Apache use. nginx uses event-driven IO (kqueue/epoll), which can handle thousands of concurrent connections without the overhead of forking the process on each request. Apache uses pools of threads which handle multiple connections without needing to be spawned per-request. A head-to-head against any other web server would mostly measure "fork-per-connection vs event loop/thread pools", which assembly has nothing to do with.

In a comparison between a similar fork-per-connection server written in C and this, I would imagine the throughput would be about the same, because the bottleneck in this model is fork() itself rather than the actual code. It probably matters more for binary size and startup time than requests/sec. Would be fun to actually benchmark, though.

Should i ask my Claude to benchmark it against nginx or will you ask yours

> This does nothing since the drive is still unencrypted.

Even though the data is unencrypted in memory, an attacker would still need either a local privilege escalation (from the login window?), or some sort of side-channel attack if they're still not able to get the password.

Love it

> Meaningful contribution is easy: these groups always benefit from more participants.

Same for probably all small dance communities! While it seems like a different kind of 'contribution' than the OP is looking for, it's very meaningful personally to share music and creativity with people. (Personally, I dance lots of Balboa -- a swing dance with a local scene of probably less than 100 active participants.)

I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can otherwise restrict access to a single repo with write access. Essentially, though, you'd want to find a way to give the remote host the most limited possible privileges to your Github account.

You could also just set the development machine up as a remote on the repo on your local host and then pull, diff, and merge locally. Then the llm agent doesn’t have access to any github account at all.

I use an overlay copy of my workdir, then the sandboxed LLM doesn't get any of my secrets, can do its own commits, and I pull the ones back that I want.

Oh, a separate GitHub account that has its own forks of the repos the agent is working on. Yeah, that's probably the most secure, isolated, and safest. The merge to the canonical repo then needs to go through a human, or at least separately controlled, process via a GitHub pull request.

Maybe this is doable with scoped API keys instead of SSH keys?

On a GitHub project, agents must just be considered untrusted external contributors.

Hence

> that almost certainly will break in the next OS release

My scanner has drivers available for download that date from 2015 with no updates since then.

My solution to this very problem was to virtualize an ancient OS X (was not easy) so I could continue to use a perfectly good scanner.

Though I'm certain you've raised this issue before, and it was met with "I've never heard of anyone needing a scanner, you must be doing something weird, have you tried taking a picture of it with your iPhone(R) instead?"