Project Logs

Collapse

• Project Ceylon Development Log — October 9, 2026: Asteroids Is Running. Please Don’t Call It a Game Yet.

  Mike • 7 hours ago • 0 comments

  Today was not a dramatic Ceylon day.

  It was a slow, sleepy, stare-at-the-same-log-for-too-long kind of day.

  Most of it was spent trying to get Asteroids across the line from:

  “there is application code in the machine”

  to:

  “I can actually sit down and play Asteroids.”

  We are not there yet.

  But we're considerably closer than we were yesterday.

  The Good News: It Actually Launches

  The application path made real progress.

  Asteroids can now make it through the normal Ceylon machinery far enough to enter its native application code, get a drawing surface, and push application pixels through NuGUI and Nu-Iris toward the display.

  That's important because this is no longer a fake built-in demo or some special test program living outside the normal application model.

  We're trying to make the game behave like an actual Ceylon application.

  Application exists.

  Desktop discovers it.

  User launches it.

  Application gets an isolated runtime slot.

  Application gets a window/surface.

  Application draws.

  That much is becoming real.

  The Bad News: Blue Is Apparently a Video Game Now

  At one point we had a screenshot that, according to the instrumentation, contained Asteroids output.

  I looked at it.

  It was blue.

  Mostly blue.

  There were a few tiny white points hiding in there if you were feeling charitable.

  Technically, those pixels had traveled through the right machinery.

  Technically, the application had produced output.

  Technically, I suppose this was progress.

  Visually?

  Nope.

  If I showed that screenshot to somebody and said, “Look, Asteroids is running,” they would quite reasonably assume I needed sleep.

  So we tightened the definition of success.

  “Application pixels reached the display” is useful engineering evidence.

  It is not the same thing as:

  “Asteroids is visibly running.”

  And neither of those is the same thing as:

  “Asteroids is playable.”

  Operating-system development apparently requires a surprisingly large vocabulary for saying, “Almost.”

  Then We Had to Make Time Exist

  Once the application could launch and render something, the next problem was animation.

  The host version of the game already has a perfectly good game loop.

  We're not rewriting that.

  The job is to replace the host computer's timing assumptions with Ceylon's own timer/event machinery.

  That sounds simple.

  “Send the game a tick every so often.”

  Sure.

  Except the timer has to belong to the correct application instance, survive the right things, disappear when the application disappears, avoid delivering stale events after a restart, and arrive through the same bounded runtime model as everything else.

  Eventually we did get legitimate timer-driven application updates moving through the Ceylon path.

  Frames started advancing.

  Which means we've progressed from:

  blue rectangle

  to:

  blue rectangle capable of changing over time.

  Look, I'm taking the wins where I can get them.

  Input Is the Next Annoying Little Detail

  Of course, an animated Asteroids game that can't hear the keyboard is basically a screensaver with ambition.

  So the remaining work is centered on the semantic input path.

  The keyboard already exists.

  NuGUI already receives input.

  Asteroids already knows what “left,” “right,” “fire,” and “thrust” mean.

  The missing bit is proving that the normal Ceylon path reliably carries those user actions all the way into the running application instance and that the game responds properly.

  No direct injection.

  No test-only shortcuts.

  No reaching around the desktop and poking the game with a stick.

  The point of this exercise is not merely to get Asteroids working.

  The point is to prove the path that every later interactive Ceylon application will need.

  Which is why a tiny arcade game has somehow become an operating-system integration test.

  I regret nothing.

  Mostly....

  Read more »

