Last time, we discussed how we might create a Windows virtual machine as part of a series on running a Windows VM with native-level graphics performance via GPU passthrough and integrating it seamlessly into your Linux desktop via Looking Glass. Today, we shall turn that normal Windows virtual machine into something far more interesting by giving it a real GPU.
As far as Windows is concerned, the GPU is real hardware and can be treated as normal, so we will not go into too much depth. Most of the work lies on the Linux side, where we must do some work to make sure the GPU is free for the VM to use, and then instruct the hypervisor to use it. Again, we will be using the standard QEMU/KVM setup, managing our virtual machines with
Naturally, the same procedure here can be used for any other PCIe device, such as NVMe SSDs. Let’s begin!
Last time, we introduced a series on running a Windows VM with native-level graphics performance via GPU passthrough and integrating it seamlessly into your Linux desktop via Looking Glass. We start this journey by creating a basic Windows virtual machine, which will form the foundation of all future work.
For this example, I decided to use Windows 11 for fun, since I did it quite a few times with Windows 10 already. However, given that Windows 11 is basically a renamed Windows 10 with some additional hardware requirements, there is not much of a difference anyway.
On the Linux side, we will be using the standard QEMU/KVM setup, managing our virtual machines with
libvirt. Let’s begin!
As you may know, I contributed quite a bit to the Looking Glass project — an ultra-low-latency viewer for virtual machines with GPU passthrough. To those who understand the use case, this is amazing technology; but to most people, these words hold little meaning. I had plenty of difficulty explaining what this is all about, so I thought I’d write about it.
What is GPU passthrough? It is essentially giving a dedicated GPU to a virtual machine, just as if you plugged it into a PCIe slot if it were a real machine. This is commonly called “VFIO” (Virtual Function I/O). Originally, this is intended for server applications, for example, giving a network card to a virtual machine. These days, however, it’s also commonly used by Linux users to run a Windows virtual machine to play games at native speeds without dual-booting — just as if you had a separate Windows computer.
Annoyingly, this requires you to plug a monitor into the Windows GPU to get a display output, requiring you to either have a new monitor, switch inputs, or buy a KVM switch. Looking Glass is meant to address this problem — by capturing the output of the Windows display and presenting it to you in a window that is integrated into your favourite Linux desktop environment. This eliminates all annoyances with monitors — simply move your mouse into the window to start using Windows, and move it out to use Linux.
In this series, I will slowly walk you through the process of creating such a virtual machine and installing Looking Glass, explaining the technical details along the way. Expect updates over the next little while:
Over a year ago, I wrote about making ARM virtual machines. Times have changed a lot since then — the release of Apple M1 has dramatically changed the perception of ARM. No longer is ARM a niche platform for low-power gadgets like phones or tablets, but a viable desktop computing platform. Similarly, in the server space, Amazon Graviton and Ampere Altra have gained traction. My old blog post presented only a quick hack to get the ARM virtual machine to boot — by copying the kernel image. This leaves a lot to be desired. Somehow, despite this, it quickly became one of the popular posts on my blog. Today, we shall rectify that flaw and present a way to boot the latest kernel installed in the virtual machine using the Unified Extensible Firmware Interface (UEFI).
Again, like before, this tutorial will use Debian as an example, but the same methodology should work for other distributions. If you are looking for a simple chroot, you should instead follow the original post.
Finally, we have all the background knowledge required to understand how we might calculate the French Republican Calendar. This is a calendar that was created and saw widespread use during the French Revolution for around 12 years from 1793 to 1805, when Napoleon abolished it in favour of the Gregorian calendar. These days, it is mainly of interest historically, as we might see in names of events like the Coup of 18 Brumaire.
The idea of the calendar is simple: every year is divided into 12 months of 30 days each, named Vendémiaire, Brumaire, Frimaire, Nivôse, Pluviôse, Ventôse, Germinal, Floréal, Prairial, Messidor, Thermidor, Fructidor. Since a solar year is around 365¼ days, it adds 5 complementary days, and one more in leap years: la Fête de la Vertu, la Fête du Génie, la Fête du Travail, la Fête de l’Opinion, la Fête des Récompenses, and la Fête de la Révolution (leap years only). The first year started on September 22, 1792, the founding of the French Republic, which also happens to be the autumnal equinox.
The part about the calendar that I found intriguing was the way it handled leap years — every year started on the date of the autumnal equinox at the Paris Observatory, no matter what. As such, a year is a leap year if the next autumnal equinox happens 366 days later instead of the normal 365, and the calendar will never drift against the seasons — at least if we followed the calendar as originally specified. Unfortunately, perhaps due to laziness, all the versions of the calendar I could find online used alternative leap year schemes that reduced the calendar into a mere variant of the Gregorian calendar, complete with its ability to drift out of sync with the seasons.
The most popular scheme for leap years these days is the so-called Romme method, which follows the same leap year rules as the Gregorian calendar, except applied to the years of the French Republic. I find it distasteful, mostly because it made years 4, 8, and 12 leap years when historically, years 3, 7, and 11 were leap years instead, thus altering history on top of eliminating one of the intriguing features of the calendar.
For this reason, I constructed my own version based completely on equinoxes, and I will be explaining exactly how to calculate the dates so that no one has to keep making Romme versions out of ignorance.
Last time, we introduced an equinox as “the point [in the sky] where the celestial equator intersects with the ecliptic.” This is perhaps an unfamiliar definition, as an equinox is more commonly defined as the time when the centre of the sun is directly above the equator. So, what does our point definition really mean?
To understand this, we must start by understanding how the various coordinate systems for points in the sky work in astronomy. Eventually, this will help us calculate the exact time of the equinox, from which we will finally be able to calculate the French Republican Calendar.
In this post, we shall cover the following concepts:
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:
- Uniform Time.
- Solar Time.
- Universal Time.
- 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:
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:
- The most obvious change is probably the domain. Instead of
using my old
quantum2.xyzdomain, I switched to the shiny new
- The second most obvious change is the short URL on every post.
- 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…
- The most obvious change is probably the domain. Instead of using my old
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-staticwould require adding a
purge-staticcommand 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: