I know a kernel developer sitting on a bunch of AI generated 0day patches for Zig they have not submitted since it is against Zig policy and they do not want to deal with the drama. That is what these policies do.

Zig and GCC have endangered their users for the sake of keeping their hobby running the way they most enjoy, and thus they are now hobby projects.

Imagine a mechanic that insisted on only using parts forged by human hands with a hammer. You can call that masochism, or hand crafted art, but you cannot call it responsible engineering.

We already switched our linux distro (stagex) to be LLVM native this year. Better compiler by far, but now have even more reasons to support the choice.

Disallowing AI contributions is as irresponsible as allowing them without review.

Why can't you? That's what VMs are for. And even then, most cross-platform codebases have an abstraction layer that rarely changes. So even testing on one platform can raise your confidence very high.

> Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly"

Again why? I wouldn't care about the dev's local branch. But what is send to the main repo can be easily scripted to run the CI on every commit. You just send the result back with each commit that fails. They can replicate the same workflow on their local workspace as a pre-push process.

Not every project requires this, but for those that do, it's impossible.

Also, it is much harder to enforce "everyone must run each commit through the CI equivalent properly" than it is when it's on your forge.

Download the Mac Desktop App at tryzeroshot.com/download or run curl -fsSL tryzeroshot.com | sh to give it a spin!

What ZeroShot does: it captures your coding-agent sessions locally (Claude, Codex, Cursor, Pi, OMP, more on request), then runs a classification pipeline over them in the background looking for friction such as retry loops, course corrections, and missing context. When the same friction shows up across multiple sessions or people, it clusters those and drafts a reusable skill. What's unique?

- Cross-session skill drafting. Agents can't see that they've walked the same failure trajectory five times across five sessions. Even agent-driven retrospectives miss what we catch because the same underlying friction looks different in each transcript, so anything analyzing raw transcripts comes up empty. Instead, we cluster at the pattern level.

- Team-level enrichment (paid tier). We look across your team's sessions, GitHub PR comments and contribution history, and weight skills toward the people who are experts in a given codebase or area. We're also starting to surface why some teammates get better mileage from their LLM use and share that across the team. This part is still in progress and I'd love feedback on which productivity metrics are most useful.

- The system maintains itself so you don't have to. Hand-written .md and rules files decay quickly. ZeroShot validates and regenerates skills as your sessions evolve, so the maintenance burden sits with us, not your team.

Knowledge sharing across the org. Skills live in ZeroShot-managed skillsets shared across the team, and the same accumulated skills follow you whether agents run locally or remote.

The problem we kept hitting: Between September and November of last year, I found myself getting more upset with the vibe-slop that made its way into main from engineers who knew better (and some who didn't). So we started harness engineering. At first we just wanted to make sure that the models wouldn't make the same dumb mistakes that we kept on repeating in PR comments and to our own agents. We realized that specific engineers were able to "hold" the models better and were more productive because of it. ZeroShot is born from that internal experimentation that led us to being 5x more productive as a team.

We were inspired to build the app by our own internal self-improving-skill system, which itself was inspired by systems that the Codex team has espoused on X.

Privacy: the app runs entirely on your machine for free. Session data doesn't leave your repo unless you explicitly opt into the team features. We use your local agents to parse through clusters.

Limitations:

- Skill extraction works best when there's repeated friction across multiple user sessions. If you're a solo dev doing highly varied work, the clustering has less signal to work with.

- The efficiency numbers on our site are from teams with heavy repeat work; your mileage will genuinely vary and I don't want to oversell it.

- Works with Claude Code, Codex, Cursor, Pi (including OMP) today, and we're adding support for more environments weekly. It's early days and we're constantly working on our pipelines; please give us feedback as you start using it!

Mac only for now, Windows in the works, Linux CLI.

Pricing: the local app is free, no account needed. Paid plans are for team features (shared skills, observability, cost attribution).

Happy to answer anything, especially skeptical questions about the token-savings claims. I'd rather explain the methodology than have you dismiss them outright. We're actively looking for design partners, so please hmu if you want a demo or run into any issues!

Linux strengths: file system, open source ecosystem, ssh, lockless algorithm support

macOS is the only OS which fully supports M1 hardware and its security features. Please see Asahi Linux's documentation: https://asahilinux.org/docs/platform/feature-support/m1/#m1-...

I don't know about forcing, but there's certainly a long history of emacs users trying to convince vim users that they're wrong. Without loss of generality - the same is true in the other direction of course.

Software devs are more than used to having a multitude of tools at our disposal (text editors, programming languages, Linux distros...), having strong preferences, and engaging in the delicate balancing act of advocating for our favourites while living-and-letting-live as the cosmic ballet goes on. It's part of our culture; I don't think that culture necessarily exists outside. For instance, a common layman question to ask is, "Why are there so many programming languages? Why doesn't everyone just use the same one?" And I don't think mathematicians are immune to this blind spot.

The nearest equivalent to "tooling" in math, traditionally, would be notation I suppose, and mathematicians are accustomed to eventually coalescing around a single standard notation.

So when I dip my toes into the Linux world, the first thing I do (or rather ask an LLM harness to do, being much less familiar with Linux than I am with Windows) is set up an RDP host. That way I can follow the same basic workflow on both OSes. I don't need to do anything special with terminal windows.

I guess if I were running truly headless systems that don't even have a VGA frame buffer, I'd be more interested in multiplexing. But so far I haven't had to do that, and would probably resist it because a persistent desktop strikes me as better in general than letting applications including terminals worry about their own lifetimes.

OSWorld (even the old ones, v1 and verified) runs the model in a full linux VM. And using the terminal is allowed. The models are given tools that provide a subset of possible UI actions. They then use them to open the terminal and script their way to solutions.

Even when this is prohibited, models hack their way around restrictions. Like in OSWorld v2 Claude Opus 4.8 inserts some JS in the browser search bar to execute it instead of playing the Chrome dinosaur.

WebArena is better in that regard because it doesn't allow to use the terminal. But it's worse in another regard: only allows limited actions and the tasks are only such that an agent can win by using a few pre-defined actions (click, scroll, new tab, etc). Which is a tiny subset of what real browser use is, in my opinion.

Working at an LLM platform company we spend days after days using the likes of Claude code, codex etc.. We got used to the tools and when working on side projects well if you don't have a good subscription the pace of development is slowed down considerably.

We were familiar with Ollama or other inference engine but none of them were leveraging multiple compyters at once. So we came up with this idea: Parley, a single binary that runs and serve models on your local network, find other nodes and cluster with them, your prompts are routed to the best available node depending on your task/model/latency, parley handles it for you. Model loading on the fly, hot swap, encrypted KV cache, RAG and more.

It provides OpenAI API / Anthropic endpoints so your existing tools work seamlessly.

We tested it on macOS silicon, windows CPU/CuDA, Linux CuDA. The Mac version uses MLX models if available then fallback to GGUF for maximum throughput.

Licensing, because we'd rather say it: Parley is open-core, not fully open source. Our inference engine (Spindll) is open source. The mesh layer, routing is not. We offer a free tier with up to 3 nodes (understand individual machines) and 2 concurrent requests. We judged those limits acceptable for personal use but we are okay to revise tnem.

I think I have a fundamental objection to the idea that Fielding and Fielding alone got to decide what REST is. While there hasn't been any kind of formal counterproposal, in some sense REST is what we make of it. Re: http 400 codes, I think many of us really liked the general principle of "use http semantics!" and applied that to error codes as well. That's agreeing with the principle and extending it in new ways that we like and are "truer" to the principle, even if it wasn't intended.

In my mind this is sort of analogous to talking about the relationship between linux and unix. Linux is clearly not a genetic or copyright unix, but I've seen it said before that linux is the culmination of unix principles, in some cases extended beyond what was originally envisioned in ways that are innovative and genuine improvements (io_uring perhaps?).

The REST we have today - http semantics, specific error codes, etc - may be significantly different from what Fielding may have wanted, but IMO it implements the parts that really distinguish it from the RPC world of API architecture, and I think we're generally happy with that.

My Pulsar mouse has an OLED display on the underside, DOOM could work... :P But it won't be able to use the firmware, neither would my Gaming Gear OP1.

I already have 2 Keychron HE TKL keyboards, both configured and used under Linux, and it was such a breath of fresh air to configure. I'll definitely consider their mice in the future.