• Project Ceylon Development Log — October 8, 2026: We Fixed the Filesystem. Then We Went App Shopping.

  Mike • 15 hours ago • 0 comments

  Today Ceylon did something deeply suspicious.

  It saved a file.

  Then it rebooted.

  Then the file was still there.

  I know. Wild stuff.

  For a normal computer, this is not exactly a headline feature. For an operating system we're building from the microkernel upward, though, persistence is one of those wonderfully ordinary things that requires a ridiculous amount of machinery to be correct underneath it.

  And today we got a much better handle on that machinery.

  Storage Finally Behaved Like Storage

  The filesystem repair work moved from "we think we know what's wrong" into an actual qualified fix.

  The repaired path passed the ext4/JBD2 tests, created and read a 6,144-byte file, edited and saved a 9,216-byte file, rebooted the machine, and recovered the data afterward.

  The resulting image was also reproducible. The governed build inputs and payload checks passed, and we got the same ISO again.

  That's the sort of boring result I want more of.

  Create something. Save it. Reboot. It's still there.

  There are entire layers of engineering hiding under those four sentences.

  The application-runtime work also got considerably farther. The core runtime tests reached 48 out of 48, and later filesystem qualification reached 80 out of 80 with the filesystem reaching its Ready state.

  But there's an important line I don't want to blur:

  Ceylon still has not proven the complete normal application-launch path.

  The runtime machinery exists. The filesystem can hold the application. The catalog and drawer concepts exist.

  What still needs proof is the entire normal path from:

  application on disk → discovery → drawer → user selection → launch

  No cheating with a test fixture or direct invocation.

  If I click the thing, the thing should run.

  Apparently that's considered desirable in desktop computing.

  Asteroids Volunteered as Tribute

  We've been looking for a small real application to use as the first proper windowed-app qualification target.

  Asteroids is getting that job.

  The host-side version is in decent shape. Its tests passed, and the repaired demo ran for 1,800 frames.

  What it does not have yet is the complete Ceylon-side entry point, packaging, NuGUI adapter and normal discovery/launch path.

  That's actually useful.

  A tiny game is a much better application-runtime test than a fake "hello window" program because it wants input, drawing, timing and a real event loop.

  And if the application loader is broken, at least eventually we'll be able to demonstrate the failure with an asteroid.

  Then We Went Rummaging Through Somebody Else's Workshop

  A large part of today was application research.

  We spent time looking closely at the open-source ArtCraft family of Rust applications.

  There are twelve projects in the set, covering areas like PDF work, audio, image editing, vector graphics and other creative and productivity tools.

  Rather than immediately forking everything and announcing that Ceylon now has twelve new applications—which would be an excellent way to create twelve new problems—we took the less exciting route.

  We preserved exact source snapshots, pinned the versions, recorded the manifests and hashes, reviewed the dependencies, reviewed the licenses, and started separating the useful application engines from the assumptions those applications make about their current desktop environment.

  In other words:

  Preserve first. Understand second. Port third.

  No ArtCraft application was proven running on Ceylon today.

  That's the research result, not a disappointment.

  The interesting part is that several of them look potentially reusable if we can give them a proper Ceylon application/runtime layer instead of attempting to drag an entire foreign desktop framework into the operating system.

  NuGUI Does Not Need to Become egui

  That led into a useful UI discussion.

  A number of the ArtCraft applications use Rust's egui toolkit.

  NuGUI and egui are not the same kind of thing.

  NuGUI is part of Ceylon's desktop architecture. egui is...

  Read more »

• Project Ceylon Development Log — October 7, 2026: The Build Reproduced. Then We Started Designing What Runs on It.

  Mike • a day ago • 0 comments

  Mike · October 7, 2026

  Tags: Project Ceylon, Operating Systems, Reproducible Builds, Storage, Browser, Video, Audio, FFmpeg, VST, Applications

  Yesterday was mostly about figuring out what kind of applications Ceylon eventually needs if this thing is supposed to become somebody's actual computer.

  Today started by making sure we can reliably build the computer underneath them.

  That seems like the correct order.

  It would be slightly embarrassing to spend months designing a browser, video player and music-production environment only to discover that two nominally identical Ceylon builds are actually different machines.

  So a significant part of today's work went back down into the build and qualification machinery.

  And, for once, it gave us a pleasantly boring answer.

  Build it twice. Get the same thing twice.

  That's a milestone I will happily take.

  The Build Finally Had to Prove Itself

  We've been tightening the Ceylon build process for a while now.

  The rule we've settled on is deliberately unforgiving: there is one governed candidate, one expected source baseline, one manifest describing what belongs in the image, and one qualification process.

  If an expected input is missing, that's a failure. If an input is the wrong one, that's a failure. If a payload doesn't match what the manifest says should be there, that's a failure.

  No "well, the ISO still booted."

  No quietly grabbing whatever happens to exist in an old build directory.

  No reconstructing history from shell scrollback three days later.

  Today's canonical image run got through that process cleanly.

  All 7 expected build inputs were accounted for. All 46 expected payload checks passed on the first build.

  Then we built it again.

  All 46 passed again.

  More importantly, the two ISO images were byte-for-byte identical, with the same SHA-256 hash.

  That is considerably more interesting to me than "the build completed successfully."

  A successful build tells you the build system made something.

  A reproducible build tells you it made the thing you intended to make.

  The resulting image also made it through the initial QEMU smoke path: GRUB loaded, the microkernel started, the system environment came up, and the Intel IOMMU configuration was present.

  So the build side of the machine is getting much less mystical.

  Good.

  Mysticism is a terrible dependency manager.

  Runtime Testing Immediately Found Something Else

  Naturally, once the build process stopped being the problem, runtime testing found something else to complain about.

  One test configuration produced what looked like an RNG failure.

  That would have been irritating because the RNG path has already been through quite a bit of qualification.

  It turned out the failure wasn't really about the RNG.

  The wrong QEMU invocation had been used.

  A one-drive configuration had been run where the intended machine expected the fuller storage setup.

  That changes more than "there is one less disk."

  Ceylon's qualification work increasingly treats the complete machine definition as the artifact: devices, ordering, storage layout, firmware, launch arguments, everything.

  So testing the wrong launch configuration and then blaming whichever service screams first is not particularly useful.

  Once that was understood, the storage investigation got more interesting.

  Storage Managed to Make Logging Look Guilty

  One of the problems we found involved filesystem metadata being damaged during a run.

  For a while that looked suspiciously like the storage stack itself had gone off the rails.

  The trail eventually led somewhere stranger.

  Diagnostic logging activity had managed to overwrite part of the ext4 image metadata.

  That is the sort of sentence that makes perfect sense after you've spent enough time building an operating system and absolutely no sense before.

  The other storage issue was architectural rather than corruptive: one composition path only represented a single block device even though the QEMU machine had a...

  Read more »

