Geek Blight

It’s finally happened. I bought a brand new desktop computer on August 2014, almost 9 years ago. It had an Intel Haswell processor (i5-4690s), 8 GiB of RAM and a GeForce GTX 760. I later doubled the amount of RAM to 16 GiB (precise date unknown), replaced the GPU with a GTX 1070 in November 2016 and upgraded the CPU to an i7-4770K in October 2017. Since then, no more upgrades. It’s been my main personal (non-work) computer for the last few years.

But now I’m typing this from a different box. Yet the physical box and the OS installation is actually the same.

A couple of weeks ago I grabbed an AMD Ryzen 5 7600X that was on sale together with a basic AM5 motherboard and a hard-to-find 2x8 GiB DDR5 6000 MHz CL36 kit. I decided to save some money this time and kept the case, power supply and drives. Surprisingly for me, the process was actually almost plug-and-play. The pessimistic side of me was expecting boot problems due to missing chipset drivers or something like that, but no. I replaced the components in the case for the new ones, plugged my drives in and Fedora booted without issues. The only small detail I needed to fix was firing up nm-connection-editor and replacing the old interface name with the new one in the default DHCP connection. Windows had no issues either, but it did require reactivating the license. The one I had from 9 years ago was retail, so no problems with that.

My choice of a Ryzen 5 7600X was actually simple: these days, compared to Intel, Ryzen has a slight advantage on performance-per-watt even in mid-range CPUs, with Intel now slowly catching up. The equivalent Intel competitor, i5-13400F, while a very good CPU, features a mix of efficiency and performance cores. Its design is more complex than the one from AMD and probably harder to handle in software, maybe more prone to scheduling mistakes by the OS. I run the 7600X in “Eco” mode which, for the record, means setting up the PBO limits to manual mode and using the following values: PPT limit 88000, TDC limit 75000 and EDC limit 150000. These values are documented in several sources. Other motherboards have an easier way to toggle this with a simple switch for Eco mode but, in the one I have, values need to be entered manually. Why did I get a 7600X only to run it in Eco mode instead of grabbing a plain 7600? Because the 7600X was on sale and significantly cheaper (240 vs 270 euros, final price).

A few days later I decided to replace the GPU too. I chose a Radeon RX 6700 (non-XT). Two reasons for the choice: Linux support with open-source drivers (including RADV, which is being worked on by an amazing group of developers hired by Valve and with whom I have the pleasure of interacting frequently while working on CTS) and the stellar price/performance ratio of that particular model. It’s frequently on sale for a bit over 300 euros where I live (I grabbed it for 330).

I’ve said in the past I’m not a fan of any brand, and I still say so. It’s a coincidence, favored by the market situation, that my CPU/GPU combo is now all made by AMD. I’m pretty sure in the future things may change again.

Replacing the GPU required more attention to detail, despite the replacement being conceptually and physically much easier than replacing the other components. On Windows, I ran DDU and removed all GPU drivers, leaving the computer ready for a GPU replacement. On Linux, I followed these steps:

Then I turned the computer off, replaced the GPU, turned it back on and, voilà, plug-and-play on Linux. On Windows I had to download and install the official AMD drivers, and that was it.

All in all, I was surprised by how simple the whole process was, and glad that I didn’t have to reinstall or boot from installation media to fix stuff. There is, however, a stark contrast in terms of what it meant, performance-wise, to upgrade the CPU compared to the GPU. That deserves a rant I will leave for another blog post in the coming days.

I use a Hetzner VPS “cloud” server for hosting this blog and recently discovered a small detail in its pricing that can save you a few euros under some circumstances. I want to clarify this information is not exactly hidden. It’s clearly stated in their billing FAQ but, still, some absent-minded people like myself may not be aware of it until you see the bill.

I’ve blogged in the past about how I liked to run my normal web browser under a different user. In other words, I think web browsers are the weakest link in the security chain of every desktop and workstation computer. Browsers fix security issues with every release and are used to access, download and execute programs and other documents from untrusted sources, in a wide variety of formats. When I run a web browser, sometimes I don’t know what I’m going to be opening. It may be a malicious web page that will try to exploit a vulnerability in the browser I’m using. Using the method I described in the previous link, I could run the browser process as another user, so it cannot easily access my personal files, documents, cryptographic keys, etc. That method relied on running X11 and letting local users, or at least the user running the browser, connect to the server owned by my own user.

