diff --git a/_posts/2021-11-30-arm-x86-compatibility.md b/_posts/2021-11-30-arm-x86-compatibility.md
new file mode 100644
index 0000000..ab1e9cf
--- /dev/null
+++ b/_posts/2021-11-30-arm-x86-compatibility.md
@@ -0,0 +1,94 @@
+---
+layout: post
+title: "Moving Away From The x86"
+tags: tech x86 arm kernel bsd
+---
+
+The world seems to be slowly distancing itself from The x86 in favor of less insane architectures
+like ARM and, in some cases, even RISC-V.
+Naturally, as someone who has experienced what systems programming on The x86 is like themself
+lately, i welcome this shift with open arms (believe me, you really *do not* want to bootstrap an
+Intel processor).
+However, this does not mean we aren't going to run into major issues.
+TL;DR: It would be super cool to have an ARM daughter board that pops into one of your x86 tower's
+PCIe slots, and use kernel magic to connect the two for native binary compatibility with multiple
+architectures.
+
+## How We Are Currently Handling It
+
+A lot of software is just straight up not available on those platforms at the moment, and some of
+it never will be, especially the proprietary pieces.
+Major software companies typically respond to this by pushing application development towards
+interpreted languages like, in the case of Microsoft, C#.
+Or they are Apple who, very much in line their tradition, went full bonkers and made
+[Rosetta 2](https://en.wikipedia.org/wiki/Rosetta_%28software%29),
+an x86 to ARM recompiler.
+
+Now, the Open Source community isn't nearly affected as much by all of this.
+Most software that is written in languages that produce native binaries can just be compiled for
+whatever architecture you desire.
+And by the nature of being open source, those that can't can at least be adopted by the community.
+Not to mention that popular open source kernels, most notably Linux, have been ported to just
+about anything with a processor.
+
+## Lame!
+
+The two corporate solutions have problems.
+Both come with a performance penalty because of the recompilation overhead
+(JIT in the case of C#, AOT for Rosetta).
+Also, i don't find them particularly cool or exciting.
+You know what would be super cool and exciting, though?
+Throwing hardware at the problem!
+Design a daughter board with an ARM processor that you can stick into one of your existing x86
+tower's PCI Express slots and boom, you're done!
+This is also what Apple did way back in 1995 with the
+[Power Macintosh 6100/66](https://www.youtube.com/watch?v=9UclHrIIaYA)
+by the way, so we know that at least in theory it could work as a viable product.
+Now, of course it isn't quite *that* easy, because you will also need at the very least a kernel
+that plays along with it.
+
+## Introducing GayBSD
+
+If you follow me in the [Fediverse](https://notbird.site/@fef) or on
+[Bird Site](https://twitter.com/libfef),
+you might have already gotten wind of that thing currently working on called GayBSD
+(actually, besides rants about The x86, it's almost exclusively what i post about these days).
+It is basically a microkernel that, except for its libc and probably its network stack once that
+becomes a thing, is written completely from scratch.
+As the BSD in its name suggests, it is supposed to be a BSD adjacent kernel, and i am in fact aiming
+for ABI compatibility to FreeBSD in the end.
+I was already playing with the thought of making it not only a microkernel but also a distributed
+one, and this seems like the ideal use case: native binary compatibility on multiple architectures!
+The project is still *extremely* young; as a matter of fact, i haven't even reached user space yet.
+So, i have decided to take the opportunity and leave the core design open to such an extension.
+It shouldn't even be *that* much extra work, since the nature of being a microkernel requires some
+form of abstract IPC protocol anyway.
+
+But how would this be implemented in practice?
+My thought is to handle it kind of similar to the way FreeBSD does ABI compatibility to Linux and
+other kernels.
+You have a `/compat` directory that essentially contains system roots for the respective native
+kernel and architecture (e.g. `/compat/x86-freebsd` for x86 FreeBSD binaries), and when you
+`execve` something the kernel automatically `chroot`s into the respective directory first.
+The directories inside the sysroot that are supposed to be identical on all architectures (like,
+pretty much anything besides program binaries) can just be bindings to the actual system root.
+
+This leaves us with only one problem: shared memory.
+If an ARM program wants to do IPC with an x86 daemon by writing data to shared memory, there might
+be a mismatch between the data structure on x86 and ARM.
+I don't expect this to be a major problem in most cases, because C's fundamental data types are
+(as far as i know) the same length on both platforms, but there might still be architecture specific
+quirks in individual programs.
+You probably have to try before you can tell for sure.
+Another, rather obscure situation would be if the daemon was a JIT compiler, in which case the only
+solution would of course be spawning an entirely new daemon for that specific architecture.
+
+## Conclusion
+
+In case you haven't noticed, this idea hasn't exactly gotten a lot of time to mature.
+Yet.
+But i find it a quite interesting concept and hope you do, too.
+
+If this post got you excited, you are welcome to contribute to GayBSD!
+The source is available at <https://git.bsd.gay/os/kern.git>.
+Just contact me through one of the means in the footer below if you would like to know more.