Project Ceylon Development Log — September 25, 2026: Okay, So What Exactly Is A1 Alpha?
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 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.