Project Logs

Collapse

• Project Ceylon Development Log — October 13, 2026: The Bug That Wasn't There Anymore

  Mike • a day ago • 0 comments

  Mike · October 13, 2026

  Tags: Project Ceylon, Operating Systems, Microkernel, Iris, NuGUI, Documentation, Build Systems

  Today was foundation day.

  Not the exciting kind. The kind where you prove the ground is actually solid before you put any weight on it.

  By the end of the session, Ceylon had a single canonical source line, a build that reproduces itself byte-for-byte from a clean seed, a regression suite that actually runs, and a performance baseline measured before anyone touched a single optimization.

  It also had a scope document — the full Alpha release, all seven workstreams, written down and adopted.

  And it had one bug that turned out not to be a bug at all, which is the part of today I actually want to write about.

  Measure First, Then Build

  Before any feature work, I wanted ground that wouldn't shift.

  That meant a governed seed for the build, checked six different ways: provenance, completeness, three fail-closed negative tests, and a full rebuild from scratch matched hash-for-hash against the reference image.

  Byte-identical.

  Not "close enough."

  Identical.

  It also meant establishing a performance baseline before any of it got touched.

  That is the part people skip. It is also the part that pays for itself immediately, because you cannot tell if something got faster later if you never wrote down how slow it was today.

  We Found a Process That Had Been Running for Six and a Half Hours

  While building that baseline, a verification pass flagged something that didn't belong.

  A monitoring loop, left over from an earlier measurement, was still running.

  Quietly.

  In the background.

  For six and a half hours.

  Nobody noticed because it wasn't failing anything. It was just sitting there, burning CPU and skewing whatever it touched, invisible until something actually checked.

  That is not a dramatic bug. It is not a design flaw. It is a background process somebody forgot to kill.

  But it's exactly the kind of thing that measurement catches and assumption doesn't.

  We killed it, wrote down why, and moved on.

  The rule that came out of it is simple: every measurement tool gets the same guaranteed teardown as everything else. Nothing gets to just sit there because nobody was looking.

  The Documentation Standard Got a Name

  Heathkit kits assumed nothing.

  Every step was numbered. Every step told you what you should see if it worked. The troubleshooting chart was organized by symptom, not by part number.

  Ceylon's documentation now follows that same discipline on purpose, not by accident.

  There's a user guide, a builder's guide, a theory-of-operation document per subsystem, and reference tables generated from the actual source rather than typed by hand — so they can't quietly drift out of sync with the code the way hand-written documentation always eventually does.

  We also found out exactly how far from that standard the current source sits.

  67 of 138 files still carry placeholder documentation headers.

  That number is going down, not up, as each tranche touches those files.

  It is not going down today.

  Today was just the day we measured it honestly instead of guessing.

  The Alpha Got a Shape

  With the ground settled, the scope for the first public release got written down and adopted.

  That includes the desktop and compositor, the DOS-style shell, the platform services underneath it, networking, audio, quality, release packaging, and documentation as its own cross-cutting workstream rather than an afterthought.

  The hardware plan is staged on purpose.

  The free Alpha runs under QEMU and is explicitly a proof of concept, not a performance demo.

  After that comes bare-metal hardware with CPU rendering.

  After that, GPU acceleration, built as a plug-in to the same contract rather than a rewrite.

  The rule that makes that staging possible is simple: nothing QEMU-specific is allowed to leak into the parts of the system that bare metal will eventually replace.

  That's slower to build correctly.

  It's also the only...

  Read more »

