Last time, we started our quest to understand the art of time-keeping by first trying to understand what years and dates are. Today, we shall take a look at time itself, and understand how we might divide up a day.

For most of us, the basic unit of time is the second, ticking constantly. However, the reality is far more complicated than that. The question “what is a second?” has more than one correct answer, and it all depends on which time standard (i.e. clock) you are using.

In this post, we shall cover the most common time standards:

1. Uniform Time.
2. Solar Time.
3. Universal Time.
4. Reconciling the difference between uniform time and solar time.

On the way, we shall also examine what a day actually is.

I recently created an interactive version of the French Republican Calendar, using the original equinox-based system of leap years. This was not my first encounter with calendars and time-keeping — back in 2021, I had created a programming contest about calendars for World Emoji Day (July 17th, the date most often shown on the calendar emoji 📅), and most of what I learned then was applied to my French Republican Calendar app.

While creating these, I was forced to confront the inherent difficulties of time-keeping. At first glance, it seems deceptively simple — one simply has to count the number of seconds, and once enough seconds have passed, we say that a day has passed, and when enough days have passed, we say that it is a new year. This seems simple enough. At this point, you might remember that there isn’t an integer number of days in a year, which is why leap years are needed.

This is, however, a simplified explanation of something far more complicated. As we shall see, the rotation of the Earth itself is not consistent. This is the reason behind the dreaded leap seconds, but I am getting ahead of myself. Other factors at play include time dilation caused by relativity. I thought I’d share some of the knowledge, so that we may all gain a greater appreciation of the work needed to make clocks tick correctly.

This subject is beyond what a single blog post can cover, so instead, I shall turn this into a series. First, we shall cover the background knowledge needed to understand the rest of the series, starting with years and dates:

1. Numbering of years in the Common Era system.
2. Julian and Gregorian calendars.
3. Julian Day Numbers.

I haven’t posted in a while now, but nevertheless, I have been working on this site. Perhaps I have been too bogged down in the minor details, but it was a relatively interesting experience nonetheless.

You may have already noticed some differences:

1. The most obvious change is probably the domain. Instead of using my old quantum2.xyz domain, I switched to the shiny new quantum5.ca.
2. The second most obvious change is the short URL on every post.
3. The last change is invisible: the backend is now distributed in three locations around the world. This is so that even if you are in faraway Australia, you can still load this website instantly, even if it’s not in the Cloudflare cache.

Why did I make these changes? Well, this was because I became thoroughly nerd-sniped by some ideas…

Three years ago, I wrote about a way to purge only changed static files when deploying a static site. It is very useful and I still use it for this website to this day. Its main advantage is that it only needs to be run on deploys. However, its main disadvantage is that it must be run on every deployment. Sometimes, this is not feasible.

For example, I run a bunch of APT repositories on apt.quantum2.xyz. These repositories are constantly being updated by Jenkins and me personally, and using purge-static would require adding a purge-static command to every script that updates the repositories, which is clearly infeasible. Wouldn’t it be nice to just have a background daemon that purged the CDN cache automatically?

As it turns out, I already wrote it back in 2015 before starting this blog. It was massively out-of-date (until very recently) and required you to use your all-powerful Cloudflare API key, providing a massive attack surface. However, I recently updated it, and hopefully, it will prove useful for you.

Here’s a quick introduction to using it:

Recently, I bought a USB 3.0 2.5 Gbps Ethernet dongle for my Atomic Pi router. This dongle requires a version of the r8152 kernel driver with support for the RTL8156 chipset, which is only added in Linux 5.13. Now, I am running the Debian stable kernel and have no wish to backport the latest 5.13 kernel simply for that one driver. So of course, I came up with an approach to backport a driver from a newer version.

In this blog post, I will walk you through the process of backporting a single kernel module, using the r8152 kernel driver as an example.

It’s not often in 2021 that you find yourself building new kernels, but nevertheless, the occasion comes that you need to either enable a flag—or even worse—patch the kernel. This happened recently: on DMOJ, we recently run into a kernel issue that misreports the memory usage for processes as an “optimization.” For more information about this issue, see the excellent blog post by my friend Tudor. As a result of this, I was forced to build a patched kernel to work around this issue. Since the process was far from easy, I decided to write this blog post to help others in the future.

Building a kernel is not too difficult, actually. The real challenge comes in the form of building the kernel in a maintainable way, which basically means that we should at least build the kernel into an easily installable package. For example, on DMOJ, we manage multiple judge virtual machines, and they all need to receive the same kernel. Furthermore, we want our custom build of the kernel to be distinct from the standard kernels that the operating system offers, as we don’t want a system upgrade to undo the patch that we applied.

In this article, we will explore the process I used to build a custom kernel package on Debian for the scenario described above. This will involve both patching the kernel and subsequently changing a configuration option. Specifically, we will be applying this patch. These instructions should work with minor adaptations for other Debian-based distributions.

Around four years ago, I wrote a blog post about creating vanity .onion domains for Tor. To recap, .onion domains are special domains understood by Tor, and when visiting these sites, traffic never leaves the Tor network and is end-to-end encrypted, just as if you were to use HTTPS. Furthermore, the server’s identity is completely protected, if you are into that sort of thing. Also, the domain name is linked to the server’s public key fingerprint, and so knowing the .onion domain is sufficient to authenticate the server and preventing any MITM attacks or certificate authority compromises that could happen with HTTPS.

Recently, I decided that my password generator correcthorse.pw (GitHub) should also have a vanity onion domain, and naturally, I decided to generate some onions.

I am sure that if you managed a Linux system for a while, you probably have dealt with Unix sockets—special files that act like sockets. You probably also run into permission issues when dealing with these socket files.

In this post, I’ll describe some methods of dealing with these permission issues, and a situation in which each might apply.

Update (2022-03-19): I wrote about a new way to create an ARM virtual machine that’s simpler and handles kernel updates properly. I highly suggest you follow those instructions instead, unless you are building a chroot.

I noticed that very few people seem to know how to create a full ARM virtual machine, so I decided to create a quick guide.

This tutorial will use aarch64 and Debian as examples, but the same methodology should work for 32-bit ARM and other distributions. The instructions can also be adapted to create a simple chroot.

Sometimes, you have multiple Internet connections, whether physical or virtual, and you want a few programs to access the Internet through one connection without making it the default gateway. For example, if you want a program to connect to the Internet through a VPN, but without forcing the entire system’s traffic through the VPN as well.

The traditional way to do this is with packet marking with iptables and an ip rule to force marked packets through a different routing table to send the traffic to the correct destination. However, as the source IP was selected before routing, an SNAT rule in iptables is required to change the source IP. This is ugly and clearly a hack.

However, since around 2013, Linux has introduced networking namespaces, which can be managed via ip netns as part of the iproute2 package. We can easily exploit this feature to achieve the desired goal with minimal fuss.