There’s a small risk involved in that but, more importantly, since moving to Wayland, the method to allow other users to access your display server is not as straighforward. In general, a solution involving Wayland means the web browser user needs access to some files in the XDG_RUNTIME_DIR directory, including the Wayland socket. I used filesystem ACLs for that and, in my experience, the process is error-prone and unreliable. Sometimes I’ve had to adjust the set of files, or the permissions I needed to grant to those files, and things have broken out of the blue after system upgrades. The second source of risk comes from the fact that, if you want that web browser to be able to play sounds, for example when watching a video, you also needed to give the web browser user access to your sound daemon. I mentioned a method to share your user’s PulseAudio instance with other users and an update on that when I switched from PulseAudio to PipeWire.

Today I wanted to share a simpler approach to all of this, which is running your web browser, typically Firefox, under a very restricted environment using Firejail. Firejail is an open source project, probably available from your package manager, that uses Linux namespaces, seccomp-bpf and capabilities to restrict what your web browser can do and access. Notably, it ships profiles for multiple applications either based on blocklists or, in the case of Firefox (the main use case), allowlists. When you run Firefox through Firejail, for example by running firejail firefox, the resulting Firefox process will be restricted in several ways and will not be able to access most of your home directory, except for the ~/Downloads directory and its own configuration and data directories. If, on top of that, it’s running under Wayland, it will not be able to spy on your screen and other windows unless there’s a second vulnerability available in the Wayland compositor.

The following screenshot shows the file manager and Firefox displaying the contents of the home directory. Firefox is running under Firejail and, as you can see, it does not display the whole directory contents. In fact, it’s not only not displaying every file, but also using custom versions of some of them inside its jail. For example, I don’t have a .bashrc file in my home directory and Firefox is seeing a “fake” one. The src directory you can see from Firefox is also completely restricted in contents and Firefox only sees one file in the whole hierarchy: my .gtkrc-2.0 configuration file because I have it stored in a “dotfiles” repository under src and symlinked to the final location.

Since I discovered Firejail, I’ve switched to using it by default when running Firefox, ditching my ad-hoc mechanisms described in previous posts.

A few years ago I blogged about switching my terminal and programming font from Terminus to Ubuntu Mono. It’s only fair, then, that I mention I’ve switched from Ubuntu Mono to Cascadia Code. I’ve been using Cascadia for many months now, probably over a year, and the experience has been great so far. The font was commissioned by Microsoft and released under the SIL Open Font License, which makes it available in the repositories of many Linux distributions. For example, it’s easily available in the official Fedora or Debian repositories.

When I decided to give it a try I was turned off by some inconsistencies in the shapes of some characters. In particular, the shape of the lowercase F glyph is a bit odd due to the horizontal crossing line being quite low compared to similar features in other characters. In other words, apparently Ubuntu Mono was easier on the eyes due to its simpler and more consistent shapes. However, after using it for months, I can really vouch for it. It can be used for long programming sessions comfortably, the characters are quite distinct from one another, it’s elegant and I haven’t gotten tired of it at all. Summing up its advantages:

Regarding the last point, I mention it because fonts from the Ubuntu family tend to be smaller when compared to other fonts in the system. A 16pt size text containing a 16pt size Ubuntu Mono word will likely look a bit weird, with the Ubuntu Mono word being smaller than the surrounding text. Of course, the Ubuntu font family is internally consistent in this regard: if the surrounding text is also in a Ubuntu font, you won’t have this problem.

Anyway, if you haven’t had the chance, give the font a try. I’m using it now for my IDEs and terminals. Note: if you don’t like the programming ligatures (I don’t), you have several options. The easiest one is using the Cascadia Mono variant, which removes them completely.

As I’ve explained in the past, at the end of each calendar year I always like to make a small round of personal donations to projects and organizations that are important for my personal digital life.

This year I’ve chosen the following organizations or projects: