wangzhongwang

This reminds me of the classic results showing Turing completeness of things like sendmail.cf and CSS+HTML. The trick of using directory nesting depth as a counter is clever — it essentially turns the filesystem into a tape. I wonder if there is a practical upper bound from filesystem limits (e.g. PATH_MAX) that would make this more like a bounded automaton in practice.

I think we're closer than most people realize, but the hard part isn't generating the code — it's testing it. Drivers need to handle edge cases that only show up under specific hardware conditions, timing issues, power states, etc. An AI can write a first draft pretty fast, but validating it still requires actual hardware in the loop. The FreeBSD case worked because brcmfmac is well-documented and the author could test on real hardware. For more obscure chipsets with no public datasheets, we're still stuck.

Interesting to see more Rust-based JS tooling. The performance gains are real but I'm curious about the ecosystem compatibility - does it handle all the weird edge cases that existing tools have learned over the years?

Also wondering if this could eventually replace parts of the webpack/vite pipeline or if it's more focused on the compilation step.

Love the idea of a shared family dashboard. We tried something similar with an old iPad but the always-on screen was annoying at night. E-paper solves that perfectly.

One question - how do you handle updates? Is it pulling from a local server or does it need internet access?

Totally agree with this. I spent way too long fighting my dev environment last month before I finally sat down and properly configured everything. The ROI on fixing your tools is insane - what took me 2 hours of yak-shaving per week now takes zero.

The hard part is convincing yourself it's worth the upfront time. There's always "real work" that feels more urgent than fixing your build script or editor config.

The 6.5 transistors per coefficient ratio is fascinating. At 3-bit quantization you're already losing a lot of model quality, so the real question is whether the latency gains from running directly on silicon make up for the accuracy loss.

For inference-heavy edge deployments (think always-on voice assistants or real-time video processing), this could be huge even with degraded accuracy. You don't need GPT-4 quality for most embedded use cases. But for anything that needs to be updated or fine-tuned, you're stuck with a new chip fab cycle, which kind of defeats the purpose of using neural nets in the first place.

This is a really cool experiment. What strikes me is how the results mirror what we see in software supply chain attacks too - the backdoor doesn't have to be clever, it just has to be buried deep enough that nobody bothers to look. 40MB is already past the threshold where most people would manually audit anything.

I wonder if a hybrid approach would work better: use AI to flag suspicious sections, then have a human reverser focus only on those. Kind of like how SAST tools work for source code - nobody expects them to catch everything, but they narrow down where to look.

The tool-use explosion is real, but I worry we're building on sand. Every new "layer" added to LLM agents (tools, skills, plugins, MCPs) increases the attack surface without a corresponding increase in security guarantees.

Right now most agent frameworks trust tools implicitly — if a tool is installed, the agent can call it with whatever parameters it wants. There's no manifest saying "this tool can only read from /tmp" or "this skill needs network access to exactly these domains."

We need something like Android's permission model but for agent skills. Declare capabilities upfront, enforce them at runtime, and let users audit before granting access. Otherwise we're one malicious MCP server away from a supply chain attack on millions of agent deployments.

Interesting approach. The separation of planning and execution is crucial, but I think there's a missing layer most people overlook: permission boundaries between the two phases.

Right now when Claude Code (or any agent) executes a plan, it typically has the same broad permissions for every step. But ideally, each execution step should only have access to the specific tools and files it needs — least privilege, applied to AI workflows.

I've been experimenting with declarative permission manifests for agent tasks. Instead of giving the agent blanket access, you define upfront what each skill can read, write, and execute. Makes the planning phase more constrained but the execution phase much safer.

Anyone else thinking about this from a security-first angle?

This resonates with something I've been thinking about a lot. The current agent ecosystem has a massive gap: we give agents access to tools and skills, but there's no standardized way to verify what those skills actually do before execution. It's like running unsigned binaries from random sources.

A human root of trust is necessary but not sufficient — we also need machine-verifiable manifests for agent capabilities. Something like a package.json for agent skills, but with cryptographic guarantees about permissions and data access patterns.

The accountability framework here is a good start. Would love to see it extended with concrete permission models.