Project Ceylon — Development Journal

Project Ceylon Development Log — October 4, 2026: Slow, Boring, and Exactly What We Need

Mike — Sun, 04 Oct 2026 12:00:00 GMT

A couple of days ago I put Project Ceylon on a hard hold on new development.

That does not mean work has stopped.

It means forward development has stopped.

There is an important difference.

For the next couple of days, the goal is to test, appraise, repair, and retest what is already there until we are as close as we can reasonably get to a known-good platform.

That is the point I want to resume coding from.

Not "mostly working."

Not "we think this path is okay."

Not "the logs looked healthy last time."

The closest thing to a known-good system we can actually prove.

We are finding things

The testing is doing exactly what it is supposed to do.

We are finding issues.

Some are ordinary bugs. Some are incomplete implementations. Some are places where two parts of the system each make sense by themselves but do not quite agree once they have to work together.

That is why the hold exists.

If we find a real problem now, I would much rather stop and fix it correctly than carry it forward underneath another three layers of code.

That is slower in the short term.

It is much faster than discovering later that a new feature was built on top of an assumption that was never actually true.

This phase is not especially exciting to watch.

There may be a few development logs over the next several days that amount to little more than:

still testing, still appraising, still repairing.

That is fine.

I am not going to manufacture a dramatic milestone every evening just to make the journal look busy.

The project is busy enough on its own.

The goal is a trustworthy starting point

What I want at the end of this pass is a baseline we understand.

I want to know which parts of Ceylon are genuinely solid, which parts are fragile, which assumptions have survived contact with integrated testing, and which ones need to be removed before they become permanent architecture.

That means looking at the machine from more than one angle.

Individual subsystems still have to prove their own behavior, but we are also continuing to test the paths between them and the complete behavior of the system when those pieces are connected together.

We have already learned the hard way that a green local test can coexist with a broken computer.

So this is not about collecting more green boxes.

It is about understanding what those green boxes actually prove.

Advancement is on hold

I have made this a hard rule for the current tranche:

no new implementation work until this qualification and repair pass is complete.

That includes application work.

There are several things waiting in the wings that I would very much like to start building against the system.

They can wait.

If Ceylon is going to host applications, development tools, media software, games, and eventually more serious workloads, then the platform under all of that has to be the part we trust first.

The temptation to move ahead is real.

It is especially real when a new idea looks more interesting than another hour of testing restart behavior.

But "interesting" is not a release criterion.

The planning work has not stopped

The implementation hold does not mean I have stopped thinking about what comes next.

Quite the opposite.

Some of the time that would normally go into coding has gone into tightening the specifications for work we already know is coming.

We put together a much more serious plan for a Ceylon SDK and application toolchain.

The initial idea is straightforward: start with a Linux-hosted development path that can build, package, deploy, launch, diagnose, rebuild, and replace a Ceylon application through supported system interfaces.

The important part is what does not count as success.

A program linking on Linux is not enough.

A host-side simulation is not enough.

A build artifact existing is not enough.

The application eventually has to run inside Ceylon through the actual runtime and service contracts.

That specification work is useful now because it gives us something concrete to build toward later without pretending we are ready to start that implementation today.

And, eventually, Rust on Ceylon

That SDK discussion naturally led to another question:

if Ceylon is eventually supposed to be a real development environment, should Linux remain the permanent place where serious software gets built?

Probably not.

So we also started looking at what it would actually take to run a Rust compiler and linker natively on Ceylon.

Again, this is planning, not implementation.

There is a fairly large gap between "we want Rust on Ceylon" and "the compiler runs locally."

A native compiler needs filesystem behavior, process or job control, memory management, synchronization, timing, executable loading, diagnostics, and enough host support that we are not quietly outsourcing the hard parts to another machine.

That work comes later.

But defining the problem now is useful.

It is much better than discovering halfway through a toolchain port that the operating system is missing three services the compiler quietly assumed every desktop had.

NuDOS and NuBASIC got the same treatment

We also spent time tightening the specifications for NuDOS and NuBASIC.

Both already had substantial material behind them.

That was not the problem.

The problem was making sure that "substantial" also means coherent, implementable, testable, and consistent with the Ceylon that exists now.

NuDOS needed a more serious requirements pass around command parsing, file operations, application launch, session behavior, restart handling, diagnostics, and end-to-end qualification.

NuBASIC had an even larger existing language corpus, but it still needed the surrounding platform assumptions reconciled with the current architecture.

Things like files, graphics, audio, timing, sessions, resource lifetime, and service failure cannot just be vaguely implied because the language syntax is well specified.

The goal with both of these is simple:

when implementation resumes, I do not want the developer—human or otherwise—to have to invent architecture while writing code.

The specification should already tell us what the thing is supposed to do, how it fits into Ceylon, and how we will know when it is actually finished.

Scope creep is still circling the building

There have also been some discussions about future work.

Some of those are useful.

Some of them are clearly scope creep wearing a fake mustache.

I will resist.

Probably.

The important part is that discussion is not implementation.

Ideas can be written down.

Architectural questions can be researched.

Specifications can be cleaned up.

But the source tree stays on hold until the current qualification pass is done.

That boundary matters.

Otherwise a "temporary pause for testing" turns into three new subsystems and a completely different roadmap by Thursday.

I know how this works.

Then comes cleanup

Assuming this qualification pass does what I want it to do, the next likely step is not immediately another feature sprint.

'Tis the season for a refactor and optimization tranche.

By then we should have a much clearer picture of where the awkward seams are, where duplicated logic has accumulated, which assumptions need to be simplified, and which parts are worth optimizing because measurement says they need it.

That is the right time to clean the platform up.

After we have tested it thoroughly enough to understand its behavior.

Before we start stacking another layer of applications and services on top.

Refactoring a known-good system is one thing.

Refactoring a system while simultaneously wondering whether the old behavior ever worked correctly is quite another.

I prefer the first option.

So, not much to report

That may be the shape of the journal for a little while.

If we find something genuinely interesting during testing, I will write about it.

If a failure teaches us something useful about the architecture, that is worth documenting too.

But some days may simply end with:

the testing continued,

a few things were repaired,

and the hold remains in place.

That is not a lack of progress.

Right now, that is the progress.

When coding resumes—probably in a couple of days—I want it to resume from the closest thing to a known-good Ceylon platform we can produce.

Then we clean it up.

Then we optimize what actually needs optimizing.

Then we move forward.

In that order.

For once.

Project Ceylon Development Log — October 3, 2026: The Computer Has to Prove Itself

Mike — Sat, 03 Oct 2026 12:00:00 GMT

A couple of days ago I wrote that a green test is not the same thing as a working computer.

Today we spent more time making that statement inconveniently literal.

The work was not particularly glamorous.

No dramatic desktop screenshot.

No new application showing off.

No sudden miracle where every unfinished subsystem decided to cooperate at once.

Instead, we kept digging into something that has become increasingly important as Ceylon gets larger:

how do we prove that the pieces are actually complete, that they are talking to each other correctly, and that the complete machine still behaves the way the architecture says it should?

That question is starting to change how the project is being built.

The diagnostic work is becoming part of the system

We have been developing a more formal system-diagnostic approach rather than relying on a pile of independent unit tests and a few end-to-end smoke tests.

The reason is simple.

Ceylon now has enough moving parts that it is entirely possible for several components to pass individually while the complete path is still broken.

A provider can initialize.

A client can initialize.

A protocol can compile.

A local test can return PASS.

And the two sides can still disagree about identity, lifetime, ordering, authority, or what a successful response actually means.

That is not a theoretical concern anymore.

We have already seen it.

So the diagnostic model is being built around two questions:

Does each part do what it is responsible for?

and:

Do all of the parts still work together when connected as the actual computer?

Both have to be true.

One without the other is not enough.

We are finding incomplete work, not just bugs

One useful consequence of this is that the diagnostic work is exposing a category of problem that is slightly different from an ordinary bug.

Sometimes the code is not wrong.

Sometimes the code is simply not finished enough to support the behavior we thought the system already had.

That distinction matters.

A bug means an implemented behavior does the wrong thing.

An implementation gap means some part of the required behavior was never completed, never connected, or never qualified in the first place.

Those are easy to confuse when you are looking at a large system from the outside.

Something starts.

Something logs a plausible message.

Something returns a success code.

It is very tempting to mark the box complete.

The diagnostic work is forcing us to ask harder questions.

Did the request actually reach the next service?

Did the next service interpret it the same way?

Did the resource being referenced still belong to the same generation?

Did a successful response correspond to the exact operation that was submitted?

Did the result make it all the way back to the user-visible behavior?

And if one of those answers is "we don't know," then the feature is not proven.

Inter-system communication is where the interesting failures live

This is becoming one of the bigger lessons from Ceylon.

Individual components are relatively easy to reason about.

The boundaries between them are where things get interesting.

Once two protection domains or services have to cooperate, suddenly we have to care about:

who owns the object;
who is allowed to refer to it;
which generation of that object is current;
whether a response belongs to the request we think it belongs to;
what happens if either side restarts;
what state survives;
what state must be invalidated;
whether retries are safe;
and whether a timeout means "failed" or merely "we no longer know."

That is where a lot of operating-system correctness actually lives.

Not in the middle of one function.

At the seam between two things that each believe they are doing the right thing.

The new diagnostic work is being designed to exercise those seams deliberately.

NuDOS gave us a very good example

NuDOS was part of today's work, but it was not the whole story.

We have been preparing NuDOS for a much more serious implementation pass, which means taking the specification apart and asking whether it actually describes something we can build, test, and ship.

That produced a fairly substantial gap analysis.

The encouraging part is that NuDOS is not starting from zero.

There is already a bounded command/control foundation, existing console work, filesystem foundations, execution-container work, session concepts, logging, and the surrounding desktop architecture.

The less encouraging part is that "the pieces exist" is not the same thing as "the shell is complete."

The audit identified missing or insufficiently defined areas around things like command parsing, line editing, native Terminal attachment, logical locations, file operations, application launch, session isolation, output handling, restart behavior, diagnostics, and release evidence.

That is exactly the kind of gap the new diagnostic philosophy is meant to expose before we mistake partial infrastructure for a finished product.

A shell is not just a command parser

It would be very easy to build NuDOS by starting with:

DIR

TYPE

RUN

and calling it a shell when those commands print something.

That would be quick.

It would also be sloppy.

A usable command environment has to answer much less exciting questions.

What happens when a filename contains spaces?

What happens with quotes?

What happens with malformed input?

What happens if the command is longer than the allowed buffer?

What happens if the user pastes multiple lines?

What happens if a file operation is interrupted?

What happens if a service restarts halfway through a request?

What happens if the shell receives a stale response from the previous instance of that service?

What exactly does "success" mean after a destructive operation if the provider disappeared before returning the final status?

Those are not edge cases you bolt on later.

They are part of the command environment.

So the NuDOS specification is being tightened around those behaviors before implementation races ahead of the design.

We attacked the parser instead of admiring it

Part of that work included adversarial parser testing.

The point was not to prove that normal commands parse.

That is the easy part.

The point was to throw quoting combinations, malformed input, boundary cases, and arbitrary data at the proposed grammar and see where the assumptions failed.

Thousands of quoting cases were exercised.

Then thousands more arbitrary-input cases.

That kind of testing is not glamorous, but it is exactly what I want before a command parser becomes the thing standing between user input and operations like file deletion or application launch.

A parser does not get credit for understanding:

DIR Home:

if it becomes confused by:

DIR "Home:My Folder"

or silently truncates something it does not understand.

The boring cases are where trust comes from.

The vertical test matters more than the command list

There is one test I particularly want for NuDOS because it crosses several systems at once.

The idea is simple:

Open NuBASIC.

Create something.

Save it.

Open NuDOS.

Find the same object.

Inspect it.

Reboot Ceylon.

Load it again.

Run it.

That is not really a NuDOS test.

It is not really a NuBASIC test either.

It is a computer test.

It exercises application behavior, object/file storage, the command environment, persistence, reboot recovery, and the relationships between all of them.

If every individual subsystem says PASS but that sequence fails, the system is not done.

That is exactly the kind of vertical test we are going to keep adding.

The rules are changing because the project is changing

One result of all this has been a tightening of the engineering rules.

Earlier in the project, a working demonstration was often enough to justify moving forward.

That made sense when the primary question was:

Can this architecture work at all?

We are past that stage in a lot of areas.

The question is increasingly:

Can this architecture work repeatedly, under the intended authority model, across failure and restart, with enough evidence that we know what actually happened?

That requires a higher standard.

"Code exists" is not completion.

"Tests pass" is not completion.

"A screenshot appeared" is not completion.

For important functionality, completion increasingly means the requirement exists, the implementation matches it, the target behavior is demonstrated, the negative cases are exercised, the integrated path is tested, and the result is reproducible.

That is a lot less exciting than declaring victory after the first successful run.

It is also how I would rather find problems now than six months from now.

Diagnostics need to test the tester

We are also keeping one particularly important rule from the failures that got us here:

the diagnostic itself has to prove that it can fail.

If a test is supposed to reject a stale generation, give it one.

If a test is supposed to catch an invalid identity, send one.

If a service is supposed to fail closed when a dependency disappears, remove the dependency.

If the diagnostic still returns PASS, we did not prove the system.

We proved the test is optimistic.

This sounds almost silly when written out.

It is surprisingly easy not to do.

Most tests are written to demonstrate success.

We are deliberately trying to write more tests that demonstrate the ability to recognize failure.

The eventual goal is a diagnostic mode for the whole machine

As this develops, I want Ceylon to be able to perform several levels of health checking.

A quick check should answer whether the important subsystems are alive.

A focused diagnostic should be able to drill into one area.

A full-system diagnostic should walk the important service relationships.

Longer runs should exercise soak, restart, reincarnation, stale-state rejection, resource exhaustion, and other failure behavior.

And the results should be useful after the fact.

Not:

ERROR 12

and good luck.

The machine should be able to tell us what it was testing, what it expected, what actually happened, and where the path diverged.

That will be useful during development.

It will also eventually be useful for support.

There is a big difference between a user saying:

"the computer doesn't work"

and a diagnostic saying:

"storage provider is healthy, filesystem is mounted, application launch is healthy, but this particular client cannot reattach after provider generation changed."

One of those ruins your afternoon.

The other gives you somewhere to start.

This is slower on purpose

There is always pressure in a project like this to move to the visible thing.

Finish the desktop.

Launch the applications.

Make the video.

Get the Alpha out.

I want all of that too.

But we have now seen enough cases where "looks finished" and "is finished" were not the same thing.

So some of the work right now is intentionally slowing us down.

We are identifying incomplete code.

We are testing the communication between systems.

We are tightening specifications.

We are adding negative cases.

We are defining vertical tests.

And when something fails, we are trying to fix the reason it failed instead of teaching the test not to complain.

It is a good thing I am ex-Navy.

I have a fairly extensive vocabulary available for the moments when that distinction becomes inconvenient.

Where we ended October 3

The biggest result today was not one repaired subsystem.

It was a clearer development rule.

Ceylon has to prove itself at three levels:

the component,

the connection between components,

and:

the complete user-visible behavior.

NuDOS is currently giving us a useful place to apply that discipline because its job touches the Terminal, session state, filesystem, application launch, diagnostics, and persistence.

The broader diagnostic system will carry the same idea across the rest of Ceylon.

That means more work now.

It also means fewer mystery successes.

I am becoming deeply suspicious of mystery successes.

They usually turn into tomorrow's bug report.

Project Ceylon Development Log — October 2, 2026: Tested Good. Except for the Part Where It Wasn't.

Mike — Fri, 02 Oct 2026 12:00:00 GMT

I've spent an extraordinary amount of time lately testing things that have already been tested.

That sounds stupid.

Unfortunately, it has also been productive.

As Ceylon has grown, we've started putting much more emphasis on testing the computer as a complete system instead of proving individual pieces in isolation. That work continued today: building out the system-level diagnostic and qualification approach, exercising communication between services, looking for incomplete implementation paths, and following failures far enough upstream to understand why they existed in the first place.

We're getting considerably better at finding problems.

I'd be lying if I said I was always thrilled about what we're finding.

It's probably a good thing I'm ex-Navy. I have enough expletives in reserve to cover almost any engineering situation.

Some of them got exercised today.

"Tested good" has acquired an asterisk

One of today's more frustrating examples involved storage.

We spent several hours troubleshooting something that, according to the existing evidence, was already good.

Eventually we got far enough down the rabbit hole to discover part of the problem: code involved in that path was still effectively development-level implementation. It had been sufficient for the testing being performed at the time, but it had never subsequently been brought all the way up to the standard the finished subsystem actually required.

That's an ugly class of problem.

I don't think somebody sat down and deliberately decided to cheat a test. The more likely explanation is considerably more mundane and therefore more useful: development code was written to get a path working, the test passed, attention moved somewhere else, and nobody came back later to ask whether the code that made the test pass was actually suitable for the finished system.

That is exactly the sort of oversight we're trying to eliminate.

The annoying part is that the test wasn't necessarily lying.

It may have accurately demonstrated what it was designed to demonstrate.

We just hadn't asked it enough questions.

That's becoming the real engineering problem

Ceylon has enough pieces now that component testing alone isn't sufficient.

A storage service can pass its tests. A filesystem component can pass its tests. IPC can pass its tests. A client can pass its tests. Put them together, exercise a path nobody thought was particularly interesting, and suddenly two components disagree about something that each assumed the other one handled.

That is where more of the work is moving.

We're testing inter-system communication and deliberately looking at the seams: what one service sends, what another thinks it received, who owns state, what happens after something restarts, whether incomplete paths are reachable, and whether a successful result actually represents the operation we think it does.

When one of those tests fails, we're also getting stricter about not simply fixing the immediate failure.

We want to know why the bad code was there, why it wasn't caught earlier, whether the specification or implementation was incomplete, whether the test was too narrow, and whether a temporary development shortcut became permanent by accident.

Then comes the question that matters most:

What do we change so we don't make the same mistake somewhere else?

That is becoming part of the development process itself.

We're not just fixing Ceylon.

We're fixing the way we build Ceylon.

NuDOS walked into this at exactly the right time

NuDOS was another substantial piece of today's work.

We're working toward a much more complete specification for Ceylon's command environment, including the actual logic, behavior, failure cases and interfaces required to implement it.

The first gap analysis found plenty to work on. An adversarial pass found more.

Questions that sound trivial at the command-line level become much less trivial when they touch a real capability-based operating system. COPY, for example, isn't finished when two files happen to contain the same bytes. We have to define what happens if the source changes, storage fills, authority disappears, an operation is cancelled halfway through, or a provider dies while the command is waiting for it.

We also did some executable work around the command grammar. The host-side model survived the golden cases, 5,000 seeded quoting round trips, 10,000 seeded arbitrary inputs, and explicit boundary testing around malformed or oversized input.

Useful evidence.

But after the lessons of the last few weeks, nobody gets to point at that result and say, "NuDOS works."

The more important decision was about what happens later.

NuDOS won't be considered finished until it has been exercised as part of Ceylon itself. That means real Terminal input, real storage, real application launching, multiple sessions, failures and restarts, persistence across reboot, and interaction with the same system objects the graphical environment uses.

A useful end-to-end example is NuBASIC creating and saving something, NuDOS seeing and manipulating the same object, and the result surviving a reboot and working afterward.

That's one test scenario, not a fifteen-line dramatic reading of one.

I'm learning.

The specification isn't really the frustrating part

There are still gaps in the NuDOS specification, and that's fine.

I'd much rather write UNKNOWN beside an interface than invent something plausible and discover later that I specified an operating system we don't have.

The frustrating part is discovering that the system underneath a new component isn't always as ready for that component as our previous evidence suggested.

That's the bigger problem we're dealing with now.

Before NuDOS—or any other major A1 component—can simply be dropped into place, the underlying services need to be trustworthy enough that we're not debugging three unrelated layers every time the new component exercises an old path differently.

So we're going back through those paths.

We're testing them together, finding incomplete code, finding assumptions, finding places where development scaffolding survived longer than intended, and finding tests that proved something narrower than we thought they proved.

Then we're fixing the implementation and tightening the engineering process that allowed the problem through.

It's tedious.

Occasionally it inspires colorful nautical terminology.

But it's working.

We're getting better at finding our own mistakes

There is a strange kind of progress happening here.

Every day we seem to get better at making Ceylon fail.

A month ago, that sentence would have sounded terrible.

Now I think it's one of the healthiest things happening in the project.

The system-level testing is becoming more aggressive. The diagnostic tooling is becoming more useful. We're paying more attention to communication between components instead of only their behavior in isolation. We're tracing failures to root causes instead of stopping at the first broken assertion. And when the root cause exposes a weakness in our engineering rules, we're changing the rules.

That doesn't mean we're going to stop making mistakes.

This is an operating system. If I ever announce that we've developed a process that prevents programmers from overlooking things, somebody should probably check me for a head injury.

The goal is to make those mistakes harder to hide.

A development shortcut shouldn't be able to quietly become production architecture because the associated test happened to turn green.

An incomplete subsystem shouldn't be called complete because every implemented function works.

And two independently tested components shouldn't automatically be assumed to work together.

We're learning how to ask nastier questions.

Which is good, because the computer is answering them

Some of the answers today required vocabulary that will not be reproduced on the Project Ceylon website.

Again: ex-Navy.

We're covered.

But I'd rather spend several aggravating hours discovering that "tested good" wasn't good enough now than build another layer on top of it and discover the same thing six months from now.

The objective hasn't changed.

I don't want a collection of components that can each demonstrate that they work.

I want a computer that works.

Right now, getting there means spending an uncomfortable amount of time proving where it doesn't.

And we're getting pretty damn good at that.

Project Ceylon Development Log — October 1, 2026: The Mouse Moved, Asteroids Is Real, and the Hardware Stopped Sitting Still

Mike — Thu, 01 Oct 2026 12:00:00 GMT

Today was one of those days where several things that had been "almost there" finally became a lot more concrete.

The short version:

the real keyboard and pointer path passed, the Asteroids demo turned out to be a real application core instead of a future placeholder, and Clarise proved the same Ceylon image can cope with different PCI resource layouts without rebuilding the operating system around them.

That is a fairly satisfying day.

Especially because all three of those things point at the same larger goal:

Ceylon needs to stop behaving like a carefully staged demonstration and start behaving like a computer.

The mouse problem was not a mouse problem

The first win was NuGUI input.

Keyboard input has been working for a while, and the pointer path has been under qualification for several development tranches.

Today the remaining QEMU tablet issue finally got pinned down.

The parser was rejecting the virtual tablet because it reported itself as:

class 3, subclass 0, protocol 0

That was enough to send the existing HID logic down the wrong path.

Nothing particularly dramatic was wrong with the mouse.

The machine was simply looking at a perfectly valid HID device and deciding:

"Nope. I don't know what that is."

Which, in retrospect, is a wonderfully accurate description of quite a bit of operating-system development.

The parser was corrected.

Then we went back through the actual path instead of declaring victory because one pointer event appeared.

The input path is now real

The path being qualified is the one I actually care about:

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

No shortcut that writes fake mouse movement directly into the GUI.

No host-side test pretending to be the target.

No "we proved the parser works, therefore the desktop works."

The complete keyboard and pointer transport passed.

Then it stayed up under an 11-minute soak.

The broader workspace test run completed:

480 tests, 0 failures.

And the existing Nu-Iris R2 through R8 regression sets stayed green.

That last part matters because input work should not quietly damage the display path while everybody is celebrating that the mouse moved.

So this is a genuine milestone.

Not "pointer code exists."

Not "a cursor twitched."

The underlying interactive path is now behaving like something we can build on.

Next comes focus, which sounds easier than it is

The next NuGUI step is focus routing and static application activation.

That sounds almost trivial.

Click a window.

That window gets input.

Launch an application.

It becomes active.

Done.

Except operating systems have a way of turning every sentence containing the word "just" into a week of work.

Focus has to answer questions like:

Which application owns keyboard input right now?

What happens when a window disappears?

What happens when an application crashes?

Can stale input reach a replacement instance?

What happens when pointer focus and keyboard focus differ?

What does activation mean if the application has restarted?

Those are not glamorous questions.

But they are the difference between a desktop that usually works and one that occasionally types your command into the wrong application.

The important part is that we have reached that layer now.

We are no longer debugging whether QEMU can produce a pointer packet.

We are deciding what the operating system should do with it.

That is progress.

Then I went looking for Asteroids

A1 Alpha is supposed to include a simple Asteroids-style demo as a lightweight native proof-of-life application.

The idea is deliberately modest.

Juggernaut is the heavier game workload.

Asteroids is supposed to answer a much simpler question:

Can Ceylon run a small, responsive native arcade application cleanly?

Input.

Timing.

Rendering.

Collisions.

Score.

Sound.

Nothing fancy.

Today I went looking for the actual state of that work.

And found something better than I expected.

There is already a packaged source drop:

CeylonAsteroids-0.1.0-drawer-package.zip

And it is not just a README and a future plan.

There is a real game core.

A CPU renderer.

Tests.

A host development demo.

And integration documentation explaining how the application is supposed to connect to Ceylon.

That was a pleasant surprise.

Asteroids exists. It just does not live in Ceylon yet.

The distinction is important.

The game itself is substantially there.

The missing part is the Ceylon target adapter.

That means we still need to connect the portable game core to the operating-system services around it.

Specifically, it still needs:

a Ceylon target binary / protection domain;
a NuGUI window;
an application activation endpoint;
semantic input mapped into the game's InputState;
the Ceylon timer path driving Game::step();
a pixel buffer connected to the game's renderer.

In other words, the game logic is not the blocker.

The operating-system integration is.

That is actually exactly where I hoped we would be at this stage.

I want application developers to be able to build most of their logic without having to run the entire operating system every time they change one line.

Then the Ceylon adapter should connect that logic to the native platform.

Asteroids is turning into a nice test of whether that application model is actually practical.

This may become the first really obvious desktop proof

There is something appealing about using Asteroids as the first simple application activation target.

A text editor can prove a lot.

A settings window can prove a lot.

A terminal can prove a lot.

But an arcade game makes failures obvious.

If input is delayed, you know.

If timing is wrong, you know.

If rendering tears or stalls, you know.

If focus gets confused, your spaceship starts doing something stupid immediately.

And, perhaps most importantly for a project page, it is a lot easier to show somebody a moving ship and flying rocks than it is to show them a correctly bounded IPC queue.

Both matter.

Only one of them makes a decent GIF.

Clarise also had a good day

The other major result today came from Clarise, Ceylon's Plug-and-Play/device-management work.

One of the problems we have been steadily trying to eliminate is the idea that Ceylon should only work when PCI devices appear at the exact addresses we happened to see during one QEMU run.

That is not Plug-and-Play.

That is a very elaborate static configuration file.

Clarise Stage 2 pushed against that assumption.

The current model uses runtime PCI discovery and generation-qualified device bindings rather than treating one set of BAR addresses as universal truth.

Today the same Ceylon system image was exercised against two different BAR layouts.

It passed both.

No rebuilding the image around the new addresses.

No editing one magic constant until the device appeared.

The device resources were discovered and bound dynamically.

That is exactly what I want.

Same image, different machine layout

This may be one of those milestones that sounds less important than it is.

Virtual hardware moves around.

Physical hardware definitely moves around.

Firmware changes resource allocation.

A different device topology can shift PCI BARs.

Add an audio device and suddenly something else may land somewhere different.

We have already been bitten by this more than once.

So the test today was intentionally simple:

Can the same Ceylon image deal with two legitimate resource layouts?

Yes.

The current bounded aperture covered the expected range, and the runtime binding model correctly handled the devices in both configurations.

The qualification also included a little over 20 minutes of soak time.

That does not mean Plug-and-Play is finished.

It means another hard-coded assumption is disappearing.

And every one of those we remove makes the future bare-metal work a little less terrifying.

The three stories are actually the same story

At first glance, today looks like three unrelated development threads.

Input.

Asteroids.

PCI discovery.

But they all point in the same direction.

The first version of Ceylon was necessarily full of fixed assumptions.

One display.

One known machine.

One expected resource layout.

One manually controlled application path.

That is normal when you are trying to prove anything works at all.

But a real operating system cannot stay there.

A pointer device has to be discovered and interpreted rather than faked.

An application has to be activated and connected to services rather than hand-wired into a demo.

Hardware has to be bound based on what actually exists rather than where it existed last Tuesday.

That is the transition we are making now.

From:

"Can I make this path work?"

to:

"Can the operating system make this path work without me standing next to it?"

That second question is much closer to a product.

What is next

For NuGUI, the immediate work is focus routing and static application activation.

For Asteroids, that means building the actual Ceylon adapter and making it one of the first applications launched through the real desktop path.

For Clarise, the dynamic binding work continues toward broader Plug-and-Play authority and lifecycle handling.

And importantly, none of today's work required changing Nu-Iris.

The display regressions stayed green while the input path moved forward.

I am increasingly fond of days where one subsystem improves without requiring emergency surgery on three others.

That feels suspiciously like maturity.

I don't want to get carried away.

Where we ended the night

The keyboard works through the real path.

The pointer works through the real path.

The input stack survived its soak and regression suite.

The Asteroids demo is no longer an idea on the Alpha checklist; there is a real portable game core waiting for its Ceylon adapter.

And the device-management work proved that one system image can survive more than one PCI BAR layout without being rebuilt around the hardware.

None of those things, individually, is the dramatic "Ceylon is alive" screenshot I am chasing.

Together, though, they are exactly how we get there.

A machine that can discover its hardware.

Accept real input.

Activate a native application.

Give that application a window.

Feed it time and controls.

And let the user shoot rocks until something breaks.

Honestly, that sounds like a pretty good next milestone.

Project Ceylon is an independent retro-futurist operating-system project exploring what a modern creative workstation might look like if some of the best ideas of earlier personal computers had continued evolving instead of being discarded.

Project site: ceylonprojectng.com

Project Ceylon Development Log — September 29, 2026: The Website Is Real. So Is the Next Display Bug.

Mike — Tue, 29 Sep 2026 12:00:00 GMT

Yesterday I wrote that Project Ceylon finally had a front door.

Today I actually moved some furniture in.

The new Ceylon site is no longer just a landing page saying, essentially, "yes, this project exists."

It now has the beginnings of a real public archive: project information, the development journal, supporting pages, and the plumbing needed to keep publishing without hand-editing a static page every time I do something questionable to the operating system.

And while that was happening, Nu-Iris finally crossed an important line.

R4 was promoted.

Then R5 immediately found another problem.

So the day ended with the public side of Ceylon looking considerably more finished and the display stack reminding me, once again, that appearances are dangerous.

Seems appropriate.

The website became a project site

The biggest visible change today is at:

ceylonprojectng.com

Yesterday it was a proof that the routing, certificates, hosting and deployment worked.

Today it is much closer to what I actually wanted:

a real home for Project Ceylon.

The development journal has been brought over so the project history can live with the project instead of existing only as a scattered collection of posts elsewhere.

The current site now has the pieces I expect from a proper technical project:

a public project overview;
development-journal archive;
individual journal pages;
responsive layouts;
RSS;
sitemap support;
sensible navigation;
pages that remain readable even without JavaScript;
a publishing boundary between public work and things that are not ready to be public.

That last one got tested harder than the pretty pages did.

Good.

Publishing has failure modes too

Once you have a site backed by real content, the dangerous question becomes:

What can accidentally become public?

Drafts should not appear.

Unpublished material should not leak into archive pages.

Private or unannounced research should not wander into RSS.

A page that has been deliberately withheld should not show up because somebody forgot one filter in one renderer.

So the publishing path got tested the same way I increasingly test the OS:

not just by asking whether the expected thing works,

but whether the thing that is not supposed to happen stays impossible.

One deliberately missed leak was found during that work.

It was fixed.

Then the site was checked again across the normal pages, archive, RSS, and sitemap behavior.

That matters to me because I want the development journal to remain pretty open.

Research into things I have already publicly discussed can be written about as research, even when the idea later gets discarded.

That is part of the point of building this thing in public.

But "building in public" does not mean "publish every unfinished thought, internal note, or unannounced project because a content query happened to find it."

There still has to be a boundary.

Now the site has one.

The journal is becoming part of the engineering record

Something else happened once all of these entries started living together.

The journal stopped feeling like a sequence of blog posts and started looking like a development history.

That is useful.

You can see the project change its mind.

You can see Nu-Day turn into Ceylon.

You can see early assumptions fail.

You can see First Light happen and then later learn what First Light actually proved.

You can see storage break for reasons that had nothing to do with storage.

You can see the Alpha scope get smaller and more concrete.

And you can see just how often a supposedly minor question turns into a week of architecture work.

I like that.

I do not want to rewrite the history into a neat story where every early decision was obviously leading to the current design.

It wasn't.

Some of this has been exploration.

Some of it has been wrong.

Some of it has been very wrong at 3:00 AM.

The useful part is documenting why the next decision became better.

Meanwhile, Nu-Iris R4 finally crossed the line

The quieter technical milestone today was Nu-Iris R4.

R4 had already reached the point where the design, implementation, target evidence, and independent review all said the same thing:

this exact candidate is ready.

Today that candidate was promoted into the canonical Ceylon source.

That sounds simple.

It wasn't treated casually.

The promotion had to prove that the exact reviewed source was the thing being moved forward.

Not a rebuilt approximation.

Not "the same changes, basically."

Not a branch with one extra helpful tweak.

The exact qualified candidate.

The validation harness stayed out.

Temporary evidence stayed out.

Unrelated work stayed out.

Owner work was preserved.

The result is that R4 is no longer a promising candidate sitting beside Ceylon.

It is now the current canonical Iris boundary.

That is a meaningful milestone.

What R4 actually gives us

R4 is not the end of Nu-Iris.

It is the point where the service has a much stronger internal contract.

It now deals explicitly with things such as:

surface identity;
buffer identity;
generations;
frame tokens;
lifecycle state;
stale and replayed requests;
bounded completion behavior.

In other words, it is increasingly difficult for a frame to simply be "some buffer somewhere that everybody vaguely agrees is current."

That is good.

But R4 still does not actually carry the frame all the way to the physical display provider.

That is R5's problem.

And R5 did not take long to become interesting.

The display provider needs to be replaceable

The current physical display path still goes through the existing Bochs device implementation.

That is fine for A1.

What I do not want is for "Bochs" to quietly become part of the permanent Nu-Iris architecture just because it happens to be the first provider.

So the R5 design work has been focused on putting a provider-neutral contract between Iris and whatever actually owns the physical display hardware.

Conceptually:

NuGUI → Nu-Iris → display provider

For A1, that display provider happens to be the existing Bochs path.

Later it could be something else.

A real GPU.

A different framebuffer device.

A virtual display.

A remote display.

A headless output.

More than one output.

More than one provider.

Potentially even additional Iris domains created by the user.

The first implementation does not need to do all of those things.

But it must not make them impossible.

That distinction is one of the recurring themes in Ceylon:

do the simple thing now without making the simple thing the permanent shape of the universe.

A frame needs more identity than "frame"

The provider contract got fairly serious today.

A display submission cannot just be:

"please show this buffer."

It needs enough identity that a stale response from an old provider, an old output, an old surface, or an old frame cannot accidentally release or complete something newer.

So the design is moving toward a hierarchy roughly like:

Presentation Domain → Output → Provider Binding

with explicit generations and leases underneath it.

A submitted frame carries the identities required to prove exactly what operation it belongs to.

The provider response has to echo enough of that identity that a response for frame N can never be mistaken for frame N+1.

That may sound like excessive bookkeeping for putting pixels on a screen.

It stops sounding excessive the first time something restarts while another frame is still in flight.

Then it becomes the difference between a stale completion being harmless and a stale completion corrupting ownership of the current frame.

The current Bochs path also has an honesty limit

Another thing I like about the R5 design is that it is being explicit about what the current hardware path can actually prove.

The Bochs backend can tell us that the framebuffer update completed.

That is the truthful ceiling.

It cannot honestly claim:

vertical blank completion;
page-flip completion;
physical scanout completion.

So we are not going to give the result a fancy name and pretend it means more than it does.

For A1, the strongest valid statement is essentially:

the framebuffer update completed.

Later hardware can support stronger presentation semantics.

When it does, the protocol can represent them.

Until then, the system should tell the truth.

I am becoming increasingly fond of boring, truthful status codes.

They cause fewer interesting evenings.

And then BAR2 raised its hand again

Before the physical R5 provider path can be qualified, the Bochs hardware path has to pass its own precondition.

That is where today's next problem appeared.

The BAR2 resource being configured, the BAR2 resource observed at runtime, and the BAR2 value expected by the current profile did not agree.

The values were not subtly wrong.

They were different enough that the correct response was obvious:

stop.

Do not hide it in Iris.

Do not compensate inside the provider adapter.

Do not "just use the runtime address" and move on.

Figure out why the physical path disagrees with the configuration first.

That boundary is now explicit.

R5 is not allowed to absorb a device/resource defect and turn it into an Iris feature.

I am quite happy about that, even though it means the shiny path is blocked for the moment.

A blocked test is sometimes the best result

A few weeks ago I might have described today as:

"We almost got R5 working but BAR2 stopped us."

That is not really the useful interpretation anymore.

The useful interpretation is:

the gate caught exactly the kind of problem the gate was designed to catch.

R4 is cleanly promoted.

R5 has a bounded design.

The provider boundary is explicit.

The current hardware path has a known prerequisite.

And when that prerequisite failed, work stopped at the correct boundary.

That is much better than discovering three tranches later that Iris had quietly learned how to compensate for a broken PCI assumption nobody remembered making.

Ceylon is getting two kinds of infrastructure now

Something about today made this project feel different.

On one side, there is the infrastructure people can see:

a real project site,

a journal archive,

navigation,

feeds,

public documentation,

a place where somebody new can arrive and understand what Ceylon is without reading forty terminal transcripts first.

On the other side, there is the infrastructure almost nobody will ever see:

generation counters,

leases,

provider bindings,

resource authority,

promotion gates,

artifact identity,

hardware preconditions.

They are both necessary.

The first makes the project understandable.

The second makes the machine trustworthy.

I think I have spent enough time on operating systems now to appreciate that you need both.

A machine nobody understands is not especially useful.

A machine everybody understands but that lies about which frame it just completed is also not especially useful.

Where we ended the day

The Ceylon website is now much closer to being the project's permanent public home.

The development journal has a proper archive.

The publishing boundary has been exercised rather than merely assumed.

Nu-Iris R4 is now canonical.

R5 has a much clearer provider-neutral architecture.

And the first attempt to push that work toward the physical display path hit a BAR2 mismatch and stopped exactly where it should have.

That is not a dramatic screenshot day.

But it is the kind of day where the project gets more real in two different directions at once.

One direction is outward.

People can find it, read it, and follow the history.

The other direction is inward.

The code has to prove more precisely what it means when it says something worked.

I am pretty comfortable with both of those trends.

Tomorrow, I suspect BAR2 and I are going to have a conversation.

I doubt either of us is going to enjoy it.

Project site: ceylonprojectng.com

Project Ceylon Development Log — September 28, 2026: Ceylon Got a Website. Then We Started Talking About Robots.

Mike — Mon, 28 Sep 2026 12:00:00 GMT

Today Project Ceylon got a real home on the web.

And then, because apparently I am incapable of doing one normal thing at a time, the day wandered through local-first computing, federation, real-time scheduling, CNC controllers, Raspberry Pis, Roombas, and the possibility of building an actual robot running Ceylon.

So this one may be a little all over the place.

In other words, fairly representative of the project.

Ceylon finally has its own front door

The new public site is now up at:

ceylonprojectng.com

There is also a new site for the parent company at:

inspirebycraft.com

Both are currently simple landing pages.

That is intentional.

I wanted the routing, hosting, certificates, and deployment path proven before turning either one into a giant content-management project.

The new sites are running through the same established Cloudflare Tunnel infrastructure already serving The Weekenders Project, without disrupting the existing site.

That was the first goal:

put the new doors on the building without knocking down the house next door.

Done.

The next stage will be turning the Ceylon site into the proper project home instead of relying on Hackaday alone.

Hackaday is still where I want this development journal and the contest-facing build story to live.

The Ceylon site can do the slower-moving jobs:

explain what the project is;
maintain architecture and roadmap material;
provide downloads when we reach that point;
host documentation;
collect project history;
eventually support Alpha feedback and release information.

For the moment, though, it exists.

That feels surprisingly significant.

Ceylon has spent most of its life as source trees, specifications, QEMU windows, terminal logs, and increasingly questionable amounts of coffee.

Now it has an address.

The project identity is getting clearer too

Putting up a public site forced another useful exercise:

How do I explain what all of these names actually mean?

The structure is becoming fairly simple.

Inspire by Craft is the parent maker company.

The IBC Systems Division is the computing side.

Project Ceylon is the operating-system and workstation program.

And The Weekenders Project is a separate community project under the same parent.

That probably sounds like corporate housekeeping.

It is.

But names start mattering once you expect people other than yourself to look at what you are building.

The parent-company line also finally settled into something that feels like me:

Jack of all trades. Master of some. Makers of things. Some pretty. Some useful. Some pretty useful.

That is probably a better description of how I got into this mess than any mission statement I could write.

Local-first is becoming more than a preference

Yesterday I wrote about wanting Ceylon to remain useful without depending on a remote service to grant the computer permission to exist.

Today that turned into more concrete federation work.

The question was:

How should two or more Ceylon machines work together without turning the whole system into a cloud product?

The answer is starting to take shape as three levels:

Standalone → Fed-Light → Managed Federation

Standalone is exactly what it sounds like.

The machine works by itself.

Fed-Light is the interesting middle ground.

Two nearby Ceylon systems should be able to discover one another, explicitly establish trust, and share selected services or resources without requiring a central management server.

No "every machine on the LAN is automatically trusted."

No ambient network authority.

Discovery can happen automatically.

Trust cannot.

That should require an intentional adoption step.

Once adopted, the systems can negotiate permissions, attach to allowed services, and revoke that relationship later.

Then, for businesses, labs, schools, production environments, or larger installations, there is the full managed-federation model.

That adds centralized enrollment, inventory, policy, compliance, application control, conditional access, and the other things you need once "two computers on my desk" becomes "two hundred computers somebody has to support."

The important part is that the machine does not become less capable when the management server disappears.

Local-first failure semantics matter.

The local computer should degrade gracefully, not become a decorative rectangle because the network is having a bad day.

That principle is now much more explicit in the federation design.

Then CNC dragged us into real-time computing

Another conversation today started with something much more practical.

Ceylon is eventually intended to control CNC equipment.

If you are driving motors, reading sensors, and generating motion, "the scheduler will probably get around to this soon" is not a particularly comforting engineering guarantee.

So the question became:

Does Ceylon need to be a real-time operating system?

The answer I like is:

parts of it do.

I do not want to turn the entire desktop operating system into one giant hard-real-time environment.

That would make ordinary desktop work unnecessarily rigid and complicated.

Instead, the architecture should be able to assign real-time behavior only where it is justified.

The working model is roughly along the lines of:

normal
soft real-time
firm real-time
hard real-time

Different services or execution paths can declare what they actually need.

A CNC motion-control loop may deserve hard real-time treatment.

An audio render path may need firm real-time deadlines.

Video capture and playback may need bounded timing without requiring the same guarantees as a motor-control loop.

Your text editor does not need any of this.

That seems like a much healthier model.

And, importantly, it leaves room to assign additional real-time behavior later without redesigning the operating system every time we discover a new workload that needs it.

Audio and video benefit from this too

The CNC discussion immediately looped back into the workstation side of Ceylon.

Audio production is full of deadlines.

Miss one badly enough and you do not get a polite error dialog.

You get a click, a pop, a dropout, or silence.

Video has similar problems around frame timing, capture, playback, and synchronization.

So the real-time work is not some strange industrial branch growing off the side of the OS.

It actually ties together several things Ceylon already wants to be good at:

music production;
video production;
communications;
CNC control;
robotics;
eventually other instrumentation and control workloads.

The trick is keeping the real-time guarantees narrow enough that they improve those systems without turning every application into a scheduler negotiation.

That is now part of the design problem.

And then somebody mentioned a Cylon

At some point in that conversation, the obvious joke happened:

If Ceylon gains real-time control, sensor support, networking, audio, cameras, and embedded hardware support...

we could build a real Cylon running Ceylon.

That is the sort of sentence that should probably end a meeting.

Instead, it started another project idea.

Because once you stop laughing, there is actually a pretty good systems test hiding inside it.

A robot is a beautiful way to force an operating system to deal with:

sensors;
actuators;
real-time control;
networking;
cameras;
audio;
power constraints;
device discovery;
failure handling;
remote telemetry;
local autonomy.

So yes.

At some point, Project Ceylon probably needs a robotics kit.

Not for A1.

Everybody relax.

I have learned at least some scope control.

Hack the Roomba

The version of this idea I like most is deliberately less ambitious than building a humanoid robot from scratch.

Take a Roomba.

Put a Raspberry Pi-class computer on it.

Run Ceylon.

Talk to the Roomba's existing control interface.

Then start adding things.

More sensors.

A camera.

Microphones.

Speakers.

Environmental sensing.

Maybe mapping.

Maybe remote control.

Maybe local autonomy.

Maybe another Ceylon machine acts as the workstation while the robot becomes a Fed-Light peer.

Now we have a weekend project that is also a legitimate operating-system test platform.

That could eventually make a fun Hackaday challenge:

What can you turn an old robot vacuum into when the controller is a general-purpose Ceylon computer?

There is one fairly large prerequisite.

Ceylon is x86-64 today.

A Raspberry Pi would require ARM64 work.

We have already been discussing tablets as a future ARM64 target, so the robot probably comes after that.

Which means the current unofficial sequence may be:

build operating system,

build tablet,

hack Roomba,

accidentally start robotics division.

Seems reasonable.

Nu-Iris got some quieter work today too

Not everything today involved dreaming up future hardware.

Nu-Iris also moved forward a little.

The current R4 candidate has reached the point where the technical and governance reconciliation is clear for promotion.

That does not mean I started piling the next round of display features onto it.

Quite the opposite.

One thing I am trying to get better at is knowing when to stop touching something.

The current candidate is being kept separate from the validation harness and from later experimental work.

No sneaking future display ideas into the promotion.

No mixing qualification scaffolding into the product tree.

No "while we're here, let's just add..."

Get the qualified work promoted cleanly.

Then start the next tranche from a known point.

That sounds obvious.

Ceylon has taught me repeatedly that "obvious" is not the same as "automatic."

Today felt less like debugging and more like defining the edges

There was not one giant technical breakthrough today.

No dramatic new screenshot.

No airplane flying yet.

No synthesizer concert.

Instead, several boundaries got clearer.

Ceylon has a public home now.

The company and project identities make more sense.

Local-first federation has a cleaner path from one machine to peer-to-peer cooperation to managed environments.

Real-time behavior is becoming something Ceylon can assign where it is actually needed instead of a property the entire OS has to pretend to have.

And the same architecture that may someday drive a CNC machine could eventually run a robot vacuum with entirely too many sensors attached to it.

Meanwhile, Nu-Iris quietly moved closer to a clean promotion without dragging tomorrow's experiments into today's qualified work.

That is a pretty good day.

Also, I would like it noted for the record that the robotics idea was not on the A1 Alpha list when I woke up this morning.

And it still isn't.

Progress.

Project Ceylon Development Log — September 27, 2026: Apparently Housekeeping Is Systems Engineering Too

Mike — Sun, 27 Sep 2026 12:00:00 GMT

Today I deleted almost 300 GiB of Project Ceylon development debris.

And somehow that turned into a desktop-design discussion.

That sounds about right.

The short version is that the machine had accumulated months of build trees, validation copies, temporary workspaces, old artifacts, abandoned experiments, duplicated toolchains, test images, and assorted other things that all made perfect sense when they were created and considerably less sense after they had been sitting there for a while.

The filesystem had reached about 77% used.

By the time the cleanup was finished, it was down around 53%.

Free space went from roughly 300 GiB to 600 GiB.

And, most importantly:

the canonical Ceylon source stayed exactly where it was supposed to be.

That last part is what made the cleanup interesting.

Deleting files is easy.

Deleting the right files in an operating-system project without quietly throwing away the one copy of something important is a different job entirely.

"rm -rf" was not the plan

The cleanup was deliberately conservative.

Every candidate had to earn the right to be deleted.

Build trees?

Probably disposable.

Generated output?

Usually disposable.

Temporary validation copies?

Maybe.

A directory that looks temporary but contains tracked source?

Absolutely not.

That distinction caught one remaining root-owned workspace that otherwise looked like cleanup material.

The deletion process checked it against the canonical repository, found tracked source inside it, and kept it.

Exactly what I wanted.

By the end of the run, 391 out of 392 residual root-owned paths were removed.

The one exception was preserved because it still contained canonical source.

That is a much better result than "we deleted everything and the machine still seems to boot."

Cleanup found things I actually wanted to keep

The more useful surprise came before the final deletion pass.

A proper inventory of the old workspaces found a few pieces of engineering work that had not yet been cleanly reconciled back into the main project.

That is the dangerous part of long-running experimental development.

You make a fix in a validation tree.

Then another fix in another tree.

Then a branch exists because you were trying to prove one very specific thing at 2:00 AM.

A week later, the fix is good, the test passed, everybody remembers the result...

...and the actual source of truth may not yet contain the thing that produced it.

That is how projects slowly become folklore.

So before anything was removed, the cleanup process stopped and identified those unique changes.

No merging by accident.

No "well, I think this one was already included."

No guessing.

The cleanup became a reconciliation exercise before it became a deletion exercise.

That may be the least glamorous sentence I have ever written for Hackaday.

It is also probably one of the more important ones.

This project is getting too big to rely on memory

I have a decent memory for how Ceylon got here.

That is not the same thing as having a process.

As the project has grown, I have become increasingly suspicious of statements that begin with:

"I'm pretty sure..."

I'm pretty sure that patch was incorporated.

I'm pretty sure that workspace is obsolete.

I'm pretty sure that toolchain is the current one.

I'm pretty sure we qualified that exact image.

No.

"Pretty sure" is how six months from now becomes miserable.

The system now has enough moving parts that provenance, reconciliation, qualification evidence, and cleanup discipline are becoming part of the engineering itself.

Apparently housekeeping is systems engineering too.

I did not expect that to become one of the themes of this project, but here we are.

Meanwhile, I have been thinking about the desktop again

The cleanup work was not the only thing happening today.

I also went back to a question I have been circling for a while:

If Ceylon is not going to simply copy Windows, macOS, or Linux, what should actually be different about using it?

Not different for the sake of being weird.

Different in a way that is genuinely useful.

I do not want Ceylon to ship with twenty "innovations" that all need a tutorial and make somebody wish we had just left the desktop alone.

One or two good ideas are enough.

Then improve them based on evidence.

The current one is called Workpad.

The Workpad idea is very simple

Imagine you are working on something in a window.

Maybe a document.

Maybe a source file.

Maybe a graphics project.

Maybe something else entirely.

Around that work you usually accumulate related stuff:

another file,

a reference image,

a URL,

a note,

a clip,

a shortcut,

something you dragged over because you will need it again in ten minutes.

Modern desktops are surprisingly bad at remembering that temporary working context.

So the Workpad is basically:

the tray of useful things that belongs with this work.

Not a second desktop.

Not a replacement for folders.

Not a giant project-management system hiding behind a paperclip icon.

A contextual surface attached to the work you are doing.

You can put related things there and have them stay associated with that context.

The design has now been formalized far enough that it is no longer just a sketch on my mental whiteboard.

It should still look like the thing it is

One detail I care about is object identity.

If you put a file on the Workpad, it should still look like that file.

If you put an application there, it should retain that application's identity.

A reference should remain a reference.

A URL should remain a URL.

I do not want everything transformed into generic little "cards" because some design system decided all objects need rounded corners and the same icon.

The object should keep its normal visual identity.

And where possible, the Workpad should preserve where it came from.

If you pulled in a file from a folder, you should be able to get back to that file.

If something came from a document or another context, that provenance should not disappear just because you made it convenient to keep nearby.

That seems like a small thing.

I suspect it will matter a lot once people actually use it.

The desktop should help without becoming your manager

This is also where some of the local-first research I have been doing starts to connect with the rest of Ceylon.

I grew up using computers that worked because the computer was sitting in front of you.

The C64 did not become confused because the Internet was down.

The Amiga did not ask a remote service whether you still had permission to open your own document.

A desktop computer was a place.

Your files were there.

Your software was there.

Your work was there.

You could navigate it without carrying a phone around as an external organ.

There is quite a bit about modern computing I do not want to throw away.

Networking is useful.

Synchronization is useful.

Remote collaboration is useful.

Cloud services can be useful.

But I want Ceylon's default assumption to be:

your computer is useful on its own.

Network services should extend the machine.

They should not be what grants the machine permission to exist.

That is the direction behind the local-first work.

Not "never use a server."

Not "pretend the Internet was a mistake."

Just restore the local computer as the authoritative place where the user's work can actually happen.

Local-first also fits the ownership philosophy

That idea meshes with another Ceylon principle I have been getting increasingly stubborn about:

You buy it, you own it.

If you buy a machine, it is your machine.

If you legitimately buy a copy of software, your ability to keep using that copy should not depend forever on whether some company still feels like operating a licensing server.

If a vendor disappears, your computer should not wake up one morning and decide your purchase has become historical trivia.

There are obviously details to work out around licensing, updates, services, intellectual property, and network-connected features.

But the principle itself is not especially complicated.

The computer should work for its owner.

That seems like something personal computing used to understand almost automatically.

Maybe we can remember how.

This is not all going into Alpha tomorrow

One important clarification:

the local-first research is not an excuse to keep adding things to the A1 Alpha scope.

I finally got that scope under control yesterday.

I would like to keep it that way for at least 48 hours.

The local-first work is being treated as a longer-term architectural direction.

Where it affects foundational decisions now, I want to avoid painting ourselves into the wrong corner.

But I am not stopping Alpha so we can invent the ultimate distributed personal-computing architecture first.

That would be exactly the kind of thing I am trying to stop doing.

Workpad is much closer to the immediate desktop work because it is a bounded NuGUI facility, and its specification work is now in good shape.

The larger local-first model can develop behind the release line until it has earned its way forward.

Look at that.

I may actually be learning scope control.

By the end of the day, the project weighed less

Literally, in this case.

We reclaimed just under 300 GiB.

The canonical source remained intact.

The active development state is cleaner.

Old workspaces were reconciled instead of blindly discarded.

The NuGUI research is better organized.

Workpad has moved from "interesting desktop thought" toward a real specified facility.

And the local-first work has a clearer principle underneath it:

the computer should remain useful, understandable, and owned by the person sitting in front of it.

That is not a bad result for a day that started with disk usage.

Yesterday I failed to take a day off.

Today I apparently reorganized half the project and reconsidered personal computing.

I may need somebody else to define "rest" for me.

Project Ceylon Development Log — September 26, 2026: Remember That Day Off I Was Going to Take?

Mike — Sat, 26 Sep 2026 12:00:00 GMT

Remember yesterday when I said I was probably going to take a day or two off?

Yeah.

About that.

I did not take the day off.

Instead, I went looking at Ceylon's display architecture and discovered that one of the project's oldest visible milestones was both completely real and not quite what we thought it was.

Which is a very Project Ceylon way to spend a Saturday.

The short version is this:

First Light was real. NuGUI really did put graphical output on the screen.

But the live path that produced those pixels did not travel through Nu-Iris the way the architecture said it eventually should.

We had graphics.

We had the screenshot.

We had a working visible result.

What we did not yet have was proof that Nu-Iris itself was actually the presentation authority for that result.

That distinction turned out to matter a lot.

First Light still counts

I want to start there, because it would be easy to overcorrect this story.

Ceylon's First Light milestone was not fake.

Pixels appeared on screen through Ceylon code running in the QEMU machine.

NuGUI produced visible graphical output.

That happened.

What changed today is our understanding of how those pixels got there.

The live path was effectively:

NuGUI → shared display memory → notification → PCI/display service → Bochs framebuffer

The standalone Nu-Iris service and its intended onboard presentation path were being bypassed.

So the mistake was not:

"We thought we had graphics, but actually we didn't."

The mistake was:

"We treated visible graphics as stronger evidence about the architecture than it really was."

Those are very different problems.

One is embarrassing.

The other is useful.

This one is useful.

A screenshot can prove less than you think

This may sound like nitpicking.

After all, if the pixels showed up, who cares which service touched the framebuffer?

I care.

Because Nu-Iris is supposed to become Ceylon's display and presentation subsystem.

That means it eventually needs to own things such as:

presentation authority
buffer ownership
frame publication
backpressure
stale-frame handling
pacing
damage tracking
software-rendering presentation
future accelerated presentation
multiple output providers
media-oriented surfaces
failure and restart behavior

If NuGUI can quietly bypass all of that and write through a lower-level path, then Nu-Iris can look complete while the actual desktop is not using it.

That is exactly the kind of architectural drift I have been trying to prevent elsewhere in the system.

So once we found it, the answer was not:

"Well, the picture appeared, so close enough."

The answer was:

Stop. Figure out what is actually live. Document it. Then fix the architecture deliberately.

The current display path is very old-school

The audit also showed just how primitive the current Bochs presentation path still is.

And I mean that affectionately.

Sort of.

The current path copies a full framebuffer using straightforward CPU writes.

At 1024×768 with 32-bit pixels, that is 3,145,728 bytes for a full frame.

There is no sophisticated damage system avoiding unnecessary work.

No page flipping.

No DMA presentation path.

No SIMD-optimized copy path.

No modern zero-copy surface handoff.

No clever hardware acceleration hiding underneath it.

It is basically:

Here are the pixels. Move the pixels.

And you know what?

For First Light, that was fine.

The problem is not that the early implementation was simple.

The problem would be pretending that the early implementation is the architecture we want to carry forward.

It isn't.

So Nu-Iris just became its own modernization project

This is one of those moments where fixing one discovery turns into a new development tranche.

The immediate job is not "make Iris faster."

The immediate job is more basic:

make the live desktop actually use Nu-Iris correctly.

That work is now being treated separately from the larger modernization effort.

The first corrective stages are about fundamentals:

establish real buffer identity and ownership;
make publication explicit;
prevent stale generations from being accepted;
introduce bounded backpressure;
make the presentation relationship trustworthy;
then route live NuGUI presentation through Nu-Iris instead of around it.

Only after that foundation is proven does it make sense to start piling performance work on top.

Because optimizing the wrong path very efficiently is still the wrong path.

And yes, there is a much bigger Iris list now

Once we started looking seriously at where Nu-Iris eventually needs to go, the list got large quickly.

Some of the things now on the research and modernization horizon include:

damage-aware presentation;
stale-frame suppression;
reusable buffers;
frame pacing and presentation feedback;
faster CPU copy and composition paths;
tiled composition;
multicore rendering support;
SIMD where it actually helps;
direct scanout where appropriate;
zero-copy or reduced-copy surfaces;
high-rate 1080p qualification;
media-friendly pixel formats such as YUV;
multiple outputs;
restart-safe presentation;
measurable latency and throughput;
future hardware-accelerated providers.

That does not mean all of that suddenly became an A1 Alpha requirement.

It means the architecture now has a clearer road from:

"I can put pixels on a screen"

to:

"I have a display subsystem I can build a workstation on."

Those are not the same milestone.

I know that much more viscerally now than I did a few weeks ago.

The first corrective work is already paying off

The good news is that this was not just an afternoon spent writing a depressing report.

We started correcting the foundation.

The current integration work has already established several things that were previously too implicit:

real buffer identity,

clear ownership,

immutable publication through trusted state,

bounded two-buffer backpressure,

and protection against stale generations being accepted as current.

That is exactly the kind of boring infrastructure that makes later optimization possible without turning the display stack into a collection of timing accidents.

There is still an important next step:

the live NuGUI path itself has to be routed through the Iris service.

Until that happens, I am not calling the end-to-end architecture finished.

First Light remains First Light.

But the next light needs to be honest about the path that produced it.

Meanwhile, I started thinking about the machine this eventually runs on

Because apparently discovering one architectural problem was not enough for the day, I also spent time looking farther ahead at Ceylon's eventual certified hardware.

Not because A1 Alpha suddenly moved to bare metal.

It hasn't.

A1 remains QEMU-first.

But the whole point of the A-series is eventually to reach a stable enough software environment that the B-series can carry it onto known physical hardware.

And that raises a practical question:

What kind of computer should Ceylon actually be sold on?

Not a laboratory controller.

Not an exotic industrial board that costs three times as much because somebody promises to sell the exact same model for ten years.

A normal, reproducible PC.

Something serviceable.

Something expandable.

Something where replacement parts do not require an archaeological expedition.

The current direction is toward ordinary commercial PC hardware with a controlled bill of materials rather than weird custom hardware for the sake of being different.

One candidate baseline we looked at uses a commercial ASUS CSM motherboard with a Core i5-12500-class processor and 32 GB of DDR4.

Nothing exotic.

That is intentional.

I want the storage to be accessible

One requirement I care about more than I expected is physical serviceability.

If somebody buys a Ceylon machine someday, I do not want routine storage replacement to mean disassembling half the computer.

So the current hardware thinking includes front-accessible storage.

The idea is straightforward:

system storage inside,

additional independent drives accessible from the front,

and no requirement to turn the thing into a RAID appliance.

If a user wants another drive, replaceable storage, project media, scratch space, backups, whatever — I want that to be easy.

Likewise, users should be able to install their own NVMe drives or add-in hardware.

Certified hardware means:

this is the configuration we have qualified and will stand behind.

It should not mean:

the case is sacred and thou shalt not touch it.

If you install unsupported hardware, that hardware is obviously outside the certified configuration.

But it is still your computer.

That distinction matters to me.

And the machine should remember what changed

That hardware discussion led into another idea I like quite a bit.

Ceylon's System Information utility should not merely tell you what hardware is installed right now.

The operating system should maintain a protected history of meaningful hardware changes over the life of the machine.

Shipped with this memory.

DIMM replaced on this date.

Original NVMe removed.

New drive installed.

PCIe card added.

Firmware changed.

Network device replaced.

And so on.

Not because I want to spy on somebody's upgrades.

Because if a machine comes back for support two years later, "this is not the hardware configuration we shipped" is useful information.

The important part is that ordinary applications should not be able to rewrite that history.

A privileged service should own it.

The user-facing System Information application gets a controlled read-only view.

Support tooling can get the deeper diagnostic view when appropriate.

Again, simple idea on the surface.

Much more useful once you think about supporting real machines for years instead of demoing one on a workbench.

Today was really about correcting the story

There is a pattern developing in Ceylon that I am starting to appreciate.

The project gets something working.

Then we go back and ask what "working" actually proved.

Sometimes the answer is exactly what we expected.

Sometimes it isn't.

First Light proved that Ceylon could produce visible graphical output.

It did not prove that the final Nu-Iris architecture was already carrying those pixels.

Now we know that.

And because we know it before Alpha, we have the opportunity to fix the architecture instead of documenting the shortcut as if it were intentional.

That is progress.

Not the glamorous kind.

There is no new desktop screenshot tonight.

There is no airplane to crash yet.

There is no synthesizer riff to play.

But the display stack is becoming more honest about what it is, what it isn't, and what still has to happen.

And the future hardware is starting to look less like an abstract "bare-metal target" and more like a computer I could actually put on somebody's desk and expect them to live with.

So, no.

I did not take the day off.

Apparently I am very bad at that.

Maybe tomorrow.

No promises.

Project Ceylon Development Log — September 25, 2026: Okay, So What Exactly Is A1 Alpha?

Mike — Fri, 25 Sep 2026 12:00:00 GMT

One of the problems with building an operating system in public is that eventually somebody asks a perfectly reasonable question:

"So what exactly is in the first release?"

And for a while, my answer to that was basically:

"Well... a lot of things."

Which is not a release plan.

It is a shopping list with optimism attached.

Over the last couple of days, Ceylon has finally reached the point where I needed to stop treating A1 Alpha as a vague future event and define what it actually means.

Not the final A1 release.

Not the later commercial hardware version.

Not every application I eventually want.

The first proof-of-life release somebody besides me will be able to boot inside QEMU, use for a while, complain about, break in unexpected ways, and hopefully understand well enough to tell me what is wrong with it.

That turned into a much bigger conversation than I expected.

Because once you define the first release honestly, you have to answer two questions:

What absolutely has to be there?
What are we willing to admit is not there yet?

Today was mostly about answering those.

Alpha is not the finish line

The first thing I needed to get straight in my own head was what the word Alpha means for Ceylon.

A1 Alpha is not a miniature version of the final operating system.

It is a checkpoint inside A1.

The sequence is more like this:

A1 Alpha → feedback → fixes → continue A1 → freeze the intended A1 environment → then begin B1 hardware work

That distinction matters.

The A-series is the virtual/reference-machine line.

The B-series is where Ceylon eventually moves onto certified physical hardware.

So I do not need to drag every future B-series requirement backward into the first Alpha just because I know it will matter someday.

That would be a fantastic way to make sure Alpha never ships.

The Alpha has one job:

prove that Ceylon has become a usable computer instead of a collection of qualified subsystems.

That is the line I am trying to cross.

Authentication almost became one of those things that blocked everything

Authentication is a good example of where defining Alpha helped.

Ceylon absolutely needs real authentication.

The full A1 release will have it.

But does the first Alpha need to boot into a login screen and refuse to do anything until the entire authentication path is production-complete?

After looking at what Alpha is actually for, the answer is no.

The Alpha will boot under a defined local alpha principal.

That does not mean "accept anything somebody types into a password box."

It means authentication is not required to prove the desktop, applications, storage, audio, development environment and interaction model.

The full A1 still requires the real authentication system.

Alpha does not.

That one decision removes a major dependency from the proof-of-life path without weakening the architecture we are actually building.

There is a difference between postponing a feature and pretending it does not matter.

This is the first one.

So what actually ships?

This was the useful part.

Instead of saying "desktop and some apps," I finally locked the initial Alpha application list.

The basic system needs:

NuGUI
NuDOS
Ceylon Terminal
File Manager
basic Settings/System Information
a Welcome/Help application

That gives somebody an actual machine to navigate.

Then the development side:

NuBASIC Level 1
a simple source/text editor

I have said before that NuBASIC matters to me.

I grew up in an era where getting a computer home usually meant you also got a way to make the computer do something yourself.

I want some of that back.

Not because BASIC is the only language Ceylon should ever support.

Obviously it isn't.

But because a first-time user should be able to boot the Alpha, open the programming environment, type something, run it and immediately understand that this is a machine you can create with.

Then multimedia:

Image Viewer
Video Player

And audio:

basic Synth
basic Sequencer
basic DAW

Not "basic" in the sense of fake buttons over a demo routine.

Basic in the sense of a deliberately bounded first version that establishes the real architecture underneath it.

Then there are two different game/demo workloads.

The first is a Ceylon Asteroids-style demo.

That one is intentionally simple.

It is there to prove that a native Ceylon application can take input, update game state, render frames, produce sound, keep score, and remain responsive without needing the much larger machinery behind the showcase game.

It should be something I can launch quickly and use as a visual sanity check:

Does input work?

Does timing work?

Does software rendering work?

Does audio work?

Can the machine run a basic native arcade workload without doing anything weird?

Then there is the game.

Which, naturally, stopped being a tiny game almost immediately.

First, the simple game: an Asteroids-style Ceylon demo

Before Juggernaut, Alpha needs something smaller and more immediate.

The Asteroids-style demo fills that role.

The point is not to recreate Atari's game one-for-one.

The point is to use a familiar arcade structure as a compact Ceylon proof.

A ship.

Objects moving through a playfield.

Shots.

Collisions.

Score.

Sound.

Responsive controls.

Nothing about that should require a huge engine or complicated asset pipeline.

That is exactly why it is useful.

If the Asteroids-style demo starts behaving badly, I can investigate a relatively small stack without wondering whether a sophisticated AI system, 3D renderer, network path, replay system, or large asset set is getting in the way.

It is the quick confidence test.

Juggernaut is something else entirely.

Apparently Ceylon needed a World War I dogfight

I knew A1 also needed a more demanding game.

Not because Ceylon is a game console.

Because a game is one of the best ways I can think of to force a general-purpose operating system to prove a bunch of things at once.

Timing.

Input.

Audio.

Rendering.

Storage.

Networking.

Scheduling.

Application lifecycle.

Deterministic replay.

Sustained load.

And whether the machine is still fun to use while all of that is happening.

The working title is Juggernaut.

The current V1 concept is a WWI-inspired airborne dogfighting game.

Two aircraft.

You start in the air.

No taxiing around an airfield.

No pre-flight checklist.

No campaign logistics.

No pretending this is a military flight simulator.

Just:

Two aircraft enter the fight. One leaves.

The two initial modes are:

human versus computer
human versus network human

The difficulty settings are currently named:

WALK
RUN
OMG!

If you have been following Ceylon long enough, those names probably make sense.

If not, don't worry about it.

They will.

The important thing is that the difficulty system is not supposed to cheat.

OMG! does not get magic bullets, secret extra health or impossible physics.

It gets a better pilot.

Faster reactions.

Better energy management.

Better pursuit.

Better tactical choices.

If it beats you, I want the answer to be:

"That thing flew better than I did."

Not:

"The computer changed the rules."

The game is also a benchmark wearing goggles

There is another reason Juggernaut belongs in A1.

Ceylon's graphics path is CPU-first.

The game is expected to render through Nu-Iris in software.

The aspirational performance target is 1920×1080 at 60 frames per second on an i5-8500-class six-core CPU with 16 GiB of memory and no GPU acceleration helping the game.

If the evidence eventually tells us that 1280×720 at 60 is the honest target, then that is what we will ship.

But I want us to earn that conclusion with measurements instead of assuming software rendering has to be slow because everybody stopped caring about it twenty years ago.

That means the renderer is being designed around the things you would expect if you were serious about CPU graphics:

multicore tiling,

cache-aware data layouts,

SIMD,

bounded worker queues,

minimized allocation,

culling,

reduced overdraw,

careful buffer handling,

and real instrumentation so we know where the frame time actually went.

The same game core also needs to support AI-versus-AI operation, deterministic replay and a hidden zero-player soak mode.

So the game can entertain somebody one minute and spend the night trying to break the operating system the next.

That seems appropriately Ceylon.

And then the synthesizer got serious

The audio side had a similar moment today.

The A1 Synth is now specified much more concretely.

At its center, it is intentionally understandable:

two oscillators
white noise
resonant low-pass filter
amplifier envelope
filter envelope
LFO
modulation
mono/poly operation
glide
velocity
presets
mono or stereo output

That is enough to make a real instrument.

But the important architectural decision is what sits around it.

The Alpha synth is also intended to be the first visible proof of Ceylon's plugin-host architecture.

The current design includes a Ceylon-native VST3 instrument path and four effect insert slots.

Before somebody reads that as "Ceylon runs every Windows VST now," no.

That is not what I am saying.

The important part is the architecture.

Third-party plugin code should not get to wander into the audio engine and take the whole thing down because somebody dereferenced something stupid during a callback.

Plugins run in isolated workers.

The real-time audio path remains bounded.

The host manages lifecycle and state.

Lyra owns routing, scheduling and deadline accounting.

Aria owns the native instruments.

And the same infrastructure is intended to serve the Synth, Sequencer and DAW instead of building three separate audio engines because that was expedient at the time.

That is one of those decisions that does not make the first screenshot more exciting.

It does make the second year of development considerably less miserable.

Applications should feel simple again

Another piece that finally became concrete is the application packaging model.

I miss the era when "installing" an application often meant:

copy the application somewhere.

And uninstalling it meant:

delete it.

Modern systems gained a lot of capability, but they also accumulated a remarkable amount of ceremony around putting a program on a computer.

I do not want Ceylon to recreate the worst parts of that.

So the current application model is built around self-contained bundles.

An application owns its executable, assets, private runtime, libraries and other private dependencies.

If two programs need incompatible versions of the same private library, fine.

Each gets its own.

Applications do not install random pieces into Ceylon itself.

They do not patch system libraries.

They do not replace drivers.

They do not decide the OS needs an update and quietly perform one.

Vendors own their applications.

Ceylon owns Ceylon.

That boundary is going to be enforced by authority, not by a line in the developer documentation asking people to please behave.

The bundles are also intended to be location-independent.

An application might live in the Applications drawer.

It might live on removable media.

It might use a hybrid arrangement where the program stays on one device and authorized user data lives somewhere else.

In the normal case:

copy bundle = install

delete bundle = uninstall

That feels like the right kind of old idea to bring forward.

Developers should not have to move into Ceylon to develop for Ceylon

This decision also settled something else I care about.

I do not want outside developers to have to abandon the tools they already know just to target Ceylon.

Portable application logic should be buildable and testable substantially outside the running OS.

Then the Ceylon adapter connects it to NuGUI, storage, audio, networking, Kirk, input and the rest of the platform.

The host-side version is a development harness.

Ceylon remains the actual target.

That means a developer should eventually be able to work in a loop that feels something like:

build → package → run in Ceylon → debug → rebuild → replace bundle → run again

without writing an installer,

without modifying the system image,

and without turning their private dependencies into everybody else's problem.

If I want people to write software for a new operating system, making their lives unnecessarily difficult seems like a poor recruiting strategy.

The Alpha finally has a shape

That is probably the most important thing that happened today.

A1 Alpha is no longer just:

"the point where enough stuff works that I think somebody else should try it."

It has a shape.

It boots into a real desktop.

It has a command environment.

It has a terminal.

It has files.

It has system information.

It has help.

It has BASIC.

It has an editor.

It can show an image.

It can play video.

It can make sound.

It has a synthesizer.

It has a sequencer.

It has the beginnings of a DAW.

It has a simple Asteroids-style native arcade demo that can act as a quick visual proof that the core interactive stack is alive.

And it has a ridiculous little biplane game whose hidden second job is trying to expose every timing and performance problem I failed to notice.

There is also a feedback utility planned for the Alpha.

That one is intentionally straightforward:

write what happened,

optionally include the relevant logs,

send it back.

Because once other people start touching this thing, the most valuable feature in the operating system may briefly become:

"Tell Mike exactly how you broke it."

What still has to happen

Defining the contents does not magically make them exist.

There is still a lot of work between here and release.

NuGUI still needs to become the actual usable desktop environment.

The application/runtime integration has to close.

Storage has to become ordinary user-visible persistence instead of just a qualified block path.

The terminal and file manager have to be finished.

NuBASIC has to move from specification into the complete Level 1 implementation.

The audio framework has to move from contracts and pieces into working applications.

The Asteroids-style demo has to become a clean, dependable native proof-of-life workload.

Juggernaut has to go from a very detailed specification to an actual airplane somebody can crash into a tree.

The image and video paths have to become applications.

The Alpha packaging and feedback flow have to work.

And all of it has to be integrated into one reproducible QEMU machine without breaking the things underneath it.

Which, based on the last several weeks, will probably be the part where Ceylon teaches me several entirely new varieties of humility.

But this feels different

There is a psychological difference between a project with an endless list of things it could someday contain and a project with a defined first release.

Yesterday the question was:

"What else should Ceylon eventually do?"

Today the much more useful question is:

"Does this belong before Alpha or after Alpha?"

That question is going to save us a lot of time.

There are already things I want that are now firmly on the other side of that line.

Good.

They can wait.

A1 Alpha does not have to prove everything Ceylon may become.

It has to prove that Ceylon is something.

A coherent computer.

A system somebody can sit down in front of, explore, create something with, play with, break, restart, and begin to understand.

That is enough for the first public checkpoint.

And, frankly, after the pace of the last couple of weeks, I think I am probably going to take a day or two off.

The code will still be broken when I get back.

I am reasonably confident of that.

Project Ceylon Development Log — September 24, 2026: 55 Out of 55 Passed. Then We Found the Test Was Wrong.

Mike — Thu, 24 Sep 2026 12:00:00 GMT

Yesterday I wrote that "worked once" is no longer one of our engineering states.

Apparently Ceylon took that personally.

Today we got NuGUI through 55 out of 55 requirements.

The compositor was producing reproducible pixels.

Client crash containment worked.

Bad handles were rejected.

The negative tests passed.

The independent review looked good.

For a little while, it looked like we had reached the point where the new NuGUI work could be promoted into the main Ceylon line.

Then we did the reconciliation work.

And storage disappeared.

Not "a disk test was flaky."

Not "one read failed."

Both drives were being rejected.

The really irritating part?

One of the smoke tests had already told us storage passed.

It was wrong.

That, more than anything else, is what today's work was about.

First, the good news: NuGUI really did make a lot of progress

I do not want the later failure to erase what actually worked.

NuGUI's current D2 work is a substantial step forward.

The compositor is no longer just an architectural sketch with a few pieces hanging off it.

We now have bounded per-client resources.

We have shared ring behavior with explicit ordering.

We have damage-carrying presentation.

We have real client-fault containment.

We have stale-handle rejection.

We have visible target output.

And we have been deliberately testing what happens when applications misbehave instead of assuming polite applications forever.

One of today's more satisfying tests involved deliberately crashing a client with a real invalid-instruction fault.

Not once.

Three times.

The compositor survived.

Another client kept running.

The stale client handles were rejected afterward.

That is exactly what I want from the architecture.

If one application falls over, the desktop should not throw itself down the stairs in sympathy.

The test suite also reached 55/55 requirements for the D2 scope.

That is a real milestone.

But it turns out there is a difference between:

"This component passed its requirements."

and:

"This entire set of changes is safe to promote into the operating system."

Today was mostly about that difference.

Promotion is where things got interesting

The D2 work is not a tiny patch.

It spans 29 commits and more than a hundred files.

Along the way, pieces of the low-level development environment changed too: SDK pieces, kernel-facing dependencies, Rust support, launch configuration and some older diagnostic paths.

That does not automatically make the work wrong.

But it does mean promotion cannot be treated like copying one compositor binary into a directory and calling it done.

The question became:

What exactly are we promoting?

And more importantly:

What assumptions changed underneath the part we were actually testing?

That is where storage raised its hand.

The smoke test said storage passed

During reconciliation, both storage devices were rejected.

That should have been impossible according to the smoke result.

So we did what you do when the machine and the test disagree:

we assumed the test was guilty until proven innocent.

It was.

The smoke check was not actually proving that usable volumes had been published.

It was counting the presence of expected-looking log activity.

Those are not the same thing.

A system can print a line that looks encouraging while still failing the actual thing the line was supposed to represent.

That sounds painfully obvious when written down.

It is also exactly the kind of mistake automated testing can hide beautifully because the output is green and everybody wants to move on.

The corrected question is not:

Did storage print the right message?

It is:

Did the expected volumes actually appear and remain usable?

That is what the test should have been asking in the first place.

So today we got one of those wonderful development milestones that does not look good on a feature list:

we found a test that was capable of lying to us.

Honestly, I would rather find that now than after somebody else downloads A1.

Why this matters more than one storage bug

This is not really a story about storage.

It is a story about qualification.

As Ceylon gets larger, it is becoming possible for one subsystem to be completely correct inside its own test boundary while the larger integrated machine is still wrong.

NuGUI can pass its compositor tests.

Storage can have passed yesterday.

Networking can work.

USB can work.

And a change in the platform underneath all of them can still create a machine that is not the same machine we thought we qualified.

That is why I keep coming back to the complete QEMU configuration as an artifact.

The kernel matters.

The SDK matters.

The Rust bindings matter.

The loader matters.

The firmware matters.

The launch command matters.

The virtual devices matter.

The order of those devices matters.

Apparently, even a test script's definition of the word "pass" matters.

Operating systems are very good at punishing vague nouns.

So we stopped promotion

This is the part where it would have been very easy to say:

"NuGUI passed 55/55. Ship it."

We did not.

The D2 work remains valuable.

The qualification evidence remains valuable.

But promotion into the canonical Ceylon tree is being held until the platform ancestry and storage behavior are reconciled properly.

That also means preserving the exact artifacts that produced the qualified results.

If a test result depends on a particular build environment, kernel revision, SDK revision or launcher, then that environment is part of the evidence.

I do not want a future version of me staring at a directory six months from now wondering which mystery toolchain created the binary that everybody once agreed was good.

Future Mike already has enough reasons to be irritated with Current Mike.

No need to manufacture more.

The weirdly good news: the Rust side may be cleaner than expected

While sorting out the platform mismatch, we ran another experiment.

The concern was that different parts of Ceylon might have quietly become dependent on incompatible Rust/platform combinations.

If that were true, cleaning up the toolchain could turn into a major source-code migration.

So we tested the obvious question:

Can the applicable Ceylon components build against one homogeneous platform tuple?

Then we tried the other candidate tuple.

The result was encouraging.

All 30 applicable MicroKit protection domains and 40 host/no_std libraries built on either single tuple with zero source changes.

That does not yet prove that either tuple is the final answer.

Build success is not runtime qualification.

We have learned that lesson enough times now.

But it strongly suggests that the source tree itself is not hopelessly split between two incompatible worlds.

The next step is boot and runtime qualification, including proving that real volumes publish, not merely that storage says something pleasant in the log.

Independent adversarial review is also still part of the closure work.

So the result tonight is:

promising, but not promoted.

There is a phrase I seem to be using a lot lately.

This is what the project looks like now

One thing I have noticed over the last couple of weeks is that the nature of the failures is changing.

Early Ceylon failures were things like:

"Nothing happened."

"Why are there no pixels?"

"Why did the controller never start?"

"Why is this pointer zero?"

Those are hard problems, but they are usually fairly local.

The newer failures are more annoying because the individual components often look healthy.

The compositor works.

The storage driver works.

The build works.

The machine boots.

The test is green.

And then some assumption between those things turns out not to mean what we thought it meant.

That is a sign of a larger system.

Not necessarily a mature one yet.

But definitely a larger one.

The job now is increasingly about making sure the pieces agree with each other.

And because apparently we needed another project...

While the platform work was being sorted out, I also spent some time on the A1 audio side.

The basic synth requirements are becoming more concrete.

One decision that came out of that work is that I want the A1 synth architecture to be able to support VST3-style plugins rather than building a closed little island that becomes obsolete the moment somebody wants to extend it.

That is not the same thing as saying every random desktop plugin will magically run on Ceylon tomorrow.

There is a lot of architecture between those two statements.

The current direction is to isolate third-party plugin execution, keep real-time audio on bounded low-latency paths, and make plugin failure somebody else's problem instead of the audio engine's last words.

There will be more to say about that later.

Tonight I am mostly mentioning it because apparently, while debugging an operating system, I needed something relaxing to do.

So naturally I started designing plugin isolation.

Where we ended the night

NuGUI D2 has real qualification behind it.

The compositor work is substantially stronger than it was yesterday.

Client crashes can be contained.

Visible pixels are being produced.

The D2 requirement set reached 55/55.

Then promotion testing exposed a storage regression.

That exposed a weak smoke test.

That exposed a platform-ancestry question.

And that, in turn, led to an experiment showing that the Rust source may be considerably easier to normalize than we feared.

That is not a bad day's work.

It is not the kind of progress that produces a dramatic screenshot.

But it does make the eventual screenshot mean more.

Because when I finally show a Ceylon desktop and say:

This works.

I do not want that sentence to mean:

"The log looked about right."

I want it to mean we actually checked.

And, increasingly, we're getting better at checking the checker.

Project Ceylon Development Log — September 23, 2026: So, How Much of This Thing Actually Exists?

Mike — Wed, 23 Sep 2026 12:00:00 GMT

A little over two weeks ago, I started this journal with a fairly ridiculous question:

What would the Amiga have turned into if development had never stopped?

Not what would an Amiga emulator look like.

Not how do we recreate an A500 with modern parts.

What would the idea have grown into?

At that point I had a lot of research, a failed first attempt called Project Nu-Day, some working pieces, a pile of architectural notes, and considerably more confidence than was probably justified.

Since then, Ceylon has become large enough that even I occasionally have to stop and ask:

Okay, what the hell have we actually built?

So tonight I am not going to bury y'all in another fourteen pages of transaction IDs, PCI BAR addresses and qualification-state abbreviations.

We've done plenty of that lately.

Instead, I want to zoom out.

Where did this thing start?

What actually exists today?

And what still has to happen before I can put the first A1 proof-of-life image in somebody else's hands and say:

Here. Break it.

This started as a media workstation

The original project was not an operating system.

That part is important.

Project Nu-Day was supposed to be a modern media workstation inspired by some of the things I loved about the Amiga, Video Toaster and DigiPaint.

Graphics.

Audio.

Video.

Responsiveness.

Specialized hardware actually doing specialized work.

I wanted something that felt like a machine built to create things instead of a generic computer that happened to have creative software installed on it.

Then I made the mistake of getting pieces of it working.

That is when the scope problem became obvious.

A serious media workstation needs storage.

It needs networking.

It needs applications.

It needs input.

It needs authentication.

It needs device management.

It needs crash recovery.

It needs a filesystem.

It needs some way for applications and services to find each other.

It needs graphics infrastructure.

It needs audio infrastructure.

It needs an actual desktop.

At some point I had to admit that I wasn't building a workstation anymore.

I was building the computer underneath the workstation.

That is where Project Ceylon really began.

First decision: build the machine in QEMU

One of the better decisions I made early was not trying to drag all of this onto bare metal immediately.

Ceylon A1 is a QEMU-first system.

That lets me define a reference machine and keep asking the same hardware the same questions.

Same chipset.

Same devices.

Same CPU model.

Same memory layout.

Same firmware.

Same PCI topology.

Same launch configuration.

That sounds boring until you spend an evening chasing a bug that turns out to exist because somebody added one virtual audio device and shifted half the PCI resource map.

Ask me how I know.

The virtual machine itself is now treated as part of the product being qualified.

The ISO is not the machine.

The whole configuration is the machine.

That lesson cost enough hours that I don't expect to forget it.

The foundation is real now

The low-level Ceylon platform has gone through a fairly major upgrade since the first journal entries.

That migration is now behind us.

Ceylon boots on the newer MicroKernel foundation.

Multiprocessor support works.

The IOMMU works.

The system controller starts.

PCI enumeration works.

The USB controller initializes.

Storage works.

Networking works.

The display path works.

The random-number service works.

And we have been repeatedly rebuilding and booting the system instead of treating one successful run as proof that the problem is solved.

That last part has become kind of a theme around here.

"Worked once" is no longer one of our engineering states.

We have real storage

Ceylon has functioning block-device paths on the A1 reference machine.

We can identify the devices.

We can publish volumes.

We can read.

We can write.

We can flush.

We have also already managed to break storage in several ways that turned out not to be storage bugs.

One was a changed PCI resource map.

Another was a missing virtual-device serial number.

Another was booting the wrong validation artifact.

Operating-system development is apparently a wonderful way to discover how many different things can impersonate a disk problem.

The remaining A1 work is not "can bytes reach a block device?"

It is building the user-facing persistence path on top of that foundation and proving that something an application saves can be recovered after reboot.

That is a much more interesting milestone.

Networking exists too

Ceylon can currently move network traffic on the QEMU reference system.

Transmit works.

Receive works.

ARP works.

Basic IPv4 connectivity exists.

We have been doing a larger architecture pass this week because I do not want to complete IPv4 in a way that makes IPv6 a miserable retrofit later.

The networking design is therefore being pushed toward a real dual-stack model from the start.

That includes interfaces that can own multiple addresses, routes and prefixes, neighbor state, address lifetimes, source selection and the other things that become awkward if the entire network layer secretly assumes an IPv4 address is just a 32-bit integer attached to one card.

There is still plenty to build here.

But "Ceylon has networking" is no longer theoretical.

USB input is becoming an actual input system

Keyboard input has been working through the virtual USB hardware for a while.

Not a shortcut.

Not a key magically inserted into the GUI.

QEMU USB device, xHCI controller, HID handling, semantic event.

Pointer work followed.

That has turned into some of the current NuGUI qualification work.

We recently found a particularly annoying bug where the GUI consumer could read events but faulted when advancing the shared ring-buffer tail because that mapping was protected incorrectly.

That one common mistake could lose both pointer and keyboard events.

The mapping has been corrected in the validation work.

Pointer and keyboard route records are now passing again.

The remaining work is closing the complete target interaction path and making sure the final machine definition, boot artifacts and input behavior all agree.

That is considerably less glamorous than drawing a window.

It is also the difference between a demo GUI and an input system I can actually trust.

And yes, there is a GUI

NuGUI is finally moving from architecture diagrams toward something that will eventually resemble a desktop.

The design is intentionally not "let's clone Windows."

Ceylon owns the desktop and windowing model.

Applications do not own the framebuffer.

The display service retains presentation authority.

Input reaches the desktop as bounded semantic events instead of every application poking at hardware.

CPU rendering remains a first-class path.

That last one matters to me.

Ceylon will eventually benefit tremendously from accelerated graphics, but I do not want "no supported GPU" to mean "congratulations, your workstation is now a serial console."

The current NuGUI work is in the compositor/input/window-management stage.

This is one of the most visible things between the current system and A1.

Once the desktop begins appearing, I suspect Ceylon is going to suddenly look much farther along than it did the day before.

Operating systems are funny that way.

You can spend weeks building infrastructure nobody can see, then draw three windows and everyone assumes you built the OS over the weekend.

Kirk exists because applications shouldn't live alone

Another major piece that now exists is Kirk.

Kirk is Ceylon's local service and application coordination layer.

The easiest way to explain it is that applications need some sane way to discover each other and cooperate without hard-coding everybody else's location and implementation.

Kirk handles the control-plane side of that.

Who are you?

What capability do you provide?

What generation are you?

Can I attach to you?

Did you restart?

Is the thing I was connected to still the same thing?

Have I been revoked?

It does not try to carry every byte in the system.

Pixels don't go through Kirk.

Audio samples don't go through Kirk.

Large data transfers get appropriate data paths.

Kirk coordinates the relationship.

The implementation exists and has already survived substantial stress testing, including a 100,000-operation target run.

The long-duration autonomous qualification work is the remaining gate before I treat it as fully qualified infrastructure for A1.

That is one of those components users may never see directly.

If it works correctly, they shouldn't have to.

Device management is getting a grown-up administrator

This week also introduced Clarise.

Clarise is the working name for the service intended to administer Plug-and-Play hardware, including PCI/PCIe and USB devices.

Originally that sounded like:

"detect device, load driver."

That lasted about five minutes.

Real device management has to deal with devices disappearing halfway through configuration, services restarting, resource assignments, generations changing, composite USB devices and multiple drivers potentially trying to claim the same thing.

So Clarise is being designed around transactions.

Either a device operation commits correctly or it doesn't.

Recent shadow testing ran 256,000 transaction operations through the model with eleven different crash-injection locations.

We saw no state corruption, provisional-resource leaks, duplicate commit effects, stale transactions being incorrectly accepted, partial interface binds or overlapping claims.

That's the good part.

The qualification still did not close.

We successfully triggered the real supervisor restart we wanted to test, but the replacement Clarise instance did not receive the required post-restart event.

So the reconstruction part of the test could not honestly be claimed.

We stopped.

That is one of the changes in how I am building Ceylon that I am happiest about.

A year ago I probably would have looked at 256,000 successful operations and called the subsystem done.

Now the answer is:

"Nope. The thing we said we would prove at the end didn't happen."

So it stays open.

We have a command-line world too

Ceylon is not going to be a GUI-only operating system.

NuDOS is the command environment, and there is now a much more complete terminal/session architecture behind it.

A terminal turned out to be another one of those things that becomes complicated the moment you stop thinking of it as "a rectangle that prints characters."

The terminal UI is one thing.

The terminal protocol is another.

The session behind it is another.

The process or service on the other end is another.

And a persistent or remotely attached session introduces another layer again.

The basic A1 requirement is simpler than all of the future possibilities:

I want a usable native terminal and NuDOS environment available in the alpha.

That is still on the A1 list.

NuBASIC is coming with A1

This one matters personally.

Ceylon A1 is supposed to ship with a real Level 1 NuBASIC environment.

Not:

PRINT "HELLO"

followed by a blog post claiming BASIC exists.

The language specification has been getting beaten on pretty heavily before implementation because apparently BASIC becomes less "basic" the longer you try to specify all of its behavior precisely.

Procedures.

Call frames.

Errors.

STATIC data.

STOP and CONTINUE.

Stack exhaustion.

Platform bindings.

Deterministic behavior.

The specification work is far enough along that the next challenge is implementation.

So NuBASIC is not done tonight.

But it is also not a vague someday idea.

It is part of the A1 target.

I want somebody downloading this first public image to be able to sit down, open the machine's native programming environment and make the computer do something.

There is something appropriately old-school about that.

Audio is being built as infrastructure, not an app trick

Ceylon also has the foundations of Aria and Lyra, the two major pieces of the native audio path we have been researching and wiring.

The A1 goal here is deliberately modest.

I am not trying to replace Pro Tools in the alpha.

The proof-of-life release needs enough reliable audio infrastructure to play bounded PCM/WAV audio and support the first simple music applications we're building toward.

Longer term, the audio work becomes much more interesting.

For A1, I just need to prove the path correctly.

Logging got more serious after we crashed something

Ceylon already had structured logging when we deliberately crashed a service and discovered that the most interesting fault information was being printed to the debug serial console instead of going into the structured durable log.

That was useful.

Annoying, but useful.

The logging architecture worked for components that actually published structured events.

The supervisor fault path wasn't doing that.

So logging work has shifted from:

"Can we collect log messages?"

to:

"When the system is broken, can we still trust the evidence it leaves behind?"

That qualification is still open.

For an OS intended to isolate and recover services, that matters quite a bit.

So what is left before A1?

This is the part I wanted to get written down tonight.

Because the project has grown enough that "we're working on an operating system" doesn't tell anybody whether we're three days or three years away from something they can boot.

The basic A1 proof-of-life release still needs these pieces brought together:

Finish the current NuGUI compositor, window-management and input qualification work.
Complete the user-facing persistence path so an application can save something, reboot, and retrieve it.
Finish the native terminal/NuDOS path.
Implement the A1 NuBASIC Level 1 environment.
Close Kirk's long-duration qualification.
Finish the production authentication/session path.
Close the remaining logging and recovery evidence.
Finish the bounded A1 audio path.
Complete the required application/runtime integration.
Provide a basic file browser and ordinary desktop file operations.
Launch native applications from the desktop.
View an image.
Play audio.
Run the constrained video proof.
Run at least one real native interactive demonstration instead of a collection of infrastructure tests.
Expose useful system information and diagnostics.
Package the whole thing into a reproducible QEMU release another person can actually boot.

That is still a decent list.

I am not pretending otherwise.

But compare it with where this started.

The question used to be:

Could we build something that carries the good ideas forward?

Now the questions are things like:

Can we recover this transaction after a supervisor restart?

Does the keyboard still work when the pointer queue is under load?

Can the app save a file and get it back after reboot?

Is this exact QEMU machine reproducible on another system?

Those are much better problems to have.

A quick note on AI

AI is part of the Project Ceylon toolchain, but it is not the point of the project.

I use it primarily as a research tool, a governance-management tool, a best-practices helper and a debugger. It also helps keep a project this large moving forward without losing track of architectural decisions, specifications, validation requirements and the reasons behind them.

Some of that work is supported by proprietary tooling I have developed around the project to help detect architectural drift, compare implementation against specifications, verify that delivered behavior matches the stated intent, and keep safety and security requirements visible as the system evolves.

The goal is fairly simple: use the tools available to help build Ceylon correctly, keep the project disciplined, and get it delivered in a reasonable amount of time.

The actual standard for whether something belongs in Ceylon remains the same regardless of how it was produced:

It has to meet the specification, satisfy the architectural intent, survive the required testing, and behave correctly on the target.

This is finally starting to look like a computer

I still don't have the screenshot I really want to show y'all.

The one where Ceylon boots, the desktop comes up, you move the mouse, open the terminal, run NuBASIC, save something, launch a native program, play some audio and realize there is now an actual little computer living inside that QEMU window.

That is the A1 proof-of-life moment I am chasing.

We're not there tonight.

But for the first time, I can look at the remaining list and it mostly consists of joining and finishing systems that already have foundations underneath them.

That is very different from staring at a blank repository and wondering whether any of this is possible.

Project Ceylon started with a stupid question about what the Amiga might have become.

Then it became a media workstation.

Then the media workstation accidentally became an operating system.

Now the operating system is starting to become a computer.

And when that first A1 image finally boots on somebody else's machine, I fully expect them to find something I missed in about fifteen minutes.

Honestly, I'm kind of counting on it.

That's the point.

Project Ceylon Dev Log — September 22, 2026

Tue, 22 Sep 2026 12:00:00 GMT

September 22 was one of those days where a lot of the visible work happened below the surface.

We did not end the day with a shiny new desktop feature or a finished application to show off. Instead, we spent the day tightening several pieces of Ceylon that will determine whether the system can grow into something dependable rather than simply something that boots.

A surprising amount got done.

Building Out the Networking Roadmap

One of the biggest research efforts today was Ceylon's native networking architecture.

Ceylon already has active IPv4 work, including pieces of Ethernet, ARP, ICMP, UDP, DNS and early TCP functionality. The goal is not to throw that work away and start over.

Instead, we began defining what the complete networking system eventually needs to look like.

The target is now much clearer:

Ethernet
  ↓
Full IPv4
  ↓
Full IPv6
  ↓
True IPv4/IPv6 dual-stack operation
  ↓
Modern physical Ethernet hardware

The important part is that IPv6 cannot simply be bolted onto an IPv4-centric design later.

Even while IPv4 is being completed, common components need to understand concepts such as:

multiple addresses per interface
IPv4 and IPv6 address families
address scopes
address lifetimes
routes and prefixes
neighbor state
path MTU information
multicast membership
interface lifecycle
source-address selection

That gives us a common network foundation instead of two unrelated protocol stacks.

We also expanded the hardware side of the design.

The eventual Ceylon network driver architecture is expected to support modern NIC capabilities including DMA/IOMMU isolation, multiple receive and transmit queues, MSI-X interrupts, receive-side scaling, checksum offload, VLAN support, multicast filtering, interrupt moderation, and hardware fault recovery.

VirtIO networking remains extremely useful for development and QEMU testing, but the end goal is a native driver for a modern physical PCIe Ethernet controller.

After an initial gap analysis, the networking reference architecture was expanded and checked again.

The result is now mature enough to serve as the R&D baseline from which the actual implementation specification can be built.

The next networking step is not more theoretical architecture.

It is an inventory of the networking implementation already inside Ceylon so we can classify each component as something to keep, extend, refactor, replace, or retire.

Clarise: Making Plug-and-Play Transactional

Another major focus today was Clarise, the administrator we are designing to eventually manage Plug-and-Play devices, including USB devices.

The problem sounds simple:

Find a device and give it to the right driver.

In a real operating system, it gets complicated quickly.

A device may disappear halfway through configuration. A driver may restart. A resource may have been provisionally assigned but never committed. A USB device may return as a new hardware generation. Composite devices can have multiple interfaces, and two providers must never silently claim overlapping resources.

So Clarise is being built around a transactional model rather than simply performing device operations in sequence.

The I3 work exercised that model heavily.

Today it completed:

256,000 transaction operations
11 crash-injection points
3 reconciliation paths
0 unexpected accepts
0 unexpected rejects
0 state corruption
0 provisional resource leaks
0 duplicate commit side effects
0 duplicate abort side effects
0 stale transactions accepted
0 partial atomic interface binds
0 overlapping interface claims

The transaction machinery itself performed very well.

However, I3 is not closed.

That is intentional.

The remaining requirement was proving that, after a real supervisor-mediated restart, a new Clarise instance could receive its restart event and reconstruct transaction state against the current device, provider and resource generations.

We successfully caused and observed the supervisor restart.

Clarise did not receive the required post-restart event.

That means the reconstruction test could not legitimately continue.

Rather than replacing that missing target evidence with a simulated result, the run stopped.

The status tonight is therefore:

CLARISE_I3_STATUS=NOT_COMPLETE

SUPERVISOR_RESTART_OBSERVED=YES
CLARISE_POST_RESTART_EVENT_RECEIVED=NO

TARGET_TRANSACTION_RECONSTRUCTION=NOT_PROVEN
NEXT_TRANCHE_MAY_BEGIN=NO
AUTHORITY_TRANSFER_AUTHORIZED=NO

This is exactly why we have qualification gates.

The transaction model looks strong, but we have not yet proven the complete target lifecycle.

The next Clarise session will repair the supervisor-mediated restart path so that a new Clarise instance actually starts and receives the required event. Only then will transaction reconstruction and rollback qualification resume.

Also important: Clarise still has no live Plug-and-Play authority.

Today's testing remained bounded and shadow-only.

Terminal Architecture

We also spent substantial time defining Ceylon's terminal architecture.

A terminal seems like another simple application until you ask what it should mean inside a modern Ceylon system.

The resulting work distinguishes several concepts that are traditionally collapsed together:

terminal UI
terminal protocol
session
process/service connection
remote connection
persistent session

That resulted in a proposed native terminal/session architecture, bounded terminal parsing rules, a Ceylon terminal protocol, and compatibility paths for traditional VT-style terminal behavior.

One important conclusion was that Ceylon already has pieces of the security/session architecture needed for interactive sessions, but a persistent bridge-session abstraction will eventually be needed for longer-lived or remotely attached sessions.

That led to another idea worth preserving for later research: a lightweight ANSI-style collaborative text system inspired by the old BBS world.

The idea is not to make that part of the immediate A1 build.

Instead, it has been separated into its own R&D work so it can eventually explore low-overhead messaging, collaboration, administration and even Internet-accessible BBS-style hosting without distorting the terminal work itself.

This was also part of a larger cleanup of the Ceylon R&D library so experimental work is separated from specifications and active implementation material.

Hardware Layout Reconciliation

A less glamorous but important piece of work was cleaning up the current QEMU hardware model.

We found evidence from multiple generations of PCI layout mixed together in existing artifacts.

That matters because a device's BAR addresses, interrupt routing and IOMMU mappings can change when the virtual hardware set changes.

The current layout was reconciled around the active Q35 configuration, including storage, audio and USB hardware.

The resulting map successfully covered:

PCI layout
xHCI resources
VirtIO resources
IOMMU mappings
CapDL relationships
storage
network
display

and passed three reproducibility runs.

That gives us a much better foundation for future device qualification because we now know which hardware description represents the machine we are actually testing.

NuGUI Input Qualification

NuGUI input work also continued today.

Static architecture and hardware layout work moved forward, but the next input milestone was deliberately not declared complete.

The remaining target evidence includes areas such as:

real pointer traffic
stress behavior
generation handling
malformed-input handling
keyboard regression
latency
observability

The current stopping point is USB HID injection qualification.

Again, this is an example of the engineering approach we are trying to maintain throughout Ceylon:

"the architecture looks right"

is not the same as:

"the target behavior has been proven"

Until the second statement is true, the gate stays open.

Kirk Continues Toward Qualification

Kirk, Ceylon's local service/federation control plane, also continued qualification work.

Recent testing has exercised:

service discovery
registration
capacity limits
rejection paths
revocation
reincarnation
stress behavior
reproducible boot behavior
clean rebuilds

A 100,000-operation target stress run passed, and long-duration soak qualification has been underway.

Kirk is an important piece of the eventual Ceylon application ecosystem because it lets applications and services find each other, identify capabilities, manage lifecycle relationships and coordinate work without becoming the bulk-data transport itself.

That separation remains deliberate.

Control traffic goes through the control plane.

Large or real-time data stays on the appropriate dedicated path.

Taking Inventory of A1

Another useful outcome from today's work was a more disciplined look at what is actually present in the A1 system.

The current production-readiness inventory identified 32 services and eliminated unclassified repository items from the baseline being examined.

That doesn't mean A1 is finished.

It means we increasingly know exactly what is there, what state it is in, and what still blocks higher-level integration.

Several areas remain active work, including desktop integration, persistence, audio integration, device input qualification and application-layer completion.

But an operating system this size becomes much easier to reason about once every component has a name, an owner, a role and a qualification state.

What Today Was Really About

If there was a common theme to September 22, it was this:

turning implicit architecture into explicit contracts.

Networking became a defined IPv4/IPv6 architecture rather than simply a collection of protocols.

Plug-and-Play became a transactional lifecycle problem rather than simply device enumeration.

The terminal became a session architecture rather than merely a command window.

PCI configuration became a reproducible hardware baseline rather than accumulated historical artifacts.

And qualification gates continued to distinguish between things we believe should work and things we can demonstrate actually work.

That difference is becoming increasingly important as Ceylon gets larger.

The system is reaching the point where adding another feature is often easier than proving that twenty interacting features still behave correctly together.

That means some development days are going to end with:

NOT_COMPLETE

And sometimes that is the right answer.

Clarise is a good example tonight.

We learned exactly where the next failure boundary is:

supervisor restart succeeds
    ↓
new Clarise instance must start
    ↓
post-restart event must arrive
    ↓
transaction state must be reconstructed
    ↓
only then can I3 close

That's a very specific problem.

Specific problems are solvable.

Tomorrow, we keep building.

Project Ceylon Development Log — September 21, 2026: Turning a Working System Into a Trustworthy One

Mike — Mon, 21 Sep 2026 12:00:00 GMT

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:

the current virtual hardware,
the older known-good configuration,
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.

Ceylon Development Log — September 20, 2026: Back to Solid Ground

Sun, 20 Sep 2026 12:00:00 GMT

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.

Ceylon Development Log — September 19, 2026: The Controller Was Ready. It Still Wouldn’t Run.

Mike — Sat, 19 Sep 2026 12:00:00 GMT

Today I submitted Project Ceylon to the Hackaday Retrocomputing Contest.

And then, almost immediately, Ceylon reminded me why I am writing this development journal instead of waiting until everything is polished and pretending the path was obvious.

A controller that should have started did not.

Not crashed.

Not faulted.

Not obviously misconfigured.

It just sat there.

That turned the rest of the day — and quite a bit of the night — into one of those debugging sessions where the useful result is not a dramatic fix.

It is eliminating one wrong explanation after another until the problem finally becomes small enough to understand.

First, the public side

The Hackaday project page got a fairly substantial cleanup today.

I uploaded the current architecture and progress graphics, clarified the staged alpha plan, and added an older framebuffer capture as historical proof that Ceylon has already produced native graphics under QEMU.

That image is the project's earlier First Light milestone.

First Light did not happen today.

The important distinction is that the Hackaday page now has more evidence of what already exists instead of relying mainly on descriptions of where the project is going.

The alpha plan also became clearer.

The first A-series release will go to a small curated group of technical testers. The things they break, misunderstand or expose will be addressed before a broader public QEMU evaluation.

That is slower than throwing an image onto the Internet and calling it an alpha.

I think it is also more useful.

Then the controller refused to start

The main engineering problem today was a controller Protection Domain that never produced its expected startup marker.

The first obvious question was whether I had simply failed to start it.

That would have been convenient.

The generated configuration said otherwise.

The controller had the correct resume flag.

The system initializer could see it.

It was included in the generated startup collections.

Its executable was loaded.

Its scheduling context was present.

The initializer attempted to start it.

The child identifier was valid.

So the easy explanation disappeared.

The machine thought this thing should exist.

The question became:

What does the MicroKernel think the controller is actually doing?

Looking inside the running system

A diagnostic observation finally gave us the controller's kernel-visible state.

Its instruction pointer was sitting exactly at its generated entry point:

0x2025d8

Its stack pointer looked correct.

Its priority was 199.

It was assigned to CPU 0.

Its scheduling context was bound.

Most importantly, its thread state was Restart — a runnable/startable state.

That was a significant result.

The controller was not inactive.

It was not blocked waiting on a message.

It was not sitting in a fault state.

And it had not wandered halfway through startup before failing.

It appeared to have never moved from the front door.

A bad observation can be worse than no observation

The next scheduler snapshot initially looked suspicious.

The controller was still waiting while a higher-priority supervisor was running.

Except the supervisor was still inside its own initialization routine when the snapshot was taken.

That means the observation itself was too early.

A priority-250 thread running while a priority-199 thread waits is not evidence of a scheduler bug.

It is the scheduler doing exactly what it was told to do.

So that result was classified as an observation-timing problem, not a system failure.

That may sound like splitting hairs.

It is not.

One of the easiest ways to manufacture a fake operating-system bug is to instrument the system in a way that changes the thing you are trying to observe.

So we stopped and changed the observation method rather than changing the system.

After initialization, the mystery remained

A valid post-initialization observation came next.

The controller was still sitting at:

PC = 0x2025d8

Still in Restart.

Still ready to go.

But the existing debug interfaces did not expose enough information to answer the next question.

Was the controller actually in the ready queue?

Was the ready bitmap set?

Was its scheduling context really eligible at that moment?

Those details live inside the scheduler.

So I built a temporary diagnostic kernel whose only job was to expose those internal states without changing them.

That gave us the strongest result of the night.

The controller was:

queued                 YES
present in ready queue YES
ready bitmap present   YES
runnable               YES
schedulable            YES
SC refill ready        YES
SC refill sufficient   YES
release queued         NO
CPU/domain match       YES

In other words:

the controller itself looked healthy.

Then we found what was ahead of it

The highest ready thread on CPU 0 was the PCI service.

Its priority is 248.

The controller's is 199.

And the PCI service was observed running.

That explained the scheduler decision at that instant.

It did not, however, prove that PCI was the bug.

That distinction became important almost immediately.

The obvious temptation would have been to lower the PCI service's priority, raise the controller's priority, force a resume, or otherwise make the symptom disappear.

I did none of those things.

Changing a priority until something starts running is not debugging.

It is negotiating with the evidence.

PCI looked guilty. Then it didn't.

The next pass audited the PCI service itself.

Was it spinning?

Was it sitting in an accidental infinite loop?

Was it polling forever?

No.

Its initialization path was bounded.

Its notification handler did bounded work.

It returned to the normal blocking runtime path afterward.

Lower-priority services were observed getting CPU time after PCI initialization.

Later PCI wakeups also had legitimate event-driven explanations.

So the first theory —

the high-priority PCI service is simply spinning forever and starving the controller

— did not survive inspection.

That is where the controller investigation stood when I stopped that branch for the night.

We had proven a great deal about what wasn't wrong.

We had not yet proven what was.

That is still progress.

A provenance problem surfaced too

Late in the investigation another issue became impossible to ignore.

We are in the middle of validating the move to the newer 2.3 platform stack, but some of the retained build tooling and validation paths still trace back to the older 2.2 environment.

That means there is a dangerous question sitting underneath all of the scheduler evidence:

Are we actually debugging the exact software stack we think we are debugging?

That needs to be answered before I start accusing the MicroKernel scheduler of doing something impossible.

So the next stage of this work will include a full provenance check of the build environment: exact source revisions, exact tools, exact generated artifacts, and which copy of what actually produced the test image.

This sounds like bookkeeping until the day it isn't.

Reproducibility only matters when two things that are supposedly the same suddenly are not.

Then it matters a lot.

NuBASIC got another round of scrutiny

The controller work was not the only thing that made it into the overnight session.

I also spent time reviewing the proposed NuBASIC Level 1 specification.

The goal remains to have a complete Level 1 language available for A1 rather than shipping a tiny novelty BASIC that exists only to print HELLO.

But writing a plausible language specification is surprisingly good at exposing places where hand-waving is not good enough.

The current review surfaced issues around things such as:

grammar consistency
STOP/CONTINUE lifetime
procedure and call-frame behavior
STATIC data reset behavior
stack exhaustion
error scope
platform-binding completeness
built-in function accounting
deterministic behavior

None of that is implementation work yet.

That is deliberate.

It is much cheaper to discover contradictions in a specification than in a language runtime people have already started using.

And the applications are starting to shape the machine

Near the end of the night I also went back to something I keep returning to with Ceylon:

I don't want the operating system to become technically impressive and unpleasant to actually create things with.

That led into more design research around future 2D/3D tools.

One principle is becoming firm:

CPU-only capability stays first-class.

A GPU can eventually make rendering dramatically faster.

It should not be the admission ticket for rendering at all.

If a user wants to let a CPU grind on a final render for a long time, the system should still be capable of producing the result.

The same philosophy is starting to shape CAD and design-tool thinking.

Precision needs to exist.

Exact dimensions need to exist.

Constraints need to exist.

But I do not want every creative action to begin with somebody typing measurements into a dialog box.

There should also be room to sketch, push, pull, shape and experiment — and then have the system help normalize that work into something dimensionally valid and, eventually, fabricatable.

That is research, not an implementation commitment yet.

But it is exactly the kind of application pressure that tells us what the platform underneath needs to become.

What today actually accomplished

If I reduced today to a release-note list, it would look unimpressive.

The controller still wasn't running when this workday ended.

But that misses what happened.

We proved that the controller is generated correctly.

We proved that the initializer starts it.

We proved that the MicroKernel sees it.

We proved that it is runnable.

We proved that it is schedulable.

We proved that its scheduling context is usable.

We proved that it is actually present in the ready queue.

We found a higher-priority contender.

Then we proved that our first explanation for that contender was incomplete.

And instead of forcing the machine into the answer we wanted, we stopped.

That is what development looks like sometimes.

The project also became public in a new way today.

It is now entered in the Hackaday Retrocomputing Contest.

There are architecture diagrams on the page.

There is an old First Light image showing that the thing really has put pixels on a screen.

There is a plan for how outside testers will eventually get their hands on it.

And behind all of that, there is still a stubborn controller sitting at 0x2025d8 waiting for us to explain precisely why it has not been given its turn.

That's tomorrow's problem.

Tonight, the useful result is that the list of possible answers is a whole lot shorter than it was this morning.

Ceylon Development Log — September 18, 2026: Why an Operating System Needs a Game

Mike — Fri, 18 Sep 2026 12:00:00 GMT

Today Ceylon's first native game stopped being a side idea and became something much more useful: a plan for a real application that can entertain people, stress the operating system, test recovery, and teach us how third-party software should be built on the platform.

Project Ceylon Nightly: Why an Operating System Needs a Game

There is an easy way to demonstrate an operating system.

Draw a window.

Put some text in it.

Move a mouse cursor.

Play a sound.

Save a file.

Those are all important milestones, and Ceylon needs them.

But eventually a collection of technical demonstrations stops answering the harder question:

Can this machine actually run something interesting?

That is why I have been spending time on a native game for A1.

Not a port.

Not a browser game.

Not an SDL demo quietly carrying another operating system's assumptions underneath it.

A real Ceylon application.

Why a game is a useful systems test

Games are brutal in useful ways.

People notice input lag immediately.

They notice timing glitches.

They notice dropped frames.

They notice audio hiccups.

They notice when controls feel wrong.

They notice when a pause in storage, logging or background work interrupts the foreground experience.

A benchmark can tell me that Ceylon completed a million operations.

A game can tell me whether graphics, input, audio, timing, memory, storage, scheduling and application lifecycle can all cooperate while somebody is actively using the machine.

That is much more interesting.

The goal is not to write a fake game whose only purpose is to tick API boxes.

If we do this, I want the game to actually be worth playing.

That matters because an entertaining game creates design pressure that a technical demo does not.

Controls have to feel good.

The world has to make sense.

Difficulty has to be fair enough that people can learn.

Sound has to communicate something.

The graphics have to remain readable under pressure.

Those are human-factors tests as much as software tests.

The research started with Sinistar, but it did not stop there

The historical starting point was Williams' Sinistar.

Not because I want to remake Sinistar.

I do not.

What fascinated me was how much that game managed to do on extremely small hardware.

The world did not simply wait for the player.

Workers collected resources.

Other enemies hunted you.

The larger threat was being assembled while you were busy elsewhere.

The player was constantly deciding between the problem directly in front of the ship and the bigger problem developing somewhere else.

And under all of that, the programmers built a tiny multitasking-style executive to coordinate the game's independent behaviors.

That is the part I care about.

They were not building a miniature operating system because that sounded clever.

They were solving a game-design problem: how do you make many things appear alive at once when the machine cannot afford heavyweight machinery for every object?

That is a remarkably relevant question for Ceylon.

Looking beyond one game

One of today's research goals was deliberately broadening the survey so the new game does not become "Sinistar with different artwork."

I have been looking at preserved source and development material from a number of early games and asking what each one did unusually well.

Defender made a world larger than the viewport and compressed that world into a useful radar display.

Robotron produced overwhelming actor density while keeping the player's controls extremely crisp.

Joust got enormous depth from a tiny control vocabulary and a good movement model.

Tempest treated demo and self-test behavior as part of the machine rather than as an afterthought.

Missile Command used hard object limits and irreversible world damage to turn constrained resources into game rules.

Centipede let enemies modify the environment instead of merely moving through it.

Battlezone created convincing spatial scale from minimal geometry and instrumentation.

Elite generated an enormous perceived universe from compact deterministic data.

The point of this research is not to copy old routines.

It is to identify ideas that survived their original hardware.

What made a game readable?

What made it feel larger than memory?

What let many autonomous actors appear active?

Which limitations produced elegant design?

Which limitations should be discarded because modern hardware no longer requires them?

That is the research question.

Old source code is a textbook, not a parts bin

I have said this before about the Amiga and Video Toaster work, and the same rule applies here.

Historical source is useful because it exposes decisions.

It shows what people were trying to accomplish when memory, CPU time and storage were painfully finite.

But source being visible does not mean we should translate it into Ceylon.

The new game needs original code, original art, original audio, original fiction and its own behavior.

The historical material belongs on the research side.

The implementation side should receive independent requirements and design lessons.

That gives us something more valuable than a clone.

It forces us to answer the same kinds of engineering questions ourselves.

The game is starting to take shape

The current idea is a large-feeling field where the player and autonomous machines compete for the same resource.

The machines are not simply enemies waiting to be shot.

They are trying to accomplish something.

They collect.

They transport.

They build.

Other actors defend that process.

If the player ignores it long enough, the world changes.

That gives us a natural game loop:

explore;
collect;
intercept;
prepare;
disrupt;
survive;
and eventually deal with the thing the autonomous system has been building.

The large threat should not be a recognizable copy of Sinistar.

I am much more interested in something geometric, mechanical or energetic—a system event rather than a giant face with a health bar.

Why this structure is useful to Ceylon

The nice thing about that design is that the gameplay itself generates a useful operating-system workload.

Autonomous actors need scheduling.

Resources need state.

Projectiles and effects need bounded pools.

The player needs responsive keyboard, mouse and gamepad input.

The scanner needs a second view of the same world state.

Audio can warn about activity that is not currently visible.

Storage can preserve settings, scores and replays.

Structured logging can record faults and unusual conditions.

A developer overlay can expose real frame times, pool usage, task counts and audio problems.

None of that has to be bolted on merely to make a benchmark.

The game naturally needs it.

A hidden player that never gets tired

One of the stranger ideas may also become one of the most useful.

The game should have a hidden CPU-controlled player that uses the same logical controls a human uses.

No cheating.

No directly changing the world.

The bot generates movement and action commands exactly like a keyboard, mouse or joystick adapter would.

That means Ceylon could run the game by itself for hours.

It can win.

It can lose.

It can recover.

It can create crowded situations.

It can stress object pools.

It can exercise audio, rendering, storage and telemetry repeatedly.

Then it can stop cleanly and leave behind a report.

That turns the game into a soak-test harness without turning the public experience into a benchmark utility.

A visible version could even double as an old-fashioned arcade attract mode.

Replay as a flight recorder

The same design points toward deterministic replay.

If the world starts from a known seed and consumes a known input stream, then many failures can be reproduced rather than described vaguely.

A useful replay can contain:

world seed;
input changes;
important events;
periodic state hashes;
performance checkpoints.

If a bug only appears after 43 minutes under a particular load pattern, the goal is to replay the conditions that created it.

For an operating-system alpha, that is extremely valuable.

CPU first, on purpose

The first game does not need a GPU.

That is deliberate.

A1 should be able to demonstrate itself with software rendering through Ceylon's native display path.

Later systems can add acceleration.

But the first application should prove that the underlying machine is useful before future graphics hardware becomes a requirement.

This also creates a stable reference path.

If a later accelerated renderer behaves differently, we have a known software implementation to compare it against.

The research is also changing how I think about development tools

Another idea emerged from the game research today.

If we eventually build more than one kind of game for Ceylon, we should probably not build one giant universal game engine.

A scrolling arcade game, a sector-based first-person game, a polygonal 3D game and a flight simulator need very different world models.

What they do share are things like:

graphics access;
input;
audio;
timing;
storage;
logging;
asset handling;
packaging;
telemetry.

That suggests a reusable framework underneath multiple engines.

The first game does not need to wait for that framework.

In fact, it is probably better if it does not.

We can build the game first, discover which pieces are genuinely reusable, and then extract those pieces after they have survived real use.

That is safer than designing a giant abstraction around games we have not written yet.

Assets may become their own platform

The same logic applies to game assets.

Not every asset belongs in every engine.

A 3D character model may become a full animated model in one engine and a prerendered sprite set in another.

A sound effect may work everywhere.

A collision mesh may only matter to certain engines.

So the longer-term idea is an asset store that preserves a canonical source, tracks where it came from and how it is licensed, then lets engine-specific processors generate only the runtime representation a game actually needs.

That could eventually let first-party and independent engines share one asset ecosystem without requiring them to share one runtime architecture.

It is a larger idea than today's game, but today's game gives us somewhere concrete to start.

Why this may matter to outside developers

Ceylon is eventually going to need software that I did not write.

If an independent developer already has an engine, I do not want the platform to say:

Throw it away and use ours.

I want Ceylon to say:

Bring your engine.

Use our engine.

Use part of our framework.

Use our asset system.

Or just use the native APIs and build your own tools.

Keep ownership of your work.

The platform should make development easier without demanding control of the developer's engine.

That is a much better way to earn serious developer interest.

Certification and compatibility logos may make sense someday.

That is later.

First we need to make the machine worth developing for.

Where this leaves A1

The immediate target remains practical.

Build a standalone native game.

Keep the architecture clean enough that reusable pieces can be extracted later.

Use the game to pressure-test the APIs.

Add deterministic replay and zero-player testing.

Make it fun.

Make it measurable.

Make it shut down cleanly.

And learn everything we can about what building a real native Ceylon application actually requires.

If the game succeeds, the most important result may not be the game itself.

It may be everything Ceylon learns while building it.

— Mike

Ceylon Development Log — September 17, 2026: When a Crash Needs to Leave Evidence

Mike — Thu, 17 Sep 2026 12:00:00 GMT

A real fault exposed an important distinction today: Ceylon can detect and contain a crashed component, but that is not enough. If the machine is going to recover from failures, it also needs to remember exactly what happened.

Project Ceylon Nightly: When a Crash Needs to Leave Evidence

Today started with something that, on the surface, looked encouraging.

One of Ceylon's isolated execution components hit a real illegal-instruction fault.

The system detected it.

The fault stayed contained.

The rest of the machine did not fall over with it.

That is exactly the kind of behavior a componentized operating system is supposed to provide.

But the fault also exposed a hole.

Ceylon knew what had happened well enough to print useful information to the debug serial console, yet the same information never entered the structured logging path we have been building for the operating system.

In other words, the architecture worked well enough to catch the failure, but the evidence stopped at the equivalent of somebody yelling across the workshop.

That is not good enough for the system Ceylon is intended to become.

The difference between a debug message and an incident record

Serial output is incredibly useful while an operating system is under construction.

It is simple.

It is immediate.

When something goes wrong at a very low level, there is a good chance the serial console is still alive.

I do not want to get rid of it.

But serial output is not a durable incident history.

If a component faults, gets reclaimed, and is restarted, I eventually want to be able to answer questions such as:

What fault happened?

Which exact component instance failed?

Which build was running?

What instruction or address was involved?

What did the supervisor decide to do?

Was the component reclaimed?

Was it restarted?

Did the restart succeed?

Did any diagnostic information get dropped along the way?

A line of text on a debug console cannot answer those questions reliably after the fact.

A structured incident record can.

The good news: the logging architecture is not broken

The useful discovery today is that we do not need to throw away Ceylon's logging system and start over.

The existing design already has most of the right ingredients.

Ceylon has bounded shared-memory error transport.

It has explicit drop accounting.

It has a collector boundary separate from the producer.

It has a path for structured records to reach durable storage.

That part is important because I do not want a faulting or supervising component trying to perform filesystem I/O while it is dealing with a failure.

The intended path remains:

component or supervisor
→ bounded shared-memory record
→ collector
→ durable local log
→ management/query tools

The problem is much narrower.

The execution-manager fault path never enters it.

Right now that path effectively looks like:

fault
→ supervisor
→ debug serial

What it needs to become is:

fault
→ supervisor
→ structured fault event
→ bounded error mailbox
→ collector
→ durable incident record

Serial can remain as a secondary human-readable path.

It simply cannot be the only record.

One fault should become one coherent story

Once I started looking at this, it became obvious that simply logging "component crashed" is not enough either.

Ceylon is being designed around restartable, generation-safe resources.

That means one execution slot may host one component instance, be reclaimed, and later be reused for another instance.

So a useful fault report needs to identify more than a slot number.

It needs to identify the exact generation of the thing that failed.

It also needs a correlation identifier so we can connect the complete lifecycle:

FAULT OBSERVED
↓
CONTAINMENT
↓
RECLAIM
↓
RESTART ATTEMPT
↓
NEW GENERATION
↓
RECOVERY SUCCEEDED / FAILED / QUARANTINED

That turns a collection of unrelated log lines into an incident.

If Ceylon is going to recover automatically from failures someday, that distinction is critical.

The most dangerous kind of "reliable" system would be one that silently restarts things while losing the evidence explaining why they were restarted.

No silent telemetry loss

There is another rule that came out of today's work.

If the fault-reporting path itself is full or unavailable, that failure has to be visible too.

The system should never be allowed to claim that everything was recorded merely because nobody noticed the log buffer overflowing.

So the design now treats loss as part of the telemetry model.

If the error mailbox fills, count it.

If the collector is unavailable, expose it.

If storage cannot accept records, make that visible.

If a record is malformed, record the rejection.

The goal is not to pretend diagnostic infrastructure can never fail.

The goal is to make sure failure of the diagnostic infrastructure does not disappear silently.

That is a very Ceylon kind of rule: bounded resources are fine. Unexplained behavior is not.

Research before freezing the next interfaces

A significant part of today's work was research rather than implementation.

That is becoming normal as Ceylon grows.

I spent time comparing how mature systems separate fault capture from durable logging, how they preserve component identity across restart, and how diagnostic data can remain useful without turning the fault path into another source of failure.

The same research habit is also being applied to graphics, application integration, compatibility, and device architecture.

On the graphics side, one important working assumption is deliberately pessimistic: we should design Ceylon so it remains useful even if hardware vendors never write native drivers for us.

That pushes us toward a native Ceylon presentation architecture that can learn from open drivers, Mesa, firmware interfaces, virtual devices, and other operating systems without making Ceylon dependent on their architecture.

The same pattern applies elsewhere.

Study what already exists.

Understand why it works.

Keep the durable lessons.

Reject assumptions that do not fit Ceylon.

I would rather spend a day understanding why a mature design works than spend a month rediscovering the same failure mode in our own code.

The machine should be able to explain itself

This has become one of the themes I like most about Ceylon.

I do not just want the system to attempt recovery.

I want it to be able to explain what it did.

That applies to memory ownership.

It applies to device authority.

It applies to application execution.

And now it applies to faults.

The eventual management tools should be able to reconstruct something like:

At 14:22:31.482, application worker generation 17 faulted with an illegal instruction.

The supervisor contained the fault.

The worker was reclaimed.

No fault telemetry was dropped.

A new generation was created.

The application resumed.

That is much more useful than:

"Something crashed earlier, but it seems fine now."

This is also part of making Ceylon supportable

The public-facing side of the project is becoming more important as A1 gets closer.

An operating system that only its author can diagnose is not much of a platform.

Eventually somebody should be able to send a bounded support record or diagnostic bundle that identifies:

the Ceylon build;
the boot/session;
the component;
the fault;
the recovery sequence;
and whether the telemetry itself remained healthy.

That does not require a mandatory cloud service.

The architecture remains local-first.

But local-first does not mean opaque.

It means the machine should keep useful evidence under the user's control.

Where this leaves the work

Today's conclusion was reassuring.

The structured logging architecture is viable.

The fault-containment architecture is viable.

The missing piece is that one important supervisor path bypasses the structured system.

So the next work is targeted rather than revolutionary:

publish supervisor-observed faults into the existing bounded mailbox;
preserve exact identity and generation;
correlate the recovery sequence;
prove that healthy qualification runs lose no fault records;
and make the degraded cases visible when the logging path itself is under stress.

The larger lesson from the research side is equally important.

Ceylon is reaching the stage where every major subsystem should be designed with enough historical and modern context that we understand the tradeoffs before we freeze the interface.

That may look slower on a daily changelog.

It should make the project much faster over the long run.

— Mike

Ceylon Development Log — September 16, 2026: Static Foundations, Dynamic Systems

Mike — Wed, 16 Sep 2026 12:00:00 GMT

Ceylon is learning how to become dynamic without abandoning a static, bounded and predictable foundation: leased execution workers, mirrored VSpace cohorts, bounded page capabilities, and a capability-pool question still open.

Project Ceylon Nightly: Static Foundations, Dynamic Systems

Today was one of those days where the most important progress was not a new screen, a new driver, or another user-facing feature.

It was figuring out what the machine underneath all of those things needs to become.

Over the last several development cycles, Ceylon has been moving onto an updated microkernel foundation and a newer generation of its surrounding system-construction tooling. That upgrade brought substantial capabilities with it, but it also invalidated a few assumptions that had quietly worked their way into the earlier architecture.

That forced us to stop and answer a more fundamental question:

How dynamic can Ceylon become while preserving a system that is deliberately static, bounded, isolated and predictable at its foundation?

The answer is turning out to be: surprisingly dynamic.

The execution problem

One of the first challenges was application execution.

Traditional operating systems tend to build processes and threads dynamically. Ceylon's underlying platform is intentionally different. Much of the system is constructed ahead of time, with explicit resources, explicit authority and tightly controlled relationships between components.

Initially, that looked like it might become an obstacle.

Instead of fighting that design, we tried a different approach.

We built a bounded pool of isolated execution workers ahead of time, then allowed Ceylon to lease those workers dynamically.

The underlying execution resources remain static.

Their use becomes dynamic.

That means an execution worker can move through a lifecycle resembling:

FREE ↓ LEASED ↓ ACTIVE ↓ QUIESCING ↓ RESETTING ↓ FREE

Each lease carries generation information so stale references can be rejected rather than accidentally referring to a newly reused resource.

More importantly, multiple isolated workers can participate in one logical application environment while retaining separate protection domains.

That has some useful security properties of its own: sharing memory does not automatically mean sharing authority.

Making isolated workers feel like one address space

That led directly to the next problem.

If two workers are supposed to behave somewhat like threads in one application, they need to agree about memory.

We proved that two—and later four—isolated workers can map the same backing memory at the same virtual address and successfully exchange actual pointers.

Not offsets.

Not handles pretending to be pointers.

The same numeric address.

One worker can create an object in shared memory, publish a pointer to it, and another worker can dereference that pointer directly.

That was an important result because it suggested that Ceylon could build a logical shared application address space across independently isolated execution contexts.

There are caveats.

Ordinary writable program globals remain private to each worker unless we deliberately place them into shared backing memory. Private stacks and thread-local state also need to remain private.

But that is an architectural problem we can define clearly rather than an indication that the model is impossible.

The virtual-memory problem

The next step was harder.

Static shared mappings are useful, but a modern workstation eventually needs runtime memory behavior:

mapping and unmapping memory; shared heaps; guard pages; permission changes; executable-code transitions; sparse reservations; deterministic cleanup; controlled reuse.

At first, the upgraded platform appeared not to expose enough authority for that.

The obvious response would have been to start modifying the microkernel or turn Ceylon into something the underlying platform was never intended to be.

We resisted that.

Instead, we asked whether the capacity could remain static while the mappings themselves became dynamic.

That produced one of today's most useful findings.

We can preconstruct bounded virtual-memory arenas during system construction. A tiny reserved page placed at regular intervals causes the required paging hierarchy to exist before the operating system starts.

Once those structures exist, runtime memory operations do not need the ability to dynamically manufacture page tables.

They only need authority over the individual physical pages being mapped.

That greatly simplified the problem.

Instead of needing a general-purpose runtime memory-object allocator inside the kernel, the problem reduced to:

Safely provide the memory manager with bounded authority over an explicitly approved pool of pages.

That is a dramatically smaller requirement.

A tiny platform addition

We built an isolated validation extension to test exactly that.

It does not modify the microkernel.

It does not create new kernel behavior.

It simply allows the system-construction layer to expose carefully selected page capabilities to the memory manager.

The first target proof succeeded.

The manager could take a page from a bounded provider pool and map it at runtime into a worker's preconstructed virtual-memory arena.

The same physical page could also be mapped into multiple isolated workers at the same address.

We verified four independent address spaces sharing the same backing page while preserving pointer transparency.

We also confirmed that mappings outside the preconstructed arena fail as expected.

That distinction matters.

The system is not secretly turning itself into an unlimited dynamic virtual-memory manager.

It remains bounded.

Stressing it

Once the mechanism worked, the next job was trying to break it.

The current stress campaign has reached a partial qualification result.

Among the completed tests:

four isolated workers sharing one physical page; identical pointer use across those workers; repeated map/unmap lifecycle testing; virtual-address rotation; physical-frame rotation; 10,000 target lifecycle cycles; three repeatable hardware-accelerated virtualization runs; more than 500,000 randomized model operations across several deterministic seeds; zero resource drift in the executed scope.

That is encouraging.

It is not yet enough to call the entire virtual-memory system qualified.

Several advanced cases remain open, including complete rights transitions, guard-page stress, sparse commit/decommit, cohort rollback, stale target mapping rejection and fault-time cleanup.

Those should eventually be tested against the architecture we actually intend to ship rather than against a temporary proof configuration.

The next bottleneck: capability scale

The stress work also found the next important architectural issue.

Each simultaneous mapping needs its own capability instance.

For a small proof, those can simply be provisioned ahead of time.

For a large application-memory pool, that becomes expensive.

So the next question is no longer whether dynamic mapping works.

It does.

The next question is:

How do we build a bounded capability pool that can efficiently create and recycle mapping authority without giving the memory manager broad system authority?

The direction we are investigating is another example of the same principle that has been emerging throughout Ceylon:

static capacity dynamic use explicit ownership deterministic exhaustion

The likely model is a dedicated capability pool owned by the memory manager.

A small number of master page capabilities would exist within that pool. Individual mapping capabilities could then be copied into bounded slots when needed, used for a mapping, retired, deleted and recycled.

No unrestricted kernel-object allocator.

No unlimited memory growth.

No requirement to share another process's complete capability space.

Just a purpose-built pool with explicit limits.

Research is becoming part of the development process

A significant portion of today's work was research rather than implementation, and that is intentional.

Ceylon has reached a point where blindly writing everything ourselves would be wasteful.

We have been studying modern componentized operating-system designs, device-driver frameworks, real-time systems, memory-management approaches, multimedia architectures and older workstation designs to identify ideas that can accelerate development without compromising the architecture.

Some of that research is already paying off.

One modern driver framework we reviewed has several characteristics very close to decisions Ceylon has independently been moving toward:

small isolated hardware drivers; shared-memory data paths; bounded single-producer/single-consumer queues; asynchronous notifications rather than synchronous bulk IPC; separate components for device sharing and address translation; explicit handling of DMA-visible buffers.

It also contains working implementations for several device classes directly relevant to our development path, including virtual block devices, virtual networking, high-performance storage, timers and serial hardware.

That does not mean Ceylon is simply going to import another project's driver stack.

It does mean we would be foolish not to study working implementations before reinventing every queue, reset path, interrupt sequence and DMA rule ourselves.

We are therefore preparing a systematic driver-reuse audit.

For each candidate component we will decide whether the right answer is:

direct reuse port wrap reuse the protocol reuse the algorithm reuse the tests reference only reject

The highest-value targets initially are storage, networking, PCI, timers, serial devices and the shared-memory transport architecture surrounding them.

The goal is not to make Ceylon dependent on someone else's operating system.

The goal is to avoid spending six weeks rediscovering something another engineering team has already spent six months validating.

Research does not mean architectural drift

There is an important distinction here.

Ceylon has accumulated a fairly strong architectural identity:

capability-based authority; bounded resources; generation-safe reuse; isolation by default; small control messages; shared and registered bulk-data paths; predictable real-time behavior where required; hardware-shaped interfaces that can move from virtualization to bare metal.

Any external idea has to fit those rules.

We are not changing the architecture every time we find an interesting project.

We are using research to ask better questions before freezing our own interfaces.

That is especially important now because several major pieces are beginning to intersect:

execution workers virtual memory physical memory ownership buffer sharing DMA device drivers real-time scheduling audio graphics storage networking

A bad decision in one layer can create unnecessary copies, authority leaks, reset problems or performance ceilings throughout the rest of the machine.

This is the point where slowing down long enough to study good prior work can actually make development move faster.

The larger pattern

The most interesting lesson from the last several days is that the supposed conflict between a static microkernel architecture and a dynamic workstation may not really be a conflict.

Ceylon does not need to make its foundation behave like a conventional desktop operating system.

Instead, we can provision resources deliberately and then build dynamic behavior above them.

Static worker inventory.

Dynamic execution leases.

Static virtual-address capacity.

Dynamic page mappings.

Static physical-page pools.

Dynamic ownership.

Static capability capacity.

Dynamic capability leases.

The lower layers remain understandable and bounded.

The upper layers gain the flexibility applications expect.

That combination is starting to look like one of Ceylon's defining architectural ideas.

Before the next major implementation push, we are going to close out the current development cycle properly.

That means cleaning the validation and source trees, preserving the evidence that matters, reconciling the architecture handoffs, updating the project's durable engineering records, and making sure the next development session begins from a known state.

After that, two research tracks move to the front:

designing and proving the bounded capability pool needed for larger dynamic-memory workloads; performing a systematic driver and data-path reuse audit to determine where existing work can accelerate Ceylon's storage, networking, timing and device architecture.

Neither is particularly glamorous.

Both could save an enormous amount of development time.

And both move us toward the same goal:

a machine that is dynamic where users need it to be, but predictable where engineering demands it.

Originally published on The Weekend Report: https://theweekendersproject.com/report/ceylon-development-log-september-16-2026-static-foundations-dynamic-systems

Ceylon Development Log — September 15, 2026: Locking the Baseline Before Moving Forward

Mike — Wed, 16 Sep 2026 12:00:00 GMT

A day spent proving the new low-level foundation: DMA and interrupt isolation, multicore FPU safety, runtime boundaries, and an integrated harness that learned to trust shared state instead of notification counts.

September 15 was one of those days where a lot of work happened without producing something flashy on the screen. That is not a complaint. For an operating system project, these are some of the most important days.

The focus was on getting Project Ceylon's current reference build into a state where we could confidently say: this is the known-good machine, and anything we change from here has to prove that it is at least as trustworthy. That baseline is now locked.

The last known-good build

Before beginning the next major low-level system update, I wanted a reproducible reference point. Not the last version that seemed to work. Not whatever happened to be in the build directory. A real baseline.

That meant capturing the exact source revision, system image, kernel image, dependency versions, test results and performance measurements associated with the current working system.

The reference build completed its regression suite successfully, including 407 workspace tests, 86 documentation and contract checks, RTC and time synchronization tests, software-emulated and hardware-assisted virtualization boot testing, and baseline IPC, notification, shared-memory and floating-point performance measurements.

That build is now the project's GOLDEN-PRE23 reference. It gives us something extremely valuable: a control group. From this point forward, a major platform change cannot simply say, "it boots." It has to answer a much harder question: is it actually better—or at least no worse—than the system we already know works?

Why I am being so conservative

The low-level platform underneath Ceylon is going through a fairly substantial upgrade. This affects process isolation, memory ownership, shared memory, device access, DMA isolation, interrupts, multicore execution, inter-process communication, floating-point and SIMD state, and runtime and linker behavior.

Those are not areas where I want to rely on optimism. A bug in a graphical application is irritating. A bug in the part of the system that decides which device is allowed to write to which physical memory is an entirely different class of problem.

The goal is to eventually take Ceylon from the virtual development machine to real x86-64 hardware. The more of these architectural assumptions we can prove now, the fewer surprises we should encounter when that transition begins.

DMA isolation passed

One of today's major validation areas involved device DMA. In simple terms, DMA allows hardware devices to access memory without asking the CPU to copy every byte. It is important for high-performance storage, networking, graphics and media processing—and it needs strict boundaries.

The test system defines separate, bounded DMA windows for multiple virtual devices and verifies that a device cannot wander outside the memory assigned to it. The validation included attempts below and above an allowed window, across its boundary, through unmapped holes, into memory owned by another device, and into memory belonging to another authority domain.

Those tests passed in both software-emulated and hardware-accelerated environments. That may not make for a glamorous screenshot, but for the kind of workstation Ceylon is intended to become, this is foundational.

Interrupt ownership found a real defect

The interrupt tests did exactly what good validation is supposed to do: they found something. A network device still had an interrupt assignment left over from an earlier configuration, even though that network path had evolved into a polling-based design.

The stale route was removed, the candidate was rebuilt, and the interrupt tests were repeated. The corrected build demonstrated proper interrupt ownership and no cross-delivery between unrelated components. That corrected build became the current upgrade candidate.

Multicore floating-point isolation

Another major test involved floating-point and SIMD state across multiple CPU cores. The validation exercised vector registers, traditional floating-point state, control registers and fault behavior while placing independent owners on separate processor cores.

The state remained isolated. One component could fault without exposing its floating-point state to the surviving component. That is important evidence that the upgraded low-level system is behaving the way Ceylon's architecture expects.

Runtime and shared-memory testing

The upgraded runtime was also put through tests covering IPC buffer placement, stack alignment, linker layout, thread-local storage, protected procedure calls, notifications, shared memory, runtime identity, fault-entry behavior and multicore operation.

Some of this work is specifically important because seemingly small changes to the underlying runtime can alter assumptions made by Rust, the linker or the system's memory layout. I'd rather expose those assumptions now.

Then came the integrated test

Individual tests are useful, but eventually all these pieces have to operate at the same time. So the next step was an integrated multicore workload combining many of the previously tested paths.

That test initially failed. Interestingly, the operating system itself was not the culprit. The validation harness was. We found synchronization problems in the test machinery, particularly around how completion notifications and shared-state bookkeeping interacted.

That resulted in an important design correction to the test framework: notifications are treated as doorbells, not counters. The actual truth lives in monotonically advancing shared state. A notification says, essentially, "something may have changed; go look." It does not attempt to encode exactly how many things changed.

By the end of the day's work, the corrected harness had progressed through increasing workloads, including the longer integrated test horizon.

Validation tools need validation too

One recurring theme in this phase is that test software deserves the same skepticism as production software. We've found several occasions where an apparent operating-system failure was actually a flaw in the test fixture itself.

That isn't wasted work. A test that cannot prove it would detect the thing it claims to detect is not very useful. The validation framework includes negative controls and deliberately incorrect states intended to demonstrate that failures really are observable.

Where Ceylon stands

The previous system remains the governing baseline. The upgraded system is still a candidate. That distinction is intentional. The new build does not become "the operating system" merely because it compiled, booted or completed a few demonstrations.

The remaining process includes integrated validation, regression reconciliation and performance comparison against the known-good baseline. Only after that evidence is complete will I consider replacing the current reference.

Why this matters later

Ceylon is being built in a virtual machine first, but the VM is not the destination. It is the laboratory. The eventual goal is real x86-64 hardware, with real storage controllers, real networking, real graphics hardware, real DMA and real timing behavior.

I want the virtual implementation to give us a tested architecture for those systems before we begin dealing with hardware-specific complications. Then moving to bare metal becomes a hardware-enablement problem instead of an architectural reinvention.

That is the theory, anyway. And September 15 moved us quite a bit closer to finding out whether it works.

— Mike

Originally published on The Weekend Report: https://theweekendersproject.com/report/ceylon-development-log-september-15-2026-locking-the-baseline

Ceylon Development Log — September 14, 2026: Strengthening the Foundation

Mike — Tue, 15 Sep 2026 12:00:00 GMT

A long day of audit closure and microkernel migration work froze a reproducible Ceylon baseline and advanced the new foundation to the B0 validation gate.

Today turned into a much longer development tranche than I expected. What started as preparation for an underlying system update ended up consuming most of the afternoon and evening, but we finished the day in a very good place.

The first major milestone was freezing a new known-good Ceylon baseline. That means we now have a version of the system that is not simply working, but documented, reproducible, independently reviewed, tested under multiple execution environments, and backed by a performance baseline we can use for future comparisons.

That distinction is important. When you are building an operating system, especially one intended to grow into a serious multimedia and workstation platform, eventually "it boots" is no longer a useful definition of success. You need to know exactly what code produced the system, whether another clean build produces the same functional result, whether failure paths behave correctly, and whether future changes make the system better or worse.

Why We Are Updating the Microkernel

With that baseline safely preserved, we moved on to the next major step: updating the microkernel foundation underneath Ceylon. This is not an update for the sake of having a newer version number.

Recent architectural research into memory management, shared memory, device access, DMA, process isolation, execution contexts, and high-performance data paths exposed opportunities that make more sense if we modernize the underlying kernel environment first.

As the project grows, memory cannot just be thought of as RAM an application gets. We need increasingly sophisticated control over which subsystem owns a region, which processes may map it, which devices may access it directly, when memory is pinned or reclaimed, how stale mappings are rejected, how shared data moves without unnecessary copying, and how those rules remain enforceable when something crashes or restarts.

Those are foundational operating-system problems, and they directly affect performance. If we get the architecture right, Ceylon can eventually move large amounts of graphics, audio, storage, and media data through the system without constantly copying it from one private buffer to another.

Research Before Implementation

A lot of the recent work has actually been research rather than coding. I have been looking closely at how mature operating systems and multimedia platforms solve problems such as shared buffers, registered memory, DMA ownership, resource lifetime, high-performance queues, and hardware isolation.

The goal is not to copy another operating system. It is to understand which ideas have proven durable, why they work, where they fail, and which lessons make sense for Ceylon. That research has already generated several promising architectural directions for later development.

But before implementing those ideas, it became clear that updating the microkernel now would give us a much better foundation to build them on. So that became today's job.

A Longer Tranche Than Expected

Updating something this far down in the system affects considerably more than changing a dependency number. Low-level memory configuration changed. Device isolation changed. Interrupt handling needed to be reviewed. Runtime and linker assumptions had to be checked. Hardware-access paths needed to be validated.

Because we had just established a clean baseline, I was not willing to make enough changes to get the machine to boot and call it finished. The updated system had to pass the same tests as the previous baseline. By the end of the night, it did.

The new candidate builds successfully, boots under both of our primary virtualized execution modes, reaches the authentication system, display subsystem, and NuGUI normally, and passes the existing workspace, documentation, clock, synchronization, and performance-test infrastructure. Preliminary performance results show no obvious regression from the update. That is encouraging, but it is not enough for promotion.

Next: Try to Break It

The updated microkernel candidate is now frozen for the next phase. The old baseline remains the official governing version of Ceylon.

Next comes deeper validation. Instead of simply asking whether the system runs, we will deliberately test the new isolation and hardware-access behavior: devices must not reach memory they were not authorized to access, interrupts must remain correctly isolated, floating-point state must not leak between execution contexts, and the underlying runtime must continue behaving correctly under failure and stress.

Only after those checks pass will we move into a more formal performance and assurance comparison. Only after that will the new foundation replace the old one.

That may sound conservative, but this is exactly the point in the project where conservative engineering pays off. Ceylon is becoming complicated enough that future progress depends on having foundations we can trust. Today was a long afternoon and evening spent strengthening one of those foundations. Not flashy. But very important.

Originally published on The Weekend Report: https://theweekendersproject.com/report/ceylon-development-log-september-14-2026

Ceylon Development Log — September 12, 2026

Mike — Sun, 13 Sep 2026 12:00:00 GMT

September 12 was a day of architecture review, development governance, and a closer look at what modern Amiga users actually want from a workstation.

From Prototype to Engineering Discipline

September 12 was not primarily a "new feature" day for Ceylon. It was a day spent making sure that what we are building can survive the transition from an interesting operating-system experiment into a system that can actually be maintained, verified, extended, and eventually trusted.

That meant doing two things in parallel: taking a hard look at the current Ceylon source tree and formalizing the rules that will govern development from this point forward, while also stepping outside the code to ask what current Amiga users are actually asking for when they talk about a modern system. Those exercises reinforced each other surprisingly well.

A Full Architecture Review

The source review captured 119 maintained Rust, C, Python, shell, and Microkit composition files. The documentation checker and its tests are passing after correcting the XML block-comment handling discovered during the review.

The review gave us a clearer picture of where Ceylon is strong and where parts remain proof-grade. The architecture remains centered on seL4 and Microkit for protection, capabilities, mappings, interrupts, notifications, and controlled lifecycle management, while higher-level Ceylon services own storage, networking, input, graphics, application execution, authentication, management, and the user environment.

One principle was reinforced throughout: the microkernel is there to enforce isolation and authority, not to become the high-frequency data bus of the operating system. Ceylon's preferred model remains small typed control messages, shared or registered buffers for bulk data, descriptor and SPSC rings for streaming, batched publication and completion, and notifications for meaningful state changes rather than per-byte or per-pixel kernel traffic.

Restarting a Process Is Not the Same as Recovering a Service

A protection domain being restartable does not automatically mean the service it contains is restart-safe. A restarted driver or service may still have stale shared-memory cursors, outstanding requests, device queue state, DMA ownership, external consumers holding old references, replay state, or hardware that was never properly quiesced.

Ceylon therefore needs explicit reincarnation contracts for restartable services: how state is torn down, what becomes invalid, how generations advance, what happens to work already in flight, and how clients reconnect. That is the difference between saying "we can restart a component" and actually being able to recover a workstation after something fails.

Shared Memory Is Becoming a Platform Contract

The source review found several synchronization approaches already present in the tree. That is normal during bring-up, but it cannot remain that way in a multiprocessing production system.

We identified the need for standardized Ceylon shared-memory publication patterns covering SPSC rings, request/result pages, immutable snapshots and seqlocks, and descriptor/data-window rings. Each needs defined ownership, memory ordering, overflow behavior, restart behavior, generations, cache assumptions, and notification rules. Storage, graphics, audio, networking, input, media processing, and application services all depend on moving data between isolated components quickly without sacrificing correctness.

Proof Paths Cannot Quietly Become Production Paths

An implementation good enough to prove a concept is not automatically good enough to become permanent architecture. Several Ceylon paths intentionally use simplified copies, single outstanding operations, or other bounded bring-up mechanisms. Those are useful for proving behavior, but they are not necessarily how the production system should move data.

The production direction is registered/shared buffers, descriptor queues, bounded concurrency, batching, and explicit completion semantics. Real-time paths such as audio also need fixed-capacity behavior with no surprise allocation or unbounded processing in the steady-state path.

Authentication Moved Forward, but It Is Not Finished

The normal authentication request/result path and its publication-race proof are closed. What is not yet closed is the harder lifecycle case: protection-domain restart and service reincarnation. The authentication foundation therefore remains correctly classified as PARTIAL, rather than being promoted prematurely to complete.

Throughout Ceylon we are deliberately separating DESIGNED, HOST_PROVEN, TARGET_PROVEN, PARTIAL, and REFERENCE_ONLY. A feature existing in source code is not enough to call it finished.

Development Governance Became Part of the Architecture

September 12 also marked adoption of the new Ceylon software-development governance model. The basic rule is intentionally demanding:

DONE = implemented + documented + tested + target-verified where required + reconciled against the approved specification + independently reviewed + traceable + reproducible + auditable + recorded.

As Ceylon grows, the larger risk is architectural drift: different parts of the operating system quietly acquiring incompatible assumptions about ownership, authority, synchronization, lifecycle, memory ordering, resource limits, or failure behavior. The governance model is intended to stop that while preserving Ceylon's identity as an independently developed modern workstation operating system informed by the strongest ideas of the classic Commodore/Amiga workstation lineage.

We Also Asked What the Amiga Community Actually Wants

We reviewed recurring discussions in established Amiga communities to get a qualitative picture of what active users mean by modernization. This was not a survey and does not produce statistically representative percentages. The useful question was simply: what requests keep appearing?

The expected requests were there: 64-bit support, multiprocessing/SMP, real memory protection, stronger security boundaries, modern filesystems and storage, accelerated graphics, better audio and multimedia, modern networking and IPv6, USB and current peripherals, Wi-Fi and Bluetooth, Unicode, current browser capability, printing and scanning, and affordable hardware.

But the discussion was not only about specifications. People also want a machine that feels direct: fast input, fast launch, predictable behavior, no enormous unexplained background stack, and no feeling that the computer is fighting the person using it. That maps closely to Ceylon's goal of making responsiveness an architectural property through bounded queues, explicit resource budgets, minimal hot-path kernel crossings, and deterministic data paths where they matter.

People Remember Workbench for More Than Its Appearance

When people talk about Workbench fondly, they are often remembering clarity, not just colors and gadgets: understandable files and volumes, obvious application launching, visible system state, simple file associations, useful small utilities, and consistent interaction patterns.

That gives NuGUI a clearer design target. Ceylon should not reproduce Workbench's historical limitations; it should try to reproduce the feeling that the machine is understandable.

Local Ownership Is Still Valuable

There is continued resistance to turning the workstation into a terminal for somebody else's cloud service. Local files, offline usefulness, user-controlled systems, transparent behavior, and reduced dependency on mandatory remote accounts remain attractive characteristics. Network services and cloud integration may be useful, but neither should be required for the workstation to remain the user's computer.

ARexx, Datatypes, and Logical Volumes

The important lesson of ARexx is application cooperation: applications could be composed and automated by the user. A modern Ceylon interpretation would be a capability-safe command and action model with discoverable operations, structured arguments and results, explicit authorization, asynchronous completion, scripting support, stable identities, and bounded execution.

Amiga Datatypes offers another useful idea: applications should not each have to understand every media format. Isolated typed providers for image, audio, video, and document decoding or conversion could give Ceylon smaller applications, shared format support, centralized updates, and safer isolation around complex parsers.

Amiga-style assigns and named volumes also retain real usability value. Stable logical names need not be welded directly to physical storage locations; a future Ceylon version could combine that convenience with capabilities and explicit ownership.

Multimedia Remains Central

Graphics, animation, audio, video, and creative software remain strongly associated with what made the Amiga interesting. For Ceylon, that is not merely nostalgia. Those workloads are exactly where bounded architecture, shared-memory data paths, isolation, predictable scheduling behavior, and purpose-built resource providers can justify a new workstation operating system.

Where That Leaves Ceylon

The lesson is not simply that people want a new Amiga. Preservationists, users of Amiga-derived systems, and modernizers do not all want the same thing. Ceylon does not need to pretend they are one audience.

What we did see is substantial overlap between recurring community requests and the qualities Ceylon is already trying to build: modern multiprocessing, isolation and recovery, current hardware, strong multimedia, direct interaction, an understandable desktop, scripting and application cooperation, local ownership, extensible media services, and a system that remains comprehensible to the person sitting in front of it.

The useful lesson is not to chase a historical feature checklist. It is to build the general Ceylon capability that satisfies the underlying need. Candidate A1 capabilities now include application profiles, transactional updates, logical storage roots, command/action automation, typed media providers, stable presentation contracts, file interchange, recovery support, and controlled clipboard/application exchange.

These are Ceylon features first. If they also make future compatibility work easier, that is a benefit rather than the reason they exist.

September 12 made the project less ambiguous. We have a better definition of what Ceylon is, a clearer picture of what is proven and transitional, stronger rules for graduating experimental paths into production architecture, and a better understanding of which historical workstation ideas remain genuinely useful.

The immediate release remains a proof-of-life system: boot, authenticate, enter NuGUI, run applications, persist data, and demonstrate that the architecture is real. The larger ideas now have somewhere to go.

Ceylon is starting to move from "a collection of things that work" toward "a system with rules about why they work together." And apparently good operating-system architecture benefits from tacos, tamales, and homemade chocolate chip cookies.

Originally published on The Weekend Report: https://theweekendersproject.com/report/ceylon-development-log-september-12-2026

A Night Off, a Looney Tunes Movie, and a Hard Look at Ceylon

Mike — Fri, 11 Sep 2026 12:00:00 GMT

A night away from Ceylon turned into dinner, a movie, a serious software audit, and a complete rewrite of the rules for building the operating system.

September 10 was a genuine night off.

No Ceylon work. No documentation. No architecture review. No testing. Nothing.

That was intentional.

I have been spending enough time buried in Ceylon lately that taking an entire evening and simply not touching it was probably overdue, so that is exactly what I did.

September 11 started out considerably less serious.

I grabbed McDonald's for dinner and went to see Coyote vs. Acme.

The easiest way I can describe it is as something in the general neighborhood of Who Framed Roger Rabbit and Space Jam, but without all of the bells and whistles.

It is a simpler movie than either of those, and that is not necessarily a bad thing.

There is plenty there for kids, while the parents get the nostalgia of seeing Wile E. Coyote, Acme, and the familiar Looney Tunes world given the live-action treatment again.

It is not trying to be some enormous effects-driven spectacle. It is just a fun family movie with enough familiarity to keep the adults entertained too.

My verdict: 3 out of 5 stars.

Good for the kids. Nostalgic for the parents. Worth seeing for what it is.

Then I came home and somehow the evening became considerably more serious.

We conducted a fairly extensive software audit of the current Ceylon codebase.

The point was not simply to ask whether Ceylon builds, boots, or passes tests. We went back through the actual engineering assumptions behind several parts of the system: shared-memory behavior, synchronization, ownership, unsafe code, restart behavior, performance concerns, and the places where proof-of-concept implementations eventually need to become production-quality implementations.

We found some issues.

That is not a bad result.

In fact, that is exactly what I wanted an audit to do.

The important thing is that we are finding these weaknesses now, while the system is still under active development and they can be corrected deliberately, rather than allowing questionable assumptions to become deeply embedded in the operating system.

The audit also forced us to take a harder look at the rules governing Ceylon development itself.

The result was a complete rewrite of the Ceylon software-development contract.

The new contract is much more rigorous about what "finished" actually means.

Code existing is not enough.

A test passing is not enough.

Even getting something working on the target is not, by itself, enough.

The new development rules put much more emphasis on complete specifications, architectural ownership, requirements traceability, testing, target evidence, documentation, gap analysis, independent review, and keeping a durable record of why engineering decisions were made.

The idea is straightforward:

As Ceylon gets larger, I do not want it slowly turning into a collection of local fixes, undocumented assumptions, and architectural compromises that nobody can explain six months later.

The architecture needs to remain intentional.

So September 10 was a night completely away from Ceylon.

September 11 was McDonald's, a Looney Tunes movie, and then several hours of finding problems in an operating system and rewriting the rules for how we build it.

Apparently that counts as balance around here.

I am also about halfway through another fairly substantial piece of Ceylon documentation.

That one is not ready to discuss yet.

There will be plenty to say about it when it is.

Originally published on The Weekend Report: https://theweekendersproject.com/report/a-night-off-a-looney-tunes-movie-and-a-hard-look-at-ceylon

Ceylon Dev Log: When "Restart" Doesn't Mean Restart

Wed, 09 Sep 2026 12:00:00 GMT

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

From First Light to First Key: Ceylon's Keyboard Path Comes Alive

Mike — Tue, 08 Sep 2026 12:00:00 GMT

Ceylon reached first light this morning. Tonight it went further: a real USB keyboard, discovered, configured, and decoded into semantic key events flowing through Ceylon's bounded input architecture.

Earlier today, Ceylon reached first light.

For the first time, the operating system booted in QEMU, brought up its display stack, passed a frame through Iris and Loom, presented it through the virtual graphics hardware, and put an actual Ceylon startup screen on a 1024×768 display.

Tonight, we pushed considerably farther.

Ceylon can now discover a USB keyboard, configure it, receive real hardware-style keyboard reports from it, decode those reports into semantic key events, and publish those events into the operating system's bounded input architecture.

That sounds like a lot of words for "the keyboard works."

It is.

Because we're not trying to make a keyboard work by taking shortcuts.

We're trying to build the machinery that a real operating system can depend on.

The long way around to the letter A

The keyboard in the current development machine isn't a physical USB keyboard yet. Ceylon is still being built inside QEMU, where we can inspect, reproduce, break, and validate the architecture before taking it to bare metal.

The path currently looks something like this:

VNC key event → QEMU input subsystem → emulated USB keyboard → xHCI USB controller → Ceylon USB/xHCI driver → HID interrupt endpoint → 8-byte keyboard report → Ceylon input decoder → semantic key event

Every one of those arrows represents something we had to make real.

There is no BIOS keyboard call hiding underneath it. No PS/2 fallback. No fake input queue injected directly into the GUI.

Ceylon is talking to a modern xHCI USB controller.

That matters because the same plumbing we're building for the keyboard is the beginning of the USB infrastructure that will eventually support mice, MIDI devices, storage, and other modern peripherals.

First, we had to make the controller real

The first challenge wasn't actually the keyboard.

It was convincing the USB controller to do anything at all.

Ceylon had to acquire authority over the controller's memory-mapped registers, a bounded DMA area, and its interrupt.

Then came the usual xHCI machinery: controller reset, capability discovery, Device Context Base Address Array, command ring, event ring, Event Ring Segment Table, interrupt configuration, controller RUN state.

The first meaningful test was intentionally boring: submit an xHCI No-Op Command and wait for the controller to complete it.

Boring is good.

A No-Op gave us a way to prove the entire controller command path without involving USB device enumeration yet.

Eventually QEMU fetched the command from Ceylon's DMA memory and returned a successful Command Completion Event.

Then we hit an interrupt problem.

Eleven was not twenty-two

This one is worth writing down because it is exactly the sort of thing that can consume an afternoon in systems programming.

The xHCI PCI device reported: Interrupt Line: 11, Interrupt Pin: A.

Naturally, we initially treated that as interrupt 11.

That was wrong.

On the Q35 machine model, the PCI Interrupt Line value is a legacy PIC-era representation. The actual routed IOAPIC interrupt for this particular xHCI INTx-A path is GSI 22.

Once we followed QEMU's lower-level IOAPIC trace, the real path became obvious: xHCI INTx-A → Q35 PCI routing → IOAPIC GSI 22 → Ceylon interrupt vector → USB driver.

After correcting that, the interrupt storm we'd been seeing disappeared.

The controller began doing exactly what it was supposed to do: raise one meaningful interrupt for the completion, let Ceylon service it, and return to an idle state.

That also reinforced something we're trying to be disciplined about throughout Ceylon: measure the hardware behavior; don't infer it from a convenient number.

Then the keyboard appeared

Once the controller itself was trustworthy, USB enumeration could begin.

Ceylon scanned the xHCI root ports and found the keyboard attached to port 5.

From there it performed the normal USB sequence: Port detection → Port reset → Enable Slot → Address Device → Endpoint 0 control transfers → Device Descriptor → Configuration Descriptor.

The device identified itself as: Vendor ID: 0627, Product ID: 0001, USB version: 2.00, Configuration: 1.

More importantly, Ceylon found exactly the interface we were looking for: Class: HID, Subclass: Boot, Protocol: Keyboard, Interface: 0, Endpoint: 0x81, Packet size: 8 bytes.

At that point we had independently proven, from inside Ceylon, that the device was a USB HID Boot Keyboard.

We weren't relying on the fact that the QEMU command line happened to say usb-kbd.

One tiny packet

A USB Boot Keyboard report is wonderfully small.

Eight bytes.

Once Ceylon configured the interrupt-IN endpoint, we armed a transfer and injected an actual key event through QEMU's VNC input path.

The first key was deliberately unexciting: A.

The report that arrived in Ceylon was: 00:00:04:00:00:00:00:00.

Then we released the key: 00:00:00:00:00:00:00:00.

That little 04 is the USB HID usage for the A key.

It came through the real path: VNC → QEMU input → USB keyboard → xHCI → DMA → Transfer Event → Ceylon.

Not simulated guest memory.

Not a fabricated report.

Not a test hook bypassing USB.

A real emulated keyboard transaction through the same architecture we expect to carry onto physical hardware.

That felt like a pretty good moment.

Turning USB into Ceylon input

Raw USB reports should not be the interface applications see.

An application shouldn't care whether a key arrived from USB, Bluetooth, a future accessibility device, or something else entirely.

So the next layer feeds those reports into Ceylon's existing input core.

The A-key report now becomes a semantic event: key = 0x1e, state = pressed, modifiers = 0, and then: key = 0x1e, state = released, modifiers = 0.

The input transport is deliberately small and bounded.

It currently uses a 32-event shared ring with: one producer, one consumer, fixed-size entries, sequence numbers, generation tracking, overflow accounting, stale-generation rejection, explicit publication ordering.

There is no dynamically growing queue and no USB memory exposed to the GUI.

The USB driver owns USB. The GUI gets semantic input.

That separation is important.

Where we stopped tonight

We're not quite ready to draw the login box yet.

The provider side is now doing its job: real HID report → semantic decoder → semantic input event → bounded shared transport → notification.

The remaining issue is at the final delivery boundary.

The input provider is publishing events and issuing its notification, but NuGUI has not yet demonstrated that it is receiving that notification and consuming the shared event ring.

So tonight's result is not: "Keyboard input is finished."

It's more precise than that: the hardware-facing keyboard stack works. Real HID reports are being converted into Ceylon semantic input. The remaining work is connecting that semantic transport cleanly into NuGUI's locked pre-login input consumer.

That is a much smaller problem than where we started this morning.

And first light is still there

Through all of this, the display path remains intact.

Ceylon still boots into its 1024×768 startup display through the graphics architecture we established earlier today.

The known first-light frame checksum remains: 0xa98302d3.

That matters too.

Adding USB shouldn't mysteriously damage graphics.

Adding input shouldn't require the GUI to own the USB controller.

One subsystem coming alive should not mean destabilizing everything around it.

That's part of what we're trying to preserve from the Amiga philosophy while building something meant for modern hardware: specialized components, clear responsibilities, asynchronous work, and a machine that stays responsive because the architecture isn't constantly tripping over itself.

What's next

The next milestone is wonderfully ordinary.

Get this: A key → USB → Ceylon input → NuGUI.

Then put a real locked login surface on the screen.

After that comes focus, editable fields, credential handling, authentication, and finally the transition from the pre-login environment into an authenticated Ceylon desktop.

There is still a lot of operating system between a boot logo and something you can sit down and use.

But tonight, for the first time, Ceylon saw someone press a key.

And it knew which key it was.

Originally published on The Weekend Report: https://theweekendersproject.com/report/from-first-light-to-first-key-ceylons-keyboard-path-comes-alive

Project Ceylon: Keeping the Architecture, Rebuilding the Assumptions

Mike — Mon, 07 Sep 2026 12:00:00 GMT

Project Ceylon keeps the architectural ideas that made the Amiga compelling while rebuilding the assumptions underneath them for modern hardware.

One of the questions hanging over Project Ceylon from the beginning has been pretty simple: if the Amiga architecture had been allowed to evolve continuously for another forty years, how much of the original design would still make sense in 2026?

This week I finally took a fairly hard look at that question.

Not from the standpoint of nostalgia, and not from the standpoint of trying to recreate a machine from 1987 with faster parts. The question was whether the ideas behind the original architecture still held up against modern CPUs, modern memory systems, GPUs, DMA, multicore processing, isolation, modern storage, and the sort of workloads people actually expect from a computer today.

The answer was encouraging.

We did not find a reason to throw the overall architecture away.

What we found instead were several places where the original thinking was still good, but the mechanism underneath it needed to grow up.

That is exactly what I had hoped would happen.

The original idea was better than some of the original limitations

The Amiga's custom chips divided work into specialized areas instead of asking the CPU to do absolutely everything.

That basic idea still makes sense.

What doesn't make sense is reproducing the limitations that existed because of the technology available at the time.

A modern machine does not need to recreate Chip RAM, fixed DMA slots, raster-timed bus arbitration, or a display system built around analog CRT assumptions just because those things existed on the original hardware.

Those were solutions to specific hardware constraints.

So the approach we're taking with Ceylon is to preserve the responsibility and design intent, while replacing the historical mechanism where modern hardware gives us a better answer.

That distinction turned out to be pretty important.

Iris doesn't need to pretend it is Agnus

Iris is our descendant of the Agnus/Alice side of the architecture.

Historically, Agnus had a huge amount of responsibility because it had to coordinate access to shared memory and arbitrate DMA among the custom chips.

That was necessary then.

It would be a bad design choice now.

Modern x86-64 hardware already gives us PCIe, device DMA, memory protection, multiple CPU cores, IOMMU support, and much more sophisticated resource management.

So Iris does not need to become a fake 1980s bus arbiter.

Its role evolves toward coordinating graphics and media resources, ownership, scheduling, and work relationships without trying to own every byte moving through the machine.

That is a good example of what I mean by preserving the architecture without preserving obsolete machinery.

Baton survives surprisingly well

Baton is the descendant of the Copper concept.

The original Copper was built around precise display timing and raster position.

The underlying idea, though, is much broader than "wait for scan line 143 and change a register."

The useful part is deterministic sequencing of operations relative to presentation timing.

That still matters today.

Frames have deadlines. Presentation has ordering requirements. Effects may depend on previous work completing. Buffers have to be ready before display. Video and animation still depend on timing.

So Baton evolves from raster-position programming into a general sequencing and presentation-timing facility.

Same idea. Much better clock.

Loom may be one of the more interesting evolutions

We decided to keep the name Loom for the Blitter descendant.

The original Blitter was an extremely effective solution for moving and manipulating blocks of graphics data without tying up the CPU.

That idea aged very well.

What changes is the implementation.

Loom is becoming a provider-neutral graphics and image execution layer.

An application can ask Loom to perform operations such as copy, fill, scale, composite, transform, clip, blend, or color conversion without caring whether the actual work is done by plain CPU code, SIMD instructions, integrated graphics, or a discrete GPU.

That gives us a very useful property: the operation stays the same even as the hardware gets faster.

On a base machine, the CPU implementation should still be genuinely useful.

Add GPU acceleration and the same workload can move from merely fast to ridiculous.

That fits the performance rule we've been using throughout Ceylon: acceleration raises the ceiling. It does not establish the floor.

I don't want a machine that requires a discrete GPU just to behave like a normal computer.

The microkernel shouldn't become the new bottleneck

Another area we reviewed carefully was communication between all of these pieces.

Ceylon is built on a security-certified microkernel foundation, and that provides some extremely useful isolation and authority boundaries.

But having a microkernel does not mean every pixel, audio sample, disk block, network packet, or video frame should bounce through the kernel as an individual message.

That would be secure and architecturally pure right up until the machine became miserable to use.

Instead, we have increasingly converged on a common pattern: small control messages establish authority and ownership, while high-frequency data moves through bounded shared resources such as buffers, rings, and descriptor queues.

The kernel remains responsible for authority, isolation, scheduling, and containment.

It does not need to sit in the middle of every byte.

Interestingly, we found variations of this same design appearing independently in the graphics, filesystem, random-number, and audio work.

That is usually a good sign.

When several subsystems independently converge on the same pattern, it is probably worth formalizing.

Multicore means we should actually use the computer we have

There is also no reason to act as if we still have one CPU competing with a handful of custom chips for every cycle.

If six cores are sitting there, we should use them.

If work can safely happen in parallel, let it happen in parallel.

If a background encoder can consume five cores while leaving the desktop, input, audio, and foreground work responsive, that is exactly what it should do.

The rule is not "conserve CPU at all costs."

The rule is use resources without making the user pay for it in responsiveness.

That led us to a performance vocabulary I've started calling the Mike Scale.

The normal machine should RUN.

Heavy production work should be allowed to FLY or reach OMG territory when hardware allows it.

But the desktop should not suddenly fall back to WALK because somebody started an encode.

Responsiveness is part of correctness.

Audio is being treated the same way

Aria and Lyra are being developed as shared Ceylon audio infrastructure rather than something every application reinvents privately.

They need to work for ordinary audio playback, but also for the music-production environment we're planning and eventually as part of the Ceylon replacement for the Video Toaster.

That means we are having to think carefully about routing, buses, PCM streams, MIDI, clocks, synchronization, and the relationship between audio time and video time.

Again, the goal is not to make one giant media subsystem that knows everything.

The goal is to give applications stable system facilities so they don't each have to bring along their own miniature operating system.

The Toaster work uncovered another architectural opportunity

While reviewing how the original Video Toaster software fit together, we found something worth preserving conceptually.

The old system did not use one universal mechanism for everything.

Timing-critical work used the mechanism appropriate to timing-critical work.

Applications could use ARexx for loose control and automation.

Media assets could be exchanged through projects and files.

That led us toward a more general Ceylon application-federation model.

Some applications will be able to cooperate more deeply when explicitly authorized.

NuBrush could operate as a standalone graphics program but also participate in the Toaster environment.

The music-production software could operate by itself or become the audio-production side of the same project.

Future applications could embed or link live objects in ways similar to putting a spreadsheet inside a word-processing document.

We're calling the federation coordinator Kirk for now.

Kirk's job is not to carry the video frames or render the graphics.

It maintains the relationships: who owns this object, what application can edit it, is it embedded or linked, what revision is current, what provider can handle this type, and if the provider restarts, is the old relationship now stale.

The actual graphics still go through Loom. Audio still belongs to Aria and Lyra. Files still belong to the filesystem.

Kirk just keeps the crew coordinated.

And importantly, not every application has to participate.

A non-federated application remains isolated and does not get cross-application shared-resource privileges.

It can still copy data or save a file like any normal program.

But live shared objects and shared resources require explicit federation.

That seems like a much cleaner security model than quietly letting every application reach into every other application because somebody wants fancy drag-and-drop.

The architecture survived the review

That is probably the biggest conclusion from all of this.

We went into the review fully prepared to discover that some of the original architectural ideas simply did not survive contact with modern hardware.

Instead, most of the important ideas did survive.

What changed were the assumptions underneath them.

Agnus does not need to arbitrate 1980s memory buses.

The Copper does not need to think in CRT scan lines.

The Blitter does not have to be one fixed piece of silicon.

Audio does not have to live inside an application.

Applications do not have to sacrifice isolation just to cooperate.

And the operating system does not need to route every high-frequency data transfer through its smallest control mechanism.

That feels like the right outcome for Ceylon.

We're not building an old Amiga with modern parts.

We're trying to figure out what the architecture might have become if engineers had been allowed to keep improving it for forty years.

Some of that means keeping ideas that were already very good.

Some of it means admitting that technology moved on.

And some of it means finding opportunities the original designers simply did not have the hardware to exploit.

The next major milestone is still the same: get the complete reference workstation running under QEMU, prove the architecture end to end, and only then start getting serious about the physical machine.

But the architectural foundation feels considerably better defined now than it did a week ago.

And after spending a large portion of the week thinking about DMA, generation counters, application federation, audio clocks, shared buffers, and what exactly a Blitter ought to be in 2026, I went over to my sister's house and had brisket with the family.

It was very good brisket.

Some systems are already adequately optimized.

Originally published on The Weekend Report: https://theweekendersproject.com/report/project-ceylon-keeping-the-architecture-rebuilding-the-assumptions

The Backstory Is Live. Tomorrow, Y'all Get the Mess as It Happens.

Mike — Mon, 07 Sep 2026 12:00:00 GMT

The retrospective is caught up. From here forward, Project Ceylon becomes a real-time record of the work, wrong turns, breakthroughs, and whatever happens next.

Project Ceylon Development Journal — September 6, 2026

Well, this has been a day.

When I started this morning, most of Project Ceylon's history existed in exactly the places you would expect a long-running personal engineering project to keep its history: old notes, specifications, source trees, test results, conversations, half-remembered design decisions, and a collection of moments where I was absolutely certain I knew what I was doing right up until the math informed me otherwise.

Tonight, most of that story is finally public.

We went back to the beginning and built out the Project Ceylon Development Journal on The Weekender Report.

Not the sanitized beginning.

The actual beginning.

The question was: what if Amiga development had never stopped?

From there, the journal works its way through the research into what actually made the Amiga interesting, the Video Toaster, the old NewTek source and development documentation, Project Nu-Day, QEMU, graphics experiments, the Intel Arc A770, the move to a security-certified microkernel architecture, and eventually the realization that Nu-Day had become too small for the operating system growing inside it.

That last part is important.

I Didn't Want to Rewrite the Past

One of the things I specifically did not want to do was write this like we knew where everything was going from the beginning.

We didn't.

I didn't sit down one morning with a complete architecture diagram for Ceylon and spend the next several months dutifully implementing boxes.

There were wrong turns.

There were ideas that looked good until they were tested.

There were things that worked technically but turned out to be the wrong product direction.

And there were moments where I ran the numbers, stared at the screen for a while, and thought something along the lines of: well, hell.

The early Nu-Iris display work was one of those.

The display path could do useful things.

That wasn't the problem.

The problem was what happened when I started asking it to scale into the high-resolution video workstation I actually wanted to build.

The math didn't care how much I liked the architecture.

It wasn't going to work the way I needed it to.

I was irritated.

I remain perfectly comfortable admitting that.

Engineering blogs have a bad habit of turning every failure into some sort of inspirational corporate lesson: "We discovered an exciting opportunity to rethink our architecture."

No.

Sometimes you discover that something you spent a bunch of time on isn't going to work and you're pissed off about it.

Then you go eat enchiladas and look at it again tomorrow.

That's part of the story too.

The A770 Story Is Finally in There

We also got the Intel Arc A770 story written down properly.

I'd been concerned that people would look at the card and assume the decision was basically: 16 GB GPU. Fast. Cheap enough. Good.

That wasn't it.

The development information Intel makes publicly available was one of the reasons I was willing to take the card seriously in the first place.

If you're building your own operating system, documentation starts becoming a hardware feature.

Y'all can sell me the fastest device on Earth, but if the only programming documentation consists of a marketing brochure and some guy on a forum saying, "I think this register does something," we've got a problem.

Intel gave me something I could actually research: architecture documentation, programming material, open-source compute runtime, media-driver source, Linux driver documentation. Enough material to begin understanding what the device expects from an operating system.

That doesn't make writing an A770 driver easy.

It merely changes the problem from witchcraft to a really large engineering project.

I'll take the latter.

Nu-Day Gets Its Proper Ending

The other story I wanted to get right was why Nu-Day failed.

It didn't fail because nothing worked.

That's almost the opposite of what happened.

Enough pieces started working that it became increasingly obvious I was no longer building a media workstation.

To build the media workstation, I needed an application environment. And a filesystem. And networking. And identity. And authentication. And service lifecycle management. And hardware isolation. And management interfaces. And cryptographic services.

And eventually you have to look at that list and admit something.

You're building an operating system.

Worse yet, you're building a general operating platform while still trying to describe it as one specialized workstation.

Nu-Day worked well enough to prove I was building the wrong-sized project.

That's where Ceylon really started.

And Now We're Caught Up

That is probably the biggest thing we accomplished today.

The journal now has a beginning.

Someone discovering Ceylon for the first time doesn't have to land in the middle of some discussion about IPC contracts, SecureRandom, application slots, or GPU command submission and wonder what sort of lunatic decided this was a sensible weekend project.

They can start with the innocent question.

Then watch it gradually get out of hand.

Which is much more accurate.

We also put together a shorter review piece that pulls the major parts of the story into one article.

That's intentional.

The full journal is for somebody who wants to follow the project.

The review piece is for somebody who needs to decide whether the project is interesting enough to follow in the first place.

Those are different jobs.

Tomorrow Is Different

Up until tonight, the journal has mostly been reconstruction.

Tomorrow that changes.

The backstory is caught up.

From here forward, the journal becomes what I actually wanted it to be: a running record of the project while I'm building it.

That means some entries will probably be long.

Some will be technical.

Some days we'll close a major architecture gate.

Some days we'll spend six hours chasing something that turns out to be a hard-coded number.

Some days I'll get something running that I've been trying to make work for a week.

And I'm sure there will be days where the entire update amounts to: nothing worked today.

That's fine.

I don't want to write the polished version of this three years from now and accidentally convince myself that I knew what I was doing the whole time.

I'd rather leave the fingerprints on it.

So, as of tonight, the retrospective is done.

Tomorrow, y'all get the project in real time.

The things that work. The things that don't. The things I change my mind about. The occasionally questionable engineering decision. And whatever dinner happens to be when I finally shut the computer down.

Right now I'm thinking brisket sounds pretty good.

But that's tomorrow's problem.

Originally published on The Weekend Report: https://theweekendersproject.com/report/the-backstory-is-live-tomorrow-yall-get-the-mess-as-it-happens

Where Project Ceylon Stands Today — September 6, 2026

Mike — Sun, 06 Sep 2026 12:00:00 GMT

This closes out the retrospective backfill with an honest accounting: what's proven, what's partial, what's planned, and what flatly isn't built yet. Starting tomorrow, this becomes a real daily journal.

This is the entry that closes out the backfill. Everything before this one documented work that already happened, written up after the fact. Starting after this entry, the journal catches up to real time — dated posts, written as the work happens, not reconstructed afterward. So I want this one to be a genuinely honest accounting, not a highlight reel, because everything after this gets measured against what I claim right here.

What's actually proven

Real, working evidence exists for: the application runtime and its container/identity/lifecycle model; typed management semantics as a real design, with wire and adapter work underway; console and access architecture; the Horos directory, identity, authentication, and session architecture; the SecureRandom architecture, including a working virtual-entropy backend and cross-component client proof that it actually works end to end; the restart-starvation fix and the channel-configuration fix from the last two entries, both verified; and the supporting QEMU reference-machine work that everything above was built and proven against.

That's real. I stand behind every item on that list as demonstrated, not aspirational.

What's partial

The Arc A770 driver work is at the early staged steps described a few entries back — discovery and ownership, moving toward controlled operations — not a finished driver, not close to one yet. The management API has real semantics designed and partially wired, not a fully connected GUI-and-CLI experience yet. The application runtime has a real narrow contract working, with the deliberately deferred POSIX-adjacent capabilities still, correctly, deferred.

What's planned but not real yet

Bare-metal deployment is planned, not built. The eventual target hardware is a Z390-class x86-64 machine, using Intel's integrated graphics for display duties, with the Arc A770 available for acceleration once that driver work is far enough along to matter. Remote management consuming the shared semantic layer is a planned future addition, not a current capability.

What flatly isn't built

Let me be completely direct about this, because overclaiming here would undercut every honest entry that came before it: this is not a complete desktop operating system. Not a complete server. Not a finished bare-metal system of any kind. Not a complete UHD 630 driver, and not a complete Arc A770 driver. Not a finished painting application in the DigiPaint tradition. Not a browser, and not a productivity suite. None of that exists yet. Some of it is designed. None of it is done.

What comes next

Tomorrow the backstory is over. From here on out, y'all get the mess as it happens — the real decisions, in something much closer to real time, including the ones that don't work out. I'd rather you see this project the way it actually gets built than the tidied-up version I could write if I waited until things were finished to talk about them. That second version doesn't teach anybody anything, including me.

Originally published on The Weekend Report: https://theweekendersproject.com/report/where-project-ceylon-stands-today-september-6-2026

52, 53, and Other Numbers That Ruin Your Evening

Mike — Sun, 06 Sep 2026 12:00:00 GMT

With the scheduler starvation bug fixed, the next client finally ran — and immediately failed for a much dumber reason. Shared logic assumed channel 52. It was actually assigned channel 53.

With yesterday's starvation bug actually fixed, Client B finally got to run for the first time in a while. Good news. It then immediately failed, which — after the RNG-bug-that-wasn't — I was almost prepared to find funny.

The dumbest possible reason

Shared logic across the SecureRandom clients assumed a hardcoded startup channel: 52. Client B's actual assigned channel, in this particular configuration, was 53. One number. Off by exactly one, in a config-dependent way that the previous starvation bug had been successfully hiding, because Client B hadn't gotten far enough to hit this problem until the scheduler was actually letting it run.

Why I'm including something this small in the same journal as microkernel decisions

Because this is real, and pretending a project this size is only made of grand architectural decisions would be dishonest about what actually eats an evening. Extremely complicated systems — capability-based security, custom entropy subsystems, a whole staged GPU driver plan — can still faceplant on a boring hardcoded number that nobody double-checked against the actual runtime configuration. That's not a contradiction. That's just what real systems work is like most of the time, in between the entries that make for good story arcs.

The fix, and keeping it that size

The correction was narrow and configuration-aware: stop assuming 52, read the actual assigned channel for the configuration in question. I'm not going to dress this entry up as more architecturally significant than it was. It's a one-line-shaped bug with a two-day setup because a bigger bug was standing in front of it the whole time.

Two real bugs, back to back, both hiding behind symptoms that pointed somewhere else entirely. That's most of what debugging actually is on a project like this — and now that both were behind me, it felt like a reasonable point to step back and take an honest look at where the whole project actually stands, which is exactly where this retrospective run closes out.

Originally published on The Weekend Report: https://theweekendersproject.com/report/52-53-and-other-numbers-that-ruin-your-evening

The RNG Bug That Wasn't an RNG Bug

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Two SecureRandom client tests were failing. Every instinct said the bug was in the random-number code. It wasn't. It was a busy-spinning restart starving lower-priority services out of CPU time entirely.

Two lower-priority SecureRandom client tests weren't running correctly, right on the heels of the entropy subsystem work from the last entry. Every instinct I had said: the bug's in the new random-number code, obviously, what else would it be. Every instinct I had was wrong, which is exactly the kind of thing worth writing down honestly instead of quietly editing out of the story.

What was actually happening

The real cause was nowhere near the RNG code. A higher-priority application slot that had been restarted was sitting in an unconditional busy spin — actively burning CPU in a loop, at high priority, with no yielding, no waiting, nothing that would let a scheduler consider it "idle" even for a moment. From the scheduler's point of view, that slot always had work to do, right now, more urgently than anything else. So it never gave up the CPU voluntarily, and the lower-priority SecureRandom client services underneath it functionally starved. They weren't failing because anything was wrong with them. They were failing because they were never getting scheduled at all.

Why this looked exactly like an RNG bug

From where I was sitting, the SecureRandom client tests were failing, so the SecureRandom client code was the obvious first suspect. That's a completely reasonable first assumption, and it's also a great example of why scheduler and service-composition behavior can hide behind a completely unrelated subsystem's symptoms. The bug wore the RNG subsystem's clothes. It had nothing to do with the RNG subsystem.

The fix, and a rule I want to be honest about

The actual fix was replacing that inappropriate busy-spin quiescent state with a proper blocking wait suited to how that composition of services was actually supposed to behave — let the restarted slot wait properly instead of spinning at full priority forever.

Here's the rule I want to be explicit about, because it's tempting after a satisfying fix like this one to retroactively explain every other weird thing that's ever happened as "oh, that was probably this same bug." I'm not going to do that. Other historical faults in this project that I never fully diagnosed stay unknown. I'm not rewriting old mysteries to make this one bug the tidy explanation for everything, just because it would make for a more satisfying narrative. It fixed exactly what it fixed.

The actual lesson here, the one worth keeping: a subsystem can look completely broken while being completely innocent, if something upstream of it is quietly eating all the CPU time it needed to prove otherwise. Worth remembering literally every time something "doesn't work" going forward. Which, as it turns out, came up again almost immediately — for a much, much dumber reason.

Originally published on The Weekend Report: https://theweekendersproject.com/report/the-rng-bug-that-wasnt-an-rng-bug

Random Numbers Turn Out to Be a Whole Damn Subsystem

Mike — Sun, 06 Sep 2026 12:00:00 GMT

I expected to spend an afternoon on random numbers. I spent a lot longer than an afternoon on random numbers, because it turns out trustworthy entropy is genuinely its own subsystem, not a library call.

I went into this expecting a fairly boring afternoon: get a random-number source working, wire it up, move on to something more interesting. That is not how it went, and in hindsight I should have seen it coming, because "random numbers you can actually trust" is a much bigger commitment than "random numbers that look random."

Why this needed its own subsystem instead of a library call

A single, central SecureRandom authority sits behind a proper DRBG — a deterministic random bit generator seeded from real entropy, not a quick call to whatever the standard library happens to expose. Consumers throughout Ceylon don't read raw entropy themselves; they go through SecureRandom, get output for a specific typed purpose, and never touch the underlying entropy pool directly.

Readiness is an explicit, checked state, not an assumption. If the entropy source isn't ready, or isn't trustworthy yet, the system fails closed — consumers that need randomness they can actually stand behind do not get handed something that merely looks plausible instead. That's a deliberately harder requirement than most systems bother enforcing, and it's exactly why this turned into its own subsystem instead of a two-line wrapper.

Purpose typing, and why reboot behavior needed its own rule

Different consumers get typed purposes rather than one undifferentiated "give me a random number" call, so the system has an honest, checkable record of what a given piece of randomness was actually used for. And reboot and state-loss behavior needed explicit rules of their own — what's allowed to persist across a restart, what must not persist, and what has to be freshly reseeded before anything is allowed to trust it again.

Built hardware-neutral, tested against a virtual source

The whole authority is architected to be hardware-neutral rather than tied to one specific entropy source, and for actual development and testing it currently runs against a virtual entropy source rather than a specific physical hardware RNG — consistent with the whole "reference machine first" discipline that's shown up throughout this journal since the QEMU entry. This isn't the part of the system I'm going to publish specifics of key material, internal state, or anything genuinely security-sensitive about — that's a hard line for obvious reasons, same as not naming the microkernel.

What I will say is: I did not expect "random numbers" to turn into one of the more architecturally serious subsystems on the whole platform. It did. And it's not even the last surprise entropy-adjacent work had for me this summer — the actual debugging story is next, and it's a genuinely good one.

Originally published on The Weekend Report: https://theweekendersproject.com/report/random-numbers-turn-out-to-be-a-whole-damn-subsystem

One Management API, Whether You Click It or Type It

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Whether you're driving Ceylon through a GUI or a terminal, it should be the same semantic backend underneath, not two tools that happen to overlap most of the time.

A pattern I see a lot in existing systems, and specifically didn't want to repeat: a GUI settings panel and a terminal command that do almost the same thing, maintained by almost the same logic, duplicated in two places, that quietly drift apart from each other over time until one of them supports something the other doesn't and nobody remembers why. Ceylon's management layer is built to avoid that by construction, not by discipline alone.

The actual design

There's one typed management API underneath everything, organized around domains — System, Services, Storage, Network, Logs, Apps. Both NuGUI and the terminal-facing management CLI are meant to eventually consume that exact same semantic backend, rather than each having its own parallel logic that happens to produce similar results most of the time.

The API draws a clear line between queries and mutations, and mutations are generation-aware — a change carries with it an understanding of what state it expects to be modifying, so a stale or conflicting change gets rejected rather than silently applied on top of something that's already moved on. That idea isn't unique to management operations either — it's the same generation-and-staleness discipline that shows up in the application-runtime entry's container reuse, applied here to configuration and system state instead of process containers.

Authority comes from the caller, not the wire

A management operation's authority comes from who's actually calling it, resolved through Horos, not from untrusted text sitting on the wire claiming to be privileged. That sounds like an obvious requirement once you say it out loud, but it's exactly the kind of thing that's easy to get subtly wrong if the management layer and the security layer are designed by two different trains of thought instead of one deliberately unified one.

Why this matters beyond just "less duplicated code"

The practical payoff, beyond just not maintaining two versions of the same logic, is that a future remote-management capability — something I haven't built yet, and I'm not going to pretend otherwise — gets to consume that same semantic layer instead of requiring a third parallel implementation. Building the shared semantic core first, before either surface, is what makes that a realistic future addition instead of a redesign waiting to happen.

Next entry is a genuine surprise from earlier this summer: it turns out random numbers are a lot more of a subsystem than "call a library function" would suggest, once you actually take them seriously.

Originally published on The Weekend Report: https://theweekendersproject.com/report/one-management-api-whether-you-click-it-or-type-it

Applications Without Pretending We're Unix

Mike — Sun, 06 Sep 2026 12:00:00 GMT

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

Ceylon Horos: The Lion at the Boundary

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Horos is Ceylon's security umbrella — the conceptual boundary between identity, credentials, authentication, sessions, and authority. The name comes from an old Greek word for a limit or boundary marker.

Every profile on Ceylon eventually needs to answer the same handful of questions: who is this, what are they allowed to prove, what does proving it actually grant them, and where exactly does that authority stop. I gave the umbrella concept covering all of that a name: Horos — the Ceylon security architecture.

What Horos actually covers

Conceptually, Horos spans directory services, a credential authority, authentication, authorization, session authority, a secure-random and cryptographic substrate, recovery, and provisioning. That's a wide net on purpose, because the whole point of naming it as one umbrella instead of a pile of unrelated features is to force the boundaries between those pieces to be explicit instead of assumed.

The boundaries, which are the actual point

The thing Horos is really about is drawing clean lines: between identity and credentials, between credentials and authentication, between authentication and a session, between a session and authorization, between raw authority and how it's presented to a user, between raw entropy and the random output something actually consumes, and between a pre-authentication screen and an authenticated desktop. Every one of those is a place where a lot of systems quietly blur two things that should be separate, and blurring them is usually where the security bugs live later.

I'll get into one of those boundaries in real, specific detail a couple of entries from now — the entropy one, and a bug that came out of a place I genuinely didn't expect. For this entry, I want to stay at the conceptual level, because the shape of the boundaries matters more than any one implementation detail sitting inside them.

Where the name comes from

Horos is an old Greek term, used in Gnostic writing, roughly meaning a boundary or a limit — a marker of where one thing ends and another begins. I picked it because that's exactly what this umbrella is: not a single feature, but the discipline of knowing precisely where one kind of authority ends and the next one's responsibility begins. The lion-at-the-boundary framing is symbolism, not a literal mascot and not a statement about anything beyond the naming itself — I want to be clear about that so nobody reads more into it than a name chosen because it fit.

With the security umbrella named and the boundaries drawn, the next real question is what actually runs inside those boundaries — and that turns out to require rethinking what an "application" even means on a platform that was never going to pretend to be Unix. That's next.

Originally published on The Weekend Report: https://theweekendersproject.com/report/ceylon-horos-the-lion-at-the-boundary

From Nu-Day to Ceylon: Stop Building the Workstation and Build the Computer

Mike — Sun, 06 Sep 2026 12:00:00 GMT

The pivot: one shared platform, validated across multiple profiles — workstation, server, security appliance, media workstation, development — instead of one narrowly-scoped media application pretending to be small.

If Nu-Day's problem was that a media workstation quietly needed to be a whole platform underneath it, the fix isn't to shrink the ambition back down to fit the old boundary. The fix is to stop pretending the boundary was ever the right shape, and build the platform on purpose instead of by accident. That's Project Ceylon.

One platform, multiple profiles

The core idea is simple to say and a lot of work to actually mean: one shared underlying platform, with multiple validated profiles built on top of it. A Workstation profile. A Server profile. A security-appliance profile I've been calling SBS internally. A Media Workstation profile — Nu-Day's original ambition, now honestly positioned as one profile among several instead of the whole project. A Development profile. And, further out, appliance and micro-device profiles once the shared foundation is solid enough to support them.

The difference between this and what Nu-Day was trying to do isn't really technical — a lot of the actual pieces are the same pieces. The difference is honesty about what's shared infrastructure and what's profile-specific behavior on top of it. Nu-Day tried to be one profile's worth of ambition wearing a full platform's worth of requirements. Ceylon is explicit that the platform comes first, and profiles are validated configurations of it, not separate projects that happen to share a name.

What the shared platform is meant to include, eventually

The long-term list of shared components includes a GUI layer (NuGUI), a terminal and management CLI, a system manager and file manager, authentication, networking, storage, service management, logging, a help system, and application launching. I want to be very direct about something: that is a list of intended shared components, not a list of finished ones. Some of them exist in early form. Some of them exist mostly as a clear design intent and not much implementation yet. I'll be specific about which is which as this journal goes on, and especially in the status-update entries — the whole point of writing this in public, as it happens, is that I don't get to quietly blur that line.

Why this is the right container this time

A profile-based platform means a media workstation can genuinely be a first-class citizen of Ceylon without every other use case having to be a media workstation too, and without the shared authentication, networking, and storage layers having to pretend they only exist to serve one profile's needs. That's the structural fix for Nu-Day's actual problem — not more discipline about scope, a container shaped correctly for what I was actually always trying to build.

The next few entries get into the shared foundation itself, starting with the part that turned out to need the most careful thinking of anything so far: security and identity, under a name I've been calling Horos.

Originally published on The Weekend Report: https://theweekendersproject.com/report/from-nu-day-to-ceylon-stop-building-the-workstation-and-build-the-computer

Why Project Nu-Day Failed

Mike — Sun, 06 Sep 2026 12:00:00 GMT

"Failed" doesn't mean nothing worked. It means the project's boundaries stopped making sense. Building a real media workstation meant building an entire operating platform underneath it, whether I'd scoped for that or not.

I'm not going to soften the title. Project Nu-Day failed. I want to say clearly what I mean by that, though, because "failed" is doing something more specific here than "nothing worked" — the last entry just spent its whole length showing you real, working evidence. This isn't that kind of failure.

What actually went wrong

Nu-Day started as a media-first workstation concept — a Video Toaster and DigiPaint-inspired system, aimed at real desktop video and graphics work on modern hardware. That was the boundary. That was the product definition I'd set for myself.

The problem is that actually building the infrastructure a real media workstation needs — a real application runtime, a real service model, a filesystem that behaves correctly, a network stack, a graphics system, identity and security handling, management tooling, hardware abstraction, recovery behavior, drivers — is, without any exaggeration, building an entire operating platform. Not "a media app with some OS-flavored plumbing underneath it." An actual platform, full stop.

Once I was honestly looking at that list, the media-only product boundary stopped making sense as a boundary at all. It wasn't protecting scope anymore. It was just an arbitrary line I'd drawn early, before I understood what I was actually committing to underneath it.

The temptation, and why I didn't just keep going

The tempting move, and I felt the pull of it more than once, was to just keep piling features into Nu-Day as I hit each gap — add the piece I was missing, call the product boundary flexible, keep the name, keep the momentum. I don't think that would have been dishonest exactly, but it would have been building a platform while still calling it a media app, and eventually the mismatch between what the thing actually was and what I was telling myself it was would have caught up with me in a much more expensive way than it did here.

The actual verdict

Nu-Day worked well enough to prove I was building the wrong-sized project.

That's the honest summary. Not "Nu-Day was broken." Not "the technical work was bad." The technical work — the last entry's worth of it — was real. What was wrong was the shape of the container I was trying to pour a platform-sized project into. A media-first workstation and a general-purpose operating platform are not the same thing wearing different names, no matter how much I wanted them to be, and pretending otherwise wasn't going to get easier the longer I put off admitting it.

So I stopped, and rethought the whole thing at the platform level instead of the application level. What came out of that rethink is Project Ceylon, and that's where this journal actually turns a corner — starting with the next entry.

Originally published on The Weekend Report: https://theweekendersproject.com/report/why-project-nu-day-failed

Project Nu-Day: What Actually Worked

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Before I get into why Nu-Day didn't survive, it deserves an honest accounting of what it actually proved. A working path is not the same thing as a finished subsystem, but it's not nothing either.

Before the next entry, where I get into why Project Nu-Day ultimately didn't survive in its original form, I want to give it a fair accounting of what it actually did prove. It would be easy to skip straight to the postmortem and let the failure overshadow real work that got done. That's not honest, and it's not the kind of history I want this journal to be.

What had real, working evidence behind it

Inside the QEMU virtual reference machine, there was real, demonstrated evidence for boot, for storage, for logging, for clock handling, for basic display output, and for service lifecycle behavior — services starting, checking in, and in the cases where I'd actually built it correctly, shutting down cleanly instead of just vanishing. That's not a small list. That's most of what a computer needs to be recognizably a computer, working, reproducibly, in the reference environment I'd built specifically so I could trust what I was seeing.

What had real but partial work behind it

Framebuffer and presentation primitives had real work behind them, even after the Iris architecture reset — the reset changed the approach, it didn't erase everything that had been learned getting there. Early semantic work on what eventually became Nu-Iris. Input handling. Real boundaries around filesystem responsibilities. Early concepts for bulk data descriptors. Genuine IPv4, ARP, ICMP, and UDP networking work. NuBasic work on both a host development target and an early static target.

None of that was finished. All of it was real — not mockups, not aspirational diagrams, actual working code exercised against the reference machine.

The distinction that matters

A working path is not the same as a finished subsystem.

I want to sit on that sentence for a second because it's going to matter a lot in the next entry. Having a working path through a problem — this boots, this responds, this proves the concept — is real and valuable. It is not the same claim as "this subsystem is done and production-ready." Conflating those two things is exactly how projects quietly grow scope nobody signed up for, which, as it turns out, is precisely what happened here.

So: credit where it's due. Nu-Day proved a lot. The reference-machine strategy from a few entries back paid off exactly the way I'd hoped — I could trust what I was seeing, because the virtual hardware underneath wasn't lying to me. What it also did, gradually and without me noticing for longer than I'd like to admit, was reveal the actual size of the thing I'd agreed to build. That's next.

Originally published on The Weekend Report: https://theweekendersproject.com/report/project-nu-day-what-actually-worked

What It Actually Takes to Drive an Intel Arc A770

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Good documentation gets you past the product page. What's underneath is PCIe, MMIO, firmware, command submission, and a long staged plan instead of one heroic attempt at everything at once.

Good documentation gets you past the product page. What's actually underneath — the part nobody puts in the marketing material — is PCIe enumeration, memory-mapped I/O, firmware handshakes, VRAM and GPU address space management, command submission and execution queues, synchronization, execution contexts, fault handling, reset behavior, CPU/GPU memory coherency, the media engines, and command validation so a bad or hostile submission can't take the whole GPU down with it. That's the actual job description, and none of it is optional if you want something more serious than "a triangle appeared once."

Why I'm not trying to do all of that at once

I've already got one very fresh scar from trying to skip ahead — that's the whole point of the Iris entry a few weeks back. So the plan for the Arc A770 work is explicitly staged, on purpose, in an order I chose specifically to avoid repeating that mistake.

The staged plan

First: discover and identify the device — get the platform to actually see and recognize the card as a real, present piece of hardware. Second: establish ownership — make sure exactly one part of the system has authority over it, no ambiguity, no two components racing to think they're in charge. Third: basic transfer and copy operations — move data to and from the card reliably before asking it to do anything clever. Fourth: controlled compute or render work — small, bounded, verifiable operations, not open-ended workloads. Fifth: measure and reassess before going further, honestly, based on what actually happened rather than what I hoped would happen. Sixth: media capabilities, later, once the foundation underneath them is solid. Seventh: display ownership, later still, and only if it turns out to actually be warranted rather than assumed.

That ordering is deliberate. Every step depends on the one before it actually being solid, not just apparently working. That's the lesson from Iris, applied on purpose this time instead of learned the hard way a second time.

A practical detail: headless, for now

The development machine's Intel UHD 630 integrated graphics can handle the actual display output while the Arc A770 operates headless — doing compute and, eventually, media work without also being asked to drive a monitor. That separation keeps the two concerns from tangling with each other while the A770 side is still young, and it means a mistake on the Arc side doesn't cost me my actual screen.

What this entry is not claiming

I want to be really clear, because it would be easy for this entry to read as further along than it is: this is not a finished driver. This is not even a mostly-finished driver. This is the plan, the constraints, and the ordering I'm committing to in public so that later entries can be measured honestly against it instead of me quietly redefining "done" after the fact. Progress on where this staged plan actually stands shows up in the status-update entries later in this journal, and I'm going to keep those honest about exactly which of these seven steps are real and which are still aspirational.

Next entry steps back from the GPU work entirely and takes stock of what Project Nu-Day, as a whole, actually managed to prove — because there's real evidence there, and it deserves an honest accounting before I get into why the project ultimately didn't survive in its original form.

Originally published on The Weekend Report: https://theweekendersproject.com/report/what-it-actually-takes-to-drive-an-intel-arc-a770

Could an Intel Arc A770 Be the Modern Amiga Custom Chipset?

Mike — Sun, 06 Sep 2026 12:00:00 GMT

The Arc A770 isn't a literal replacement for Agnus, Denise, and Paula. But one of the actual deciding factors in choosing it had nothing to do with raw performance: documentation is a hardware feature.

Let me say the thesis plainly, because it's easy to misread this entry as "look how powerful this GPU is" and that is genuinely not the point. The Intel Arc A770 is not a literal replacement for Agnus, Denise, and Paula. Nobody sane is claiming a discrete GPU from 2022 is a spiritual reincarnation of an Amiga custom chip. What I'm actually interested in is the philosophy those chips represented — specialized hardware doing specialized work, off the main CPU, as a first-class part of the machine's identity — and whether a modern GPU could fill that same architectural role.

The specs, briefly, because they matter but they're not the whole story

16 GB of memory. Xe-HPG architecture. Real render and compute resources, dedicated media engines for video encode and decode, XMX support for matrix-heavy workloads. On paper, plenty of horsepower to be a serious specialized-hardware partner to a general-purpose CPU, in the same structural role Agnus and Denise played decades ago even though the actual silicon has nothing else in common with them.

The deciding factor that isn't performance

For this project, documentation is a hardware feature.

Here's the thing that actually tipped the decision, and it surprised me a little how much it mattered once I sat with it: Intel publishes real, usable, developer-facing documentation about how this hardware actually works. Xe-HPG architecture documentation. Programming and optimization guides. Level Zero, as a genuinely open low-level API. Compute Runtime and the Media Driver, both open source, both on GitHub, both things I could go read right now if I wanted to (and I did want to, so I checked — they're real, they're maintained, and I've linked them below).

A GPU I can't get real information about is a GPU I'm reverse-engineering from scratch, no matter how good its silicon is. For a project already built on the discipline of "study the historical material to understand the architecture, don't just cargo-cult it," a vendor that hands you the architecture documentation instead of making you guess is worth an enormous amount. It's the difference between researching and reverse-engineering, and I already knew from the Video Toaster work which one of those I wanted to be doing.

What this is and isn't

This is not me claiming I'm about to have a finished, production-quality driver for this card. That's a much later entry, and even that later entry is going to have some very honest limits on what's actually done. This entry is just the decision: why this card, and why the documentation mattered as much as the silicon did.

Intel did not publish a manual called "How Mike Can Write an A770 Driver for His Weird Operating System." Unfortunately.

So no, having good documentation doesn't mean the work is easy. It means the work is possible, and honestly, on a project like this, that's most of what I need from a hardware vendor. The existing open Linux driver work and the open compute/media runtimes aren't things I'm going to blindly import — they're research and reference material, same rule as the Video Toaster source, same rule as everything else in this journal. Understand why it works, then build my own version for my own foundation.

Sources & Research: Intel Xe-HPG Architecture (introduction), Intel Compute Runtime (Level Zero / OpenCL), Intel Media Driver (VAAPI).

Next entry gets into what actually driving this thing looks like once you get past the product page and into PCIe, MMIO, command submission, and all the unglamorous plumbing a GPU driver actually is.

Originally published on The Weekend Report: https://theweekendersproject.com/report/could-an-intel-arc-a770-be-the-modern-amiga-custom-chipset

Why a Modern Amiga Needed a Secure Multicore Microkernel

Mike — Sun, 06 Sep 2026 12:00:00 GMT

The display failure was a symptom. The actual disease was an architecture with no real boundaries between components. The fix was moving to a security-certified microkernel foundation.

The display math failing wasn't really a display problem. It was a symptom of something bigger: the early architecture didn't have real boundaries between its pieces. When one part misbehaved, or scaled wrong, or made a bad assumption, there was nothing structurally stopping that from becoming everyone else's problem too. That's fine for a demo. It is not fine for anything I'd want to call a real platform.

What 1985 could get away with that 2026 can't

The Amiga's security model — to the extent "model" is even the right word for it — assumed one person at the keyboard, running software that person chose to run, on a machine that was never going to sit exposed on a network being poked at by things nobody invited. That was a completely reasonable assumption in 1985. It is not a reasonable assumption for a long-lived, networked, modern machine in 2026, one that's going to run software I didn't personally audit line by line, handle data I don't fully trust, and stay running for a long time without a reboot fixing whatever's wrong with it.

A modern continuation of this machine's philosophy needed real fault isolation. Real authority boundaries — not "this program probably won't do anything bad," but structural guarantees about what a given piece of code is and isn't allowed to touch. The ability for one service to crash, misbehave, or get compromised without taking the rest of the machine down with it. And underneath all of that, multicore support done properly, because "properly" was never going to mean "one core doing everything while the others watch."

The foundation, and what I will and won't say about it

This is the point where I need to be direct about something I'm keeping deliberately vague, on purpose, permanently: I'm not going to name the specific microkernel underneath this project. Publicly, this runs on a security-certified microkernel foundation, and that's the extent of what I'll say about the specific technology choice in this journal, now or later. That's not me being coy for dramatic effect — it's a boundary I've set for how I talk about this project publicly, and I'm going to hold it consistently across every entry in this series, not just this one.

What I will talk about is the reasoning, because the reasoning is the actually interesting part anyway. A security-certified microkernel foundation gives you capability-style authority instead of ambient trust — a piece of code can only do what it's been explicitly handed the authority to do, not whatever the OS happens to allow by default. It gives you services that can restart independently instead of taking the whole machine down with them when they fail. It gives you a foundation that was actually built and verified with the assumption that hostile or buggy code is going to show up eventually, instead of a foundation that assumes good faith from everything running on it.

What this actually changes

This is the point where "a modern Amiga" stopped being a slogan and started being an actual architectural commitment. The custom-hardware-as-division-of-labor idea from the original machine doesn't go away — it gets stronger, because now each piece of specialized work can live in its own properly isolated service instead of all sharing one undifferentiated address space and hoping for the best. Fault isolation and the Amiga's original "let the right hardware do the right job" philosophy turned out to reinforce each other instead of fighting each other, which I honestly wasn't sure would be true until I was well into building it.

This decision is still standing today. It's the actual foundation everything downstream of this entry gets built on. Next up: the hardware side of the equation, and a decision that turned out to hinge less on raw horsepower than I expected, and a lot more on something Intel does that a lot of vendors don't — they actually tell you how their hardware works.

Originally published on The Weekend Report: https://theweekendersproject.com/report/why-a-modern-amiga-needed-a-secure-multicore-microkernel

Well, Hell: The Iris Math Doesn't Work

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Pixels appearing on screen is not the same thing as an architecture that scales to real high-resolution video editing. I found that out the hard way, and I was irritated about it for the rest of the night.

I want to get something out of the way before I write the rest of this entry: I was irritated. Not "disappointed, but it's all part of the process" irritated. Actually irritated. The kind where you stare at a terminal for longer than is useful because some part of you is hoping the numbers will change if you just keep looking at them.

Here's what happened. Early display work — the stuff that eventually got the working name Nu-Iris — got to the point where pixels were showing up on screen. Real pixels, from real framebuffer writes, through the pipeline I'd built. And for about a day, that felt like a genuine win.

Pixels appearing is not the same thing as "this works"

Then I actually sat down and did the math on what the intended display path would need to sustain for the kind of high-resolution video editing this whole project was supposed to be aimed at — remember, this traces back to the Video Toaster, to DigiPaint, to real media work, not just "can we draw a window."

I was irritated. The math showed the intended display path would not scale to the kind of high-resolution video editing being targeted.

I want to be careful here about a promise I made to myself for this journal: I'm not going to invent specific numbers I can't actually stand behind just to make this section feel more dramatic or more technical. The honest version is this: the bandwidth and resource-scaling pressure of real high-resolution video work, run through the assumptions the early display architecture had baked in, did not close. Not "tight, but workable." Did not close. The gap wasn't a rounding error I could optimize away with a better inner loop — it was structural, baked into decisions I'd made early about how the pipeline moved data around.

What assumptions were actually being tested

The core assumption under the microscope was something like: if the basic framebuffer path works for getting pixels on screen at all, then scaling it up to real editing workloads is a matter of degree, not a matter of kind. That assumption is exactly the kind of thing that feels true right up until you actually run the numbers, and then it very much does not feel true anymore.

"Pixels appeared" answers the question "does this pipeline function at all." It does not answer the question "does this work for a real high-resolution media workstation," and those are genuinely different questions wearing the same demo. I'd let the first one quietly stand in for the second one for longer than I should have, mostly because the first one felt so good to finally see working.

Why the architecture had to be reconsidered

Once the math didn't close, there wasn't a patch available — I couldn't just tune the existing pipeline harder. The scaling problem was upstream of any individual optimization I could make downstream. That meant going back to the display and media architecture itself, which is a genuinely bad feeling a few months into a project, when you've already convinced yourself the hard part was behind you.

This is also, in hindsight, the same lesson DigiPaint's painting engine had already handed me a few entries back, and I hadn't fully absorbed it yet: the hard constraint in real-time media work is almost never the math you're doing to a single pixel, it's how much data you're moving and how often. I'd read that lesson. I hadn't yet felt it in my own broken numbers. Now I had.

I'd stared at it long enough for one night. I think we had enchiladas. The enchiladas worked, which at that particular moment felt like it should count for something.

What came out of this, eventually, was a much more serious conversation about isolation, resource ownership, and — the thing that actually ties directly to the next entry — why a modern version of this machine needed real service boundaries and real fault isolation from the ground up, not bolted on after the fact once something like this went wrong in production instead of on my own desk.

Originally published on The Weekend Report: https://theweekendersproject.com/report/well-hell-the-iris-math-doesnt-work

Why I Built the Computer in QEMU Before I Built the Computer

Mike — Sun, 06 Sep 2026 12:00:00 GMT

QEMU was never the destination. It was the laboratory — a reference machine where I could isolate architecture mistakes from hardware-driver mistakes before either one had a chance to hide behind the other.

QEMU was never the destination. I want to say that as plainly as I can, because it's easy to read "I built it in a VM first" and assume that's a placeholder step on the way to the real thing, like scaffolding you tear down once the building's up. That's not what it was. QEMU was the laboratory, and a laboratory is a permanent, useful thing, not a placeholder.

The actual problem it solves

Here's the failure mode I was trying to avoid: you're building a new system, and something doesn't work. Is it because your architecture is wrong, or because you're fighting a driver for a specific piece of real hardware that has its own quirks, its own undocumented behavior, its own timing weirdness? On bare metal, those two categories of bug look identical from the outside. They both just look like "it doesn't work." And when they look identical, you end up debugging the wrong layer half the time, because you genuinely can't tell which one you're looking at.

A virtual reference machine breaks that tie. QEMU's virtual hardware is well-documented, consistent, and — critically — the same every single time you boot it. If something's broken in QEMU, it is overwhelmingly likely to be my architecture, my IPC design, my service boundaries, because the virtual hardware underneath isn't the kind of thing that has mystery quirks nobody's written down.

What actually got built and tested this way

Storage. Networking. Display. Interrupt handling. The lifecycle of services starting up, checking in, and (when I did it right) getting torn down cleanly. DMA-like data paths between components. All of that got built and exercised against QEMU's virtual hardware first, where I could trust that any weirdness I saw was a weirdness I'd introduced, not a weirdness the silicon introduced.

Reproducibility was a big part of the appeal too, and I don't think I appreciated how much until I had it. Every boot starts from the same state. Every bug is, in principle, reproducible by just booting again with the same inputs. That's a genuinely rare property to have handed to you for free, and bare metal does not hand it to you for free — bare metal hands you thermal variance, firmware quirks, and hardware that ages differently than the hardware on someone else's desk.

The plan for what comes after

The eventual plan — and I want to flag this as a plan, not a thing that's done, because overclaiming that part would be exactly the kind of thing I'm trying not to do in this journal — is to use everything proven in the virtual reference machine as a template and a comparison point once real hardware enters the picture. If bare metal behaves differently than the virtual reference did, that's a signal, not a surprise to just shrug at. It tells you where the real hardware's assumptions diverge from the clean ones, and that's exactly the information you want before you start blaming your own architecture for a problem the silicon caused.

This decision held up well. It's still how I work today. What didn't hold up nearly as well was the early display and media architecture I built on top of it — and that one's next, because it's the first real gut-punch of this whole project, and I'm not going to sand the edges off it.

Originally published on The Weekend Report: https://theweekendersproject.com/report/why-i-built-the-computer-in-qemu-before-i-built-the-computer

Project Nu-Day: Okay, Y'all, Let's Actually Build Something

Mike — Sun, 06 Sep 2026 12:00:00 GMT

All that research had to turn into something eventually. Project Nu-Day was the first real attempt: a modern media workstation, built for x86-64, inspired by the Toaster and DigiPaint but not trying to be either.

At some point, research has to turn into a project, or it's just a very well-organized way of reading old documentation forever. So: Project Nu-Day. That was the name for the first real attempt to build something out of everything I'd been chewing on — the Amiga's good ideas, the Video Toaster's approach to real-time media, DigiPaint's painting engine — aimed at modern, ordinary, commodity x86-64 hardware.

What Nu-Day was actually trying to be

The goal was a media workstation. Not an operating system for its own sake — a machine built around the idea that graphics, video, and painting-style tools deserved to be first-class citizens of the platform, the same way they were on the Amiga, but running on hardware you could actually buy in 2026 instead of hardware you'd have to find on an auction site.

I was explicit with myself from the start that this was not an emulator project. I wasn't trying to run Amiga binaries. I was trying to build a new thing that took the same philosophy — specialized hardware doing specialized work, multimedia as identity, responsiveness that a person can feel — and applied it fresh, on hardware nobody in 1985 had any reason to design for.

Virtual first, on purpose

From day one I decided this was going to be developed virtual-first — inside QEMU, not on bare metal. I'll spend the entire next entry on why that decision mattered as much as it did, because it's not just "easier for development," it's a real architectural strategy. For now: I wanted a laboratory before I wanted a machine.

Early hardware abstraction thinking

Even at this early stage, I knew I didn't want the media/graphics ambitions hard-wired to one specific piece of hardware. The whole point of "specialized hardware doing specialized work" only holds up if the software layer knows how to talk to specialized hardware in general, not just one card I happened to own. That idea was still pretty vague at this point — more of a discipline I was trying to hold myself to than an actual abstraction layer with real boundaries — but it's the seed that eventually turns into a much more serious conversation once GPU work enters the picture.

Nu-Day was ambitious for what it was, and I want to be honest that at this point I did not yet see the shape of the problem I was actually walking into. That comes later, and it comes from a direction I did not expect: not from the media ambitions failing, but from the media ambitions succeeding just enough to reveal how much operating system I was quietly agreeing to build underneath them.

Next up: why the very first real infrastructure decision was to build the computer inside QEMU before building anything resembling the computer itself.

Originally published on The Weekend Report: https://theweekendersproject.com/report/project-nu-day-lets-actually-build-something

Old Source Code Is Useful. Copying It Isn't the Point.

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Having thirty-year-old source code available doesn't mean the job is to transcribe it. Here's how I actually use historical material as research instead of a shortcut.

I said in the last entry I'd come back to this, because it's the kind of thing that's easy to say correctly in one sentence and then get wrong in practice if you're not paying attention. So: having the Video Toaster's source available doesn't mean the job is "go copy the good parts into a modern language." That's not research, that's just slow transcription with extra steps, and it would also potentially be a licensing mess I have no interest in stepping into.

What I'm actually doing with it

When I read old source — Toaster code, DigiPaint's painting engine, whatever else turns up as this project goes on — I'm reading it for behavior and architecture, not for lines to lift. What data structure did they reach for when they needed to composite video in real time on hardware with no headroom to spare? What order did they do operations in, and why that order and not another one? Where did they put the boundary between "the hardware does this" and "software does this," and does that boundary still make sense on completely different hardware forty years later?

Those are architectural questions. The answers to those questions are useful to me. The literal C (or 68k assembly, in some of the older stuff) that implements those answers on a machine that hasn't been manufactured in decades is a lot less useful, because it's solving problems — memory pressure, clock speed, a specific bus architecture — that mostly don't exist on the hardware I'm targeting anymore. Studying WHY something worked survives the trip to modern hardware. WHAT LINE OF CODE did it survives a lot less well.

Provenance matters, and clean-room separation isn't paranoia

I try to keep a clean separation between "I read this and now I understand the problem better" and "I am now writing code." That's not me being precious about it — it's just good practice any time you're working with someone else's historical material, licensed release or not. If I understand a design decision well enough to reimplement it from a description of the problem, without the original code open in another window while I type, that's a real, defensible clean-room boundary. If I'm translating line by line, that's not research anymore, that's a port, and it comes with a completely different set of obligations I'm not trying to take on here.

This matters doubly because NewTek's release explicitly comes with usage terms, and even generous ones deserve to be respected on their own terms rather than stretched to cover something the release wasn't meant for.

A concrete example: DigiPaint

DigiPaint's painting engine had to do real-time brush rendering and color manipulation on hardware that measured its memory in kilobytes it could actually spare for the framebuffer. Reading how they approached that taught me something about where the actual hard constraints in a painting tool live — it's rarely the brush math itself, it's how aggressively you can avoid touching memory you don't have to touch. That's a genuinely portable lesson. It shows up again in completely different form when I get to display architecture a few entries from now, and — spoiler for an entry I haven't written yet — getting that lesson wrong is a real part of why an early display approach didn't survive contact with actual requirements.

So: old source code, useful. Old source code as a find-and-replace target for a modern rewrite, not useful, and honestly a little bit of a trap. Next up, the project this research actually turned into: Project Nu-Day.

Originally published on The Weekend Report: https://theweekendersproject.com/report/old-source-code-is-useful-copying-it-isnt-the-point

Then I Found the Video Toaster Source Code

Mike — Sun, 06 Sep 2026 12:00:00 GMT

NewTek released the Video Toaster's source publicly years ago. That's where the real research thread started — not the Amiga's OS, but the thing that made the Amiga famous in the first place.

If you want to know what the Amiga was actually good at — not what it was capable of in theory, what it was famous for, what put it on television sets — the answer is the Video Toaster. NewTek built a desktop video production system on top of the Amiga that could do real broadcast switching, graphics, and character generation on consumer hardware, at a fraction of what dedicated video hardware cost at the time. That's not a footnote in the Amiga's history. For a lot of the outside world, that WAS the Amiga's history.

So when I started asking what a modern continuation of this machine should be able to do, the Toaster was the obvious first research thread. Not the OS internals — the actual flagship application people bought the machine to run.

[A demonstration video of the original Video Toaster running live was embedded here in the original post.]

Finding it was still there

Here's the thing that got me excited enough to stay up later than I should have: NewTek actually released the Video Toaster source publicly a while back, and it's still sitting out there, maintained by a small community, at discreetfx.com. Full source. Developer documentation. The Flyer. ToasterCG. DigiPaint. All of it, or at least a meaningful chunk of it, available for anyone willing to go dig.

I want to be careful here, because it would be really easy to overstate what this means. This isn't a green light to lift code. I'll get into exactly how I think about that boundary in the next entry, because it deserves its own space and it's more subtle than "copy good, don't copy bad." For this entry, I just want to talk about what's actually there and why it mattered to me.

What became researchable

Desktop video switching, in source form, from a company that was actually shipping it commercially. Graphics and character-generation code from ToasterCG, which — for the era — was doing professional-quality titling and scrolls on hardware that cost a fraction of the broadcast equipment it was replacing. DigiPaint's painting engine. Developer documentation that explains not just what the code does but why it was built that way, which is honestly the more valuable half.

That's a real body of research material about how a small team in the late '80s and early '90s solved genuinely hard real-time media problems on genuinely limited hardware. Reading it doesn't hand you a modern architecture. It hands you a set of real, tested decisions about where the hard parts of a media system actually are, made by people who had to ship something that worked on live television.

A note on link rot

I checked every one of these links before publishing this, because half the pain of pointing people at 30-year-old software history is that the links are usually dead by the time anyone follows them. Most of what's below is still live. One document I originally wanted to cite — a PDF that was supposed to be the NewTek Video Toaster Developer's Handbook — turned out, when I actually opened it, to be a scanned document from a printer with nothing to do with the Toaster. So it's not in the list below. I'd rather tell you a source didn't pan out than link you to something that looks official and isn't.

Sources & Research: Open Video Toaster — project history and downloads (DiscreetFX); Amiga Video Toaster Complete archive; DigiPaint — source and binary download; Flyer — download; ToasterCG — download.

I'm not going to reproduce any of that source code here — that's not what this journal is for, and it's not how I want to treat someone else's work. What it's for is the next entry: how I actually think about using historical source as research without just becoming a very slow, very legally questionable copy-paste operation.

Originally published on The Weekend Report: https://theweekendersproject.com/report/then-i-found-the-video-toaster-source-code

What Was Actually Worth Saving From the Amiga?

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Before building anything, I had to separate what I actually loved about the Amiga from what I just remembered fondly. Those turned out to be two different lists.

Before I could design anything, I had to do something a little uncomfortable: go through everything I remembered loving about the Amiga and sort it into two piles. Pile one: things that were genuinely good architecture. Pile two: things I just remembered fondly because I was younger and everything was more exciting back then.

Nostalgia is a hell of a filter, and it lies to you in a very specific way — it tells you the whole package was great, when usually what was great was three or four ideas wearing a costume made of 1985 hardware limitations.

What earned its place

Multitasking that actually felt responsive was the big one. Not multitasking as a checkbox feature — multitasking that a person sitting at the keyboard could feel. Things kept moving while other things were happening. That's a real, durable design goal, and it's one a lot of "modern" systems still get wrong in their own ways.

Custom hardware as a division of labor was the second one. Agnus, Denise, Paula — I'm not defending the specific chips, I'm defending the idea that they represented: don't make one general-purpose processor do everything. Let dedicated hardware do the parts it's actually good at, and let it do that work without babysitting from the CPU. DMA wasn't just a technical trick, it was a philosophy about where work belongs.

Multimedia as a first-class capability, not a bolt-on. Coherent system integration — the sense that the OS and the hardware were designed by people talking to each other, not two teams that never met. Those all survive the trip to 2026 fine. They're not nostalgia, they're just good engineering that happened to ship in 1985.

What doesn't automatically survive

Here's the harder pile. The old address spaces don't survive — there's no principled reason to drag 24-bit addressing into 2026 out of loyalty. The exact chipset register layout doesn't survive; that's an implementation detail of hardware that hasn't been manufactured in decades. CPU-specific assumptions baked into the OS don't survive. Old memory constraints don't survive — those were constraints, not choices, and constraints from forty years ago don't deserve a vote in 2026's design.

And the big one, the one I keep coming back to: the trusted-single-user-at-the-keyboard assumption does not survive. The Amiga's security model, to the extent it had one, assumed the person touching the machine was the only person who'd ever touch it, and that whatever ran on it could be trusted about as far as the OS could throw it. That was fine in 1985. It's not fine for a machine that's going to sit on a network in 2026. I'll get into exactly what that means for the architecture a few entries from now, but I want to flag it early: this isn't a small asterisk, it's one of the load-bearing decisions of the whole project.

Exact binary APIs don't survive either, for what I'd hope is an obvious reason — there's no binary compatibility target here. Nobody is running original Amiga executables on this thing today. That's explicitly a job for a future emulator, not something baked into the core design.

The actual question

Which parts were principles, and which parts were just 1985?

That's the sorting test I used on everything, and it's the same test I'm going to keep applying as this journal goes on. Every time something from the old machine shows up in a design conversation, that's the question: is this a principle worth carrying forward, or is this just what 1985 looked like wearing a costume made of nostalgia? Next up: the machine that actually got me started down this road in the first place, and the reason it wasn't the Amiga's OS — it was the Video Toaster.

Originally published on The Weekend Report: https://theweekendersproject.com/report/what-was-actually-worth-saving-from-the-amiga

What If Amiga Development Never Stopped?

Mike — Sun, 06 Sep 2026 12:00:00 GMT

Commodore went bankrupt in 1994 and took continuous Amiga development down with it. This is the question that started everything: what would still be true if it hadn't.

I want to be upfront about something before I write another word of this: I am not rebuilding an Amiga 500. I am not rebuilding an Amiga 1200. Nobody is getting a cycle-accurate Motorola 68000 out of me, and if that's what you came here for, this whole series is going to disappoint you early and often.

What I'm actually chasing is a different, weirder question, and it's the one that started this whole thing: Commodore went bankrupt in 1994. Amiga development, as a continuous line, stopped. Not the ideas — people kept the ideas alive in emulators and hobbyist projects and a couple of increasingly sad corporate ownership changes — but the actual forward motion of "what does this architecture become next" stopped cold.

So: what if it hadn't? What would be sitting on somebody's desk in 2026 if that story had never been interrupted?

We're not rebuilding the Amiga of 1987. I'm trying to figure out what might have been sitting on somebody's desk in 2026 if the story had never stopped.

That's an alternate-history engineering question, not a preservation project, and the distinction matters more than it sounds like it should. A preservation project asks "how do we keep the old thing running." I'm asking "what would the old thing have grown into." Those point in almost opposite directions once you actually start working.

Principles versus hardware constraints

The Amiga in 1985 got a handful of things right that most of the industry took another decade or more to catch up on. Real preemptive-ish multitasking on consumer hardware. Custom chips doing real work off the main CPU instead of the CPU doing everything itself. Multimedia — audio, video, graphics — treated as first-class citizens of the machine's identity instead of an afterthought bolted on by a sound card manufacturer. A sense that the hardware and the OS were one coherent idea, not a CPU with a pile of drivers stapled to it.

None of that is 1985-specific. Responsiveness, asynchronous operation, modularity, specialized hardware doing specialized work, multimedia as identity, efficient use of what you've got, a coherent machine/OS relationship — those are principles. They'd be just as correct in 2026 as they were then.

What IS 1985-specific: the exact chipset, the exact address space, the exact CPU family, the assumption that whoever's sitting at the keyboard is the only person who will ever touch this machine and can be trusted completely. Those aren't principles. Those are just what 1985 hardware and 1985 threat models looked like.

Modern hardware and modern security requirements are going to change the implementation of every single one of those good principles. That's not a compromise on the vision — that's the actual work. Anybody who tells you they're bringing back the Amiga unchanged is either rebuilding a museum piece or lying to you about the scope.

Where this is going

I've already gone and looked at NewTek's Video Toaster, because if you're asking "what was the Amiga good at that nobody else was doing," desktop video is most of the answer. That's next.

Y'all are going to see this thing change shape more than once over the course of this journal. I'm not going to clean that up after the fact and pretend I knew where I was going the whole time. I didn't. I still don't, entirely. That's kind of the point of writing it down as it happens instead of after.

Originally published on The Weekend Report: https://theweekendersproject.com/report/what-if-amiga-development-never-stopped