The slicefields Rust crate is a procedural macro (essentially an extension to the language) which allows for structs to be partitioned up into bit slices which can be used as if they were members of said struct (minus some syntactical differences). This is particularly useful in kernel programming because a lot of data types contain both pieces of data and flags, e.g. interrupt descriptors. One goal of slicefield was to generate code that would compile to as efficient object code as possible, even with compiler optimizations turned off, which led to me using the faboulus Godbolt compiler explorer quite a lot.

A Rust crate which provides a container type for volatile memory access. To my knowledge, this is the only crate to support access to unaligned pointers as well as custom defined memory layout offsets, both of which are necessary in kernel programming to represent some data structures (e.g. APIC tables).

I've been writing my own micro kernel in Rust for quite some time now. Aside from learning a lot about the x86 architecture and obviously about how operating systems as well as drivers work and are designed, this led to me creating a few of the projects above. Furthermore, I believe that often having to rely on manufacturer documentation alone has improved my ability to learn new concepts and technologies greatly. As of writing this, I'm currently in the process of implementing support for NUMA and ACPI.

I repurposed an old laptop as a somewhat power efficient x86 server by removing its screen and doing some smaller modifications. It's now used to host my private Git repos, some backups, game servers and whatever else I currently feel like running there (including some of my other projects).

backnet is a lightweight yet highly flexible as well as extensible reverse proxy that was supposed to route traffic from a low-powered ARM board to my x86 server when needed so that the later could be shut down or in hibernation when only a few services would be running, thus saving power. Sadly, the prices of ARM boards prevented this but I still got a quite nice side project out of it.

After I stopped working on Minecraft related projects, I experimented with a lot of different things. Here's a non-exhaustive list of what I worked with or learnt in that time:

• ptrace
• The C programming language
• A tiny bit of Vulkan
• Injecting code into processes
• How processes work
• Manipulating syscalls

Due to me using C for a few of these, I also implemented some common algorithms and data structures myself.

My interest in Minecraft servers made me want to try out modding Minecraft and creating my own utility mod. In the process of doing so, I not only learnt how to quickly comprehend large code bases and read JVM byte code but working with Minecraft's physics engine and OpenGL also led to me being confronted with Eucledian geometry and linear algebra which re-ignited my love for mathematics. Furthermore, I planned to release Tavely for some time and developed a server for authentication, updating, integrated chat, etc. because of that. Said server was my first large project written in Rust and clients connected to it using a custom protocol. Moreover, I utilized some cryptographic algorithms such as RSA, AES and Argon2 and learnt about how they work.

I started my programming journey creating plugins for Minecraft servers using Java and the Bukkit API. This soon evolved into developing for various Minecraft mini game networks where I not only learnt how to program systems that scale to multiple Minecraft server instances but also a ton of things about working on software collaboratively, using Git and of course also Linux which is what we deployed on. Furthermore, as time went on my focus started to shift increasingly towards what would essentially be backend development, for example creating a ranked matchmaking system. Running a publicly accessible service, we of course also had to combat people cheating, abusing Minecraft bugs to crash servers and even DDoS attacks which became another point of focus for me.