Another New Website

I’ve just finished porting my website from Vite + React + Sanity to static HTML.

Now you don’t have to download 0.6MB of JavaScript to view it. This probably won’t make a big difference to you, but I will sleep better for the fact of not living in npm dependency hell.

The underlying technology is Jekyll, which is a static site generator written in Ruby. I feed it markdown data, template my raw HTML/SASS using Liquid, and off we go.

I’ve noticed that front-end engineers use their websites to show off their extreme front-endiness, while systems engineers prefer an HTML standard non-specific webpage to underscore how they really just don’t have the time to spend on frivolities like CSS. I’m fond of simple programs which get the job done in the most simple way possible^{1 2}, and I find such websites visually appealing as-well. So here we are: I’m taking sides with the systems engineers, and taking care about my image at the same time.

I had spent some time previously identifying a blogging solution in the JavaScript ecosystem which would have involved fetching data from an API whenever someone wanted to view the website. This didn’t really make any sense, because I have no specific need to serve my data from somewhere else. (Ironically, I set it up using a CMS called Sanity.) Static HTML is a better solution because it meets my functional requirements more simply. I had used React by default just because I was comfortable with it.

Jekyll meets the blogging requirement out of the box. It describes itself as a “simple, blog-aware, static site generator”. By “blog-aware”, it means that the infrastructure for permalinks, blog posts, and categories are built-in to Jekyll. I simply create a markdown file for a new post, and Jekyll manipulates that data to generate new static pages using the Liquid template I provided it.

The porting was simple — I had no blog content which I wanted to keep, and I had only a few React components to convert. Further, Jekyll bundles SASS, so I was able to copy my old SASS directory over and have it work. The liquid template engine allowed for object composition to be kept, replacing React components with include directives. Here’s an example:

<div class="main">
    <AboutMe/>
</div>

becomes

<div class="main">
{ % include about_me.html % }
</div>

It was a few hours’ work for the port, and perhaps a day for the full website redesign. This was thanks to an excellent official tutorial. It was time profitably spent, which also left me with a curiosity about Ruby. Its 16.75 MiB download size (an additional 2.72 MiB is required for the package manager) is a breath of fresh air compared to Nodejs 22 (64 MiB) and my bloated npm projects.

OSTEP book review

I’ve been operating a sort of time-sharing scheme with respect to my reading material, which means throughput is pretty high, but time to completion is poor. The result is that I’ve finished reading Operating Systems: Three Easy Pieces after a very long time. The book is free online and I very highly recommend it.

The title is a reference to Feynman’s Six Easy Pieces, but the authors’ point out that computer science is only half as difficult as physics, and so there are only three easy pieces: virtualisation, concurrency, and persistence.

Linux is used as a reference kernel, and code examples are Linux/xv6 in flavor. It’s been a joy to see what’s going on behind the magic curtain and understand how the computer works from a low level. (The danger is that one might then want to understand computer architecture. How does the electricity do all that, anyway? And so on…)

The book begins by describing virtualisation of the CPU, and the implementation of a process. Filesystems come at the end — this was one of my favorite parts, and unexpectedly so, because I thought filesystems would be mundane. I found that problems which occur in memory management reoccur in the virtual filesystem, and have similar solutions. It caught my interest enough to want to learn filesystems further, so I obtained a dead tree copy of “Practical File System Design with the Be File System”. I’m really looking forward to going through that and understanding a filesystem implementation in greater detail.

Right now, I’m tackling Maurice Bach’s Design and Implementation of the Unix Operating System, which goes in the opposite direction – it begins with an overview of the virtual filesystem before talking about process management. Bach’s book is much heavier on the implementation details in comparison with OSTEP, and less conscientious about explaning concepts or assuming knowledge, so I’m finding that it makes a much better second book.