Blog

  • Multithreading Work Continues

    Code for synchronising multithreaded programs has been added to my libc (but is mostly just empty dummy functions for now), and the graphics server (“desktop”) is now starting to get closer to normal GUI rendering including ordering of windows and bring-to-front commands.

    So far the new desktop system is stable but useless, and improving gradually, I expect it will take a few more days to get it functioning somewhat smoothly with input and then probably another month or more to iron out some glitches and have it running real apps.

  • Why Are All The AI Companies Run By Idiots?

    Genuine question, who is hiring these mentally deficient people to run large companies involved in “intelligence”?

    There are plenty of people who don’t need a GPU to write code for them who could be running the show instead, why is it so much harder for us (people who don’t act lobotomised) to get hired?

    Jensen Huang is dumber than a baked potato, why the hell are militaries buying chips off someone that stupid? It seems like these figureheads are just political plants who are extra loyal to western imperialism but offer no engineering value. All those chips do is matrix calculations, you shouldn’t need any advanced proprietary technology for that.

  • First Peek At Window Decorations

    Not there yet, but I wanted to upload the first screenshot that actually draws a window!

    The final window decorations will probably look much like this “DeskTool Demo” window though, as I do not plan to even bother with glossing it up to compete with modern operating system bubbleware crapshows. Fonts and other things can be improved later once I’ve added more drawing functions.

  • Same Vibe As WWI

    On the plus side the Australian army are not very keen on hiring people who grew up here anyway, but somebody else will probably be dieing for foreign interests in Australia’s name.

  • Is Australia Buying Duds?

    It looks like current generations of American aircraft aren’t as effective against modern air defences as the Americans seem to have had people believing.

    Australia is even more invested in these aircraft than Israel, and the ones in use there seem to be making news for “hard landings” when put to use against Iran. These reports are appearing in mainstream outlets now but there were already unconfirmed reports of these planes being downed a year or more ago.

    Australia should have supported local industries instead of buying junk from overseas and getting drawn further into these conflicts as a result.

  • Progress Towards Terminal Emulator

    The (third-party) libtmt library is now partly integrated with the desktool program but hasn’t been enabled yet, in the meantime I’ve been adding the text rendering code to desktop to start painting terminal-like program output.

    This is shown as a block of dummy text output from desktool at the end of it’s checkerboard test output (later this will be connected to libtmt for real terminal output).

    Other changes include beginning to support wide characters in libc, but to run a real terminal emulator other features are needed like a virtual terminal device in the kernel for connecting it to terminal programs properly.

    NOTE: This is another screenshot made in a virtual machine on Ubuntu, ignore the window decoration at the top (I haven’t developed window decorations in the new desktop yet).

  • Next Milestone Set: Terminal Emulator

    This will mean some new kernel features will need to be implemented to support virtual terminals, at least enough to provide posix_openpt and ptsname functions, as well as porting a terminal emulator system itself and adding some font rendering & input functions to the desktop system.

    The terminal emulator will probably be part of desktool which should provide basic diagnostic & demonstration capabilities for the desktop system. This support may be based on libtmt or a similar library. A more advanced terminal emulator may be developed later along with further work on GUI toolkits, better fonts etc.

    Once a simple terminal emulator works on the new desktop & kernel it will start becoming much easier to demonstrate other multitasking & graphics capabilities, and to start moving my development workflow into the new system as well!

  • I Think The Police Don’t Like Me

    … Because I claimed that the Egyptian government is in control of their phone spyware. If police in westernised countries have access to this kind of technology what do they think other people will be doing with it?

    https://www.theguardian.com/australia-news/2026/mar/18/nsw-police-overusing-highly-intrusive-legal-powers-to-monitor-phones-and-computers-national-watchdog-finds

    The only real solution is to promote full secure operating systems with no planned government backdoors (it seems to be the case that the popular phone platforms pushed on everyone are designed to destroy user privacy).

  • Networking & Threading Code Is Stable!

    My earlier bugs seem to have just been in obscure test scenarios (specifically reading/writing zero-size or huge-size blocks at a time doesn’t work!), in normal operation such as for simple non-blitting drawing commands the networking & threading code doesn’t present any problems.

    Without further hesitation, finally a screenshot of a regular “client” program running on the new desktop system on my kernel (within an emulator window still!). From these humble beginnings I hope to develop an entire graphics library that’s efficient and flexible enough for my OS.

  • Ambitious Design Meets Elusive Bugs

    I announced the new desktop system at the very beginning of it’s development, the time since has been spent developing more of a structure for prototyping the desktop system and working towards resolving underlying weaknesses in my kernel & platform.

    Design: Multithreaded Networked Desktop

    The desktop system is designed in a fairly straightforward manner:

    • A desktop server splits off into multiple threads to handle connections, rendering & input from different “client” programs
    • Client programs connect to the server over standard socket APIs (until some faster mechanism can be negotiated over the protocol in the future)

    This design is similar to some legacy graphics systems and also helps test features like networking and multithreading in the kernel, the downside being that it’s very exposed to any bugs or limitations of these features.

    Solved: Lack Of Loopback Networking

    The first problem with this approach was that I had to extend the networking code slightly to enable a “localhost” type loopback network.

    This now appears to work, but may need some cosmetic changes to avoid people confusing it for a real network driver (right now it shows up like a normal network backend).

    Problem: Multithreading/Wakeup Instability

    While the client/server architecture works correctly on the new kernel & microps-based network stack in simple test cases the kernel will probably require some more troubleshooting before I can get it to work reliably with multiple threads and in different timing scenarios.

    Multithreading code in the kernel has only been used for straightforward tests previously so some degree of “unexpected” behaviour was expected. Currently I’m having some problems with the secondary thread hanging when almost the same code seems to work in single threaded or forked-process situations, so this is likely a problem relating to unfinished multithreading support but will take a little while to figure out the exact problem.

    While basic support for multithreading exists at the kernel level, the libc (C library) implementation currently has no support for multiple threads, so the current problems could just be a simple problem like malloc memory being corrupted due to a call in the second thread. In that case the fix will probably just be enabling locking in some libc subsystems.

    Summary

    It’s all still coming, and some more workarounds can be made if not every problem can be solved in the short term, but the kernel & libc code in particular will take a while to get to a stable point where I can easily develop & debug new programs on it!

    This is part of the reason the desktop system is designed to run on Linux or elsewhere as well, making it easier to determine which bugs are in the desktop code and which are deeper in the system.