Blog

This binary release is mostly intended to clean up a few things I couldn’t fit in in time for 1.0.1, but also represents some general progress towards a stable operating system. Note that some things missing from the first (1.0.1) release are included here and some things are missing here again (I forgot to check that ‘vi’ built). Future releases will be more complete and more reliable of course!

https://securelang.net/release/slrd-1.0.2.zip

To simplify early releases I’ll probably just post the full archive as above for now, this includes all current build targets (QEMU and Ky X1, with builds from different compilers) and some notes.

Worst Case

Bunch of files thrown into BOOT:/ or RD0:/ with minimal documentation (current scenario as of 1.0.1).

Best Case

Every component neatly packaged and easy to enable, disable or switch out in a particular system build.

Likely Compromise

System programs will go in the drive’s /DOS directory and development tools will go in a /SDK directory, maybe with other top-levels for other optional stuff. This will be managed by simply extending mkfs to build “release packaged” disk images, the regular package manager will be included in /DOS but not overly relied on by the system itself.

This works in well with the PATH system allowing users to look up programs from the current drive or from their BOOT: or equivalent drive. E.g. a possible PATH setting would be “/DOS;BOOT:/DOS” allowing lookup of system programs from the current drive’s installation first when available or otherwise from the BOOT: drive. A fully packaged approach may need a more complicated PATH instead.

This also allows for easy packaging in the future as any new large components can easily be broken off into subdirectories first and then packaged separately whenever it makes sense.

So that will probably be the compromise used for later 1.x releases rather than the full packaging approach or the “just chuck the files in” approach.

They need to stop asking stupid questions and deport me back to the Egyptian army so that we can do what needs to be done.

https://www.aljazeera.com/amp/news/2025/12/24/australias-nsw-passes-tough-anti-protest-gun-laws-after-bondi-attack

The “whites” need to return me to Egypt just for a start, and finally accept that they lost the war against us and have no power to deny us citizenship.

I also want to know why people from Lloyd’s of London forced their involvement in my mother’s estate against the wishes of my family. That all seemed highly illegal to me, I believe large scale fraud is still being committed by these people not just in historical cases.

Lloyd’s of London were one of the biggest profiteers of the transatlantic slave trade which is why they obviously were unwelcome in an Egyptian inheritance case (as well as them acting highly fraudulently in that case, such as conspiring with other solicitors who had a personal grudge against me). Total conflict of interest and fraudulent behaviour from these people.

https://www.theguardian.com/global-development/2025/dec/25/reparations-caribbean-africa-britain-restorative-justice-slavery

Not even open on holidays to explain why they don’t support local business?

Fuuuuuuuuuck off. These are the people who call me lazy?

Coming In 1.0.2

A 1.0.2 release is coming soon with a few changes moving towards a usable operating system:

• The new shell program supports a PATH environment variable which is necessary for proper directory structure in future releases
• A port of svi vi-compatible text editor is working with a rough implementation of curses, though a bit slow
• An ioctl system call has been added especially for the curses backend to control console options
• The existing kqueue1 & kevent system calls are now mostly implemented ready for more complex I/O, but these probably won’t be properly demonstrated until later
• The mkfs program has been cleaned up slightly and can probably be included in a release soon (maybe with some kernel changes to allow formatting new ramdisks as a demonstration)
• The ls and drives commands have been improved slightly

The 1.1 Release

As most of the improvements planned for a 1.1 release have already been implemented as well as the kqueue implementation I will probably try to finish the rest of the kernel subsystems to a reasonable degree by 1.1 (so this means networking, containers & the driver layer should all be demonstrable).

This will allow a 1.2 release to follow just focusing on usability improvements. But that plan could change slightly, I’ll try to finish a few more small features for 1.0.2 and then see how I progress from here.

This toolkit appears to be based on Go, which will probably be ported later on down the track, but maybe I can get an early version working on my OS sooner than needing a full port.

I’ll take another look at this when I’m ready to start expanding the suite of development tools:

https://nuruprogramming.org/en/

I just discovered this while looking around for scripting tools, maybe will try to port something like this after I get some more stuff working.

I also have a compiler which can be modified for non-English languages but that will be in a future release, I’ll probably try to port some existing tools first! This language appears to be implemented in TypeScript so hopefully it will work on my kernel after an ECMAScript interpreter is added.

https://try-setanta.ie/tut/en/intro.html

Using large codebases in critical applications sure sounds like a dumb idea to me, although I haven’t looked in to any relevant regulations yet so I don’t know what the process is.

This article from Michael Larabel suggests the industry may be desperate for alternative methods though.

https://www.phoronix.com/news/NVIDIA-ASIL-B-Linux-Kernel

I want to set an easy target for version 1.1.0 so I can do some quick 1.x.x releases instead of getting bogged down. This means 1.1 could arrive very quickly or I could tinker for a while but it won’t be a huge update like the road towards the first release was.

Towards 1.1

Version 1.1 should have the following features which may be included in small 1.0.x releases or all at once:

• New or ported “shell” program
• Improved/added system utilities
• Small kernel improvements, e.g. finishing any code which was rushed in the replacement of old code

1.2 & Onwards

Versions 1.2, 1.3 etc. will be focused on finishing off or adding new subsystems but a full plan hasn’t been formulated yet. By around version 1.2 the system should be more modular and easier to build larger releases!

By version 2.0 the system should be able to recompile itself, connect to networks, run legacy software and so on.