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.
Leave a Reply