• Project Ceylon Development Log — October 12, 2026: The Terminal Finally Came Back

  Mike • a day ago • 0 comments

  Mike · October 12, 2026

  Tags: Project Ceylon, Operating Systems, NuDOS, NuGUI, Terminal, Rust, Audio, Testing, Application Lifecycle

  Yesterday ended with one of those wonderfully specific operating-system problems:

  The Terminal could open.

  It could take input.

  Copy and paste worked.

  Closing it was the part that still wasn't trustworthy.

  Today we pushed that path harder.

  By the end of the session, NuDOS had made it through revoke recovery, real keyboard input, ordinary copy and paste, close, reopen, and the rest of the lifecycle path on the corrected machine profile.

  That is a much better place to be than we were twenty-four hours ago.

  It also came with a useful reminder that not every failure belongs to the product.

  Sometimes the test rig is the thing lying to you.

  We Found the "Bug" in the Runner

  One of the remaining NuDOS failures looked like a post-revoke keyboard problem.

  That was concerning because revoke/recovery behavior is exactly the sort of thing we are trying to prove before calling the desktop environment stable.

  The eventual root cause was not a production input defect.

  The qualification run had been using the wrong machine profile.

  Once the intended Q35/IOMMU/xHCI configuration was restored, the supposedly broken recovery path behaved correctly.

  Keyboard input after revoke passed.

  Ordinary copy and paste passed.

  Closing the Terminal passed.

  Opening it again passed.

  The session lifecycle passed.

  That result matters for more than just the Terminal.

  We have spent a lot of time lately making sure Ceylon's qualification process distinguishes between "the system failed" and "we did not actually test the system we thought we were testing."

  Those are very different conclusions.

  A bad runner configuration can waste hours if you trust the first screaming subsystem and start repairing it.

  So today was another case where the most useful debugging result was figuring out which layer was actually guilty.

  NuDOS Is Getting Close to the Interesting Part

  The NuDOS work has now moved well beyond "does the parser understand a command?"

  We have already been through command semantics, malformed input, clipboard behavior, application/session interaction, saturation, cancellation, revoke behavior, and recovery.

  Now the important paths are increasingly the ones that make the shell feel like part of the operating system rather than a library with a prompt attached to it.

  That means the Terminal has to survive the same lifecycle expectations as any other application.

  It has to open through the normal desktop path, interact with the system services it is entitled to use, shut down cleanly, give its resources back, and start again without inheriting stale state from the previous session.

  Today's R32 work proved that sequence on the corrected test configuration.

  That is significant.

  It is not the same thing as saying NuDOS is finished.

  There are still open qualification items, the final native adapter is not complete, and the full target session remains ahead.

  But the remaining problem set is getting smaller and much less mysterious.

  That is exactly where I wanted to get before integration work starts becoming expensive.

  The Audio Work Also Reached a Useful Boundary

  Audio continued moving in parallel, but under a very deliberate rule:

  do not let audio experimentation interfere with the NuDOS qualification work.

  The current audio prebuild has now reached a useful host-side checkpoint.

  The code compiles on the host.

  The host tests pass.

  The reference audio fixture passes.

  That includes the basic 48 kHz stereo path we wanted for the first round of validation.

  What did not happen today is just as important.

  We did not prove native Ceylon audio.

  The target-side build hit an offline toolchain dependency around the Rust build-standard-library path.

  The Aria/Lyra source reconciliation is still incomplete.

  Native HDA output was not run.

  Nothing was promoted into the canonical system image.

  That...

  Read more »

• Project Ceylon Development Log — October 11, 2026: Copy, Paste, Close… Well, Two Out of Three

  Mike • a day ago • 0 comments

  Mike · October 11, 2026

  Tags: Project Ceylon, Operating Systems, NuDOS, Terminal, Rust, Audio, Compilers, Application Runtime, Testing

  Yesterday was one of those satisfying operating-system days where Asteroids finally started behaving less like a test payload and more like an application.

  Today was more shell-shaped.

  NuDOS continued moving toward the real Ceylon desktop, and by the end of the day we had ordinary copy and paste working through the intended path, the input regressions were still green, and the next failure had become wonderfully specific:

  we can open the Terminal. We can use it. We can copy and paste. We just can't close it and reliably open it again yet.

  Honestly, I'll take that.

  That is considerably better than "something somewhere doesn't work."

  NuDOS Is Starting to Meet the Rest of the Computer

  The portable NuDOS command engine has been coming together for a while, but the interesting work now is increasingly at the boundary between that engine and the actual Ceylon desktop.

  That means the boring-but-important stuff.

  Input has to arrive through the real semantic-input path. Output has to travel through the correct Terminal/session plumbing. Clipboard operations have to behave like desktop operations rather than test-harness tricks. Closing the Terminal has to tear down the application cleanly enough that the operating system can create another one afterward.

  Today the copy/publication path passed.

  Paste passed.

  The existing HID/input behavior survived the changes.

  That gives us another useful slice of normal desktop behavior rather than a synthetic test case.

  The Terminal can receive the user's input, interact with the clipboard, and continue through the normal application path without regressing the input work underneath it.

  The current problem is lifecycle.

  Closing the Terminal and bringing it back is still blocked.

  That is now the thing we are chasing.

  "Close the Window" Is Still Not a Small Request

  Yesterday Asteroids gave us a similar lesson.

  Running an application is one problem.

  Stopping one correctly is another.

  Stopping it and then proving the operating system can reuse everything afterward is where the lifecycle starts becoming interesting.

  The same applies to the Terminal.

  When the user closes it, several things have to agree about what just happened. The GUI has to issue the right close request. The application has to receive it through the supported lifecycle path. Its session attachments need to be retired correctly. Resources need to be returned. Stale state must stop being useful. Then a new Terminal instance has to start without inheriting pieces of the old one.

  If any one of those steps is incomplete, "close the window" becomes "close the window and discover an operating-system archaeology project."

  That is roughly where we are.

  The useful part is that the failure has moved toward the normal NuGUI close ingress rather than remaining some vague Terminal problem.

  So the next qualification pass is focused on that path: get the normal close operation through teardown, prove reopen, and then repeat the cycle enough times to make sure we have not merely gotten lucky once.

  Until that works, I am not calling the Terminal lifecycle finished.

  The Native NuDOS Adapter Still Has Work Left

  There is another distinction worth keeping clear.

  NuDOS itself now has substantial portable implementation behind it.

  That does not mean the complete native Ceylon NuDOS environment is finished.

  The final native adapter is still not qualified, and the full target session has not yet been run end-to-end.

  That distinction matters because I do not want to repeat one of the project's recurring bad habits: proving ninety percent of a path and then mentally promoting it to one hundred.

  The command engine can be good.

  The Terminal can be good.

  The session transport can be good.

  The clipboard can be good.

  And we can still be missing the one piece that makes them behave like one...

  Read more »

