Project Ceylon Development Log — September 27, 2026: Apparently Housekeeping Is Systems Engineering Too
Today I deleted almost 300 GiB of Project Ceylon development debris.
And somehow that turned into a desktop-design discussion.
That sounds about right.
The short version is that the machine had accumulated months of build trees, validation copies, temporary workspaces, old artifacts, abandoned experiments, duplicated toolchains, test images, and assorted other things that all made perfect sense when they were created and considerably less sense after they had been sitting there for a while.
The filesystem had reached about 77% used.
By the time the cleanup was finished, it was down around 53%.
Free space went from roughly 300 GiB to 600 GiB.
And, most importantly:
the canonical Ceylon source stayed exactly where it was supposed to be.
That last part is what made the cleanup interesting.
Deleting files is easy.
Deleting the right files in an operating-system project without quietly throwing away the one copy of something important is a different job entirely.
"rm -rf" was not the plan
The cleanup was deliberately conservative.
Every candidate had to earn the right to be deleted.
Build trees?
Probably disposable.
Generated output?
Usually disposable.
Temporary validation copies?
Maybe.
A directory that looks temporary but contains tracked source?
Absolutely not.
That distinction caught one remaining root-owned workspace that otherwise looked like cleanup material.
The deletion process checked it against the canonical repository, found tracked source inside it, and kept it.
Exactly what I wanted.
By the end of the run, 391 out of 392 residual root-owned paths were removed.
The one exception was preserved because it still contained canonical source.
That is a much better result than "we deleted everything and the machine still seems to boot."
Cleanup found things I actually wanted to keep
The more useful surprise came before the final deletion pass.
A proper inventory of the old workspaces found a few pieces of engineering work that had not yet been cleanly reconciled back into the main project.
That is the dangerous part of long-running experimental development.
You make a fix in a validation tree.
Then another fix in another tree.
Then a branch exists because you were trying to prove one very specific thing at 2:00 AM.
A week later, the fix is good, the test passed, everybody remembers the result...
...and the actual source of truth may not yet contain the thing that produced it.
That is how projects slowly become folklore.
So before anything was removed, the cleanup process stopped and identified those unique changes.
No merging by accident.
No "well, I think this one was already included."
No guessing.
The cleanup became a reconciliation exercise before it became a deletion exercise.
That may be the least glamorous sentence I have ever written for Hackaday.
It is also probably one of the more important ones.
This project is getting too big to rely on memory
I have a decent memory for how Ceylon got here.
That is not the same thing as having a process.
As the project has grown, I have become increasingly suspicious of statements that begin with:
"I'm pretty sure..."
I'm pretty sure that patch was incorporated.
I'm pretty sure that workspace is obsolete.
I'm pretty sure that toolchain is the current one.
I'm pretty sure we qualified that exact image.
No.
"Pretty sure" is how six months from now becomes miserable.
The system now has enough moving parts that provenance, reconciliation, qualification evidence, and cleanup discipline are becoming part of the engineering itself.
Apparently housekeeping is systems engineering too.
I did not expect that to become one of the themes of this project, but here we are.
Meanwhile, I have been thinking about the desktop again
The cleanup work was not the only thing happening today.
I also went back to a question I have been circling for a while:
If Ceylon is not going to simply copy Windows, macOS, or Linux, what should actually be different about using it?
Not different for the sake of being weird.
Different in a way that is genuinely useful.
I do not want Ceylon to ship with twenty "innovations" that all need a tutorial and make somebody wish we had just left the desktop alone.
One or two good ideas are enough.
Then improve them based on evidence.
The current one is called Workpad.
The Workpad idea is very simple
Imagine you are working on something in a window.
Maybe a document.
Maybe a source file.
Maybe a graphics project.
Maybe something else entirely.
Around that work you usually accumulate related stuff:
another file,
a reference image,
a URL,
a note,
a clip,
a shortcut,
something you dragged over because you will need it again in ten minutes.
Modern desktops are surprisingly bad at remembering that temporary working context.
So the Workpad is basically:
the tray of useful things that belongs with this work.
Not a second desktop.
Not a replacement for folders.
Not a giant project-management system hiding behind a paperclip icon.
A contextual surface attached to the work you are doing.
You can put related things there and have them stay associated with that context.
The design has now been formalized far enough that it is no longer just a sketch on my mental whiteboard.
It should still look like the thing it is
One detail I care about is object identity.
If you put a file on the Workpad, it should still look like that file.
If you put an application there, it should retain that application's identity.
A reference should remain a reference.
A URL should remain a URL.
I do not want everything transformed into generic little "cards" because some design system decided all objects need rounded corners and the same icon.
The object should keep its normal visual identity.
And where possible, the Workpad should preserve where it came from.
If you pulled in a file from a folder, you should be able to get back to that file.
If something came from a document or another context, that provenance should not disappear just because you made it convenient to keep nearby.
That seems like a small thing.
I suspect it will matter a lot once people actually use it.
The desktop should help without becoming your manager
This is also where some of the local-first research I have been doing starts to connect with the rest of Ceylon.
I grew up using computers that worked because the computer was sitting in front of you.
The C64 did not become confused because the Internet was down.
The Amiga did not ask a remote service whether you still had permission to open your own document.
A desktop computer was a place.
Your files were there.
Your software was there.
Your work was there.
You could navigate it without carrying a phone around as an external organ.
There is quite a bit about modern computing I do not want to throw away.
Networking is useful.
Synchronization is useful.
Remote collaboration is useful.
Cloud services can be useful.
But I want Ceylon's default assumption to be:
your computer is useful on its own.
Network services should extend the machine.
They should not be what grants the machine permission to exist.
That is the direction behind the local-first work.
Not "never use a server."
Not "pretend the Internet was a mistake."
Just restore the local computer as the authoritative place where the user's work can actually happen.
Local-first also fits the ownership philosophy
That idea meshes with another Ceylon principle I have been getting increasingly stubborn about:
You buy it, you own it.
If you buy a machine, it is your machine.
If you legitimately buy a copy of software, your ability to keep using that copy should not depend forever on whether some company still feels like operating a licensing server.
If a vendor disappears, your computer should not wake up one morning and decide your purchase has become historical trivia.
There are obviously details to work out around licensing, updates, services, intellectual property, and network-connected features.
But the principle itself is not especially complicated.
The computer should work for its owner.
That seems like something personal computing used to understand almost automatically.
Maybe we can remember how.
This is not all going into Alpha tomorrow
One important clarification:
the local-first research is not an excuse to keep adding things to the A1 Alpha scope.
I finally got that scope under control yesterday.
I would like to keep it that way for at least 48 hours.
The local-first work is being treated as a longer-term architectural direction.
Where it affects foundational decisions now, I want to avoid painting ourselves into the wrong corner.
But I am not stopping Alpha so we can invent the ultimate distributed personal-computing architecture first.
That would be exactly the kind of thing I am trying to stop doing.
Workpad is much closer to the immediate desktop work because it is a bounded NuGUI facility, and its specification work is now in good shape.
The larger local-first model can develop behind the release line until it has earned its way forward.
Look at that.
I may actually be learning scope control.
By the end of the day, the project weighed less
Literally, in this case.
We reclaimed just under 300 GiB.
The canonical source remained intact.
The active development state is cleaner.
Old workspaces were reconciled instead of blindly discarded.
The NuGUI research is better organized.
Workpad has moved from "interesting desktop thought" toward a real specified facility.
And the local-first work has a clearer principle underneath it:
the computer should remain useful, understandable, and owned by the person sitting in front of it.
That is not a bad result for a day that started with disk usage.
Yesterday I failed to take a day off.
Today I apparently reorganized half the project and reconsidered personal computing.
I may need somebody else to define "rest" for me.
Project Ceylon is an independent retro-futurist operating-system project exploring what a modern creative workstation might look like if some of the best ideas of earlier personal computers had continued evolving instead of being discarded.