This post was supposed to come out on the 14th-15th of February, however things happened, I'm ill again for the 2nd time in 2 weeks and I totally forgot.

It's official, ToaruOS is planned to have a 2.3 release almost 3 years after 2.2.0 was released (and the only source available 2.2.1).

On February 13th 2026, klange created an issue named "ToaruOS 2.3 Planning".

The issue reads as follows:

It has been over two years since the last numbered release of ToaruOS.

Major changes that have already landed for 2.3 include:

• An improved DNS resolver.
• Several improvements in Kuroko.
• New system calls like pread, fcntl, rename.
• Support for multiple ICMP sockets so you can send simultaneous pings.
• A real sigsuspend, and improved support for signals overall.
• Support for current versions of the virt QEMU AArch64 configuration.

However a line was edited out which talks about 2.2.1, despite no proper release:

We have been using the intermediary version "2.2.1" since then, but it has been so long that we should rename this to "2.3" and begin planning for a formal release.

Since this announcement, many other things have been done in ToaruOS. For example, the mv, cp and rm commands have gotten a bit of an overhaul. To quote klange:

mv now at least calls rename to attempt to perform local moves before falling back to cp and rm, but it would be better if mv directly performed the actions from cp and rm. Sharing code between these three utilities is fairly common in other implementations.

Avoiding the extra execs is beneficial on its own, but it also means we can more easily report appropriate error messages - at the moment, if mv has to call cp and cp fails the error message will say cp instead of mv.

This was then followed by:

I have largely rewritten mv to hopefully do more correct things and support moving multiple files into a directory with rename.

Along with this, there have been a ton of fixes to the Toaru libc along with small little bugs in userspace programs. It also seems like we are getting fchmod, fchown, truncate and ftruncate capability in ToaruOS, mentioned in ToaruOS's issues by a friend of mine from the Arikoto project.

Now I know this is really silly for me to say about a hobby OS that isn't even supposed to be used like a real OS But I think the most exciting part about all of this for me is that ToaruOS might finally also be getting a Netsurf package in the repositories!

klange said in, the now almost 3 years old, issue #277 "Restore Netsurf port":

I have had a separate checkout of the main OS repo for going on three years now with the build environment for Netsurf. I double checked that the built binaries still work in a current build of the OS, which it does:

I am trying to work out what I actually patched in Netsurf. The Netsurf source tree is not from a revision control repository, so I need to directly diff it against a fresh download of the same version.

Additionally, I believe I did this previous work before the last (ever?) release of Netsurf, so upgrading might also be worthwhile. There's also been some development in Netsurf since that release...

klange also plans to give msk it's own dedicated packaging format again, which also includes a little detailed explanation!

In ToaruOS 1.2.x, backed by Python, we had a dedicated package format consisting of compressed tarballs with a JSON control file containing information on dependencies, package names, descriptions, etc. As we abandoned Python and gzip in the NIH project, this package format was dropped, and for a time the package management system was reverted to its pre-1.2 state of installing files directly. Eventually, the package system regained support for tarballs and then compressed tarballs with the introduction of our own inflate library. We also have a json library in C, plus a separate JSON parser for Kuroko, so the dependency chain for supporting similar "all-in-one" packages has returned.

The entire msk package manager could use a rewrite: It suffers from a number of issues related to how it downloads and unpacks tarballs, it relies on having an available terminal emulator to display progress, and it's still built around support for all of these weird "package" formats (raw binaries, tarballs installed to particular directories, etc.).

I think it's about time we actually do this...

The last version of the original MSK package manager is here: https://github.com/klange/toaruos/blob/v1.2.3/userspace/py/bin/msk.py And its GUI frontend is here: https://github.com/klange/toaruos/blob/v1.2.3/userspace/py/bin/package_manager.py

The format of the original MSK packages is worth bringing back directly, I think. A classic MSK package was a gzipped tarball consisting of a manifest.json at the root, preferably the first file, and then a . directory containing the root filesystem contents for the package.

The basic structure of our current tgz files matches the filesystem contents of the old packages - we're just missing that manifest at the beginning.

Let's look at a sample manifest.json from the glgears package:

{"package": "glgears", "version": [1, 0, 0], "description": "Displays 3D rotating gears.", "maintainer": "K Lange <klange@toaruos.org>", "friendly-name": "GL Gears", "depends": ["mesa"], "icon": "gears"}

We have a JSON object with the following members:

• package is the name of the package.
• version is an array of three integer version numbers, so 1.0.0 is [1,0,0].
• description is a textual description of the package. These could contain markup in psuedo-HTML syntax, but this was rare.
• maintainer is a git-author/email style description of package maintainer.
• friendly-name is the name displayed in the package manager GUI.
• depends is an array of dependencies that must be installed first. In theory these are all just strings, but we could support more complicated dependencies with minimum version numbers.
• icon is the name of an icon to display; the icons had to already be installed to be supported. We could probably do something better where the icon is embedded or expected to be found in ./usr/share/icons/48/ within the package.