• Project Ceylon Development Log — October 6, 2026: Apparently We’re Building an Office Now

  Mike • 2 days ago • 0 comments

  Mike · October 6, 2026

  Tags: Project Ceylon, Operating Systems, Applications, Office Suite, Browser, Rust, Reproducibility, R&D

  Today was one of those Project Ceylon days where the actual coding work mattered, but some of the more interesting progress happened because we stopped and asked what kind of computer we're actually trying to build.

  That question wandered through office software, communications, web browsers, build reproducibility, a storage problem, and eventually back around to one of the recurring Ceylon themes:

  A computer is not finished because the operating system boots. It is finished when somebody can sit down and do useful work with it.

  We're still a long way from that finish line.

  But the picture of what needs to exist on the other side of Alpha got considerably clearer today.

  Okay, apparently Ceylon needs an office

  We've talked about individual productivity applications before.

  Word processor.

  Spreadsheet.

  Presentation software.

  A lighter page-layout program that can eventually grow into something more serious.

  Those are obvious enough.

  Today the discussion expanded beyond "we need an office suite" into what an actual working office environment needs around those applications.

  Mail came into the conversation.

  Contacts.

  Calendar.

  Tasks.

  PDF support.

  And eventually a softphone with SMS capability.

  That last one is where the discussion became considerably more interesting, because once you start talking about communications, the applications stop being independent little boxes.

  A contact should not have to be one thing in the address book, another thing in email, another thing in the calendar, and yet another thing in the phone application.

  That suggested a common foundation.

  The current direction is a small Office Services Hub that provides shared contracts and common services the applications can build on.

  Not a giant "everything talks to everything through one magical process" architecture.

  Just enough common plumbing that Contacts can really be Contacts, Calendar can really be Calendar, and later applications can use those things instead of inventing their own private versions.

  The likely development sequence now looks something like:

  Office Services Hub → Contacts → Calendar/Tasks → Browser → Softphone/SMS

  That order changed slightly as we dug into the dependencies.

  The browser, in particular, turned out to be more important than it first appeared.

  The browser is not just for browsing

  I had originally been thinking about the browser as another application on the list.

  Turns out that's probably the wrong way to think about it.

  A modern business machine depends on the web for enough things that the browser becomes part of the practical application foundation.

  Account sign-in.

  Web applications.

  Documentation.

  Research.

  Communications.

  WebRTC.

  Audio.

  Authentication flows.

  Downloads.

  Potentially incoming-call workflows for services that expose browser-based communications.

  If we eventually want a Ceylon softphone talking to something like GoTo Connect, it makes a lot of sense to understand the browser and web-runtime problem before we build the communications application around assumptions we haven't proven yet.

  We also ruled out one obvious path for the phone side.

  Asterisk is not something we can simply drop onto Ceylon and turn into an internal PBX.

  So the current thinking is much narrower: build a native softphone capable of calls and SMS, and let it connect to an appropriate external service using supported protocols.

  That's a later project.

  The browser comes first.

  Which led directly to: how in the world are we going to build a browser?

  This became a fairly substantial research session.

  The obvious answer is Chromium.

  The less obvious problem is everything required to make Chromium happy.

  A browser like Chromium assumes a mature underlying operating environment with a tremendous amount of machinery around process management, dynamic memory, IPC,...

  Read more »

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

  Mike • 5 days ago • 0 comments

  Mike · October 4, 2026

  Tags: Project Ceylon, Retrocomputing, Operating Systems, Testing, Diagnostics, Refactoring, NuDOS, NuBASIC, SDK, Rust

  Project Ceylon is under a hard hold on new development right now.

  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...

  Read more »

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

  Mike • 6 days ago • 0 comments

  
  

  Mike · October 3, 2026

  Tags: Project Ceylon, Retrocomputing, Operating Systems, Diagnostics, NuDOS, Testing, Architecture, Reliability

  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...

  Read more »

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

  Mike • 10/03/2026 at 05:29 • 0 comments

  Mike · October 2, 2026

  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...

  Read more »

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

  Mike • 10/02/2026 at 06:18 • 0 comments

  Mike · October 1, 2026

  Tags: Project Ceylon, Retrocomputing, Operating Systems, NuGUI, Input, Asteroids, Clarise, Plug-and-Play, QEMU

  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....

  Read more »

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

  Mike • 09/30/2026 at 05:43 • 0 comments

  Mike · September 29, 2026

  Tags: Project Ceylon, Retrocomputing, Operating Systems, Nu-Iris, Display Architecture, Website, Build in Public, QEMU

  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....

  Read more »

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

  Mike • 09/29/2026 at 03:51 • 0 comments

  Mike · September 28, 2026

  Tags: Project Ceylon, Retrocomputing, Operating Systems, Local-First, Federation, Real-Time, Robotics, Nu-Iris

  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,...

  Read more »

View all 51 project logs