*September 9, 2026*

**Tags:** Project Ceylon, Workshop

---

Tonight Ceylon closed the authentication publication race and uncovered the deeper distinction between execution restart and full service reincarnation.

Tonight's work on Ceylon ended in one of those places that operating-system development seems especially good at producing: we proved the thing we set out to prove, and in doing so uncovered the next problem hiding underneath it.

That counts as progress.

Ceylon is an independently developed modern operating system based around a security-certified microkernel foundation. The design exercise behind the project is simple to describe, although considerably harder to implement:

What might a machine in the Commodore/Amiga workstation lineage have become by 2026 if development had never stopped?

The goal is not to reproduce a 1980s computer or wrap a modern Unix-like system in retro graphics. Ceylon is being developed as a modern operating system in its own right, using current hardware, isolation, multiprocessing, digital graphics and modern application architecture.

Tonight we stayed deep in one of the less glamorous but extremely important parts of that work: the boundary between the graphical login environment and the authentication service.

## Closing the Authentication Publication Race

Ceylon's login UI and Authentication Service communicate asynchronously through bounded shared-memory structures.

That is deliberate.

The login interface should not freeze simply because an authentication component is busy, restarting or unavailable. Likewise, a notification by itself must never be enough to convince the login environment that authentication succeeded.

The shared result has a simple state progression:

## EMPTY → WRITING → PUBLISHED

The critical rule is that the UI may only consume a result after it has reached PUBLISHED.

That sounds straightforward until you remember that two isolated components are executing independently.

What happens if the Authentication Service begins writing a result, sends or triggers a notification at an awkward moment, and the graphical shell sees the shared page while it is still incomplete?

Tonight that case was deliberately forced.

A test-only build paused the Authentication Service while the result page was explicitly in the WRITING state. The login environment was notified and allowed to inspect the page.

It correctly refused to consume the result.

The Authentication Service was then allowed to complete the publication, after which the login environment consumed it exactly once.

The target evidence came back clean:

AUTH_TEST_PAUSE_WRITING=PASS
NUGUI_OBSERVED_WRITING=PASS
WRITING_BLOCKS_CONSUMPTION=PASS
AUTH_TEST_RESUME_PUBLISHED=PASS
RESULT_CONSUMED_AFTER_PUBLISHED=PASS
RESULT_DUPLICATES=0

The remainder of the login path survived the same test as well.

Ceylon still obtained a fresh authentication epoch, accepted a credential submission, securely cleared the credential buffer and remained locked because no real credential verifier exists yet.

That last part is important.

At this stage, a submitted password cannot authenticate anybody.

The correct current result is essentially:

Verifier unavailable. Remain locked.

And that is exactly what happened.

## Then We Asked the Harder Question

The next requirement was to test what happens if either side actually restarts during one of these transactions.

That is where tonight became more interesting.

At first glance, restarting a service sounds simple enough: service crashes → restart service → continue.

But a low-level operating system has to define exactly what the word restart means.

In Ceylon's current environment, the available low-level restart mechanism does not reconstruct an entire protection domain from scratch.

It does not automatically rebuild its address space, mappings, capabilities, IPC relationships or private memory.

Instead, it can redirect the existing execution context to another entry point.

Those are very different things.

And an older piece of Ceylon work turned out to have already encountered an even subtler problem.

## The Rust Event Loop Problem

Both the Authentication Service and NuGUI currently use the normal Rust Microkit protection-domain runtime.

That runtime enters an event loop and retains internal state associated with its IPC buffer.

If we simply redirect execution back to the beginning of that normal Rust event loop after a fault, the previous stack has never actually been unwound.

The result could be two logical users of runtime state that was never designed to be re-entered that way.

Fortunately, this is not completely new territory for Ceylon.

An earlier application-slot experiment already established a safer pattern: restart through a dedicated low-level trampoline rather than attempting to re-enter the original Rust startup path.

But tonight's analysis revealed an important difference.

The earlier application slot only needed to recover, report its status and stop.

Authentication and the graphical shell have to keep running afterward.

So the next test harness will require restart-safe entry points that explicitly recover their software state and then enter a safe receive/dispatch loop without re-entering the abandoned Rust event-loop stack.

That work is now designed and ready for implementation, but we deliberately stopped there tonight.

## Restart Does Not Clear Memory

Another useful finding came from forcing ourselves to be precise about the restart model.

A restarted protection domain does not magically receive clean private memory.

If the login screen crashed while someone was halfway through typing "correct horse batt...", those characters could still physically exist in its memory unless Ceylon explicitly erases them during recovery.

The same applies to authentication-service scratch buffers and transaction bookkeeping.

So the restart design now explicitly requires cleanup of things including: login identity buffer, login credential buffer, authentication scratch buffers, current transaction state, authentication epoch bookkeeping, correlation bookkeeping, timers, test state, in-flight request state.

This produced a security case we had not previously needed to prove: what happens to a credential that was typed but never submitted when the login component crashes?

The answer will now be part of the lifecycle test: the restart path explicitly zeroes it.

Finding that case before declaring the authentication foundation complete is exactly why these failure tests exist.

## Shared State Must Survive Deliberately

Private state should be cleaned.

Some shared state, however, must survive.

Ceylon's authentication protocol uses a monotonically advancing publication sequence to distinguish a genuinely new result from something left behind by an earlier transaction.

That means restart behavior cannot simply zero everything.

The intended split is: PRIVATE SOFTWARE STATE → explicitly reset/zeroed; SHARED PROTOCOL STATE → deliberately inspected and recovered.

For example, if the Authentication Service dies while a result is in WRITING, that partial result must become non-consumable.

But the publication sequence remains a high-water mark.

The next real result must advance beyond it rather than allowing stale state to masquerade as something new.

Likewise, when NuGUI restarts it cannot forget everything and then treat an old PUBLISHED result as new.

It must first establish a baseline from the surviving shared state, obtain a fresh authentication epoch and only accept results belonging to the new transaction.

This is where the seemingly mundane concepts—generation numbers, sequence counters, ownership and explicit publication—start paying for themselves.

## One More Edge We're Going to Attack Tomorrow

There is still another boundary worth testing.

The NuGUI-to-Authentication-Service path is asynchronous.

The Authentication Service's request to Ceylon's secure random service currently contains a synchronous call.

What happens if the Authentication Service itself is restarted while that synchronous operation is outstanding?

We don't know yet.

And rather than declaring the lifecycle problem solved because the easier restart cases work, tomorrow's test plan explicitly includes that condition.

If it works cleanly, good.

If it doesn't, the authentication foundation stays open until we understand why.

That is the rule we're trying to follow throughout Ceylon: a feature is not complete merely because the happy path works. Its failure and recovery behavior have to be understood too.

## Where Authentication Stands Tonight

Authentication ABI — PASS
BeginEpoch — PASS
Secure random epoch — PASS
Credential submission — PASS
Credential zeroization — PASS
Fail-closed behavior — PASS
WRITING → PUBLISHED race — PASS
Exactly-once result consumption — PASS
Execution-restart lifecycle proof — NEXT
Full service reincarnation — FUTURE PLATFORM WORK
Real credential verifier — NOT STARTED
Authenticated desktop — NOT STARTED

## Most importantly: AUTH REQUEST/RESULT FOUNDATION = NOT YET CLOSED

The publication race is closed.

The lifecycle proof is designed.

Tomorrow we build the harness and see whether reality agrees with the design.

## A Little Ecosystem Thinking

We also spent some time tonight thinking farther down the road.

A brand-new operating system has the same uncomfortable software problem that early home computers had: want a program? Somebody has to write one.

Ceylon will continue developing native software and native APIs, but an optional POSIX-compatible environment is looking increasingly attractive as a porting bridge, rather than as part of Ceylon's identity.

The idea would be to let existing open-source applications and libraries reach Ceylon through a compatibility boundary, instrument what they actually depend upon and then progressively replace important compatibility paths with native Ceylon interfaces.

Projects such as Chromium and Blender make useful long-range targets because getting either of them running well would exercise enormous portions of the platform.

The rule remains: compatibility follows applications. Ceylon's architecture does not follow compatibility.

That's work for considerably later.

Tonight we were still worrying about whether a login service can crash at exactly the wrong instruction and safely come back.

Operating systems are fun that way.

Development fuel tonight: Taco Bell. Probably not part of the formal architecture. Probably.

---

*Originally published on The Weekend Report: https://theweekendersproject.com/report/ceylon-dev-log-when-restart-doesnt-mean-restart*