Mike · September 21, 2026

Tags: Project Ceylon, Operating Systems, NuGUI, Kirk, Systems Engineering, QEMU, Development Log

Today was one of those days where Project Ceylon kept answering one question with another.

The good news is that the questions are getting better.

A few weeks ago, most of the work was still about proving that individual pieces could function at all.

Can the machine boot?

Can a service start?

Can storage respond?

Can the keyboard produce an event?

Can one isolated component communicate with another?

Those are still important questions, but they are no longer enough.

The questions now sound more like:

Can this service be trusted as a dependency?

Can it recover if something disappears underneath it?

Can we reproduce the machine configuration tomorrow?

Does the thing we call the “production path” actually match what the virtual hardware is doing?

And when we start building the desktop on top of all this, are we building on real foundations or accidentally cementing test code into the operating system?

That was the theme of September 21.

Kirk Moves Into Long-Duration Qualification

One of the biggest milestones today involved Kirk, Ceylon’s local service-discovery and coordination layer.

Kirk exists so applications and services do not need to know everything about each other ahead of time.

It handles things such as service discovery, provider identity, generations, lifecycle changes, capability negotiation, attachments, detachments, revocation, and reconnection.

It is deliberately not the data pipe for everything.

Audio samples do not go through Kirk.

Pixels do not go through Kirk.

High-frequency mouse movement does not go through Kirk.

Kirk is the control plane.

That distinction is important because it allows the operating system to coordinate independently developed services without turning one component into a giant central bottleneck.

Today Kirk completed the remaining bounded functional tests needed before the long-duration qualification stage.

That included stress testing, capacity edges, unauthorized requests, malformed requests, revocation, reincarnation, isolation between services, and repeated boot verification.

The result was strong enough that Kirk is now provisionally approved for application-development integration.

That does not mean final qualification is complete.

The remaining test is an autonomous eight-hour active soak that is currently running independently. During that run, the system is collecting evidence about memory stability, latency, structured logging behavior, resource use, and continued functionality after sustained operation.

Most importantly, the test is autonomous.

Nobody is sitting there babysitting it for eight hours.

It starts, exercises the service, records checkpoints, gathers measurements, and will produce a final evidence package when it finishes.

That is how this kind of qualification should work.

We Audited the Foundation Before Building More on It

With Kirk running in the background, I did not want the rest of the project sitting idle.

So the next task was a full A1 production-readiness baseline.

The question was simple:

What can we safely build on right now?

Thirty-two platform services and facilities were inventoried.

Every one of them was classified according to its actual maturity rather than how much I might want it to be finished.

That distinction matters.

The audit did not hand out “production ready” labels just because something compiled or worked once.

Instead, the services were examined for things such as:

• authority and security boundaries,
• restart behavior,
• generation handling,
• shared-memory semantics,
• queue bounds,
• failure behavior,
• target evidence,
• logging,
• resource behavior,
• provenance,
• and what higher-level software depends on them.

The result was not a wall of green checkmarks.

In fact, nothing was classified as fully production complete yet.

That is fine.

What matters is that the maturity is now known.

Twenty-four services are usable with identified gaps.

Seven remain reference-quality implementations that need further work before they become final public-runtime dependencies.

One component is deliberately deferred.

Nothing was left unclassified.

Most importantly, there are no hidden prototype dependencies in the path currently cleared for development.

That means the next NuGUI work can move forward without pretending the rest of the operating system is more finished than it really is.

NuGUI Gets a Real Architectural Baseline

That led directly into NuGUI.

NuGUI is Ceylon’s native graphical environment.

The exact reviewed NuGUI architecture specification and A1 desktop profile were then imported, cryptographically verified, preserved in the project documentation, and recorded with provenance.

Once that was done, the architecture reconciliation passed.

No unresolved contradictions were found between the low-level NuGUI architecture and the A1 desktop profile.

The major boundaries are now frozen.

NuGUI owns desktop and windowing behavior.

The display service owns the actual presentation authority.

Applications do not get direct hardware access.

Input is semantic by the time it reaches the GUI.

Kirk may help discover and coordinate services, but it does not carry pixels or high-frequency input traffic.

CPU-based rendering remains a first-class path even though future accelerated graphics are planned.

That gives the desktop team a stable contract to build against.

The Pointer Path Starts Becoming Real

The first actual implementation step after freezing the NuGUI architecture was semantic pointer input.

Keyboard input already existed on the target.

Pointer support existed partially on the host side, but the target input path was still largely keyboard-shaped.

The new D1 work added a separate bounded semantic pointer page, generation protection, overflow and high-water telemetry, and a clean boundary for NuGUI to consume pointer events later.

Fourteen host-side tests passed.

Then the target build failed.

At first glance, it looked like a new NuGUI problem.

It was not.

The failure came from dependency drift in the low-level Rust bindings used by the microkernel environment.

That dependency mismatch was repaired, preserved, and documented so the same problem should not need to be rediscovered later.

The system image and bootable ISO built successfully afterward.

Then the machine failed even earlier during startup.

Again, not NuGUI.

This time the virtual machine was launching without the Intel IOMMU configuration that the qualified system expected.

The initialization code saw zero I/O page-table levels when it expected three and stopped before user services ever started.

That launcher problem was fixed.

Three consecutive boots succeeded.

And then we found the next issue.

A Migration Ghost in the PCI Map

The USB controller was now starting, but its hardware-resource address did not match the static authorization recorded inside Ceylon.

The virtual machine reported the USB controller at one address.

The operating system still expected another.

Simply changing that one address would have created a collision with the VirtIO devices.

That was the clue.

The system was carrying a mixture of PCI resource assignments from two different virtual-machine layouts.

The older qualified layout used two virtual drives and no audio device.

The current machine uses one drive plus the audio device.

That changed the deterministic resource allocation made by the firmware.

The old static map had partially survived the migration.

Rather than moving individual addresses around until the system booted, the entire PCI resource profile was reconstructed and compared against:

1. the current virtual hardware,
2. the older known-good configuration,
3. and the static authorization inside Ceylon.

The result confirmed it.

The profile contained values from multiple generations.

The entire map was reconciled to the current one-drive-plus-audio Q35 configuration.

Three consecutive boots now reproduce the same PCI device ordering, addresses, IOMMU configuration, USB controller location, and VirtIO layout.

Storage works.

Networking works.

Display works.

The USB controller initializes.

The pointer device is detected.

No unexpected IOMMU faults were observed.

And the complete virtual-machine definition is now being treated as a qualification artifact instead of an incidental command line.

That may not sound glamorous, but this kind of work is what turns “it booted on my machine” into an operating system someone else can actually reproduce.

Where NuGUI Stands Tonight

The NuGUI architecture phase is complete.

The semantic pointer implementation is partially complete.

The host tests pass.

The pointer hardware is detected on the target.

The full target event path still needs to be exercised.

The next step is building a deterministic test harness that can inject real USB pointer movement, button presses, wheel movement, and stress traffic into QEMU while proving that those events travel through the actual path:

virtual USB device → xHCI controller → Ceylon HID provider → semantic input service → bounded pointer transport → NuGUI

No shortcuts.

No writing directly into the semantic page just to make a test turn green.

Once that path is proven, the remaining D1 tests will cover button integrity, queue behavior, high-rate motion, provider generations, malformed input, keyboard coexistence, latency, and observability.

Only then do we move on to the compositor and window manager.

The Larger Pattern

Today had a recurring pattern:

We would fix a problem.

The fix would expose the next deeper assumption.

And instead of patching around it, we kept following the evidence.

Dependency drift.

Launcher drift.

Static PCI-map drift.

Input-path qualification.

None of those are particularly exciting screenshots.

But each one removes another hidden assumption from the system.

That matters because Project Ceylon is reaching the point where more visible software is about to arrive.

NuGUI.

Applications.

NuBASIC.

Audio tools.

Games.

Eventually much more.

Those things will only be worth building if the platform underneath them is understandable and reproducible.

September 21 was not a day when Ceylon suddenly became visually impressive.

It was a day when several parts of the system became significantly harder to lie about.

I consider that progress.

Project Ceylon is an independent retro-futurist operating-system project focused on building a modern general-purpose workstation environment with strong isolation, native multimedia capabilities, and an architecture intended to remain understandable to the people building and using it.