I did also try to get some OS design tips out of the AIs a year or so back, but from what I’ve heard they should be more advanced now.
I don’t think it’s the direction I’d want to take with kernel code at least for a main product but I am very interested in what kind of OS designs people will come up with vibe coding! Congrats to the person who claimed the name VibeOS first.
When the AIs replace your job. It’s happened to me before and frankly I don’t really miss working at a checkout anyway.
But people in fields they perceive as more intellectual might take it a bit more personally.
It wasn’t that your performance wasn’t good enough. You were Plato, this is Aristotle.
This is not an overly pro- or anti-AI business. (And I’m mostly referring to LLMs as “AI” here, since that’s basically classic AI materialising.)
I certainly consider myself an enthusiast and have been researching this topic for a long time. I’m aware that over the last few months there have been reports of incredible progress, including people now publishing vibe coded operating systems, while I’ve still been operating mostly the old fashioned way.
My expectation is that AI will be really good at delivering customised apps, but there are huuuuuge questions about security and economic implications. For my own part I’m concerned it might be too controlled by big players & governments. So I’m very bullish on AI, but cautious.
So in summary, yes I will probably eventually publish some AI stuff, but I’m not going all in and I’m still looking at quantum computing or similar material technologies as the next big thing, AI is just a large factor now!
SecureLang® is now a registered trademark of my business according to Australian law!
This process takes many months and can be a real test of patience checking for updates over that time but as of today or yesterday that process initiated in the middle of last year is finally complete.
Hopefully this will mark a turnaround in my problems with government red tape & the legal system.
This has not received many updates as I’ve focused on finishing the OS code, and remains an amalgam of legacy code with many extensions & patches by myself to make it practical (but very imperfect) for some typical modern use cases.
So as this probably won’t be “finished” as a full C compiler but is marginally enough to build the kernel, some examples and now some of the networking code, so it will probably just become a free compiler for an extended subset of C. This may be useful for porting to other small operating systems as well.
I have some more-reusable compiler code for higher-level C-like languages, that will be used in some parts of the OS and maybe even for kernel modules in the future.
The network stack has been tested successfully but I don’t have good demo apps ported yet.
Current task is getting the network code compiling on my own C to RISC-V backend (which is lagging a bit behind the OS codebase). This will be the first step towards a “hardened” codebase, as the compiler can be used for fully audited systems or for extended features adding safety checks etc.
Kqueue support will come after a bit more testing, that should hopefully work easily as long as everything else is working.
Thanks to code borrowed from the microps project the system is now able to run simple network demos like a HTTP server, but without extended features like IPv6 or kqueue-enabled sockets.
Although this network stack is quite limited, it works, and I like it the code is very compact I know where things are. So I’m happy with this borrowed codebase but still want to improve it.
Later 1.x versions of the operating system will come with a “hardened” and more integrated version of the current stack. This should include performance/stability fixes as well as general streamlining and auditing of the code, but probably won’t involve rapid redesigns at least until I’m more familiar with the codebase.
Testing the kqueue/kevent system will be an initial priority, as well as getting features like DHCP working (this will probably involve some extended system call API unless I’m mistaken). Server applications should run well on these versions aside from lack of more modern protocols.
New drivers and a lot of documentation should be introduced in this stage as well.
Other options will be investigated for integrating a full featured network stack, while keeping the streamlined simple stack for use cases not needing advanced features.
This could involve porting functionality from the BSD operating systems or from another source, or could just be a more full featured fork of the streamlined stack. It’s also very likely that new improvements will be ported over from new versions of microps or related projects.
The porting of a simple network stack to the operating system is now complete enough for simple HTTP demonstrations, and with a few differences to xv6-riscv-net:
There will be some more updates soon, together with downloadables and plans for future improvements.
Mostly finished, still needs some cleanups but less than most kernels. A few features missing or not quite finished, but mostly working well.
The kernel core is lean and focused, most functions have descriptive names.
Ahead of schedule, reasonable support for networking is expected as long as there are no huuuuuge bugs but full support like the latest protocol versions will come later.
Behind schedule. Still relying on legacy drivers for emulators when doing most testing.
Ahead of schedule but awaiting a proper plan I hope to come up with imminently while looking into driver improvements.
Usable but behind schedule, delayed while coming up with better OS demos.
Coming but a little behind schedule.
This will probably be the focus of my work this year, although I expect quite a bit of pushback from the Australian authorities as they have thus far been absolutely fucking toxic to me trying to innovate here.