Skip to content

Oliver Dixon

Welcome

I’m Oliver Dixon, a software engineer in the final year of a degree in Computer Science at the University of York. Thanks for visiting my website; I hope you find what you’re looking for. If not, please email me at od641@york.ac.uk.

This website is an amalgamation of personal and technical content. If I have an opinion on a topic (which I’ve been told is highly likely), it’ll probably appear on here. The main categories, accessible on the top menu, are:

  • Projects: personal software-adjacent projects I’m currently working on, or have previously completed. Most of these were born out of personal interest, unrelated to the university curriculum, but some started as coursework and grew into something more. I open-source almost everything I do in my spare time, but project pages try to be more than an extended README.
  • Blog: shorter, more frequent articles covering topics that I find interesting.
  • CV: a Markdown rendering of my CV covering professional activities.
  • Non-Tech: pages covering non-computing content.

About me

My top three interests, in descending order, are:

  1. Spending time with Maia (fiancée).
  2. Deleting code.
  3. Cycling, but not competitively.

Maybe those latter items should be broken down a little more. The first point needs no elaboration.

Computing

“Computing” can refer to many things, but I like the phrase because it is sufficient to express a fairly specific interest without sounding too pretentious. But, since you’re here, you probably want something more specific.

I’m mainly interested in systems software: C++, formal methods, signal processing, WebAssembly/WebGPU, embedded systems, and the unglamorous engineering work needed to make large-ish software projects stay understandable over time. Most of what I build sits somewhere between software engineering, mathematics and hardware-adjacent computing.

My hobby of “deleting code” tells you everything about my approach to software development. I detest complexity with a passion, and nothing brings more joy than cutting away vast amounts of code and admiring the commit diff. Of course, this strategy works best when the existing code had a reasonable set of unit tests and benchmarks, so the functionality and performance of the impending refactor can be validated; but in truth, if it’s ugly, I’ll probably want to delete it anyway!

Here are some projects I’ve worked on in my free time. Most of them are self-initiated, though some were a result of university coursework that I took beyond the spec out of interest. They’re listed in rough reverse chronological order.

  1. Digital signal processing workbench to run natively in the browser (source).
  2. Requirements engineering software using first-order logic (source; report).
  3. FPGA-accelerated nonogram solver using FreeRTOS (source).
  4. Demonstrations of computational fluid dynamics simulations under different computational paradigms (CUDA source, OpenMP source, MPI source; video).
  5. A command-line querying tool for the Gentoo package manager (source; interview prep providing some more context).
  6. Kernel driver and userland utilities for interfacing with a 1980s-era electronic teletypewriter (video 1; video 2).
  7. Mandelbrot and Julia fractal rendering application in C and OpenGL for A-level Computer Science (source; video; report).

Like most C++ people, I like the idea of Rust but haven’t found time to build any non-trivial projects using it. At least for solo-developer projects, I feel that modern C++ provides you with enough opt-in safeguards to write good code, relative to C or pre-C++20. (You could repeat that sentence when discussing Rust, only having to remove the “opt-in” qualifier!)

I’m also fortunate to work in the Computing field (full-time software; part-time systems; part-time hardware; part-time network; part-time firmware; part-time DevOps; part-time algorithms), so I have experience in a few more technologies that aren’t listed above, such as the venerable area of Model-Driven Engineering.

I’ve also done some extracurricular technical projects in Mathematics:

  • First-year university report covering some applications of Category Theory in Theoretical Computer Science, such as functional programming paradigms and computer algebra systems (report; presentation).
  • Typesetting tour de force covering a second course in Analysis (following Real Analysis; prior to Functional Analysis) (source; document).

Everything besides computing

Outside “work”, in which I conveniently choose to include studying and working on personal projects, I enjoy cycling, but not competitively, and not always on smooth tarmac. I’m past the stage of feeling self-conscious in cycling clothing, but haven’t quite reached the level of understanding required to rationalise spending £8,400 on a single bicycle wheel. (That’s something of an outlier, but it feels representative of the higher-end bike industry as a whole.)

At the moment, I ride a 2026 Trek Checkpoint ALR 4 Gen 3 gravel bike. It’s fully tubeless (although I run a tube in the rear), and I have only had one (slow) puncture in about 5,000 miles of riding. The large size provides a comfortable riding position for my typical-cyclist frame (188cm; 75kg BW), and I slammed the stem to make it feel like I’m pedalling harder. The groupset is the road variant of Shimano CUES: a mechanical but nippy 1x11 setup. For all rides, including commuting, I really enjoy wearing the Specialized Recon 2.0 SPD shoes.

I’m currently planning my first long ride from Hull, UK to Eastern Europe along the Central European and Iron Curtain EuroVelo routes, likely to take place in early summer 2027 following graduation, prior to beginning a grad job.

About this site

I created this website to replace my existing university-hosted instance (archived; live). The IT provision at York is best-in-class, especially for Linux tinkerers who like to break things, but I considered it important to provision infrastructure capable of:

  • Outlasting my time at the university.
  • Hosting dynamic content if needed.
  • Being used for “other stuff”, which, while technically possible on York’s infrastructure, might raise some eyebrows, such as running self-hosted GitHub Actions daemons.

The backend hardware is not exactly the Viking supercomputer, but it has held up well so far.

owd@semanticpad:~$ lscpu
Architecture:                x86_64
  CPU op-mode(s):            32-bit, 64-bit
  Address sizes:             39 bits physical, 48 bits virtual
  Byte Order:                Little Endian
CPU(s):                      4
  On-line CPU(s) list:       0-3
Vendor ID:                   GenuineIntel
  Model name:                Intel(R) Celeron(R) J4105 CPU @ 1.50GHz
    CPU family:              6
    Model:                   122
    Thread(s) per core:      1
    Core(s) per socket:      4
    Socket(s):               1
    Stepping:                1
    CPU(s) scaling MHz:      96%
    CPU max MHz:             2500.0000
    CPU min MHz:             800.0000
    BogoMIPS:                2995.20

owd@semanticpad:~$ lsmem
RANGE                                  SIZE  STATE REMOVABLE BLOCK
0x0000000000000000-0x000000006fffffff  1.8G online       yes  0-13
0x0000000100000000-0x000000027fffffff    6G online       yes 32-79

Memory block size:                128M
Total online memory:              7.8G
Total offline memory:               0B

The software stack isn’t very exciting either: it’s running Ubuntu Server 26.04 LTS. Most services are containerised with Podman and orchestrated through systemd (with Quadlets) behind a Caddy reverse proxy.

Currently, we (as in myself, my father Mark, and my fiancée Maia), use the box for:

  • This personal site, built with Hugo.
  • Mark’s staging and development area for his WIP SemanticPad web application, which uses Apache Tomcat for servlets and MariaDB for persistent relational storage.
  • Maia’s file storage and multimedia server.
  • A constant reminder of paying the ISP £5/month for a static IP.

Education

I’m due to graduate in the summer 2027, with a Master of Engineering in Computer Systems (with a year in industry). There are a few components to break down, especially if you’re not familiar with the UK higher education system:

  • “Master of Engineering”: essentially a regular three-year Bachelor’s degree, specialising in some form of engineering, immediately followed by a “top-up year” to reach (in theory) an equivalent level of education as a standalone Master’s degree, sometimes called an M.Sc. Traditionally, the Master’s level was intended to be more research-focused than the preceding years of study, with the goal of preparing students for doctoral level study, but this distinction has largely been lost.

  • “Computer Systems”: Computer Science. The name mismatch is due to a technicality involving the process of degree accreditation in the UK. At York, there are two courses identical in all but the name: Computer Science, and Computer Systems. The former is vetted for quality and rigour by the British Computer Society; the latter (despite having an identical curriculum) is not. By opting to take Computer Systems, students experience at least four things:

    1. Upon completion, a mildly less prestigious degree certificate for people “in the know”.
    2. Freedom to enrol in modules that were not checked by the BCS.
    3. Requirement to take an additional exam to join the BCS as a member following graduation.
    4. A potential barrier to entering regulated industries post-graduation, though for computing this is far less poignant than, say, electronics or medicine.

    As I’m interested in mathematics, which isn’t connected to the BCS, taking Computer Systems allows me to mix modules from the Department of Mathematics with the Department of Computer Science to have, in my opinion, a more well-rounded education. The CS course at York is quite traditional, insofar as training students in mathematical logic and fundamentals of CS, so the mathematics modules complement the core structure very well.

  • “(with a year in industry)”: the best part. Between the second and third years, students temporarily leave university to work in industry for around a year in a role relevant to their course. For most CS students, this involves working at a medium-to-large company in some SWE-adjacent position. I completed my placement at Thales Underwater Systems in Stockport, Greater Manchester.