Project ideas from Hacker News discussions.

What even is an OS now?

📝 Discussion Summary (Click to expand)

Theme 1: New OS mechanisms for safe, “conjurable” software
Commenters see a need for fresh permission, access‑control, and sandboxing designs that can safely run LLM‑generated or ad‑hoc code.
- Zee2: “There could be some interesting actual OS design innovations for new permissions, access control, and sandboxing systems that are designed from the ground up for these ‘conjurable’ experiences… Finding some balance between access and safety for vibe‑conjuring parts of the OS…”

Theme 2: Skepticism that these ideas are just old computer science repackaged
Several participants dismiss the proposals as recycled concepts, arguing the field isn’t breaking new ground.
- tptacek: “Oh, ok. I guess computer science is finished, then. I should have known. It's not like there's any evidence that it's been blown wide open recently.”
- tptacek (later): “Maybe everything we're doing is just crate‑digging through old settled computer science.”

Theme 3: The gap between expert and lay‑person views—treating all software as untrusted
The discussion highlights how non‑experts blur UI/OS boundaries and why even user‑created code should be handled like stranger‑written software.
- msla: “This is by and for people who do not distinguish between the UI and the OS, like how 'MSIE' is 'The Internet' for them.”
- chroma_zone: “If I'm running software written by an LLM, even if I was the one who prompted the LLM, I would still want my OS to treat it as if written by a stranger.”
- tptacek: “I love the idea that normal people building software to solve real problems in their life is, necessarily, a toy; the only real software is blessed by our sacred priesthood of PLT experts.”


🚀 Project Ideas

Generating project ideas…

LLMShield: Capability‑Based Sandbox for AI‑Generated Code

Summary

  • Provides a lightweight WASM‑based runtime that treats all LLM‑generated code as untrusted by default, enforcing fine‑grained capability checks for file, network, and device access.
  • Core value proposition: lets developers safely execute AI‑written scripts or plugins without exposing the host system, addressing the distrust of LLM code highlighted by HN commenters.

Details

Key Value
Target Audience Developers integrating LLM outputs, plugin creators, and SaaS platforms that allow user‑supplied AI code
Core Feature Capability‑driven sandbox (WASM + capability tokens) with audit‑able policy UI
Tech Stack Rust, WASM/WASI, Cap'n Proto for capability descriptors, optional React admin UI
Difficulty Medium
Monetization Hobby

Notes

  • HN user chroma_zone said: “If I'm running software written by an LLM… I would still want my OS to treat it as if written by a stranger.” LLMShield directly fulfills that wish.
  • Sparks discussion on capability‑based security for AI workloads and offers practical utility for AI‑powered extensions in editors, chatbots, or automation tools.

ConjureOS: Capability‑First Microkernel for Composable OS Experiences

Summary

  • A minimal capability‑based microkernel that exposes OS primitives (processes, memory, devices) as unforgeable tokens, enabling users to “conjure” custom OS components by composing capabilities safely.
  • Core value proposition: gives power users and OS experimenters a principled way to build and modify OS‑level features without risking system stability, directly answering Zee2’s call for new permission/sandboxing systems.

Details

Key Value
Target Audience OS researchers, hobbyist kernel hackers, power users seeking a safe playground for OS modifications
Core Feature Capability token API for spawning isolated environments, routing device access, and composing custom services
Tech Stack Rust (or Zig) for kernel, seL4‑inspired capability model, userspace runners in WASM or native
Difficulty High
Monetization Hobby

Notes

  • Zee2 advocated for “actual OS design innovations for new permissions, access control, and sandboxing systems… balancing access and safety for vibe‑conjuring parts of the OS.” ConjureOS is a concrete answer.
  • Provides a fertile ground for HN debates on capability systems versus traditional ACLs, and a practical tool for prototyping OS extensions like custom filesystems or network stacks.

ToyToPro: Guided Low‑Code Platform for Building Verified, Capability‑Safe Apps

Summary

  • A visual/low‑code environment that guides non‑experts to create desktop or web applications while automatically generating capability‑safe code (type‑checked, sandboxed) under the hood.
  • Core value proposition: turns the “toy” perception of citizen‑built software into trustworthy, production‑ready apps by embedding PLT‑expert safeguards, countering tptacek’s remark that only “blessed” software counts.

Details

Key Value
Target Audience Citizen developers, small‑business builders, educators who want to create real tools without deep CS knowledge
Core Feature Drag‑and‑drop UI + capability policy generator outputting verified Rust/WASM binaries
Tech Stack TypeScript/react for editor, Rust backend, Capability DSL, WASM target
Difficulty Medium
Monetization Hobby

Notes

  • tptacek lamented: “normal people building software… is, necessarily, a toy; the only real software is blessed by our sacred priesthood of PLT experts.” ToyToPro gives those normal people a path to “blessed” output.
  • Encourages HN discussion on democratizing safe software creation and offers practical utility for internal tools, automation scripts, or community apps that previously remained “toys.”

Read Later