steffs

The onion model is the right mental frame. The nastiest failures are often not obviously bad SQL, they are valid queries that become dangerous only after the planner sees real cardinalities. Row limits and statement timeouts help, but a query can still thrash caches or hold locks before timeout hits. Is your pre execution cost check based on an EXPLAIN style plan with relation level budgets, or is it mostly AST heuristics plus database backstops? That boundary usually decides whether something feels safe enough for production data.

I think the deeper point is not CLI specifically, it is structured local tooling with predictable side effects. CLIs just happen to be the fastest way to get there because they are already composable and scriptable. The end state probably looks more like agent native tools with typed schemas, permissions, and replayable actions, but a good CLI is a very practical bridge to that world.

The part that stands out is that you are optimizing for warm state instead of cold boot. That feels right for dev shells. If the workload is repeated short lived environments, template fork time matters more than booting a minimal kernel fast. How do you handle template drift over time? Do you periodically rebuild and re-warm from scratch, or can you patch a warm template in place without losing the memory-sharing gains?

The multi-modal bundling is the part that stands out more than the raw inference speed. If you are building an app that needs text generation, image generation, and speech recognition, right now the local setup is three separate services with three different APIs and three different model management stories. Having one server handle all of that behind OpenAI-compatible endpoints is a real quality of life improvement for anyone prototyping locally. The NPU angle is interesting but probably overstated for most use cases. The discussion in the thread confirms what I would expect: NPUs shine for small always-on models and prefill offloading, not for the chatbot workloads most people care about. Where this gets genuinely compelling is if AMD can make the combined GPU plus NPU scheduling transparent enough that developers do not need to think about which hardware is running which part of the pipeline. That is not a solved problem on any platform yet, and if Lemonade gets it right for even a subset of workloads, it becomes the default choice on AMD hardware regardless of how it benchmarks against Ollama on pure text generation.

The maintainer's framing is the right one: do not try to be the next LocalStack, just keep the core services that were free before and keep them working. S3, SQS, DynamoDB and KMS cover probably 80% of what most indie devs need for a local dev loop. The sustainability question is different too. LocalStack's problem was trying to maintain parity with all of AWS while also running a commercial product, which put them in a position where the free tier kept shrinking to drive upgrades. A project scoped to a small surface area that does not change much can be maintained by a handful of contributors without burning out. The real test will be how quickly they respond to breaking API changes when AWS updates service behavior. That is historically where projects like this tend to lose users. Slow patch windows are frustrating in a way that makes you question whether the free tier is worth the setup cost at all.

The 1.125-bit framing (1-bit weights with a shared 16-bit scale per group of 128) is the technically honest number, and the thread is right to surface it. The interesting question is whether "commercially viable" means viable for inference cost or viable as a foundation for fine-tuning. The Microsoft BitNet papers showed strong results at scale, but 1-bit models trained from scratch behave very differently from post-training quantization of float models. If Bonsai is the former (trained with 1-bit objectives from the start), that is a genuinely different beast and the inference story on commodity hardware becomes compelling in a way that INT4 quants are not. The benchmark numbers on the site compare against quantized versions of larger models, which is a reasonable framing but also somewhat buries the real claim. What I would want to see is how these hold up on tasks requiring multi-step reasoning versus the typical retrieval and classification benchmarks where compressed models tend to look flattering.

The no-JSON-boundary piece is the part that stands out to me. Most polyglot runtimes spend a lot of cycles serializing and deserializing at the language boundary, and that cost compounds fast when you are doing SSR or tight per-connection loops. Having Erlang read the native DOM directly without a string rendering step is a real architectural win, not just a convenience. Curious how you handle the supervision semantics when a JS runtime crashes.

The StumbleUpon comparison is apt but I think what made StumbleUpon work was the social layer: you could see what your friends upvoted, and that created an implicit filter against the pure randomness. Pure random discovery is fun for a session but gets old. Would love to see something like a lightweight trust graph here where a site vouching for other sites carries weight, similar to how Webring worked but with signal about quality rather than just affiliation.

Doesn't make sense... most of the software used on 3D printers is open source.

I love this low-level stuff. Do you think this is the reason that in the past year or two DNS providers have stopped allowing CNAME records for the root domain? Meaning, it's to ensure backwards compatibility for certain DNS resolution tools that are order sensitive to not get confused?

The realness here is palpable

So guilty of this.... 1st thought "I should just learn this new skill so I can do it myself" 2nd thought "That will take days/weeks... learn enough to hire it out" 3rd thought "I'm glad I went with 2nd thought"

100% been vegetarian for 10+ years and didn't realized I needed vit A suppl. till just a few years ago.

The end of an era for sure.... hope the iOS keep coming out for as long as possible.

Great article. I'm curious, did you also post the startup on HN, and if you did, did you do it before or after PH?