Development window: September 20, 2026

The last several days of Project Ceylon development have been dominated by one job: getting the system back to a known, reproducible state after moving the underlying MicroKernel platform forward.

By mid-afternoon on September 20, we had already proven quite a bit.

The new stack booted. Multiprocessing worked. The IOMMU was operational. The system controller started. PCI enumeration worked. USB worked. The random-number service initialized. Both block devices initialized.

That sounds like a nearly finished migration.

It wasn't.

What followed was several hours of discovering just how many small assumptions can accumulate around a working machine — and how moving one layer underneath them can expose assumptions that had been invisible for months.

The encouraging part is that, by the end of the night, Ceylon was back on solid ground.

Not just "it booted once."

We now have a repeatable baseline.

One Migration Problem, Twenty-Seven Rust Targets

One of the first major discoveries concerned the IPC buffer used by Ceylon's Rust components.

The older platform arrangement placed that buffer at one address. The new MicroKernel environment places it much higher in the process address space.

A stale linker assumption remained in Ceylon's Rust target profiles.

That sounds small. It wasn't.

The same assumption existed across 27 Rust target profiles, which meant what initially looked like several unrelated failures could actually share one cause.

We corrected the integration centrally.

Representative binaries then resolved the IPC buffer at the proper new address, the previous memory fault disappeared, and the controller continued to run normally.

More importantly, another failure disappeared with it.

The RNG interface, which had previously faulted during testing, completed 256 out of 256 stress requests successfully.

That was a useful reminder of a rule we've increasingly adopted during this migration:

Fix the version contract first. Diagnose individual services second.

The RNG wasn't broken.

Storage wasn't suffering from the same memory failure anymore.

One platform assumption had been wrong in several places.

Then the PCI Addresses Moved

With the IPC issue corrected, storage progressed further — only to stop at PCI resource admission.

The addresses assigned to the block controllers no longer matched Ceylon's expected platform profile.

At first that looked like another configuration mistake.

It turned out to be more interesting.

Earlier testing had consistently produced one set of PCI BAR addresses. The new runs consistently produced another.

We reproduced the new layout with identical QEMU machine inputs and then traced the first divergence back through the boot process.

Ceylon wasn't moving them.

The firmware was.

The earlier environment had been using SeaBIOS 1.16.2. The current environment was using SeaBIOS 1.16.3.

That release includes changes in PCI resource allocation, and our testing showed the resource map changing before Ceylon executed its platform-service code.

That distinction mattered.

This wasn't a Ceylon driver changing addresses incorrectly.

It was the machine presented to Ceylon changing underneath it.

Turning the SeaBIOS Problem Into Research

Instead of immediately reverting the firmware, we stopped and asked a different question:

Could the new behavior be useful?

If firmware is responsible for assigning PCI resources, perhaps Ceylon shouldn't duplicate those assignments as handwritten constants forever.

So we ran a bounded feasibility experiment.

The exact QEMU, SeaBIOS and device topology was booted ten separate times.

Every run produced the same normalized PCI resource manifest.

Ten out of ten. Identical.

We then deliberately changed the PCI topology by adding an HDA audio device.

The resource layout changed predictably.

We removed it.

The original manifest returned.

That established something potentially useful for later development: the QEMU/SeaBIOS platform can act as a deterministic PCI-resource generator for a fixed virtual hardware configuration.

A future Ceylon build system could potentially probe that configuration and generate both the MicroKernel mappings and driver resource-admission profiles from the same machine-readable source.

That would remove an entire class of duplicated constants.

We prototyped enough of that process to establish feasibility.

Then we stopped.

The full generator is useful future engineering, but it wasn't necessary to finish the migration. A1 needs a stable machine now, not another new subsystem to develop.

So the current SeaBIOS/QEMU/platform tuple is being pinned, while generated resource integration goes onto the later engineering list.

Meanwhile: What Do We Want to Build With It?

The operating-system work wasn't the only research happening September 20.

We also spent part of the day looking farther up the stack — at the kinds of serious creative applications Ceylon should eventually support.

One of those studies focused on 3D design and modeling.

The goal was not to pick an existing application and clone it.

Instead, we looked at a range of tools with very different philosophies — including Dust3D, Plasticity, MoI 3D, MagicaVoxel, Crocotile3D, Anim8or, ZModeler and others — and asked a more useful question:

What does each one get right?

Some make it extremely easy to block out a shape.

Some are excellent at direct surface editing.

Some emphasize mathematical precision.

Some make low-poly, voxel or tile-based construction fast.

Others are aimed at fabrication rather than rendering.

