Blog

Developing “stable” builds of old code for old hardware has many benefits:

• If you can be selective about what you’re working with then compared to making fully up-to-date operating systems it’s relatively easy: apply the patch, run the full system build, wait untold hours, then see if you broke anything (and repeat…). Good practice of the basics despite often being quite advanced software
• It allows me to deploy some of my own software on top of a fairly stable base on old hardware, solving some “it won’t work on my PC issues” with “just install a VM”
• It gives me (and/or others) a solid basis for test infrastructure and for porting of old software to newer systems, a lot of the old code in these systems will already run easily on new systems too so it helps to have a “stable” patched fork
• It gives computer users or resellers of legacy hardware an extended support or self-support window for old CPUs in general, your current solution may be unmaintainable but this solution will basically work forever (until the hardware rusts out, assuming there are no major hardware incompatibilities or showstopping bugs in the code)

So right now I’m working on at least two other OS builds for “legacy” hardware, these will not have any significant modifications from the upstream sources at this stage but will just be to test build infrastructure.

The builds are now coming out more stable after some initial failures, but I’ll write about those later.

SecureLang® SL/RD

SL/RD (based on it’s early development name, SecureLang® REFDOS) is my main in-house product which was made available in some early demos around the start of the year (now with many unfinished improvements since!).

CleanFork Microkernel

These are the builds I’m working on right now and are based on a high quality legacy codebase. Future versions will have some (not all!) improvements backported from newer operating systems and some more customisation.

CleanFork HPC

This is still in the experimental stage but I think I can develop something based on other legacy code that’s a good fit for heavy number crunching, especially on the kind of hardware currently available cheaply like second-hand Xeon servers.

I should have some more builds ready to upload tonight (including last night’s ones), my MINIX-based builds are now coming out stable and I think I’ve solved the rebranding issues for early releases by using a trick to toggle old/new uname information.

The problem I’m facing now is that I probably need a plain http:// mirror site to be able to easily test builds of new programs. So I might start working on that tonight, hopefully how it will work is I’ll upload to the /releases directory on SecureLang.net (https) and then my http mirror will automatically fetch packages it doesn’t have already from there. But this might take a while to get right, in the meantime I might just reconfigure my main server to not always redirect to https (probably not a good look for a site with some security themes though).

The Goal

While developing OS kernels for new platforms is “fun”, it is also time consuming and doesn’t pay very well at this stage. So I decided to start a second brand, separate to my SL/RD project (except in possible future crossovers) to offer some solutions for legacy hardware and for retro rebuilds.

So I registered a domain CleanFork.org (which isn’t configured yet) to initially host working builds of open-source operating systems for old PCs (x86).

The First Attempt

I didn’t want my efforts to be for nothing, so I initially began by porting some small but new software packages to MINIX and then attempting a “clean” rebrand with the aim of developing a serious OS build for old PCs…

It worked, initially, but I probably focused on the wrong things for building a real OS – and after a few internal release tests part way through testing a rebrand of the base system the builds became unstable.

The Result

https://SecureLang.net/release/OriginsMK-3.1.8p01.zip

New plan and “stable” builds.

Instead of new tools and a full rebrand I instead aimed for a stable/supportable build of the 3.1.x branch. This build only includes a few trivial changes to the upstream codebase:

• A notice at boot in /usr/src/kernel/main.c to confirm that this is a third party build (this build is not the official MINIX builds, and not endorsed by the original team)
• Added /usr/src/DISTRO-NOTES and /usr/src/DISTRO-CHANGES documenting how the build was made (but missing some final notes about VM images)

Final Notes

Working with VM images and finding the right VM settings for builds was initially a challenge with my first attempt, as writing .iso files is easier in QEMU (but this is slower on my current setup). So I instead switched to VirtualBox and “dd” the final iso.bz2 file to a QCOW image file then use the QEMU tools and bunzip2 to convert it back to a working .iso file. This process feels incredibly stupid but is actually much faster than my initial approach.

Note that the target device to write to also seems to differ based on which VM is in use.

Also note that the license terms of MINIX (which should be included in the release) may prevent name-dropping the origins of the code in corporate promos, but the original developer has previously said he’d prefer if businesses (like Intel) mentioned that they were using it. So this is part of the reason I’ve tried to just take a common sense approach, mentioning the original system in early forks and leaving most internal branding untouched in this version while choosing an unrelated naming scheme for commercially supported/modern builds.