The original MSK format also didn't support post-install scripts.

Our current setup includes post-install scripts in the archive and specifies them in the (global) manifest file.

We could take a cue from deb and have the post-install script be in the archive but not in the installed content.

I cannot wait for the release of ToaruOS 2.3 and I hope this means that ToaruOS, Kuroko, Bim and other Toaru projects are back in some form of active development, or regular committing.

But the real question is, will pull request #322 make it into ToaruOS 2.3?

I want to start by saying that, yes, this is two blog posts in one day. This is UNPRECEDENTED. Anyways, let's talk about how I even got to this.

Prior to 2025 I used to main Windows on my main PC unfortunately. Yes, I WAS (keyword being WAS) a Microslop fan. However, I started leaning more towards Linux since 2020-21. I had mained Linux on laptops for a long time along with Windows.

In January 2025, shortly after getting this blog, I had switched to Gentoo Linux on a new SSD. I took back control of my machine from not only Microslop's hands but also HP's claws. Specifically, HP basically has what I consider a rootkit in Windows using their device hardware drivers. I'll probably talk about the HP thing at another time though.

Well, over time I used it for everything until things changed in August 2025. I was looking for a new music production machine to take over from my old MacBook Air from 2015. Logic Pro's trial (which I now have officially bought) was the only thing I was used to. I tried LMMS but just couldn't get used it it, and Audacity wasn't good enough for what I needed.

I finally bought an M4 MacBook Air, and here started "The *BSD Preference". I had already had some distaste to GNU and Linux, mainly because of The Stallman Report. (BIG CONTENT WARNING: This report goes through RMS's views on children and sexual relations along with plenty of other things. Do not read it if you are sensitive to those subjects.)

Linux also has Rust for Linux which has (unfortunately) suceeded in becoming a kernel language. I know this sounds very VERY controversial and a lot of Linux subjects are. In fact, Linux is just very controversial in nature. Rust has a lot of drawbacks that should NOT belong in a kernel like Linux at all. For one, Rust introduced a CVE into Linux that previous C code didn't do which crashes the entire system. Not to mention that adding another language to a kernel like Linux is a horrible idea for existing maintainers who are used to the C and Assembly base.

Linus Torvalds has also been very accepting of the idea of AI code in the kernel, even vibecoding his own projects. This is a very dangerous position to take. Linux is ran on hundreds of thousands, if not millions of mission critical systems, including my own little home office infrastructure.

If Linux wasn't as big as it is now, nor pushed as heavily as an alternative to Windows or other systems, I would probably be fine with it, but I see this as a direct attack on security and stability of systems across the planet and beyond if there are any Linux systems out in the vastness of space. What if a bug presented by AI code had slipped through all testing QA during the release process and was exploited actively in the wild? I predict this would be worse than what the xz-utils backdoor's effects would have been as this is KERNEL LEVEL.

Imagine every system on a future Linux version, let's say 6.23.2, compromised by an undiscovered zero-day exploit that was introduced by AI slop. Imagine that. I don't want to hear the stupid "oh but that will never happen, they catch it, there are systems in place for this" excuses. Under no circumstances should AI code ever be in production software that is used by very mission critical systems.

Don't even get me started on the stupid wars over distros, tools, init systems, libraries and just anything under the sun. It should be a matter of preference and reasoning, not elitism or rivalry.

Yes, I preferred Wayland. Yes, I preferred OpenRC. Yes, I preferred Gentoo. Yes, I preferred musl. But I don't hate the others nor am I negative towards using them. I have my own valid reasons for why I use them. Sure, I'll recommend them to others, but I won't mock them for using X11 or systemd.

And this is coming from someone who used to be a strong Linux elitist. I used to make fun of people for using NixOS or anything else like that, but I realised that was all because I was trying to fit in with the wrong people.

I know this might all sound contradictive of what I said about Rust but Rust has it's own issues separate from this argument which geniunely affect lots of people outside of just me unlike the usual elitist arguments.

For the last point of this, of course, LKML drama and in the community in general. That's pretty much self-explanatory.

I think I've covered all in Linux, so...

How did my MacBook Air start "The *BSD Preference"?

Well, for one, *BSD and *NIX operating systems feel cleaner and more professional than Linux. If anything, I think the speed of macOS on Apple Silicon made me see those operating systems in a new light.

This increased when I tried FreeBSD on a VM too, it just felt so fast as well. Everything just worked.

**FROM HERE ON OUT, THINGS I SAY COULD BE WRONG. I HAVE NOT BEEN IN THE COMMUNITY FOR LONG.**

When it comes to *BSD especially, everything is there and documented. There's no war over really anything. FreeBSD, OpenBSD, NetBSD and any other BSD are all different from each other in their own way with their own set tools which really removes all of the arguments I see in Linux.

Even Rust isn't that big of an issue either. While the FreeBSD team were toying with it in userspace (which I kind of disagree with doing), they don't seem to have a plan to add it to the kernel with is fine with me.

FreeBSD even have an AI policy where no AI code can be put anywhere but it can however be used to understand the codebase and write/translate documentation. This only happened because someone tried submitting an exFAT driver to FreeBSD... which AI wrote that was too similar to Linux's implementation.

Let's jump back to the "all different in their own way" point. One of the reasons why this is true is because of the fact that in Linux, everything comes from all over the place. Even the kernel might come from your distro packagers. In FreeBSD for example, all of it comes from one place. All the FreeBSD base tools comes from FreeBSD's source code repo. This is why documentation is so good in FreeBSD, the people writing the OS are the people writing the documentation. It's a distribution of the kernel all packaged in one source code repo that happens to be the main kernel repo.

Honestly, FreeBSD and other *BSD and *NIX projects need more attention. Perhaps some Linux maintainers peeps could help the FreeBSD development peeps?

When it comes to XNU/Darwin/macOS, it's just a fancy UI and ecosystem on top of a highly customisable BSD x Mach combination kernel... that is unfortunately really hard to modify unless you already work at Apple and have a deep understanding of all of the bullshit you'll get thrown at you when you try to make your own build.

But *BSD has some class to it and in fact that and everything else from before can mostly apply to *NIX projects too. It feels like it's made by real architects and not the online equivalent of UK Parliament in a mailing list.

Well, that should hopefully explain why I like *BSD and *NIX systems more than Linux nowadays. If you want to discuss this with me, feel free to ping me on Mastodon at @mrmasterkeyboard@mastodon.social or comment on the thread I'll put up for this post on my Mastodon profile!

XNU is a very powerful kernel, stemming from the NeXT Mach days and prior to that. I really, really like XNU and have always wanted to have my own fork of it to play with, compile and boot in a bare VM.

I don't want to install macOS in a VM just to run an XNU build. I just want raw XNU. Unfortunately, none of this is really possible I've slowly realised on AARCH64 or x86_64.

Here is some of my experience with XNU and microkernel projects on macOS. To begin, I've spent continued days, if not weeks or months on this. For starters I will lay out what I've observed.

Present day XNU = builds, impossible to boot bare in a VM.

Older than a couple of years XNU = harder to build, still can't boot.

Even older XNU = impossible to build outright, I don't even know if it can boot.

Of course, this may not be the same for everyone but still. I also can't seem to build the BCM2837 (I think that's the SoC name) kernels either. In the end, after multiple late nights, I've still gotten essentially nowhere.