The emerging Ceylon approach is to combine the useful ideas into a coherent workflow rather than inherit one application's limitations.

The working concept is currently called NuFormatix.

Its core idea can be summarized as:

Create the shape first. Add precision only where it matters.

The proposed workflow has four major stages.

Design

Start with a fast, approachable shape-building environment.

The emphasis here is getting an idea out of your head and onto the screen without immediately forcing the user into detailed CAD operations.

A Dust3D-style workflow is one of the inspirations being studied for this mode.

Direct

Once the basic form exists, move into freeform direct modeling.

This is where ideas found in tools such as Plasticity and modern direct-modeling systems become useful: grab geometry, push it, reshape it and refine it without turning every operation into a formal engineering exercise.

Precision

When dimensions actually matter, introduce constraints, measurements and CAD-style controls.

The important design decision is that precision becomes available when the work requires it, rather than making the entire application feel like a traditional CAD program from the first click.

Fabricate

Finally, the object should be useful outside the modeling program.

That means thinking from the beginning about manufacturing and output workflows — including image and geometry export, fabrication formats, G-code where appropriate, and eventually direct communication with supported devices.

The research is also pointing toward a shared Ceylon Design Core rather than a collection of unrelated creative programs.

The long-term idea is that 2D design, 3D modeling and other creation tools should share common concepts where doing so makes sense: documents, geometry, transforms, units, undo/redo, inspectors, asset handling, import/export and device output.

That could eventually allow Ceylon to support sibling 2D and 3D design applications without rebuilding the same infrastructure repeatedly.

CPU First Still Matters

There is another important requirement behind this research.

Ceylon's creative applications cannot assume that a powerful GPU is always available.

Future GPU acceleration is absolutely part of the roadmap, but the CPU path remains first-class.

For a 3D design application that means the software should remain usable with CPU rendering and CPU geometry processing, even if some operations become faster once hardware acceleration is available.

That's an important philosophical difference.

We don't want "CPU support" to mean an emergency screen that exists only long enough to install a graphics driver.

We want it to mean:

the application still works.

Then acceleration makes it better.

That philosophy applies beyond 3D graphics and will influence other Ceylon workstation applications as they develop.

Research, Not a Product Announcement

NuFormatix is still a working research direction, not an implemented A1 application or a product announcement.

There is significant specification work ahead before it would make sense to write application code.

But this kind of work is important now because the operating system needs targets.

It is very easy to design an OS around abstract benchmarks and synthetic demos.

It is much harder — and much more useful — to ask:

Can this architecture eventually support a serious modeling program?

Can it move large creative datasets efficiently?

Can applications share data without becoming tightly coupled?

Can the graphics stack scale from software rendering today to accelerated rendering later?

Can a designer move naturally from an idea to a precise object to something that can actually be manufactured?

Those questions influence the operating system beneath the application.

That's why application research is happening before all of the application infrastructure exists.

We're trying to make sure Ceylon grows toward something useful.

Storage Wasn't Broken Either

Back down in the operating-system migration, with the PCI resource profiles reconciled, both storage devices finally reached asynchronous command completion.

Then both identities were rejected.

The devices returned successful GET_ID completions, the identity structures were sealed correctly, but their serial-number lengths were zero.

Ceylon's storage router rejected them.

Correctly.

We did not weaken the validator.

Instead, we compared the current QEMU configuration with the previous working environment.

There was the problem.

The old virtual disks had stable identities:

• cylon-vblk0
• cylon-vblk1

The migrated launcher had lost those serial-number parameters.

VirtIO was doing exactly what it was supposed to do: a successful identity request against a virtual block device with no configured serial returned an empty identity.

We restored the historical serials.

Immediately:

• both identities validated;
• both volumes published;
• storage reads passed;
• storage writes passed;
• flush operations passed;
• the previous IPC memory fault remained gone;
• no IOMMU faults appeared;
• boot continued.

That was another migration failure that turned out not to be a defective subsystem at all.

The storage implementation was working.

Its platform contract had been incomplete.

Network, USB, RNG and Display

Once the main platform contracts were restored, we ran the broader parity checks.

The current results are:

Storage: operational Network transmit: pass Network receive: pass ARP: pass Basic network connectivity: pass RNG stress: 256/256 pass USB: pass Display/framebuffer: pass Controller: pass IOMMU faults: none observed

That is very close to the functional platform we had before beginning the migration.

There is still a networking interrupt question we intend to revisit.

The current network implementation is clearly able to move traffic, but an expected hardware-notification path was not observed during an instrumented run. Rather than invent a fix based on an assumption, that investigation has been suspended until it can be addressed independently against the clean qualification fixture.

It is now a production-readiness question, not something we are allowing to hold the migration hostage.

The Test Machine Started Moving Under Us

Late in the evening we encountered what may have been the most useful lesson of the entire session.

A test that should have reproduced the known-good machine suddenly produced different PCI addresses again.

Three unrelated devices all moved by exactly 16 KiB.

That pattern was too clean to be random.

The culprit was found quickly.

The HDA audio device that had been deliberately added during the SeaBIOS topology experiment had leaked into a later validation fixture.

There was a second difference as well: the failing launch had switched from the canonical default VGA configuration to a Bochs display device.

Once HDA was removed and the proper display configuration restored, the canonical PCI resource map returned exactly.

That should have ended it.

It didn't.

Storage still failed to publish its volumes.

This time the PCI layout was correct, the serial arguments were correct, and the machine topology was correct.

The wrong system artifact was being booted.

An earlier ISO from the IPC-validation work had been substituted for the later storage-qualified image, and it used a different loader.

Using the correct storage-qualified artifact restored the entire path:

• GET_ID completion;
• sealed identities;
• volume publication;
• storage read;
• storage write;
• flush.

We then ran the clean parity configuration three times.

Three out of three passed.

The ISO Is Not the Machine

This evening changed how we are treating validation artifacts.

Previously it was tempting to think of "the ISO" as the thing being tested.

It isn't.

For Ceylon A1, the qualification artifact is the entire virtual machine definition:

• exact system image;
• exact loader;
• exact QEMU binary;
• exact firmware;
• exact CPU model;
• processor count;
• memory configuration;
• IOMMU configuration;
• PCI device list;
• device order;
• device addresses;
• display hardware;
• block backends;
• persistent device serials;
• and the exact launch command.

Change one of those and you may have changed the machine.

That lesson is now being turned into process.

We have frozen a canonical A1 parity launcher representing the configuration that reproduced successfully three times.

Future diagnostic experiments will be layered explicitly on top of that baseline instead of quietly modifying it.

What We Did Not Do

Several things are equally important.

We did not weaken storage identity validation to get a green test.

We did not keep changing BAR addresses until something happened to boot.

We did not patch the firmware.

We did not promote the experimental HDA topology.

We did not promote the temporary networking IRQ experiment.

And throughout this work, the canonical Project Ceylon source tree remained untouched.

The migration and forensic work has taken place in external validation trees while we determined exactly which changes were genuinely required.

That distinction becomes important now.

We Are Entering Closure

At approximately 12:25 AM Central on September 21, the situation is substantially different from where it was nine hours earlier.

We have a reproducible A1 parity fixture.

We have three consecutive successful runs.

We understand the major compatibility changes that came with the new MicroKernel platform.

We understand the firmware resource-allocation change.

We understand why storage identity disappeared.

We understand the test-fixture contamination that confused later results.

And we have separated the remaining product-readiness work from the actual migration.

The next job is not another debugging marathon.

It is closure.

Every validated migration change is now being reconciled against the real Project Ceylon source tree.

Every experimental change has to be excluded.

Every required tool and runtime artifact has to be preserved with version and provenance information.

Every relevant worktree has to be clean.

Every source change has to be committed.

Every documentation change has to be committed.

And every strange-looking platform requirement needs an explanation describing not just what changed, but why it exists.

The migration will not be considered closed simply because the operating system boots.

There are now two closure requirements:

Functional closure: the migrated system builds and reproduces the qualified A1 behavior.

Repository and documentation closure: the source trees are clean, the changes are committed and documented, the toolchain is preserved, and another engineer could reproduce what we did without relying on the contents of someone's shell history.

Both have to pass.

Only then do we move on.

Back to Building Ceylon

This migration took longer than expected.

A significant portion of the work amounted to getting capabilities back that Ceylon already had before the upgrade.

That is frustrating, but the resulting platform is stronger for it.

We now have a better understanding of the boundaries between the operating system, the MicroKernel environment, firmware, the virtual hardware platform and the qualification fixture itself.

At the same time, research into applications such as NuFormatix is helping define what that platform eventually needs to support.

That's an important balance.

An operating system should not exist just to boot itself.

The point is what people can build and create with it.

More importantly, we now have a reproducible baseline instead of a collection of assumptions.

There are still things to improve.

There always will be.

But we're reaching the point where the question can change from:

"What did the upgrade break?"

back to:

"What are we building next?"

And increasingly, we have answers to that question too.

That's where Project Ceylon needs to be.