Author: admin

Some system calls have now been integrated with the network stack, and the system appears to initialise correctly (but without drivers).

This means the port of microps network protocol stack is almost complete, aside from finishing some more system calls and writing or porting some drivers.

Simple Networking Soon

This networking implementation is mainly aimed at being simple, rather than importing a larger “full” network stack. So hopefully this network stack will continue to be easy to work with as I look at bringing up more drivers & legacy software, but it won’t fully replace the features of Linux or BSD network stacks.

Fast Networking Later

Improvements such as optimisations, extended protocol support or added security checks can be added to this codebase later, or could be implemented as alternative network implementations.

https://www.tomshardware.com/tech-industry/semiconductors/china-tells-chipmakers-to-use-homegrown-chipmaking-tools-for-50-percent-of-new-capacity-decree-designed-to-squeeze-foreign-suppliers-out-of-supply-chain

Hopefully the rest of the world can learn from China and start supporting our own people for once.

Some initial announcements for 1.1.x updates have already been posted, this post will go over their technical implementation and current integration status.

Kernel Inet

The network stack will be minimal but should work particularly well for testing simple drivers.

This is based on https://github.com/pandax381/microps which conveniently already has a RISC-V demo on xv6 (which I used as a reference for the new kernel). This code is MIT licensed and is an optional module in kernel builds.

DistNX

Modern graphics stacks can be a nightmare compared to what is actually needed to run many business apps & classic games.

Porting old or new desktop systems mostly used on Linux to a new platform would be a time consuming task, whereas writing a whole new system from scratch would be a waste as the old graphics systems worked fine for most apps.

So the compromise, for now at least, will be to use a fork of Nano-X (a GUI system designed for embedded devices) but ideally scaled up a little for easy distribution as a non-bloated but general-purpose window system server.

The fork currently is almost unmodified sources from Nano-X but with a simpler build system aimed at easy/reproducible server builds, and this will stay open source or mostly so in compliance with the original license.

These are just being delayed while (the rest of) the OS is pushed into a usable state, but the payoff will be worth it as this will all still feed back into compiler testing!

The windowing system is now partly-integrated, but it won’t run until there is more OS support (sockets, drivers).

As for networking functions there have been some improvements to projects I’ve been watching in that field, so I’m gonna go right ahead and integrate a basic TCP/IP stack into the kernel at the same time I start implementing local sockets. This will probably take a little while to get right.

So it’s likely that the 1.1 release will include both these major components (GUI & networking) but in an unusable form (i.e. they will just report missing drivers for now), and a 1.2 release will follow once they become somewhat usable. This way 1.2 will be like a preview of a full “version 2” product with most auxiliary features working in some basic form, and 1.1.x will just be the initial versions of those 1.2 changes.

Both of these components were developed by third-party developers, so at least the GUI will remain mostly open source, and the networking subsystem will also be made optional if possible.

SecureLang™ REFDOS will continue to be a command-driven operating system focused on filesystem tools and other core OS features, it is designed to run on devices without graphics.

The GUI will be something like a classic desktop that can run on top of the operating system, when drivers permit! It will probably be more useful on Linux/Mac/Windows in the short term.

I can probably start posting political shit with my software now. I don’t have to care, I’ve almost made it.

Next OS release will probably ship with a windowing system but it won’t work yet. Some teasers:

• It’s not Wayland
• It’s not X11
• It’s not something new
• It may end up as a full fork with new features

There’s still a lot of work I’ve got to do to get it working, and I don’t know how long that’ll take maybe that’ll be a forever thing, but a major port is in progress! I’m looking at the code right now… The refactoring has begun, better announcements will be made when it uhhh works (or at least when it compiles for the system).

Implications For Networking

Porting a GUI rather than implementing my own means that I’ll need to use the network functions (which means I’ll need to implement my own network functions).

So this happens to be convenient for testing the network functions, and implies that local implementations of those functions will be the first step towards bringing up proper networking.

Implications For My Business

This move is part of a shift away from developer tools, towards protocols & standards relevant to consumers. But the initial graphical versions will still be developer-centric.

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