Now what about microkernels, perhaps the same fate isn't present here? Immediately we have to rule off Google Fuchsia (Zircon), Managarm and a boatload of others.

Google basically hard-killed building Fuchsia on macOS completely and Managarm just seems to not even get anywhere close to building on macOS.

Anything like fiasco.oc, L4Re, seL4, etc are either unbuildable on macOS or too hard for me to figure out. There is just so many that would be buildable on Linux but I rather prefer BSD and macOS overall, so I don't usually pull out my Linux laptop. Perhaps I'll cover that in another blog post.

I do plan that maybe someday I could smash different parts of kernels together. I'd most likely want to see a XNU/Zircon combo. XNU with Mach dropped for Zircon would be cool. Maybe a new kernel that just combines parts of Zircon and XNU together.

I know this blog post is quite short but this isn't something that I could put lots of detail that wouldn't bore people to death.

In the end, I'll probably end up writing my own microkernel.

I've officially had this blog for over a year at this point, starting from January 2025. It's time to stick to my service transition plan and finally move to Codeberg.

Unfortunately, this is not the last step. I'm still waiting for klange to merge my PR into ToaruOS and I don't know when that is. Then I can delete my fork, which leaves me with 0 GitHub repos.

This move came with an issue. I wasn't sure if Minimal Mistakes, the previous theme and base, worked on Codeberg's CI and I'm not willing to deal with whatever tomfuckery comes from that...

So, I decided that I'll take a page from klange's book and use the same base that he used for toaruos.org. (GitHub repo for toaruos.org)

This new blog design is using Pelican, and yes, is a hard-fork of the toaruos.org repo code. (It's a good place to start learning and understanding how it works since toaruos.org's code is quite minimal and not hard to understand at all.) All older posts are, of course, still accessible here.

