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

Today Project Ceylon got a real home on the web.

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

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

In other words, fairly representative of the project.

Ceylon finally has its own front door

The new public site is now up at:

ceylonprojectng.com

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

inspirebycraft.com

Both are currently simple landing pages.

That is intentional.

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

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

That was the first goal:

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

Done.

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

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

The Ceylon site can do the slower-moving jobs:

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

For the moment, though, it exists.

That feels surprisingly significant.

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

Now it has an address.

The project identity is getting clearer too

Putting up a public site forced another useful exercise:

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

The structure is becoming fairly simple.

Inspire by Craft is the parent maker company.

The IBC Systems Division is the computing side.

Project Ceylon is the operating-system and workstation program.

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

That probably sounds like corporate housekeeping.

It is.

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

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

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

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

Local-first is becoming more than a preference

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

Today that turned into more concrete federation work.

The question was:

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

The answer is starting to take shape as three levels:

Standalone → Fed-Light → Managed Federation

Standalone is exactly what it sounds like.

The machine works by itself.

Fed-Light is the interesting middle ground.

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

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

No ambient network authority.

Discovery can happen automatically.

Trust cannot.

That should require an intentional adoption step.

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

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

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

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

Local-first failure semantics matter.

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

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

Then CNC dragged us into real-time computing

Another conversation today started with something much more practical.

Ceylon is eventually intended to control CNC equipment.

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

So the question became:

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

The answer I like is:

parts of it do.

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

That would make ordinary desktop work unnecessarily rigid and complicated.

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

The working model is roughly along the lines of:

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

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

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

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

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

Your text editor does not need any of this.

That seems like a much healthier model.

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

Audio and video benefit from this too

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

Audio production is full of deadlines.

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

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

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

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

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

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

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

That is now part of the design problem.

And then somebody mentioned a Cylon

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

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

we could build a real Cylon running Ceylon.

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

Instead, it started another project idea.

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

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

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

So yes.

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

Not for A1.

Everybody relax.

I have learned at least some scope control.

Hack the Roomba

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

Take a Roomba.

Put a Raspberry Pi-class computer on it.

Run Ceylon.

Talk to the Roomba's existing control interface.

Then start adding things.

More sensors.

A camera.

Microphones.

Speakers.

Environmental sensing.

Maybe mapping.

Maybe remote control.

Maybe local autonomy.

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

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

That could eventually make a fun Hackaday challenge:

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

There is one fairly large prerequisite.

Ceylon is x86-64 today.

A Raspberry Pi would require ARM64 work.

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

Which means the current unofficial sequence may be:

build operating system,

build tablet,

hack Roomba,

accidentally start robotics division.

Seems reasonable.

Nu-Iris got some quieter work today too

Not everything today involved dreaming up future hardware.

Nu-Iris also moved forward a little.

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

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

Quite the opposite.

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

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

No sneaking future display ideas into the promotion.

No mixing qualification scaffolding into the product tree.

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

Get the qualified work promoted cleanly.

Then start the next tranche from a known point.

That sounds obvious.

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

Today felt less like debugging and more like defining the edges

There was not one giant technical breakthrough today.

No dramatic new screenshot.

No airplane flying yet.

No synthesizer concert.

Instead, several boundaries got clearer.

Ceylon has a public home now.

The company and project identities make more sense.

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

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

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

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

That is a pretty good day.

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

And it still isn't.

Progress.