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.
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.
Version 1.1 should have the following features which may be included in small 1.0.x releases or all at once:
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!
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:
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.
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!