SerenityOS

For the last few months, I’ve been absolutely fascinated with the SerenityOS project and it’s awe-inspiring rate of progress. For every day that goes by, new features and bug-fixes get merged in, and development screencasts from the creator Andreas Kling are an almost daily occurence. The operating system itself follows a design philosophy that has all-but-disappeared from computing in the last 15 years or so – a philosophy that I, along with every other fan of this project, want so badly to reappear in the modern computing landscape. See below for a screenshot as of November 2019 —

It could be nostalgia, real productivity value, or both that drives my want for a return this kind of desktop computing metaphor. No animations, superfluous UI trinkets, padding or dark patterns. I’d describe it as a snapshot of the personal computing metaphor where the utility value for software developers was at it’s highest; right before a seemingly general pivot from what I’d call ‘focus-on-productivity’ computing to ‘focus-on-consumption’ computing. What we left behind in the early 2000s was, in my opinion, the perfection of the desktop metaphor for computing professionals.

In a spot of boredom last night, I attempted to get SerenityOS running in a virtual machine on my Surface Book 2. This proved harder than I’d had expected, so I’ll quickly outline the steps I took to get the development build working – in case anyone else can derive some value from my learnings.

What I tried

My first attempt was to follow the build instructions, to the letter, entirely within my Ubuntu MATE 18.04 VM – an operating system not unlike what Andreas himself uses for development. For whatever reason however, I kept facing issue after issue – from mismatched build dependency versions to my VM randomly deciding to corrupt whatever I download in it. After downloading Serenity’s sources externally, then transferring the tarball to the VM over a shared folder, I was met with a quite slow build process – a process which eventually failed on something that I couldn’t at all fix.

My plan B was to utilise a Ubuntu Server 18.04 VM I had spare on my home server, an Intel NUC running VMware ESXi. I gave this VM 4 CPU cores, and 4 GB of RAM. I followed the same build instructions again, this time with the build progressing much faster, until I was faced with an error in the compilation of the Serenity kernel. I’m not an OS developer, however I knew going in that usually to cross-compile an operating system, you must first compile a cross-compiler (this is what the Toolchain/BuildIt.sh script does in the Serenity repo), and that this cross-compiler is then what is used to compile the rest of the system. In my case however, some parts of the system were being compiled with my system compiler, which on Ubuntu 18.04, is GCC 7. GCC 7 does not contain support for the C++2a standard, and this was causing an issue when the code required support for it. I installed GCC 8 through apt install gcc-8 g++-8, and then ran update-alternatives as similar to this StackOverflow answer to set this version of GCC (gcc-8, g++-8) as the machine’s default C and C++ compilers.

Running Kernel/makeall.sh again successfully builds the system disk and kernel images. The build instructions now instructed me to Kernel/run.sh to run the system – however as I’m SSHed into a remote VM with no X server to view QEMU on, this wouldn’t be of much use to me. I copied the _disk_image, kernel and kernel.map files from the Kernel directory to the Ubuntu MATE 18.04 VM on my Surface Book, transplanting them into the Kernel directory of my failed Serenity build. Running ./run.sh now worked – the Serenity system immediately booted in QEMU, in my MATE 18.04 VM. As I was running QEMU inside of VirtualBox however, things were extremely slow. The smart thing to do now was to attempt to boot it on qemu Windows.

How I got it running on Windows

As I don’t have an X Server on my Windows installation to run a Linux version of QEMU in, I decided it would be more efficient to just run a Windows build of QEMU directly. I downloaded and installed Stefan Weil’s 64bit QEMU build and went on my way.

Taking my disk and kernel images from my build VM, I cloned the Serenity repo inside WSL and placed the images into the Kernel directory. The Serenity Kernel/run script is a bash script and thus must be ran by a bash interpreter. My first thought was to run this directly inside WSL, altering the Kernel/run script to use the qemu-system-i386 executable from my QEMU installation. Doing this did yield some progress, however, QEMU was still finding issues in attempting to establish a network interface for the VM. I modified the run script and removed the -netdev and -device e1000 lines from the default QEMU invocation at the bottom of the file. After making these modifications, Serenity booted successfully.

Really, there is no requirement for WSL in any of this – I used it to quickly discover what exactly the Kernel/run script was doing and to discover what to change for a successful boot. The commandline below should be able to start QEMU with the Serenity images from Windows cmd;

That’s all for this blogpost. I know I had said I’d blog once-per-week but that’s definitely something much easier said than done :/. Recently I’ve acquired and began using a Nokia 2720 Flip (2019) as my main mobile phone; I do eventually plan to write on about why exactly I decided to do this, and what it’s like to develop for the KaiOS platform. Follow me on Twitter or subscribe to my RSS to be notified when I post 🙂

Until next time.