You Can Leave Your Hat On

A little while ago I wrote about my , and one of the things I mentioned in passing was that I run a Linux desktop container there as a remote development environment.

So far it’s been nothing much, just a set of minimal packages with Window Maker on top, accessible over from anywhere.

But a few days later I tried and quite liked the package selection inside 35, so I decided to give Fedora itself a spin before 22.04 arrives around mid-April.

Then the other shoe dropped – the whole thing coincided with news that the Elementary founders were breaking up. Since I rather like a lot but am wary of getting caught by niche solutions, I now had added motivation to test vanilla GNOME.

Now that a few weeks have gone by, I thought I’d publish my notes for general consumption.

A small caveat: Fedora ships with GNOME 41 (and at the time I had no clue that GNOME 42 was just coming out), but I don’t think it would make much of a difference – although I may revisit this if anything interesting turns up.

Setting Up The Container

To create the Fedora container, I followed pretty much the same steps as outlined in my notes on – just fished out the relevant LXC container image, got a shell going, and installed it once, making notes so I could start over with a reproducible setup.

So this section is the result of my second go at it, and yielded a usable container that I then mapped my Sync folder into. That folder, as the name implies, is synced across several containers by SyncThing running on the KVM/LXD host itself1.

If you want to follow up at home, this dnf invocation should yield a working GNOME environment, plus a few apps I typically use and a few packages I knew I’d need:

sudo dnf install @"Fedora Workstation product core" avahi binutils cabextract docker fira-code-fonts  gnome-shell-extension-dash-to-dock gnome-tweaks htop keepassxc net-tools nss-mdns openscad setroubleshoot rsms-inter-fonts tmux vim xorgxrdp xrdp zsh

# Lighter alternative
# sudo dnf install @GNOME avahi binutils cabextract docker dnf-plugin-config-manager fira-code-fonts firefox gnome-shell-extension-dash-to-dock gnome-software-rpm-ostree gnome-tweaks htop keepassxc keychain net-tools nss-mdns openscad setroubleshoot rsms-inter-fonts tmux vim xorg-x11-font-utils xorgxrdp xrdp zsh

sudo timedatectl set-timezone Europe/Lisbon

Creature Comforts

It’s been a long time since I’ve used vanilla GNOME, and the good news if (like me) you prefer a macOS-like experience, is that you can tweak it fairly easily into something that won’t be jarring (although you’ll have to make some allowances):

GNOME 41, themed to cater to my whims

Besides the custom theme and window widget locations (set via gnome-tweaks), eagle-eyed viewers will notice the macOS-like dock (gnome-shell-extension-dash-to-dock) and the use of Inter and Fira Code fonts.

Although this requires more manual setup than and is likely to be broken by GNOME 42, most of the required packages ship with the system and I still know my way around it, so… OK, it’s almost admissible as a baseline since I didn’t tweak anything else (for instance, I didn’t bother with themes for Qt apps and other minor eyesores that are typical in a Linux desktop).


Once window decorations stopped being a distraction, I turned to text.

I spent a long time doing print work during college, so I need to have readable text and don’t like the (serviceable, but very distracting) font substitutions that come with surfing the web on Linux.

Unlike (which has an installer package for the MS Core Fonts), I had to manually install an RPM from SourceForge2:

sudo rpm -i

…and later dropped a set of Segoe UI fonts in, for good measure.

But (and this is the good news, I suppose) I felt zero need to tweak font rendering, as was wont of Linux desktops of ages past.

Everything was excellently rendered regardless of whether I used RDP (with or without retina resolutions) on my desktop or laptop displays, including a crummy 1366x768 panel. And you get fractional font scaling (via gnome-tweaks), so a lot of my usual gripes with Linux desktops seem to be gone.

Remote Audio

One of the things I like to have is audio via RDP, if only for desktop alerts and the occasional click-through to a video.

Fedora uses pipewire as its audio system, and even though it ships a shim called pipewire-pulseaudio, I couldn’t get it to work with the RDP pulseaudio modules, so I simply removed pipewire and installed pulseaudio in my container.

General Experience

Once most of the above was sorted out, I used the container for nearly two weeks as an anti-procrastination mechanism: I shoved Slack, Twitter, HN and all my doom-scrolling into .

As expected, this pretty much ensured I’d have a session to it running for hours every day.

Besides my personal project tooling (which essentially means VS Code and right now) I also installed , and a few more things for the sheer tinkering pleasure of it.

I connected to it from my Mac, my Windows machines, my iPad and my Linux desktop, and except when running up against minor graphics performance or audio issues from RDP I pretty much forgot about where thing were running and just used them, which is great.

More to the point, neither GNOME nor really got in the way (but keep in mind I’m not a UX zealot–I just appreciate consistency and polish).


I’ve found the baseline GNOME apps to be OK in a pinch, but nothing to write home about. I did try a couple of things I’m likely to use if I ever need to spend a significant amount of time in Linux, and most of my impressions were positive:

  • Geary, the e-mail client I’ve been playing with on and off every time I try a Linux desktop, now seems to have less rough edges (but I haven’t really used it, just verified it can now read some of my e-mail).
  • The default text editor is very serviceable (I typed a good deal of this draft in it before tidying up in VS Code).
  • The built-in Connections RDP client is… OK in a pinch, but somewhat buggy.
  • GNOME Maps, for some unfathomable reason, does not zoom with a mouse wheel on one of my machines, and Night Mode doesn’t work on any of them.
  • The “native” app ecosystem seems to be active enough. For instance, I found a cute, simple KeePass-compatible password manager.


So far, GNOME has been… OK… but… sometimes I just ask myself why it’s so obtuse.

For instance, I don’t really get why hitting the Command (or Super) key to invoke the application launcher causes the entire screen to animate and show me active workspaces, windows, and everything else before I even type a single letter to, say, launch a terminal.

After the initial shock it sort of works for me, but I find it completely non-intuitive and a trifle sluggish over RDP on large displays (especially when I have it blown up to 5K).

To be honest, I’d have preferred a plain and simple Spotlight-like overlay for a launcher, or even (gasp) an application menu by default (there’s an extension that will give you one, but I punted).

But since I don’t rely on a lot of desktop environment functionality and (other than window decorations and icons) I haven’t tweaked anything of substance, the only thing that really annoyed me for the whole two weeks is a relatively minor corner case:

Timezones are Hard

It turns out that if you subscribe to an ICS calendar with timezone info, the Calendar app completely messes up your appointments and alerts – but, ironically, the overview panel you get when you click on the clock seems fine, lulling you into a false sense of security.

This drove me completely nuts since I have a pretty hectic schedule and need to overlay personal, work and project calendars, and it would have been nice to have consistent alerts when I’m immersed in a remote desktop.

Container-Specific Fixes

Also, my rather peculiar environment posed a few challenges, some of which are -related and due to their packaging choices.

For instance, to get the GNOME Software Updater to work inside LXD, I had to trick fwupd to work inside a container, because for some reason gnome-software simply refuses to work even when you don’t have fwupd installed (there is a bug somewhere filed for it).

The fix is pretty simple, though – just let it run even if it’s not doing anything:

sudo vi /usr/lib/systemd/system/fwupd.service
# comment this line

Going Bare Metal

Nearly two weeks in, things were working well enough that I felt encouraged to give another spin, but on actual hardware–in fact, the very same that I installed on , and that I mostly use as a thin client these days.

So I flashed it to a USB drive, slotted it in and went through the installer using the defaults (which I really shouldn’t have, as we’ll see when it comes to swap space…).

Setting up eCryptFS

One of the first issues I tackled was encrypting my home directory–even though most Linux installers can set up full-disk encryption out of the box, I very seldom use it because the user experience is awful (especially if you need to share the machine with someone) and most of my Linux laptops (at least until my ) were essentially low-resource throwaways where full-disk encryption does make the system appreciably slower.

So I spent a few hours poring over exactly why the tried and true setup I’ve been using with every single and variant failed to work on –and as it turns out, SELinux was to blame–or, rather, the ecryptfs packages do not do the kind of extra housekeeping ones do.

To set it up properly, I set up a secondary administrative account and resorted to setroubleshoot:

# this will log suggested policies
sudo dnf install setroubleshoot
# try to login, then check the logs and see what needs to be applied
sudo journalctl -b0

…and after a few iterations, things started working.

Fixing zram Swap

has made the rather amusing decision of using zram for swap, apparently on the grounds that it’s been working out fine for Fedora embedded and is much faster than actual I/O.

However, it is a spectacularly bad idea to try to use it on a desktop system with 2GB of RAM like this , and things would just blow up when I loaded , VS Code and anything else–often taking out the entire shell.

Some standalone apps just wouldn’t run at all. For instance, I regularly loaded up on this machine running (just for twiddling, not for any serious music editing), and under this setup it would just crash (both flatpak and re-packaged RPM versions).

Since the default partitioning scheme ate up all my disk with a single btrfs volume (see, that’s why you should never trust Linux installer defaults…), easy LVM resizing wasn’t on the cards. I ended up adding a standard swapfile instead:

sudo btrfs subvolume create /var/swap
sudo chattr +C /var/swap
sudo fallocate -l 4G /var/swap/swapfile
sudo chmod 0600 /var/swap/swapfile
sudo mkswap /var/swap/swapfile
# brief vi session to add it to /etc/fstab
cat /etc/fstab | grep swap
/var/swap/swapfile swap swap defaults,sw,nofail 0 0
sudo dnf remove zram-generator-defaults

This “works” in the sense that I can now run more than one app in those 2GB, but I still get some stutters and “stuck keys” while editing code (which I didn’t under ).


My containerized workspace doesn’t need to run SyncThing, but I had to install it on the Acer. Fortunately, there is a nice GNOME shell extension to manage it, with the caveat that the extension doesn’t autostart it itself.


After a few weeks of using Fedora and GNOME this way–reading news and Slack inside Firefox, making notes on xMind and working on various personal projects with VS Code and , I think it’s likely that I’ll stick to GNOME as my “default” Linux desktop environment from now on, even if I did have to customize it a bit more than I would otherwise do with .

As an aside, I cannot abide ‘s Unity and was never able to get the Elementary/Pantheon desktop running inside an RDP server to my satisfaction, so having GNOME work perfectly via RDP was just icing on the cake.

The only downsides for me are the UX and packaging quirks from both GNOME and Fedora, but as a learning experience, this was OK. A lot of the skills I acquired tussling with Red Hat systems in the deep past came in handy, but fixing some of these things was a good reminder of why I’ve stuck to all these years.

I will likely be rebuilding both my desktop container and going back to 22.04 eventually, but maybe not just yet… If only because it will be safer to wait for 22.04.1, as usual, and I might actually rebuild my KVM host in the meantime.

  1. Getting that going requires remapping UIDs and other boringly mundane stuff that I won’t get into here. ↩︎

  2. I suspect something equivalent might be available from RPM Fusion, but not having it built in is annoying. ↩︎

This page is referenced in: