Project Ceylon Development Log — September 23, 2026: So, How Much of This Thing Actually Exists?
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 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.