Applications Without Pretending We're Unix
An application on Ceylon isn't automatically a Unix process wearing a different hat. Building the runtime meant deciding, on purpose, what to borrow from that model and what to leave behind.
A genuinely tempting shortcut, when you're building a new platform, is to just make "application" mean "Unix process" and move on with your life — inherit forty years of tooling, forty years of assumptions, forty years of things people already know how to do. I didn't take that shortcut, and this entry is about why, and what the alternative actually looks like conceptually.
Why not just be Unix-shaped
A lot of Unix's process model comes bundled with assumptions that don't automatically make sense given everything two entries back about Horos's authority boundaries, or four entries back about wanting real fault isolation from the microkernel foundation up. If an application's identity, its execution container, and its underlying isolation domain are all just "whatever a process is," a lot of the boundary discipline I've been building elsewhere in this journal gets quietly undermined by the one layer that's supposed to run the software people actually touch.
What the runtime is built around instead
Application identity is kept separate from container identity, which is kept separate from the underlying isolation-domain identity — three distinct things, on purpose, instead of one concept doing triple duty. Execution happens in bounded, reusable containers with real lifecycle management: they can be created, they can be reused, and — this part mattered more than I expected going in — a stale or leftover ownership claim from a previous run gets explicitly rejected rather than silently trusted. Containers get scrubbed and reused rather than assumed clean by default, with a quarantine path for anything that doesn't check out.
The initial contract for what an application can actually do is a deliberately narrow ELF-loading contract — not a broad POSIX-compatible surface. A lot of POSIX-shaped conveniences are intentionally deferred rather than designed in from day one, because every one of those conveniences is also a piece of surface area that needs its own honest relationship with Horos's authority model, and I'd rather add capability deliberately than inherit it by accident because it's how everyone else's application model happens to work.
What I'm not getting into here
Some of the specific implementation details underneath this runtime stay out of this public journal on purpose — not because they're embarrassing, but because "private technical material" is a real category I've committed to respecting throughout this whole series, same as not naming the microkernel. What I want this entry to convey is the shape of the decision: applications are a first-class Ceylon concept, deliberately not just Unix processes borrowing the name, with identity, containment, and lifecycle treated as three separate, explicit things instead of one convenient blur.
Next up: how you actually manage a machine built this way — one API, whether a person's clicking through a GUI or typing into a terminal.
Originally published on The Weekend Report: https://theweekendersproject.com/report/applications-without-pretending-were-unix