The Obvious Process

You start by seeing if you can build useful extensions to the OS, you make sure it boots reliably and you can actually recompile working copies, you then focus on trying to update the build process for new branding…

This is great but it has some realistic problems: You end up with a bunch of “test” versions, if you are anything like me you can spend an hour or more trying to patch your latest test ISO to boot properly and then realise it might be broken because it’s the wrong version…

Builds can take multiple hours – sometimes many hours, it’s tempting to fit branding changes, new documentation and new features in together. Sometimes rebuilds can be corrupted in difficult-to-diagnose ways – possibly because of using obscure methods of file transfer, or because of changing a rarely-changed setting that shouldn’t really do much etc.

If you overuse things like VMs, it can also be very easy to do something silly like overwrite your working VM with your test images. In my initial tests of rebuilding old operating systems from source it’s been much the same problem as with new systems: Emulator, disk image, driver problems. These are just extensions of old problems – “how to transfer to my test machine quickly?” “what if I can’t burn CDs or boot floppies?” etc.

The Solution: Documentation & Testing First

Prior to making good builds – but after messing around a bit with test rebuilds – you should focus on making working stable builds, with the first milestone being “I can rebuild the old codebase from source, I can do this reliably in a reproducible way and I added notes referenced on the login screen”.

The important step which I have omitted is breaking anything. Things could break for numerous reasons while adding or changing details in an operating system build that you wouldn’t normally think would break everything.

What This Means For Real Products

I think the sensible option, particularly when the original codebase is an outdated version, is to start with a simpler fork that’s only a more-documented/more-tested version of the old system and then build proper updated releases from that original stable rebuild. This way you already start with a reasonably-stable system and can begin testing things & documenting how to fix them from that basis, instead of trying to make immediate updates and breaking things that haven’t even been mentioned online in over a decade.

For more complex operating systems, this would generally mean producing a minimal build which is able to rebuild itself (not necessarily reproducing the entire original ecosystem).

Or in practical terms, what this means for the user or developer is that there will probably be the original branding on early forks and updates with different branding later (the original fork versions will probably report their original version numbers to software so as not to break version checks or cause unnecessary updates to the original “stable” version).

So I’ll have to find a way to communicate this in branding, e.g. “Origin” or “Origins” versions will be rebuilds & minor patches of old operating system releases aimed at creating stable modern builds while “Legacy” or “Classic”/”Retro”/… versions will have updated features & system branding aimed at typical users (using the Origin releases, which will only be updated very sparingly mostly to add or fix documentation, as an intermediary platform for building real updates).

Well I won’t tell you exactly what I’m about to drop yet but I will tell you about some of the research behind it.

When I was young I used to go to the garbage tip with my dad, pick up old computers very cheaply and try to get them working. I developed a great eye for spotting a good classic model but there were rarely many disks with them. It was fairly rare to get all of the good game disks with an old machine, but I often ended up with things like early business programs and on other machines just a BASIC shell.

Times change but skills only really grow. While I’ve been working on a new operating kernel & new accessories for new computers, I started looking over old systems again for ideas. Something about old operating systems became immediately clear, they can be divided into two categories:

Fast Enough To Rebuild In 2026

A good “usable” operating system does not actually need to support modern hardware, modern hardware is easily good enough and supporting legacy hardware emulation on top of whatever vendor-provided kernel is installed isn’t generally problematic. A reliable legacy operating system only needs to be fast enough to be usable under full emulation.

Aside from being fast enough, it’s also very helpful – some might say necessary – if a system is able to recompile itself (and any necessary patches) in a reasonable way. Especially if you don’t have access to the original download servers or the original hardware.

The Failing Category

Testing legacy x86-era operating systems under emulators on non-x86 hardware with full software emulation seems to be a very easy way of separating the higher quality code from the lower quality code. Recompiling the operating system is also a great general benchmark, as an OS which is too slow at batch processing will immediately grind to a halt.

Having used almost exclusively RISC processors for the past couple of years has been a blessing in disguise for developing legacy x86 solutions as I can tell you straight away what won’t work in a solid legacy enterprise OS:

• Dynamic linking everywhere
• Relying on overly-specific hardware features
• Everything is downloaded from git
• Everything is downloaded from unstable package mirrors
• “We no longer publish physical media”
• Thoughtlessly advanced filesystems or VFS layers

Sometimes these things can be disabled or avoided by customising the OS, but in other cases they become a bit all-consuming.

That Leaves A Few Real Options

The “good” legacy operating systems can further be divided into two groups:

• Systems which still mostly work in their original forms but as more-finished and still-maintained systems
• Systems which were either abandoned or are still maintained but no longer support the original hardware or installation flavours

The second category has some fairly interesting options, there are a few in particular I’ve been looking into making modernised respins of to support outdated hardware.

These can be narrowed down further by considering potential migration paths, the end result being that I should be able to deliver one or more 2026-buildable software solutions for very outdated hardware but I’m still analysing the tradeoffs. The new brand will be focused on “generic” open-source solutions.

The SecureLang® brand is great for my core products as I want to focus on compiler-like infrastructure, but my products for new machines are simply taking too long between waiting on new hardware and trying to find a work/life balance funded by income somehow.

So I’ve decided to launch a second brand in the meantime for legacy hardware support based on stable open-source solutions. I think I’ll be able to use my core mechanical skills very productively in the world of second-hand servers, but I’ll be launching as a second brand to avoid confusion with the SecureLang® SL/RD OS which is targeted at research on new hardware.

Branding Yet To Be Finalised

A domain has already been registered for the new brand but it will be introduced gradually, probably without a new website initially although I have some plans to add like a generic code sharing site later (think like the git sites but hopefully with less git).

Combined Focus: High Performance Computing

The linking element of the brands (aside from links back to the main SecureLang site) will be a combined focus on lightweight HPC solutions: The new brand will cover the “Legacy HPC” field such as making ideal use of old server hardware, while the core SecureLang brand will be focused on upcoming CPUs: RISC-V and quantum computing.

Both brands will eventually offer some solutions for FPGA enthusiasts, although I haven’t been able to get to a point with FPGAs myself where I’m confident developing reliable devices with them. Someone out there will be much better at that game than I am, so I want to market robust operating systems for all of your experimental chips whether retro or futuristic in design.

The SecureLang Brand Will Be More Security Focused

The SecureLang® brand will retain it’s cybersecurity roots whereas this will be less emphasised in the new brand, I don’t recommend 2010-era CPUs if security is your main concern but they are still solid for database backend and lighter AI work if we just ignore the more public facing servers.

The SecureLang® SL/RD product still in development will increasingly have a strong cybersecurity focus, while the legacy support brand will be more concerned with patching solutions that already work. And SL/RD will not be rebranded to sound more appealing as per earlier plans, it will keep it’s original technical name and mainframe styling.

https://www.phoronix.com/news/NTFS3-Vulnerability-For-Root

CPUs

The CPU work is still coming but bootstrapping that stuff can get a little stressful between timing issues and mysterious “no output” scenarios etc. So that’s all coming, but it’s gonna be late.

Compilers

SecureLang® Pascal is becoming more robust, after some testing using it for GUI building I’ve been filling in missing logic operators and build options. I think it will become very stable.

This has basically overtaken my (unreleased) “flagship” compiler in features – it does most of the same stuff like generics & OOP but is a faster/simpler core product.

Kernel & OS

I’m fairly happy with my kernel code aside from needing some scheduler timing fixes & drivers, but the problem is it might not be ideal as a bootstrapping environment in all cases. So there will probably have to be some other kernel options.

The good news is that the Pascal compiler is now stable enough to start taking over the build tools, allowing for a more complex & reliable build system that can do things like choose different C compilers for different modules in an intelligent way. But that will still need a lot of work, so there might still be some intermediate OS builds before I start rebasing it around a new build system and new kernel options.

I’ve been trying to get medical help for years in Australia and I still don’t know if I’ve just got some leg injuries or something degenerative, or quite possibly both.

Don’t believe anything anyone says about there being free medical care here, people in my life normally die trying to get medical care from them.

So I think I’ll try to de-stress a bit and just upload some content while knocking out some short courses for a month or two, instead of trying to finish whole product ranges that I’ve been promising for years and am still behind on.

I still plan to release the operating system and some smaller/larger cores though, but I think returning to studying in the short term will help build business confidence.