Author: admin

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.

Binary releases are expected to start tonight or tomorrow, once the new build script works…

During the final replacement of legacy code a few things have been broken or fixes to existing problems have been delayed:

• Floating point support may be in a half-working state, it probably works but prints some TODOs when activated and has had no attention since before replacing the rest of the kernel
• Due to API breakages the utilities from xv6 no longer compile at all, this is kind of intentional as I didn’t want to preserve the old headers etc.
• A few bugs were found in the filesystem code, these have been partly fixed during the replacement of old system call code but some probably remain
• Threading is implemented but not yet finished, it mostly works but there will be some bugs if some filesystem operations are invoked from multithreaded programs
• Error handling is unfinished, so some recoverable errors may cause kernel panics instead of failing gracefully
• I simply haven’t had time to investigate some possible scheduler bugs when running under load

Addressing these problems will be delayed until after 1.0 or may not need addressing at all. The base system is functioning well and some command-line programs have been replaced already, once I have enough working to show some basic documentation about the software I’ll start uploading builds.

Proper testing including stress tests will be resumed later.

My original plan was to focus on tools for developers while making some cool demos like an OS kernel. However I had to focus on finishing one part first and it ended up being the kernel.

The other tools are still workable and are valuable for use in the operating system but the SDK aspects are further behind than the kernel code, so I could possibly reverse the focus of the business a little into building a full operating system instead of treating that as an advanced test rig for my other (less complete) software infrastructure.

But this is early days so we’ll see, I’m still a tech infrastructure business whatever exact form that takes.

https://www.theregister.com/2025/12/17/dhruv64_india_homegrown_processor/

Just a (maybe new) shell program running on the kernel with a few commands. That will happen once I’ve finalised branding and done a little work on getting the “userland” back in a working state.

The system is fairly scalable with general-purpose design and should be especially good for robotics projects in the future, but it was mostly designed for testing & marketing my other software so the first release will mark it as being mostly ready for that. It’s not ready for many other real-world workloads yet but it should be some day soon!

It’s a bit of a blur but I don’t recall doing anything else between 7PM Tuesday and 7PM Wednesday except making coffees.

Bit of a headache. But it’s done.

The kernel rewrite I mean, not a whole release plan. Legacy code is now only used when booting on QEMU it can be omitted entirely when building for real hardware.

This should greatly help in the next stages of development as I won’t have to balance other goals with cleaning up old code. On the other hand it created more testing work for me as now just about anything could’ve been broken and for now it’s no longer compatible with the test suite.

So bringing up some userland programs is the next goal, I’ve already written a new init program.