Disclaimer: This content reflects my personal opinions, not those of any organizations I am or have been affiliated with. Code samples are provided for illustration purposes only, use with caution and test thoroughly before deployment.
In my previous post about replacing Raycast with macOS built-ins, I recommended turning your shell scripts into .command files so Spotlight can find and launch them. That trick still works, but after using it for a while I ran into two annoyances: Spotlight is slow to rank .command files, and running one pops up a Terminal window even for scripts that don’t need to show anything. It turns out there’s a better way.
I’ve been keeping an eye on Vanilla OS for quite a while, but almost all the official documentation was still focused on version 1. Back then, they were planning for the big v1 to v2 upgrade, so I waited. Since I visit my parents once a year, I need a stable, low-maintenance operating system that can be continuously upgraded so I can do some light work during my visits. The last thing I want to do is spend three days fixing my operating system updates and miss out on all the time with family. Today, while on vacation, I set up Hyper-V on my parents’ Windows desktop and decided to finally take Vanilla OS 2 (Orchid) for a spin.
What makes Vanilla OS interesting is its design philosophy: it promises an immutable, stable core while giving you the freedom to install software from virtually any Linux distribution.
Almost every day, I see someone on LinkedIn publicly calling out a “terrible” recruiter. The complaints follow familiar patterns: a recruiter mixed up the technology and pitched a role that had nothing to do with the person’s actual skills; they demanded ten years of experience in a framework that’s barely been around for two; they proposed a position several levels below where the person is in their career, and the candidate took it as a personal insult; or the job description itself was fantasy — a full-stack, AI-data-scientist-superhuman with an entry-level salary attached. The frustration is real. But the response — the public callout, the viral screenshot, the snark — is usually a mistake.
Early in my career, every recruiter message on LinkedIn felt like a small victory. Someone had noticed me. Someone had looked at my profile and decided I was worth reaching out to. I’d read each message carefully, even the templated ones, because it meant my skills and contributions were being recognized.
Then came the messages that stung. “Hi, we have an exciting Java opportunity…” — except I’m a web browser engineer who builds JavaScript engines using Rust. Getting lumped in with generic “Java developer” outreach felt like someone had glanced at a keyword on my profile and stopped there. I remember the mix of annoyance and embarrassment, like being called by the wrong name at a party. It felt insulting, even dismissive.
If you use GitHub Copilot custom agents, you probably know you can define them per-repository in .github/agents/. That works well for project-specific agents, but it means every new repo starts from scratch. There is a way to share agents across all your repos without copying files everywhere — and it works for personal accounts too, even though the documentation only mentions organizations.
I wanted a quick way to scan paper documents with my phone, but I kept getting harsh shadows on the page. The scanner app could detect edges, but the image quality was inconsistent because my hand, phone, and room light all affected the result.
So I made a simple document scanner box from cardboard. It is cheap, simple, and works surprisingly well.