However, you may notice, this blog looks nothing like toaruos.org... and more like NeXT/OPENSTEP. This is because I'm really getting into NeXT stuff right now, I think it's really cool. Also, I can't just keep the blog looking like toaruos.org.

Over time, I'll make this look more accurate or maybe it's own inspired design but for now, it won't look perfectly like it.

By any means, this will be a huge step forward towards leaving GitHub.

Well, I genuinely forget that I have a blog sometimes and when I do remember I usually don't have anything good to post. Actually, back in August I was making a post about my new MacBook Air which had a really good title... that is now stuck on my now unplugged desktop machine which I cannot be bothered to plug back in. Good job, me.

You don't have to worry that I've abandoned the blog, I'm back now. Going into 2026 (jeez, it's been a year already?) I will make more than just four blog posts per year. So, let's catch up on what has gone down over the last 9 months since I've posted.

For one, Arikoto became a thing shortly into 2025. This is a long story, which I'll probably save for another post. Arikoto is my x86_64 OSDev project that... honestly kind of sucks. It's broken kinda badly and I can't seem to figure out why. We can switch from userspace task A to B and then it just hits a General Protection Fault. (And if my friends are reading this, no I'm not joining the OSDev Discord server. I'm too scared.)

I've gained quite a few friends and new projects since the last time I posted here. A lot has happened actually. The biggest being that the world has been plunged into absolute fucking chaos that I wish I could ignore.

I did switch to Codeberg during August or sometime around that, except for a couple of forks and this blog. The blog I'm not sure would work on Codeberg Actions and the forks are needed for making contributions to their parent repositories.

I'm now also on IRC! Specifically, I've been helping with the Moss kernel which has a channel on irc.oftc.net at #moss!

There's too much to talk about really, and it's midnight as I write this so I guess I can continue this over the coming weeks.

Anyway, thanks for sticking around everyone! I swear to god I will try to get more posts out.

So, as you may already know by now (if you know anything about me), I really like ToaruOS and its utils.

ToaruOS already has RPi4/400 support. RPi4 doesn't work too well from my testing but RPi400 probably works fine. I don't have an RPi400 but I assume K. Lange does. Why would he add RPi400 support if he didn't have one?

Anyways, I got ToaruOS to run on my RPi3. It didn't take too long. I posted a discussion about it actually.

Over the time since I posted that, I was thinking to myself:

"Hmm. Could I get my RPi3 support into ToaruOS upstream?"

Last night, from when I wrote this, I submitted an issue to the ToaruOS repo. I hope that it can be merged in eventually.

More to come from this soon.

Well, it took a while but it worked.

Kuroko is now in edge/community on Alpine. It took a while to get here. Total of 2 merge requests.

testing/kuroko: new aport (!78565) community/kuroko: move from testing (!80770)

With this addition, I've been trying to learn Kuroko. I know, I know. Adding a language to Alpine aports when you don't even know how to program for it sounds like a terrible idea.

Along with learning Kuroko, I'm making a distro with Kuroko in userspace and musl as the libs. Unfortunately, os.system in Kuroko doesn't seem to work on the distro (err code -1) but it works on Arch and Alpine?

It's a weird case but it's a thing I'll probably be able to fix.

Anyways, more to come in the works. I still need to post about Arikoto (my operating system development project) and other misc things that I'm involved in.

Something most people don't think of... unless you use postmarketOS on your phone and you wanted to port something over to main Alpine.

Now, I think my blog would be the perfect space to share this. I did share this on Mastodon at one point, but this would go more indepth as to why.

What did I port (if you didn't bother to click the hyperlink I had, how rude! /j) you may ask? I ported a long time favourite package of an OS I liked. None other than the Kuroko programming language for ToaruOS!

Honestly, this is so niche that I really don't think anyone has ever ran Kuroko on postmarketOS let alone the Pixel 3a.

After compiling all of it together on my phone and joking that I would submit it to the repos on my Mastodon post, one person in my comments section actually convinced me to do it. So, I submitted it.

Ask and you shall recieve, my fedi friend. Besides, it'd be a fun first contribution to Alpine repos. It was frustrating trying to get a working, non-lint warning, fully working APKBUILD but in the end I got it in less than 24 hours.

I think it was quite impressive about how fast I got this all working. It took a bit of time, but it was fully worth it.

As of writing, the merge request on their GitLab is still to go through but I believe it will go somewhere soon enough.

This page may change over time, keep a look out please!

(And my mistake, this post was originally contributed under my Alpine GitLab forwarding email. I guess this just shows how much I've worked on this that I've forgotten to change email!)

Hello!

Here is my blog (after doing nothing with the original idea for over a year).

Very basic, but will expand as I figure this out. Expect to see more posts related to projects I have here.