Blog

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.

This demo is very limited, only demonstrating a simple command line shell. The other purpose besides providing a (theoretically) working demo is to start testing “release” builds for future software.

My “release” builds are distinguished from normal in-development builds by having synchronised builds of the same code version with different configurations, but the code will still contain bugs & limitations like any other in-development build (it will just hopefully boot in each configuration).

This is only the first demo anyway, just in time for the solstice. This is version 1.0.1 (not 1.0) because I ended up needing to do a lot of small fixups after “finishing” the kernel. There will be much more to come!

slrd-qemu-compilec-1.0.1.zip

slrd-qemu-gcc-1.0.1.zip

slrd-ky-compilec-1.0.1.zip

slrd-ky-gcc-1.0.1.zip

https://dev.to/maame-codes/is-vibe-coding-ruining-my-cs-degree-3m3

This is my industry, younger people should all feel welcome in it and I think if I was just getting into it today I’d be using AI more.

But AI isn’t the end of the world and wasn’t as much of a game changer as I personally hoped it would be. Learning from AI isn’t much different to how the rest of us learnt from computer programs. I learnt assembly code mostly from reading compiler output, not so different to learning code from an AI, but obviously it’s still a useful skill even though a program can do most of it!

Switching over your build system is a great way to find where your most unreliable code is.

May be delayed a little more if I find any more errors but I hope to get something close to some “release” builds uploaded tonight, though just a very modest demo for now.

Once I get the build system more organised it will become easier to do reliable releases. In-development operating systems tend to have a lot of configuration-related breakages between updates, where a fix for one configuration breaks another configuration, which a better build system should address a little.