• Project Ceylon Development Log — October 10, 2026: Asteroids Finally Started Acting Like an Application

  Mike • 5 days ago • 0 comments

  Mike · October 10, 2026

  Tags: Project Ceylon, Operating Systems, NuGUI, Nu-Iris, Asteroids, NuDOS, Rust, Application Runtime, Testing

  There are certain milestones in an operating-system project that look completely unimpressive if you describe them badly.

  Today we got one of them.

  Asteroids launched.

  It accepted real keyboard input.

  The ship actually responded to it.

  It kept receiving timer events and drawing frames.

  Escape caused the application to exit.

  Its resources were cleaned up.

  The desktop came back.

  Then we launched it again.

  That last part may be the most important.

  A demo that runs once is a demo.

  An application that can be launched, interacted with, closed, cleaned up, and launched again is starting to look like part of an operating system.

  Today Ceylon got considerably closer to that second category.

  The Timer Was Lying in Wait

  We started the day chasing a timer race.

  Asteroids had already reached the point where it could get far enough into the application path to expose problems that simpler tests were not finding.

  One of those was in the timing path.

  The application could register for timer events, but there was a race between registration and the point where the application actually began waiting for them. Under the wrong ordering, the event could arrive at exactly the wrong moment and the application would sit there waiting for something that had, technically, already happened.

  Those are always fun.

  The repair was small in terms of code, but important in terms of behavior. The clock path was corrected, the governed build passed, repeated timer events arrived, and Asteroids made it through another frame and back through the normal NuGUI/Nu-Iris presentation path.

  No timer fault.

  No panic.

  No shortcut around the application architecture.

  That got us past one obstruction.

  Then input found the next one.

  Input Was Connected, But Not Quite Alive

  The semantic-input path had its own problem.

  The application input page was being reset in a way that also erased the ABI identification fields that told the receiving side what the page actually was.

  So the transport existed.

  The application existed.

  The data path existed.

  And we had managed to wipe the sign off the front door.

  That was repaired by restoring the input-page ABI magic and version correctly during reset.

  After that, the real HID path made it all the way through NuGUI focus handling and into the application.

  Not injected test input.

  Not a host-side simulation.

  Real input from the machine.

  The first useful proof was simple: Left and thrust events reached Asteroids.

  That was enough to show the path was connected.

  It was not yet enough to say the game was playable.

  So we kept going.

  Then the Ship Actually Moved

  The next qualification pass exercised the normal game state rather than merely checking whether an input event appeared somewhere.

  Rotation affected the aircraft—well, spacecraft.

  Thrust affected movement.

  The timer continued to advance the simulation.

  Rendering continued.

  Presentation continued.

  The existing Asteroids tests, platform-core tests, and clock tests all remained green.

  At that point, the application was responding to real Ceylon input and advancing through the real runtime path.

  There was one important qualification attached to that result:

  we were running QEMU without a visible display for that particular test.

  So we proved gameplay state and the presentation chain operationally, but we did not pretend that meant a human had stood there and visually verified every rendered frame.

  That distinction has become almost a reflex around here.

  I consider that progress too.

  Closing an Application Turns Out to Be an Operating-System Feature

  Once Asteroids could run, the next question became:

  what happens when the user is finished with it?

  That sounds trivial if you are used to an operating system that already has thirty years of application-lifecycle machinery underneath the close button....

  Read more »

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

  Mike • 6 days 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 • 6 days 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 • 7 days 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 • 10/08/2026 at 19:21 • 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 • 10/05/2026 at 03:25 • 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 • 10/04/2026 at 07:30 • 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 »

View all 55 project logs