Let me tell you a little about myself first, in case you’re new here: I’m a software engineer and I’ve been using Linux as my primary operating system since 2009. That’s 17 years ago at the time of writing this, back when Steam on Linux didn’t exist, not to mention Proton. The opinions expressed in this article are the result of my experience, of trial and error and hands-on experience on what works and what doesn’t.

My recommendation

Alright, onto the fun part. It really boils down to these two:

1. Universal Blue based distros (Aurora, Bazzite and Bluefin)
2. Arch Linux and its direct derivatives (more on this later)

That’s it. These are the only two options that make sense for most people.

“But what about…”

There is one caveat: if you’re using a more advanced distro like NixOS or Gentoo, or a special-purpose distro such as one for pen-testing or one for supporting a specific set of hardware, then you already know what you need from your system, and your choice is likely dictated by experience and deliberate reasoning, and this article is not for you. If you’re happy with your choice, you don’t need to change it.

Before moving on to why I chose these two families of distros in particular, I want to explain why I don’t recommend distros like Ubuntu, Linux Mint, Debian, Pop!_OS or Fedora.

Versioned releases and broken upgrades

One of the most overlooked aspects of running Linux for a long time is dealing with updates, and in particular how updates work in what I like to call the legacy versioned release model.

Excluding immutable, image based distros, once installed an operating system is a state machine that moves from state to state with every action the user takes, such as installing and uninstalling applications, changing configuration files and adding third party repositories. By nature of the immeasurable amount of things you can do to an operating system, it’s impossible to know and account for all the possible combinations of states that could exist out there.

This becomes potentially catastrophic during a version upgrade: by making the big changes required for a full system upgrade, including kernel, drivers, libraries and applications all at once, you are inevitably asking for trouble.

When the operating system cannot control its own state, big changes like these should be avoided, in favor of gradual ones, introduced bit by bit as they come.

It’s quite hard to nail down exactly all the things that can go wrong during a version upgrade, and if it wasn’t, there wouldn’t be a problem. Let’s just describe a few:

• Any third party repository you might have added (ie: PPAs for Ubuntu, Copr repos and RPM Fusion for Fedora) might not work on the new version
• A fundamental structural change in the new version (ie: what filesystem or bootloader to use) requires making assumptions on the state of the system that are often not correct
• A new version of the kernel or a low-level system package might introduce a regression that makes some of your hardware inoperable
• User-created system configurations might get overwritten

This is a huge problem, because when doing a version upgrade you’re essentially rolling the dice on whether or not it is going to succeed, or fail and leave you with a broken system and a weekend of troubleshooting ahead of you.

And trust me, I’ve seen it happen countless times, to my systems and to other people’s. It’s not fun and it’s not something that can be allowed to happen.

This is the main reason why I cannot recommend distributions that follow a versioned release model, because even if they work great, sooner or later they’re going to break and you’re going to be mad about it.

Option 1: Universal Blue – aka Aurora, Bazzite and Bluefin

Universal Blue is the easiest Linux distribution for almost everyone. Let me explain why.

You see, this problem with system upgrades, and the operating system getting messier as time goes by, doesn’t exist only on the desktop, but in the server and enterprise world as well.

However here’s the fun part: in the server world we solved it! How? Well, in the silliest and most obvious way possible of course: every time you so much as want to touch the system, you throw the entire thing away and rebuild it completely from scratch!

It makes sense: how many times have you been plagued by absurd errors or bugs on your computer? Those you could only solve by nuking the entire system and reinstalling it from scratch?

This sounds idiotic at best, but it does work, and we’ve found very convenient ways of automating this process. In the server space we have declarative infrastructure and containers, and they’re basically the industry standard at this point.

The clever people of the Universal Blue project have essentially done the same thing: they ship their operating systems as immutable glorified container images, and every time you update your system it’s just reinstalled from scratch, while your home folder and your configurations are kept intact.

It’s not even unheard of in the consumer space: both Android and iOS use a similar approach, where your system partition is locked down and immutable, and OS updates are provided as a full system image that replaces the one you’re currently running. It’s a tried and true method, and while it might admittedly still be novel in the desktop computing space, there’s little reason why it shouldn’t work out just fine.

While this is a good way of doing things, it does come with one caveat by definition: your system is immutable.

This means that you are limited in how you can install software. The Bazzite documentation has a very well put together list that should apply to all distros in the Universal Blue family, but I also want to give you my recommended methods, in order of preference:

• Flatpak (mostly via Flathub)
  • Most apps work great, some like Steam and code editors don’t
  • More on this in the Installing apps section of this article
• AppImage
  • Annoying to update apps
  • The ecosystem around the format can be problematic for developers
• In a container via Distrobox
  • Really cool and extremely versatile, but not very easy for a beginner
• Via Homebrew
  • Good idea, I don’t really like the implementation all that much on a technical level and it’s primarily made for macOS, but it does work

Additionally, if you need to make any changes at the system level, like adding kernel command line arguments, installing out-of-tree drivers or system-wide background services, you’re going to be straight out of luck, unless Universal Blue (or the particular flavor you choose) decides to support it.

But most people don’t need to do any of that.

What most people need is something that just works, gets out of your way and lets you use your goddamn computer.

And for that use case, Aurora, Bazzite and Bluefin are the best options.

But what if your use case is a bit different? What if you do need to mess around with your system, even if just a little? Maybe you need particular drivers for a special piece of hardware?

If that’s the case and you’re willing to take up a little more responsibility in exchange for full control over the system, that’s where my second option comes in.

Option 2: Arch Linux

Arch can be a fun and fairly predictable distro, but only if you know exactly what you’re doing.

Vanilla Arch is fundamentally a DIY distro: you’ll be expected to read documentation, prepare for updates and do regular system maintenance. If you choose Arch, you’ll essentially be building your own distro.

And this is an incredible prospect for people like me that enjoy this side of using computers, but it’s absolutely not a good choice for new users.

Fortunately, there are a number of very good Arch derivatives that solve exactly this problem. We’ll get to them in a moment; first let’s see what makes Arch a “good” distro.

In Arch, versioning is thrown completely out the window. Arch is a rolling-release distribution. This means that there are no versions of Arch, just one: the current one.

Packages are released into the stable repositories as soon as they are available, but not without some rigorous testing by the maintainers.

To be fair, sometimes some bugs do slip through the cracks, but so do they on versioned distros. The big difference here is that with updates being small, frequent and incremental, what can break is measured not by entire system versions but by individual packages that are easily downgraded.

For example: a while ago a regression was introduced in mesa (open source 3D graphics library, the built-in user-space driver that’s used by AMD and Intel GPUs) that created problems with running VR. I’ve been hit by this problem, and the solution was just to downgrade mesa to the last-known-good version, until the new release with the fix came around.

If I’d happened to encounter a similar bug on a versioned distro during a major version upgrade, I would have had to downgrade the entire system, and that’s not an easy task.

Also, it was just one package that was broken, hindering one (unimportant I might add) functionality in my otherwise perfectly working system.

It’s a good idea, in case you end up using Arch or an Arch based distro, to keep an eye on the Arch Linux official news section, particularly before running updates. Any (rare) issues that you might find during regular updates that might require particular attention or manual intervention are meticulously reported here, with simple instructions on how to proceed depending on the particular situation you might find yourself in.

Another advantage of Arch over Universal Blue is wider software availability:

• First of all, you can use all of the aforementioned installation options (Flatpak, AppImage, Distrobox and Homebrew) on Arch without any problems (and in fact you might be doing so if you have a Steam Deck running SteamOS, since it’s just immutable Arch).
• Second, you can use regular packages from the system repositories, which offer quite the ample variety.
• Third, you can resort to the Arch User Repository or AUR for short.

An important note on using the AUR tho, quoting directly from the Wiki:

AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.

In other words:

1. Use the AUR only as a last ditch option, if and only if all the other options fail
2. Make sure the package you’re interested in comes from a trusted user, or has been submitted or approved by the developer of the program you’re trying to install
3. If you don’t know what you’re doing, please ask the community for help

Let’s have a look at some distros that are based on Arch, and offer an easier and friendlier out-of-the-box experience.

CachyOS

CachyOS is a lot of fun. It’s very close to base Arch, with the following differences:

• It uses its own repositories that follow closely the upstream Arch release schedule, offering packages that are specifically optimized for your particular CPU architecture
  • In other words: it provides a small but measurable performance edge by making use of most if not all of the advanced features that are built into your CPU
  • It also uses a slightly tweaked kernel, more suited for real-time applications (aka desktop/gaming usage as opposed to server usage)
• The installation process is very simple and straightforward thanks to the graphical installer, while providing a lot of customization options
• Some of the extra packages it provides are quite useful, like for example gamescope-git for beating some misbehaving games into shape (see this post for an example) and gamescope-session-cachyos, which allows you to log straight into Steam Big Picture instead of your regular desktop, which is quite convenient for a TV setup.

Overall you should choose CachyOS if you want to squeeze every last drop of performance out of a recent PC (Intel Haswell or AMD Excavator or newer).

The “flavor of the week” allegations

CachyOS is getting quite a lot of media coverage, and has been described as “flavor of the week”.

I assume this is meant to imply that its popularity is a temporary trend, and that it will “fall of out fashion” at some point.

But CachyOS is at its core just Arch. Arch has been around forever and is not going anywhere any time soon.

CachyOS on the other hand is fairly new, we don’t know if it’s going to disappear tomorrow. I don’t think it will, but it doesn’t matter, because if that happens all you need to do is switch from the CachyOS system repositories to the Arch Linux ones. Your system will keep on working and you can go about your day as if nothing happened. I’m sure that if that happened, there would be much more detailed instructions on how to do this exactly, but it simply boils down to this.

To some extent I can attest to the fact that there isn’t much more to it than this. In fact, I’ve done the opposite: I’ve configured my Arch system to use the CachyOS repositories, and it was a simple and straightforward process, fully sanctioned and accounted for by the CachyOS project and further simplified by the excellent entry in the their Wiki.

EndeavourOS

EndeavourOS is very similar to CachyOS in principle, but more conservative. It uses the same exact repositories as Arch, with I believe an additional one for branding and other small tools.

This means you won’t get the performance benefits of CachyOS, but otherwise the experience will be pretty much exactly the same: a preconfigured, polished and ready to go Arch distro.

The installer is the same CachyOS uses, so there should be no big difference on that front either, and EndeavourOS also offers a similar number of customization options during the initial setup.

EndeavourOS is great if you want something simple, that stays very close to traditional Arch Linux, or if your hardware is not new enough to make use of the optimizations CachyOS provides (older than Intel Haswell or AMD Excavator).

A note on why NOT Manjaro

Given its history I can not recommend Manjaro.

From a technical standpoint, they have a history of causing problems by shipping unstable or unreleased packages, or holding off some updates for too long, breaking packages installed from the AUR, among other things.

With all the options I already mentioned, and setting aside any technical mishaps here and there, I cannot see Manjaro as an interesting or compelling option for any use case. I have no personal issue with the Manjaro project in particular, nor the people that run it. This is a technical preference and since this article is about my opinions on things anyway, I think it’s worth mentioning.

Some tips on daily usage

In this section I want to cover some suggestions, regardless of which distribution you choose, for a smooth Linux experience.

Make sure you use Wayland

In Linux there are two main display protocols. You don’t need to know what a display protocol is, but it’s a good idea to get a general understanding anyway.

• X11 (sometimes called Xorg, after its most popular implementation) is the legacy display protocol that’s been in use on UNIX systems since the ’80s and on Linux systems up until today
  • Old and clunky
  • Insecure by design, allows any application to behave like a keylogger or grab the content of the screen with no restrictions
  • New display features such as Variable Refresh Rate (VRR), HDR and display scaling are unsupported or barely supported with caveats
  • Can suffer from tearing if not configured properly
  • Most desktop environments are dropping support for it
  • Frustratingly, technically more widely supported since it’s been around forever
• Wayland is the new display protocol, developed by the same people that used to develop Xorg
  • Wide adoption is only fairly recent (as of the last couple years or so)
  • Feature availability depends on the specific desktop environment
  • Secure by design, disallowing keylogger behavior (but this causes some annoyances, like applications being unable to set their own global key bindings) and unrestricted screen recording
  • Good support for VRR, HDR and display scaling
  • No tearing by default
    • It seems like some people want tearing. I think it’s something to do with lower input latency. Anyway you can enable it on some desktops like KDE Plasma if desired
  • New display features will get support on Wayland first

To summarize, Wayland is the current recommended option for the vast majority of use cases, since it supports all modern features. Most desktop environments and application toolkits are slowly dropping support for X11 in favor of Wayland, so if nothing else it’s a good idea to use it to future proof your system.

The choice of your display server is tightly bound to the choice of desktop environment you make.

Desktop Environment choice

My recommendation of desktop environments for new users boils down to these two options:

• KDE Plasma
• GNOME

KDE Plasma is a stable desktop that offers many advanced features in a fairly easy to use package. Its default layout is also very familiar if you’re coming from Windows, but can easily be adapted for whatever workflow you prefer.

On the other hand, if you’re looking for a little paradigm shift in how you use your computer, you might be interested in GNOME. At first glance it looks a bit more similar to macOS, but don’t let that fool you, because it’s a very different way to interact with your desktop and applications. It lacks some more advanced customization options that KDE Plasma offers and overall it’s less adaptable.

Ultimately, each desktop has its pros and cons, but at the end of the day they are very comparable feature-wise, and your choice will depend on your personal preference. My own choice here is GNOME, but if you’re unsure, I recommend KDE Plasma as an option that is more suited for general usage (and so does Valve, since that’s the desktop that ships with SteamOS).

I made this table of some of the desktop environments that are out there, with a small description and the reasons behind my recommendation.

Installing apps

I strongly suggest you install most applications (except Steam) from Flathub. Depending on the distribution you choose, you’ll find one of these “App Store” like frontends for installing apps from Flathub:

Discover	Bazaar	GNOME Software

Flatpak is a universal packaging format, meaning you can install Flatpak apps on virtually any Linux distro.

It also runs applications inside of a sandboxed environment, which provides some security benefits (random applications usually aren’t able to invasively access your system) but also some headaches since you might want some applications to be able to break out of the sandbox.

Fortunately it’s very easy to manage the permissions of your Flatpak apps using Flatseal.

Random commands from the internet

It’s very common, particularly when searching how to fix various miscellaneous problems or installing obscure pieces of software, to find random commands in forum threads or blog posts.

Most people just blindly copy & paste them in their terminal, without so much as reading them. Please, do not do this.

Do not run random terminal commands you don’t understand, for a variety of reasons:

• If you don’t understand what they do, you effectively have no idea if they apply to your distribution, or to your particular problem
  • Even if you read that a certain command is specifically written for your distribution, and while technically it might be the case, there’s a high likelyhood that it’s old and not up to date and therefore useless at best and actively harmful at worst
• It might be malicious, you might install malware without even realizing it
• Even if not malicious, you could break your system beyond repair, forcing you to reinstall (this is less likely on immutable distros, like the ones based on Universal Blue)
• In the remote chance that it actually works, you don’t know why it worked

This is a very, very bad habit of the Linux community and something we need to get rid of. The reason we do it is trivial really: it’s easier to say “copy this and paste it in your terminal” than to explain your way through a graphical program, or to explain what the command does.

It gets even worse when these commands start using fancy UNIX tooling like sed, grep, awk and tee. What you get on the other end is some fabulous UNIX Magic soup. Truly delicious if you understand it, but to a novice it’s just a mess of magical incantations. Besides, someone who is not a programmer shouldn’t necessarily have to know the intricacies of the shell to enjoy using Linux properly.

And this concludes the article, it’s long and verbose but my hope is that it gives you all the information you might need to get started on your Linux adventure without surprises.

All of these opinions are my own, and I’m sure someone will disagree with me, but that’s fine.

This is the culmination of a lifetime of using Linux on the desktop and beyond, and the result of all the lessons that I’ve learned along the way.

In particular this relates to my recently acquired MSI MAG X870E TOMAHAWK WIFI motherboard, but as I understand this same problem also happens on other MSI and ASUS motherboards.

More specifically, this is an issue with the Nuvoton NCT6687-R fan control chipset and its various implementations.

The solution to allow for software fan control is decently easy, but has a few steps. It consists in installing this out of tree driver, ensuring it’s correctly loaded with the appropriate options and tweaking some settings in the UEFI/BIOS.

1. Installing the driver

If you have access to the AUR, simply install nct6687d-dkms-git. Otherwise, follow the official guide on the driver’s README.

2. Ensuring the driver loads

Create a .conf file inside /etc/modules-load.d/. I called mine gabmus-msi-fan-control.conf. Add the following string inside it: nct6687.

3. Configure lm_sensors

Run sudo sensors-detect and follow the interactive wizard to discover the hardware you have available.

Once it’s done pay attention: it will give you a summary and ask you to (over)write /etc/conf.d/lm_sensors. You can allow it to do so, but you also need to check what driver it will try to use. Chances are it will default to nct6683, which is the in-tree driver that doesn’t support manual control.

If that’s the case, once it has written the file (/etc/conf.d/lm_sensors), go edit it yourself. You will need to replace nct6683 inside the HWMON_MODULES variable with nct6687.

4. UEFI/BIOS tweaks

Inside your UEFI, in the fan control section, you should ensure all of the detected fans have Fan Type Auto Detect enabled and Smart Fan Mode disabled. Note that disabling Smart Fan Mode will lock your fans on a static speed. I recommend setting the speed to 100% to ensure that your PC stays cool before booting into Linux and having the fans controlled by your favorite fan control system.

My source for this particular section is this issue on the driver’s repo.

5. Check the speed and possibly add a parameter to the driver

Open up your fan control application. For reference I use and currently recommend CoolerControl.

Check if your fans show an RPM reading. If they do congrats, you’re done.

If they don’t, you might need to use an alternative configuration for the driver as described below.

Create a new .conf file in /etc/modprobe.d/, I called mine gabmus-msi-fan-control.conf. In it, write the following: options nct6687 fan_config=msi_alt1. This instructs the driver to use an alternative fan control mechanism that should be specific to some MSI motherboards.

Reboot and check the RPM readings again. If they show up then you’re all set, otherwise your particular hardware might not be supported yet. In this case it might be a good idea to open an issue on the driver’s repo.

Another disclaimer: I’m not a security expert and I don’t claim to be. This is just a solution that I’m using, if following anything that I write causes any problems including but not limited to data loss or theft, I don’t take any responsibility. You’re on your own.

I find myself in this very particular situation: I have a server running Arch in which I want to have full disk encryption, but being a server I want to be able to reboot it without having to insert the password manually.

A solution to this problem is using TPM to store a decryption key. This works but it’s not ideal if someone unauthorized takes possession of the server, since they will have access to the unencrypted disk by just turning the computer on.

Another solution is to store a decryption key on a regular USB stick, and in case you hear weird noises in the night or suspect someone might be out to take your server from you, you just remove the USB stick and either hide it or destroy it.

But let’s get some things out of the way first.

Are you running Arch on a server?!?!

Yes, get over it.

Is this secure?

As for any time you ask this question, the answer is it depends on your threat model. In general, no this isn’t very secure, but it’s good enough for what I need and better than any alternatives I found. If you think you know a better way to achieve a similar result, please do let me know.

What you’ll need

• Arch install with full disk encryption
• USB drive
• Shell access

Steps

1. Boot up your system using password unlock (hopefully for the last time)
2. Insert a USB drive that you’re willing to sacrifice
3. Format it as a single FAT32 partition on top of a MBR partition table
4. Mount it to a location of your choosing, I’ll use /mnt
5. Setup a key file as follows (Source)
   • Create a new random key in the USB drive, named anything you want, I’ll call it key.lek: dd if=/dev/urandom of=/mnt/key.lek bs=4096 count=1
   • Identify your encrypted volume: blkid --match-token TYPE=crypto_LUKS -o device
     • You should end up with a device path, for example /dev/sdx2. I will use this in the following command so make sure to replace it on your end
   • Add this new random key as a valid key to decrypt your disk: cryptsetup luksAddKey /dev/sdx2 /mnt/key.lek
     • You will be asked for one of the passphrases already set up for your encrypted volume, provide it to continue
6. Modify your /etc/mkinitcpio.conf to include the vfat module, so that the USB drive will be readable by the initramfs (Source)
   • For clarity, the MODULES row in your mkinitcpio.conf file will look something like this: MODULES=(vfat)
   • In case you already have other modules, don’t remove them of course, just add this one
7. Regenerate your initramfs with mkinitcpio -P
8. Modify your kernel command line arguments to instruct it on how to decrypt using the USB drive (Source)
   • Take note of the UUID of the USB drive partition in which you stored the key with lsblk -f. Since it’s a FAT32 it should be quite short compared to other partition UUIDs.
   • Add this at the beginning of your kernel options: cryptkey=UUID=YOUR-USB-DISK-PARTITION-UUID-HERE:vfat:/key.lek

That should be it, reboot and your disk should decrypt automatically. Enjoy!

gamescope --mangoapp -w 2560 -h 1440 -W 2560 -H 1440 --fullscreen --force-grab-cursor --adaptive-sync --backend=wayland -- env ENABLE_LAYER_MESA_ANTI_LAG=1 %command%

Put this in your Steam game launch options, adjusting the resolution and you should be good to go.

Just a couple more things:

1. Don’t use the “stable” version of gamescope, use gamescope-git instead
   • This is easiest on CachyOS since it’s already packaged in the main repos, medium-easy on Arch since you can just use the AUR version, and “good luck, you’re on your own” everywhere else
2. After installing gamescope, and every time you update it, run sudo setcap 'CAP_SYS_NICE=eip' $(which gamescope)
   • Source
3. Ensure you have variable refresh rate turned on on your monitor and DE/compositor

Now, if you’re still here you likely want to know what’s going on, and what the magical incantation above is doing.

What’s going on

So, for a while now some games have had issues with losing focus on Linux. In particular this is happening to me on GNOME (Wayland, considering X11 support has been dropped) with a monitor arrangement consisting of two 1440p monitors, horizontally arranged, with the primary one being to the right of the secondary one.

Note that similar issues seem to have been observed on Plasma, as well as various WM-like compositors, so it’s possible that it’s not a problem with GNOME itself.

The issue is sneaky, and it only seems to happen when rapidly moving the mouse, followed by clicking. You know, how one normally plays shooter games. By losing focus, I consistently lose in any direct confrontation, and consistently lose my patience.

I don’t know exactly when this started happening, nor why it’s happening, but it’s annoying and I’ve been trying to fix this on and off for a while.

Gamescope and stuttering

The common answer to similar issues is to just use gamescope with --force-grab-cursor, and while that works, I found that gamescope introduces problems of its own.

Notably, it seems that gamescope in nested mode (aka running it inside another compositor) introduces some anomalous stuttering and performance degradation in general.

Fixing this is multi-fold.

First, you need to run the setcap command above. This ensures that gamescope’s process is super non-nice, meaning it will have a very high scheduling priority.

Second, you want to turn on variable refresh rate/adaptive sync, in your monitor, in your DE AND in gamescope (the launch options above have the flag already set). This seems to make all the difference for me, but maybe if your monitor doesn’t support VRR at all you won’t be affected by this particular problem.

Third, you want to use the -git version of gamescope. It seems that the currently tagged version still doesn’t include many important fixes and patches.

And that should be it, gamescope should now behave properly and your game shouldn’t lose focus anymore.

A dumb alternative approach

This might sound obvious but turning off your secondary monitor(s) is an option and fixes the issue without any complicated setup. It’s dumb, it works, but it’s annoying and less than ideal. Still, worth mentioning.

Explaining the command

• gamescope: well, that’s what we need to run
• --mangoapp: optional, runs mangohud on top of the game; note that the usual MANGOHUD=1 works but is unsupported and may report inaccurate information, so just use this flag instead
• -w 2560 -h 1440 -W 2560 -H 1440
  • -w and -h are the width and height your game should run at; gamescope will tell the game that this is your monitor’s resolution to force it to run at said maximum resolution
  • -W and -H are the width and height of the window that gamescope will render; this can be lower than your monitor resolution if you want your game to run windowed, or the same if you want to run it fullscreen
• --fullscreen: optional, makes the game fullscreen
• --force-grab-cursor: the reason we’re here, this captures the mouse so that it doesn’t escape gamescope’s window
• --adaptive-sync: makes sure gamescope plays nicely with VRR monitors as explained above; disable this if you don’t have VRR
• --backend=wayland: the backend gamescope will use to render; your choice on the matter seems to be between wayland and sdl, and it seems that at least for me wayland works best
• --: this is some old school shell trickery to avoid parsing what’s after it as command line options, just put it in there
• env ENABLE_LAYER_MESA_ANTI_LAG=1: optional, this turns on an implementation in mesa of AMD anti lag; this might improve latency for you, make things worse or do nothing at all
• %command%: the command Steam uses to run your game

Alright, I’m putting this out there since there doesn’t seem to be anything out there that fully explains this problem. If you have any more insight on what’s going on, why it’s happening or if there is a way to fix it without resorting to gamescope, let me know via email or on fedi.

The only problem I find is that the project seems a little bit niche. Don’t get me wrong, it seems very polished and so far I haven’t found any bugs, so that’s exceptional considering the scope of the project. The real problem with it being niche is that of course not every use case can be fully covered and documented, so some stuff you just have to figure out for yourself.

This was the case for me with command line options.

You might know that GTK offers a way to manage command line options out of the box, but Relm4 simply doesn’t wrap that particular API. After a bit of research I found a good way to make it all work and here’s how.

So given a struct named MyAppComponent being your root Relm4 component:

let app = gtk4::Application::builder()
    // set other properties as needed...
    .flags(gtk4::gio::ApplicationFlags::HANDLES_COMMAND_LINE)
    .build();

// don't know if this really MUST be static, but that's what works for me
static BROKER: relm4::MessageBroker<MyAppComponent::Input> = relm4::MessageBroker::new();
// this is just an example, here's the documentation for the Gio.Application API
// https://docs.gtk.org/gio/method.Application.add_main_option.html
app.add_main_option(
    "foo",
    gtk4::glib::Char::try_from('f').unwrap(),
    gtk4::glib::OptionFlags::IN_MAIN,
    gtk4::glib::OptionArg::None,
    "foo option description here",
    None
);
// add as many options as you want

let sender = BROKER.sender(); // we'll move this to the signal handler below
app.connect_command_line(move |this, cmdline| {
    this.activate();
    // very basic example, what I actually did was parse the
    // ApplicationCommandLine object and save my flags in an ad-hoc struct
    // but this should also just work
    sender.emit(MyAppComponent::Input::HandleCommandLine(cmdline));
    0
});
let relm_app = relm4::RelmApp::from_app(app).with_broker(&BROKER);
relm_app.run::<MyAppComponent>(MyAppComponent::Init {
    // your init data here
});

All you need now is a handler for the HandleCommandLine input signal in your app component and you’re pretty much all set.

This is very much a simplified example of what I’m actually doing, but it should serve as a good base to build on top of. Being that this was previously completely undocumented, at least it’s a starting point.

Feel free to comment if you have found a better solution or if somehow I missed some critical piece of documentation that explains the actual way to do this.

Turns out my GPU fans weren’t spinning, even under load. It helps that it’s winter and I have some very effective case fans, but it didn’t really make sense that at 88°C junction temperature the fans wouldn’t spin.

First, you might think of reaching for CoreCtrl to tweak the fan curve, but you’ll be disappointed to find no fan control settings for your new GPU.

Turns out RDNA3 GPUs, unlike previous Radeon cards, don’t have manual fan control at the firmware level. What they do have is manual fan curve control.

The funny thing is that for whatever reason the default fan curve (at least for my particular card) looks like this:

$ cat /sys/class/drm/card1/device/gpu_od/fan_ctrl/fan_curve
OD_FAN_CURVE:
0: 0C 0%
1: 0C 0%
2: 0C 0%
3: 0C 0%
4: 0C 0%
OD_RANGE:
FAN_CURVE(hotspot temp): 25C 100C
FAN_CURVE(fan speed): 15% 100%

Basically 0% at any temperature, which shouldn’t really even be allowed if you look at the valid ranges just below.

After scouring the internet I managed to find how to actually tweak these values, and I made a simple script to set my custom fan curve. The syntax is node_index temperature fan_speed_percent, and finally c as in “commit” to confirm the settings.

#!/bin/bash

if [[ "$USER" != "root" ]]; then
    echo "You need to run this as root"
    exit 1
fi

# you might need to adjust this, in my case it's card1,
# for you it might be card0 or something else entirely
cd /sys/class/drm/card1/device/gpu_od/fan_ctrl

echo "0 30 20" > fan_curve
echo "1 50 25" > fan_curve
echo "2 60 50" > fan_curve
echo "3 70 60" > fan_curve
echo "4 80 100" > fan_curve
echo "c" > fan_curve

But it’s got a big problem: it’s a bit of a hassle, and you have to know what you’re doing. There’s a wide ecosystem of plugins that integrate into each other, most of them requiring custom configuration code to work. It took a while, but I managed to put together a pretty good config.

Over time this config, that was initially living in my dotfiles repo, grew larger and more complex. So came the refactorings, then the generalizations, modularization, custom settings systems…

It outgrew its role as a humble user config, it became its own thing. At some point I had to give it its own repo, and along with it, a proper name: Nvpunk.

Yeah, that sounds about right.

Romantic storytelling aside, let me tell you what Nvpunk is: a complete, out of the box and ready to go neovim distribution.

In other words, it’s a fully featured neovim configuration you can use without having to learn how to select, install and manage plugins, and maintain the configuration glue that holds it all together.

Some highlights of what’s included:

• LSP support with completions, snippets, diagnostics and formatting
• DAP support for debugging with a familiar UI
• Advanced syntax highlighting with TreeSitter
• Interactive file tree with git support
• Code outline panel
• Fancy greeter with customizable header graphics
• Theme chooser with a selection of popular preconfigured themes
• Categorized right click menu to access some useful features

I’ve been heavily inspired by other projects like LunarVim, NvChad and AstroNvim, with the difference that Nvpunk tries to offer a ready to go experience, while these distros give you more of a base to build on yourself, still requiring manual configuration to be effective.

Nvpunk still offers some degree of custom configuration, but it’s more tailored towards advanced users that know what they’re doing, and it’s very much optional.

Most of the things you may want to change are configurable via a UI preferences menu, accessible from the greeter.

I understand that Nvpunk may not be for everyone: some may call it bloated, and typically (neo)vim fans like to roll their own config anyway (just like I did), but that’s fine. Nvpunk is mostly targeted at people that are looking for a good, feature-rich text editor, but that don’t have the time, interest or knowledge to maintain their own config.

You can find out more on Nvpunk’s website and on the GitLab repository.

I had a look at some already available options, but nothing seemed to fit the bill, so (as it’s often the case) I decided to make my own.

I want to make a quick tangent on how easy it has become for me to quickly hack together build a GTK app.

A big part of the reason is reusing existing code and tooling from my other projects, as well as learning the proper way to do things.

Another big reason is the great ecosystem that’s been growing around GNOME technologies recently, particularly after the release of GTK4.

First of all, libadwaita is a huge help for building any kind of application. It ships a bunch of widgets and other useful tidbits such as pre-built style classes, implementing the rules defined in the GNOME HIG. This allows for quick building, clean code and great looks out of the box.

But libadwaita has already been praised enough by me and other developers, so that’s not really anything new.

The other incredibly useful tool that I’m using for my apps is Blueprint by James Westman. Without going into too much detail, it’s a markup language for building GTK4 UIs in a clean and simple way. You then use the blueprint compiler to compile it to regular XML without ever having to look at it yourself.

Going back to Swatch, it’s really as simple as it gets: you can create as many palettes as you want, and you can add colors to each palette. You can give custom names to everything, and you can quickly copy the color in hexadecimal (or rgb()) format. I also decided to give Swatch two view modes: list and grid, similar to what you’d see in a file manager.

And with that said, this little tool does exactly what I need. Hopefully you can find it useful as well.

The code is available on GNOME GitLab as usual, and you can try it for yourself using the latest flatpak CI build.

As for a proper release, I’m planning to tag one and submit it to Flathub as soon as the GNOME 42 runtime comes out, so stay tuned for that!

I never came around to implement it, mostly because I couldn’t find a guide or any similar resource, except for GNOME Web’s source code, and that’s not exactly easy to navigate. At least, it isn’t for me.

Today I decided to come back to it, and I found that it’s actually a rather easy task! That’s why I wanted to document this process, in hope that someone might find it useful one day.

First off, you’ll need one or more blocklists, in JSON format. I used EasyList, in particular here’s the link to the JSON block list. Blocklists should be updated frequently, so it’s advisable to have some sort of mechanism to download and update them at runtime automatically.

Let’s now jump to the code, which will be Python in this case, but hopefully can be easily adapted to other languages.

I’ll use some closures for convenience.

# have a function that downloads text
def download_text(url: str) -> str:
    # ...

# create the filter store somewhere in your code, ideally you should
# only have one in your application
my_filter_store = WebKit2.UserContentFilterStore.new('some/cache/path')

# a name that will be used to save/retrieve blocklists from the store
BLOCKLIST_ID = 'blocklist'

def apply_adblock(
        webview: WebKit2.WebView,
        filter_store: WebKit2.UserContentFilterStore,
        blocklist_url: str
) -> None:
    # 0: Retrieve the WebKit2.UserContentManager from the WebView
    content_manager = webview.get_user_content_manager()

    def save_blocklist_cb(caller, res, *args):
        # 6: Once saving is done we can retrieve the newly created
        #    WebKit2.UserContentFilter with save_finish and finally add th
        #    filter to the WebKit2.UserContentManager
        try:
            filter = filter_store.save_finish(res)
            content_manager.add_filter(filter)
        except GLib.Error:
            print('Error saving blocklist')

    def download_blocklist_cb(blocklist: str):
        # 5: Now that we have the blocklist (as a string containing a json),
        #    we'll need to convert it to GLib.Bytes, then save it in the store.
        #    Yes, we need to save it even if we want to refresh it every time,
        #    this is just the way this works.
        #    This is also async and when it's done it will call continue on to
        #    save_blocklist_cb
        filter_store.save(
            BLOCKLIST_ID, GLib.Bytes.new(blocklist.encode()), None,
            save_blocklist_cb
        )

    def download_blocklist():
        # 4: Download the blocklist and continue on to download_blocklist_cb
        try:
            res = download_text(blocklist_url)
            GLib.idle_add(download_blocklist_cb, res)
        except:
            print('Error downloading the blocklist')

    def filter_load_cb(caller, res, *args):
        # 2: load_finish will either succeed, and return a
        #    WebKit2.UserContentFilter object or raise a GLib.Error in case
        #    it cannot find the blocklist in the store (ie: on the first run)
        try:
            filter = filter_store.load_finish(res)
            content_manager.add_filter(filter)
        except GLib.Error:
            # 3: If loading the blocklist from the store fails, download the
            #    blocklist (async to avoid blocking of course) and save it
            print('blocklist store not found, downloading...')
            Thread(target=download_blocklist, daemon=True).start()

    # 1: try to load the blocklist from the store, this is async and will call
    #    filter_load_cb when it's done
    filter_store.load(BLOCKLIST_ID, None, filter_load_cb, None)

I decided to comment the example code above instead of writing disconnected descriptions here, hopefully it makes sense.

This said, if you want to look at the actual code that I’m using in Feeds, you can find it here (this is a snapshot to today’s current latest commit, in the future you may want to look at newer code). It contains some logic to automatically refresh or even remove the blocklist.

Let me know what you think in the comments, and feel free to point out any errors, or if something is unclear.

Most of this year, as far as personal projects go, I spent at close contact with Gtk4, libadwaita and the awesome people over at the various matrix chat rooms.

I’ve spent this time porting What IP, HydraPaper and Giara to Gtk4+libadwaita.

I’m really happy of the results, and I’m even happier with how this new stack is shaping up.

The porting process for the most part has been relatively painless across the board, with only minor changes (albeit, many of them) needed for the actual porting. Along with the updated stack, I’ve been able to introduce new features and improvements, for the most part thanks to the new widgets available in libadwaita making my life a lot easier.

What IP being the simpler of the bunch didn’t really change much from its original iteration, except for some code cleanups. But hey, the theme is different and it looks amazing!

HydraPaper also stayed pretty much the same, with the exception of a new wallpaper folder selector (that you can see in the image above) in the form of a brand new widget, the mighty Flap! It’s a sidebar that can open above other widgets, mostly a glorified overlay, but with extra bells and whistles. On a regular monitor you can open it with the usual button on the headerbar, the same that opened a Popover before, but on a touchscreen you can swipe to open it! Plus, compared to the previous Popover implementation, the new Flap is part of the main window, meaning it can scale to fill the entire vertical space of the window, making this selector/filter much easier to interact with thanks to the increased size.

Giara being one of the more complex apps, received a lot more work and attention. First off, the post views have been re-implemented using ListView, a brand new (still somewhat janky) widget in Gtk4 that allows for better optimized lists, where rows get recycled instead of adding up, with performance quickly grinding to a halt. This change required a lot of work, since my usual terrible implementation of ListBox is 100% incompatible with the way ListView works. But with a lot of help and elbow grease, I managed to land it, making the whole experience of mindlessly scrolling through reddit a little less frustrating (hopefully). Also, thanks to another awesome widget, AdwCarousel, I was able to add support for image galleries. And they support touch gestures, too! Along with these changes, I also added an internal fullscreen image viewer, very much inspired by the one in telegram-desktop.

But let’s jump to the actual reason why I’m writing this post, The new Feeds.

You see, I wanted to start porting Feeds to Gtk4 sooner than it ended up happening. Unfortunately, I wasn’t able to up until recently. The reason being WebKit. WebKit support for Gtk4 has been broken for a while, and just recently (not all that recently, tho) it got to a point where it was usable enough for me to start the port. At the time of writing this, you still need to enable Gtk4 support in WebKit by using custom build flags, making development possible by building WebKit myself (which, by the way, takes a lot of time), but at the same time making distribution unfeasible. Flatpak being the main way I distribute my apps, it could work in theory, but having a 1GB+ bundle for a simple news reader isn’t really a great user experience, so for now I’m holding off this release, waiting for it to become available in the GNOME runtime.

But let’s move on to what’s actually new in Feeds.

First of all, from a user facing perspective, The whole look of the app is quite different. Apart from the new Adwaita theme in libadwaita, the article list uses the new navigation-sidebar style class, with cool rounded corners for the rows and no separators between them, but still providing enough visual separation. Label sizes in the rows have also been tweaked slightly.

Oh, and of course, I added article pictures! The code is based on the custom picture widget I made for Giara, and let me tell you: they make any article that more interesting!

As for visual changes, another big one is the new filter view, again based on the Flap widget.

It’s a similar story to HydraPaper, the old Popover implementation was hard to use and unintuitive. A sidebar is a much more common pattern, plus the added vertical size makes it easier to find the feed you wanna look at.

As for the articles list, you may think ListView would be perfect here as well, and that’s what I thought as well. Unfortunately due to some technical issues with how ListView row selection and activation work at this current time, while it does work, it’s not really all that convenient. I added the ListView to Feeds, and you can enable it in the preferences, in the advanced section, but I kept the ListBox around as a default, and I also changed its API so that it’s the same as the ListView implementation. You can switch between one or the other and try them out for yourself, hopefully at some point I can get rid of the ListBox and have the ListView be the default.

With all the nice changes and cool things this port brought with it, I decided to tackle one of the most annoying issues I’ve had with Feeds: the actual feed parsing.

Up until recently I’ve been using the very popular feedparser python library, but I’ve always been dissatisfied with both its performance and its weird quirks. I came to the conclusion that it’s not the kind of library I was looking for.

I tried searching for alternatives, and I broadened my search to any language, but unfortunately I couldn’t find something I really liked.

So I decided to write my own! And for the best performance I wrote it in… C++! Maybe some of you were expecting Rust? Maybe one day, but I don’t really know Rust right now 😕

This new library is called Sydndication Domination or syndom for short (it’s a bit cheesy, I know). Syndom is tailor made for Feeds, but of course it can be used for any application.

It’s based around an awesome XML parser for C++ called pugixml, if you ever need to parse XML I suggest you take a look at it. Syndom is able to parse an RSS or Atom file and extract all the useful information a news reader would need, and most importantly, it does the heavy lifting of trying all the different places a certain information can be found in. It can also parse Opml files for importing feeds, as well as Html files for extracting other useful information from, say a blog post, like the featured image, the feed URL, the title or the description.

The whole thing comes together inside Feeds with python bindings, created using another library called pybind11.

Honestly this has probably been the biggest change to ever come to Feeds. The performance difference is enormous, it’s like night and day, and I couldn’t be happier about it.

So that’s all I wanted you to know, hopefully I can release Feeds sooner rather than later as I really, really want people to use this new version rather than the crusty old one.

If you want to try it for yourself you can download a recent snapshot I made manually from this link. Please do let me know what you think in the comments or in the matrix room if you prefer. And feel free to report any bugs you encounter along the way!

That’s less than ideal, considering that if I did have lots of people who wanted to comment, that’d have been quite a strain on my humble home server, where my commento instance is hosted.

Today I found this post on Mastodon (feel free to follow me there by the way) by Karmanyaah Malhotra about how he reworked his website recently. I always enjoy reading about other people’s websites, so I quickly read through it, just to find out about this comment system called Cactus Comments.

Cactus Comments uses Matrix to create a federated comment section on your website. If you have a Matrix account on any instance, you can comment on Cactus! Heck you can even use a full-fledged Matrix client to do so! That’s just great.

It’s free to use and self hostable as well, so there’s really not much of an excuse not to try it out. Plus if you already have a Matrix account you’re already halfway there.

I integrated it in my Ficurinia Hugo theme without much effort, so there’s another bonus point.

And that’s it, I’m really happy about this new comment system, it’s one less service running on my home server and due to its decentralized and federated nature it will hopefully encourage more people to leave interesting comments and get a conversation going!

I thought of making a man page, but I would have lost the color (I don’t know how to use arbitrary colors in groff), so I just created a simple text file with ascii escape sequences for colors and called it a day. It works, and it’s pretty!

I’m uploading it here for your convenience (and mine as well), you should be able to grab it from your *NIX box by just typing:

curl https://gabmus.org/pico_pinout

If you want to save it in a file, just add > some_file_name to the above.

Why

D-Bus daemons are quite useful tools. What would you need them for? Well, I decided to add one to HydraPaper to do two jobs:

1. change the wallpaper periodically
2. listen for monitor configuration changes and adapt to it, so that when you plug or unplug a monitor, the wallpaper doesn’t get all messed up

There could be other reasons, like provide an always active “server” component to your application, or if you need to send notifications to the user even when your main app isn’t running.

Of course possibilities are limitless, it’s just another way to create software. Using D-Bus to create this daemon allows your graphical application to communicate with the main application in an easy and predictable way.

If you want to read more about D-Bus, I suggest you give a look at this nicely written article by Patrick Louis.

How

Now what languages are we gonna use? Ha! Trick question! If you know me (or can read the title) you know we’ll be using Python. Besides I’m pretty sure you can use whatever language you prefer, but today that’s what we’re gonna use.

Before we begin, it’s good practice to choose a unique id for our daemon using the reverse domain name notation. For the HydraPaper Daemon I chose org.gabmus.hydrapaper.Daemon. It’s important that your name is unique, so it’s a good practice to name it something like ext.yourPersonalHandle.yourApplicationName.Daemon. Another good idea is if you have a registered domain like I do for gabmus.org, to just use that, followed by the name of your app and some other indication that this service will be a daemon. You can read more about valid names here.

Once you have decided this id, just put it in a constant, along with the same but separated by slashes as if it was a path, like this:

UID         =  'org.gabmus.myapp.Daemon'
UID_AS_PATH = '/org/gabmus/myapp/Daemon'  # notice the leading slash

Let’s now start with the basics: we need a class extending dbus.service.Object. This will be our D-Bus Object, and some of the methods inside of it will be exposed as D-Bus methods.

import dbus
import dbus.service  # yes, you need to import this as well


UID         =  'org.gabmus.hydrapaper.Daemon'
UID_AS_PATH = '/org/gabmus/hydrapaper/Daemon'


class MyappDaemon(dbus.service.Object):
    def __init__(self, bus_name):
        super().__init__(
            bus_name, UID_AS_PATH
        )

Now before moving on, I decided to include the final part here: bootstrapping our main loop and all of the things we need to get this bad boy running, so that you can actually try things out and see what’s going on instead of just blindly copy-pasting.

You’ll need these additional imports:

from dbus.mainloop.glib import DBusGMainLoop
from gi.repository import GLib

Let’s move to the bottom of the file and create a main function, just to do things cleanly:

def main():
    DBusGMainLoop(set_as_default=True)
    try:
        bus_name = dbus.service.BusName(
            UID, bus=dbus.SessionBus(), do_not_queue=True
        )
    except dbus.exceptions.NameExistsException:
        print(f'Service with id {UID} is already running')
        exit(1)
    loop = GLib.MainLoop()
    daemon = MyappDaemon(bus_name)
    try:
        loop.run()
    except KeyboardInterrupt:
        print('KeyboardInterrupt received')
    except Exception as e:
        print('Unhandled exception: `{}`'.format(str(e)))
    finally:
        loop.quit()


if __name__ == '__main__':
    main()

Alright, let’s resume from where we left.

We have a D-Bus object, and the thing can run doing nothing now, awesome.

Let’s give this object a method we can invoke from outside.

To do this we’ll create a method in our class and decorate it with @dbus.service.method. This decorator takes some parameters:

• dbus_interface: the interface we want this method to be attached to (interfaces are another nesting level for D-Bus, honestly I think they’re overkill for this kind of use, so we’re just going to use our previously declared UID as the interface, it’s gonna work).
• in_signature: what kind of parameters our method requires
• out_signature: what kind of output our method returns

For the signatures, you can read more about data types you can use in this documentation page.

Let’s create a simple hello method that takes a string and returns another string.

class MyappDaemon(dbus.service.Object):
    # ...
    @dbus.service.method(
        dbus_interface=UID,
        in_signature='s', out_signature='s'
    )
    def hello(self, your_name: str) -> str:
        return f'Hi there, {your_name}!'

That’s it! Easy, wasn’t it?

Now if like me you want to have some action to run every x seconds or something, you can just use the standard threads and sleep model of Python, not much else you need as far as D-Bus goes.

Now, let’s see what we need to do to package this new Daemon in a Flatpak and have it being recognized by the system as proper and activatable D-Bus service.

Plumbing

First off, we’ll be using meson, so I assume you already are using it for your base application.

Assuming we have our daemon inside a sub-folder called myapp_daemon. For packages reasons I suggest you call the actual daemon Python file something like myappd.in.py. Notice the trailing d, it means daemon. Another thing: make sure to give this file executable permissions! (chmod +x myapp_daemon/myappd.in.py)

At the beginning of myappd.in.py we’re going to insert our shebang like this:

#!@PYTHON@

In our main meson.build file, the one in the root of the project, let’s put the following somewhere you feel is appropriate (skip anything that is already there of course):

prefix = get_option('prefix')
datadir = get_option('datadir')
libexecdir = join_paths(prefix, get_option('libexecdir'))
etcdir = get_option('sysconfdir')
dbus_service_dir = dependency(
    'dbus-1'
).get_pkgconfig_variable(
    'session_bus_services_dir',
    define_variable: ['datadir', join_paths(prefix, datadir)]
)
python = import('python')
py_installation = python.find_installation('python3')
if not py_installation.found()
    error('No valid python3 binary found')
endif

subdir('myapp_daemon')
subdir('data')

Now, let’s create myapp_daemon/meson.build, and put this inside:

daemon_conf = configuration_data()
daemon_conf.set('PYTHON', py_installation.path())

configure_file(
    input: meson.project_name() + 'd.in.py',
    output: meson.project_name() + 'd',
    install: true,
    install_dir: libexecdir,
    configuration: daemon_conf
)

That’s it for the daemon itself, but we still need some other files to let Flatpak (or your host operating system for that matter if you install this with a regular package manager) recognize this as an activatable service.

Note: an activatable service means a service that will be started automagically as soon as an application tries to connect to it.

For this, I like to work inside of a new folder called data inside the project root.

Inside data let’s create:

org.gabmus.myapp.Daemon.desktop.in containing:

[Desktop Entry]
Name=org.gabmus.myapp.Daemon
Comment=Daemon for myapp
Icon=org.gabmus.myapp.Daemon
Exec=@libexecdir@/myappd
X-GNOME-Autostart-Delay=10
StartupNotify=false
NoDisplay=true
Type=Application

org.gabmus.myapp.Daemon.service.in containing:

[D-BUS Service]
Name=org.gabmus.myapp.Daemon
Exec=@libexecdir@/myappd

meson.build (if it exists already, just add to it) containing:

data_conf = configuration_data()
data_conf.set('libexecdir', libexecdir)

configure_file(
    input: 'org.gabmus.myapp.Daemon.desktop.in',
    output: 'org.gabmus.myapp.Daemon.desktop',
    configuration: data_conf,
    install: true,
    install_dir: join_paths(etcdir, 'xdg', 'autostart')
)

configure_file(
    input: 'org.gabmus.myapp.Daemon.service.in',
    output: 'org.gabmus.myapp.Daemon.service',
    configuration: data_conf,
    install: true,
    install_dir: dbus_service_dir
)

Finally, we need to tell Flatpak that the org.gabmus.myapp.Daemon name is owned by our application. To do this let’s add the following to our Flatpak manifest, inside the finish-args array:

"--own-name=org.gabmus.myapp",
"--own-name=org.gabmus.myapp.Daemon"

Great! Now in theory everything should be in place, of course let me know if anything is broken or doesn’t work, the comment section is there to be used!

For the final section of this small tutorial, let’s see how to call the method we created.

Summon the daemon

For this last section, I’ll just leave you with some very brief example code in Python, hopefully it’s easy enough to follow:

import dbus

def summon_hello(name):
    try:
        bus = dbus.SessionBus()
        obj = bus.get_object(
            'org.gabmus.myapp.Daemon',
            '/org/gabmus/myapp/Daemon'
        )
        interface = dbus.Interface(
            obj, dbus_interface='org.gabmus.myapp.Daemon'
        )
        return interface.hello(name)
    except dbus.exceptions.DBusException:
        print('Failed to communicate with `org.gabmus.myapp.Daemon`!')
        return ''

Hope you can find this tutorial useful. Mind you, I’m not an expert in this matter, I just did this and failed to find a single tutorial summarizing all of what I needed, so I decided to make one myself.

If you find that anything doesn’t work as expected (maybe I missed a step or two?) please let me know in the comments, or contact me directly by using one of the contacts you can find in the About page.

For the longest time, I have felt the need for a reddit app on my Linux desktop, and I waited and kept waiting for one that would finally allow me to break free of using the web version.

Some honorable mentions are due to projects like the now seemingly abandoned Something for reddit and the terminal app Tuir.

Unfortunately they were not what I was looking for.

At some point I just decided to start scratching this itch of mine, and so my quest began.

And this is how Giara got to be!

At this current stage Giara is already usable, with most of the main features you’d expect from a reddit app to work.

Many people, including some familiar faces, stepped up and helped me in the development process, and I have already received some contributions.

It’s not 100% done, tho. It still needs to reach feature parity with the reddit web client, as features like awards, polls, galleries and private messages are still to be implemented. I’m also working on improving performance, as the app tends to be slower than I would prefer sometimes. All of these missing features and improvements are up next in my to-do list.

The app has also been recently moved to the World group in GNOME’s GitLab, and I’m incredibly happy for it! The next step now is to add support for the Damned Lies translation platform, so that it can be even easier to contribute new translations to the project.

As always any help and contribution is highly appreciated!

You can find the repo on GNOME’s GitLab and you can download the latest stable version of Giara from Flathub. You may also want to take a look at Giara’s website.

I couldn’t find a proper way to map it on my app until I asked on the GTK Matrix chatroom, there baedert sent me a couple of links to how he did it in his app corebird.

I translated the code to Python and decided to make a blog post to archive the procedure.

First, here’s a function that creates the “gesture” and assigns it to a widget and a callback function

def add_mouse_button_accel(widget, function):
    gesture = Gtk.GestureMultiPress.new(widget)
    gesture.set_button(0)
    gesture.set_propagation_phase(Gtk.PropagationPhase.CAPTURE)
    gesture.connect('pressed', function)
    return gesture

As you may have noticed, this function returns the created gesture. You may think there is no need for it and ideally you’d be right.

There’s just a small issue: due to something that I could only identify as a bug in GTK, you need to keep the Gtk.GestureMultiPress object around, otherwise it gets destroyed and the button clicks are no longer registered.

Once the gesture is returned, you can assign it to something that stays in memory (or you can modify this function and do something like widget.mouse_accel_gesture = gesture and be done with it).

As for the function associated with the mouse click, here’s a template you can use:

def on_mouse_event(gesture, n_press, x, y):
    btn = gesture.get_current_button()
    if btn == 8:
        # Handle the Back button here
    elif btn == 9:
        # Handle the Forward button here

There you go, hope it helps. If you have any trouble feel free to leave a comment or contact me (contact info can be found in the about page)

So after some hacking, I seem to have found a solution that works:

from gi.repository import Gtk, GdkPixbuf, Gdk


class PictureView(Gtk.DrawingArea):
    def __init__(self, path, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.path = path
        self.pixbuf = GdkPixbuf.Pixbuf.new_from_file(self.path)
        self.img_surface = Gdk.cairo_surface_create_from_pixbuf(
            self.pixbuf, 1, None
        )

    def get_useful_height(self):
        aw = self.get_allocated_width()
        pw = self.pixbuf.get_width()
        ph = self.pixbuf.get_height()
        return aw/pw * ph

    def get_scale_factor(self):
        return self.get_allocated_width() / self.pixbuf.get_width()

    def do_draw(self, context):
        sf = self.get_scale_factor()
        context.scale(sf, sf)
        context.set_source_surface(self.img_surface, 0, 0)
        context.paint()
        height = self.get_useful_height(self.get_allocated_width())
        self.set_size_request(-1, height)

This code is actually simpler than I imagined, and that’s a good thing. Let’s see what’s going on here.

I’m doing all of this in a self contained class I unoriginally called PictureView, of course you can rename it to your liking. It takes a path to a picture as an argument.

I’m subclassing Gtk.DrawingArea to be able to draw arbitrary stuff with cairo.

The first thing is creating a base GdkPixbuf.Pixbuf to store the original image, create a cairo surface from that image and then tell the widget what to do inside the do_draw method.

This will in turn find out the size at which it wants to be rendered.

For the width, I want all of it, or in other words all of the allocated width that the widget has.

As for the height, I simply calculate the target height (indicated as allocated_height in the formula below) by solving a simple proportion between the picture width and the allocated width:

pixbuf_width / allocated_width = pixbuf_height / allocated_height

Once I have this useful data, I set the widget size request with the new values I found (I leave the width as -1 so that it doesn’t change).

Then, I scale the whole cairo context with the scale method, calculating the scale factor as widget_width / pixbuf_width, and finally set the cairo context source to the image surface I created in the constructor.

Oh, and don’t forget to call cairo.paint() as well.

All in all this is pretty straight forward, but you need to know what you’re doing, and I certainly did not up to about a couple of hour ago.

Hopefully if you need to do this, you will find this blog post and avoid wasting two hours of your time trying to figure this out from sparse C code floating around the internet.

As a final note, I’m being told that in GTK4 GtkPicture is able to do this, but since I’m still stuck with GTK3 (as you probably are as well if you’re reading this), this is the best solution I could find.

Of course writing man pages is a different thing. They are written in groff. I am not a fan of it, although I know people who do enjoy using it.

Markdown ❤ Pandoc

Of course the obvious thing to do is write your docs in Markdown, since it’s the best simple markup language out there. Fortunately, it’s very easy to convert Markdown to groff, and consequently into a man page.

And of course you can just use Pandoc to do that. It’s as simple and straight forward as you can imagine, it’s just one command away:

pandoc --standalone --to man mymanpage.1.md -o mymanpage.1

It’s actually not the first time I’ve done something like this. The first was with the handy manuals I wrote for the Glorious GMMK keyboard and Model O mouse. Most of the fancy things you’d wanna tweak with these peripherals are done with weird key combinations, and having the paper manuals or even worse PDF copies of those around isn’t very practical. So of course I wrote man pages for those.

If you know Markdown, the syntax you have to use is of course very simple, but if you wanna do it right, you may want to know about a couple of dialect forms of Markdown:

Definition lists

Definition lists are perfect for describing particular commands or arguments in your man page, and they get rendered just as you think they would in a man page. They are not part of the original Markdown spec, but Pandoc supports them no problem.

They’re really easy to use, here’s an example:

`-h, --help`

:   Shows the help message

The backticks are optional but they help escaping weird characters and besides they mark a section that is effectively code.

Metadata blocks

Metadata blocks are also useful to show the title of the man page. Definitely one of those small touches that you might want to have in your man page, as every proper one has them.

Again, the syntax is fairly straight forward. You want to have this at the beginning of your file and looking something like this:

% mymanual(1) Version 0.9.99 | Example manual for this blog post

Example

Finally I want to include an example Markdown man page I recently made for HydraPaper, so that you can get a better grasp of what a full file could look like. Of course you can also find this file in HydraPaper’s repository if you’re interested.

% HydraPaper(1) | General Commands Manual

NAME
====

HydraPaper - Wallpaper manager with multi monitor support

SYNOPSIS
========

`hydrapaper [-h] [-c WALLPAPER_PATH [WALLPAPER_PATH ...]] [-m WALLPAPER_MODES [WALLPAPER_MODES ...]] [-r] [-l]`

DESCRIPTION
===========

HydraPaper is a wallpaper manager, specifically designed to work around the lack of functionality of many desktop environments to set a different wallpaper for each monitor in a multi monitor setup. It accomplishes this by scaling and merging different wallpapers into a single one and setting it as spanned.

It currently supports various desktop environments, including GNOME, MATE, Cinnamon and Budgie. Experimental support is included for the sway window manager.

OPTIONS
=======

`-h, --help`

:   Show the help message and exit

`-c, --cli WALLPAPER_PATHS...`

:   Set wallpapers from the command line

`-m, --modes WALLPAPER_MODES...`

:   Specify the modes for the wallpapers (`zoom`, `center_black`, `center_blur`, `fit_black`, `fit_blur`)

`-r, --random`

:   Set wallpapers randomly

`-l, --lockscreen`

:   Set lockscreen wallpapers instead of desktop ones (for supported desktop environments)

BUGS
====

Bugs can be reported and filed at https://gitlab.gnome.org/gabmus/hydrapaper/issues

If you are not using the flatpak version of HydraPaper, or if you are using an otherwise out of date or downstream version of it, please make sure that the bug you want to report hasn't been already fixed or otherwise caused by a downstream patch.

I was previously using Hexo with a nice theme called cactus (properly altered to match my preference), but at some point I got tired of that as well.

I wanted to create something simple and straight forward. This is the kind of website without too many bells and whistles. Just a blog, period.

The initial idea of static site generators kinda goes well with this concept, but I don’t exactly know when or how things changed. Maybe people liked these tools so much they tried to make them more general purpose, or they just wanted to use them for different things. Doesn’t matter, point is that these generators, once simple and easy ways to make a decent blog without the burden and subsequent psychological trauma of a LAMP stack, are now bloated and messy.

Well, to be fair it’s not really an issue with the generators themselves, but with the themes. It’s the theme that has the responsibility for how the content is meant to be laid out, what is allowed and how you should do things. Honestly calling them themes is an understatement. If the generator is the skeleton, the theme is muscles, flesh and nervous system. The so called generator is useless without one.

Making themes is one of those things that I don’t like to do. I didn’t like it when I was a kid playing around with Wordpress and Joomla, and I don’t like it now. I’d rather make a plain website instead. But that’s not feasible for a blog because of pagination, tags, RSS feed and whatever else that doesn’t come to mind right now.

But at some point I just said, well F it, let’s do it. It’s a thing I’ll do once and basically forget it, and the gain I get from it is a website I actually like and that I can easily customize and change around whenever I feel like it.

I decided to use Hugo since it seems to be the most popular static site generator at this point in time. I’m not new to it, and I somewhat knew my way around it (or so I thought) since I already modified another theme for the latest iteration of the Tech Pills website. After watching some YouTube tutorials and digging through the lackluster documentation what came out was a new theme I decided to call Ficurinia.

The name choice was pretty easy. This theme is inspired by the theme I was using before with Hexo called cactus. This being sort of a grittier version of cactus (if not a more personal vision on the same idea) I decided to call it after the Sicilian word for Indian fig aka prickly pear, Ficurinia.

I’m happy to have made this theme. It’s simple, no weird layouts or messy animations, no javascript, and it works on mobile without any modification or special rules. Heck it even looks pretty damn good in the links command line browser.

So this is my new home now. Hope you like it.

As an added bonus, they should also run when creating a flatpak package, so that I don’t accidentally push a broken built to users.

Here’s the very simplistic way I accomplished this task:

• have your tests in a tests directory in the root of your project
• add this to your meson.build

envdata = environment()
python_paths = [join_paths(meson.current_build_dir(), '..')]
envdata.append('PYTHONPATH', python_paths)
envdata.append('TESTS_BUILDDIR', meson.current_build_dir())
test(
  'unit-tests',
  import('python').find_installation('python3'),
  args: ['-m', 'unittest', 'tests'],
  env: envdata
)

While this works locally, I’m still having problems with running them during the flatpak build in GitLab CI, so I’ll try to solve that as well and update this post accordingly.

This doesn’t change too much in terms of development, but it surely makes the app more discoverable. It also provides this very nice new URL for Feeds’ website which is under gnome’s domain name (that’s pretty cool, uh?).

As for Feeds’ development, lately I’ve begun a process of small cleanups here and there, and most importantly design changes.

Thanks to the help of Tobias Bernard, Alexander Mikhaylenko and some other awesome people from the libhandy community, I brought Feeds back in line with the GNOME HIG. These are small changes, but surely needed ones to have a more consistent desktop experience.

Some of the features I had planned, detailed in some of my previous posts in this blog, still haven’t made it, tho. To be fair, some of them require a decent amount of work, and I’d be nice if someone wanted to help with implementing them.

That’s why I’ll try to cleanup the code more, using Glade templates where possible, splitting different classes in different files and uncluttering the logic a bit. It’s probably one of the most boring things you could do, but if I want people to contribute, it has to happen.

That’s it for now, stay tuned.

Someone criticized the name gfeeds, because it’s kind of dumb to have GNOME/GTK app names to start with a g, similarly to how dumb it is to have KDE apps start with a k. But here’s the catch: the g in gfeeds stands for Gabriele, I pulled a sneaky on you.

Anyway, the new name should have no problems whatsoever, and besides I learned how to transition to a new appid on Flathub.

It’s not as seamless as you would think, but it’s easy enough. You’ll have to re-submit your app as if it was a new one, and specify that it’s just an appid change. There’s some infrastructure in place to transition from one appid to another automagically, and it involves a little extra json file in the old repo. Here you can see my PR for the new appid and the whole discussion around it. Hope it helps.

As for new stuff, let’s see what we have:

• More stability, broken feeds are automatically removed and error messages will be shown in an upcoming version (already in master).
• OPML file association. Now you can just open your OPMLs from your file manager and have them imported in Feeds.
• If you’re offline, feeds won’t be refreshed. Instead, an infobar will tell you that you’re offline. Saved articles are still accessible.
• CPU utilization is now lower, having removed some unnecessary busy waits from the code.

That’s it for now. Again, still a lot of work to do, but little by little Feeds is coming together pretty well.

My current setup isn’t perfect but it manages to automate flatpak builds. This is incredibly useful, as when people open issues and I try to fix them, I can just tell them to install the lastest flatpak from the CI/CD and test the fixes.

Also, for power users and curious minds I imagine it could be compelling to be able to install the latest development snapshot without jumping through many hoops.

Anyway, let’s get down to business, here’s the .gitlab-ci.yml file to let the magic happen:

include: 'https://gitlab.gnome.org/GNOME/citemplates/raw/master/flatpak/flatpak_ci_initiative.yml'

variables:
    BUNDLE: "gfeeds.flatpak"

flatpak:
    image: 'registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome:3.32'
    variables:
        MANIFEST_PATH: "dist/flatpak/org.gabmus.gfeeds.json"
        MESON_ARGS: "-Dprofile=Devel"
        FLATPAK_MODULE: "gfeeds"
        RUNTIME_REPO: "https://flathub.org/repo/flathub.flatpakrepo"
        APP_ID: "org.gabmus.gfeeds"
    extends: .flatpak

review:
    stage: deploy
    dependencies:
        - 'flatpak'
    extends: '.review'

stop_review:
    stage: deploy
    extends: '.stop_review'

Hope you find a good use for it.

Let’s see how it does on Linux.

Installation

First, I use Arch (btw) and that makes things a lot easier, at least for now. As of writing this, Navi support is still not in the mainline kernel, but it should come with Linux 5.3.

Because of the AUR and many other fun things, this isn’t much of a problem in Arch.

Don’t be surprised when you install the GPU in your PC and don’t see Xorg or anything resembling a GUI popping up.

First, you need to add a new repo to your system. Put the following in /etc/pacman.conf, just above the [core] repository:

[mesa-git]
Server = https://pkgbuild.com/~lcarlier/$repo/$arch
SigLevel = Optional

Now, let’s install some packages:

sudo pacman -Sy amdvlk clang-git libclc-git libdrm-git llvm-git llvm-libs-git mesa-git opencl-mesa-git vulkan-mesa-layer-git vulkan-radeon-git xf86-video-amdgpu-git lib32-mesa-git lib32-mesa-git lib32-vulkan-radeon-git lib32-vulkan-mesa-layer-git

This will cover most of the stuff needed to make the GPU work correctly.

Now we need the new kernel modules. For this, you have two routes: install amdgpu-dkms from the AUR, or install linux-git from the AUR. I personally suggest you to go with linux-git as the dkms driver is not official as far as I know and doesn’t cover all the stuff that’s needed to make the GPU work 100% (like sensors support).

Whatever route you choose, there’s still one more thing you need to install from the AUR: the linux-firmware-agd5f-radeon-navi10 package. This is a package I made myself containing the latest firmware for Navi 10 GPUs right from the driver developer.

So, to summarize, here’s a copy-paste command you can run:

yay -S linux-git linux-firmware-agd5f-radeon-navi10

Quick note, I tried installing mesa-aco-git, even just to give it a try, but unfortunately I wasn’t able to get Xorg (or Wayland for that matter) running with it. Maybe in the future, we’ll see.

Gaming performance

First, all of the games I’m gonna talk about were ran at 1440p. They were all tested in GNOME Wayland, and the ones showing problems were also tested in GNOME Xorg and XFCE.

So, performance is of course great, especially in native games. Here’s a list of games I maxed out without any hiccup or visible problem:

• Rocket League
• Dark Souls 3
• Road Redemption
• CS:GO
• DOOM 2016
• The Witcher 3
• Fallout 4 (except for a mouse problem unrelated to the GPU)
• Tabletop Simulator
• For The King
• Keep Talking and Nobody Explodes
• Xonotic

Small note on The Witcher 3: it runs pretty much flawlessly, but I experienced some occasional frame rate drops, especially early on when I loaded the game. This usually goes away after 10 minutes or so of gameplay.

I had various problems with other games, and pretty weird ones, too. I think they’re worth documenting.

IMPORTANT UPDATE

The games that are crossed out below don’t actually have anything wrong with them. I am just dumb enough to have used the non git versions of the mesa 32 bit libraries. I updated the install command above, just to make sure nobody gets the same problems.

• Distance: the game launches, but performance is terrible (2 fps in the menu at 1440p). Obviously there’s something wrong, as the game is far from being that heavy.
• Screencheat: about 7 fps in game, 12 or so in the menu. Very similar to the problem with Distance.
• Hover: Revolt of Gamers: As above, performance is unexplainably terrible even in the main menu.
• Rise of the Tomb Raider: game seems to work fine, launches and the menu is perfectly responsive, but 5 seconds or so after I get in game, the whole game freezes into an unrecoverable state.
• Quake Champions: Similar to Rise of the Tomb Raider, menu works perfectly, almost instant freeze as soon as I get in game. But Quake Champions is far from being a technically well engineered game.
• Enter the Gungeon: Perfectly playable, but some of the graphics show some small amount of glitches.
• No Man’s Sky: Games works almost perfectly, but the framerate drops heavily inside menus.

An interesting fact: in the games I’ve tested, where the framerate is unexplainably low, sensors shows the power draw of the GPU to be stuck at 30W (same as idle). Other games that give no problems like The Witcher 3 manage to raise the power draw between 150W and 300W. I later confirmed that (of course) the clock speeds (monitored via sudo watch cat /sys/kernel/debug/dri/0/amdgpu_pm_info) are directly proportional to the power draw.

This probably shows something’s wrong with the driver. It made me wonder if I could force a clock speed on the GPU manually to see if those games work fine. I didn’t want to go that route since it would kinda count as an overclock and I’m still not confident enough in my abilities or in the driver’s.

What I did try to do was force the higher pstates (power states) on the GPU to see if that would work. Of course, it doesn’t. Following the AMDGPU page on the Arch Wiki I tried these commands:

sudo -i # better be root for this
echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk # set highest pstate 2 on the memory
echo "5 6 7" > /sys/class/drm/card0/device/pp_dpm_sclk # set higher pstates 5, 6 and 7 on the actual gpu

This didn’t work at all, and showed some rather interesting errors in dmesg, similar to this one: Failed to send message 0x20, response 0xfffffffb param 0x5. Of course searching for these messages gave me zero results.

About OpenCL: Unsurprisingly Clover doesn’t work, but so doesn’t the AMDGPU-PRO OpenCL implementation. Still need to investigate that further, I didn’t get into much detail with OpenCL. Will do soon after I have these more serious problems sorted out. OpenCL now works using the opencl-amdgpu-pro-pal package from AUR.

Conclusions

It’s not an entirely bad thing to be an early adopter. I mean, I am starting to understand how the driver works (kinda?) and digging into lower level stuff with the kernel and the GPU than I’ve ever had.

This said, there’s still much I don’t understand. I am willing to learn and help. If you have more experience with this stuff and want to add your voice to the conversation, don’t hesitate to comment or contact me personally.

Will keep this blog updated with any news regarding making this GPU work.

The code starts to feel a little more complex, and it would probably use another small refactoring, but that’s not too important right now.

Let’s lay out a new roadmap, with the features I implemented, and some new ones I want to add:

• Read and unread articles
• Keeping history of older articles locally (still not sure if I actually want this or not)
• Adblocking
• Saving articles
• Suggestions
• Integration with GNOME Online Accounts
• Integration with TTRSS
• Ability to open rss links and OPML files
• Offline mode with a banner indicating that the system is offline

There’s still some work to do. Of course any help is welcome and appreciated.

In a previous post I layed out a roadmap for my feed reader application Feeds. Here’s a little update on how things are going.

Alright, first I want to thank @Etamuk again. He’s being very active with the German translation, and any time I make a commit, soon after I already see he has opened a merge request with the updated translation. That’s just impressive, and I’m truly greatful for his awesome contributions!

But now let’s get down to business with the new features.

Saving articles

Every article now has a right click or longpress popover that contains two buttons. The first one is a Save button. You can use it to save or unsave delete an article.

Once an article is saved, its content is downloaded and available offline. This allows easy consultation whenever you want and also provides an alternative to browser bookmarks or online “read it later” services.

Read and unread

A feature that I should have implemented from the beginning made its way into Feeds just now. Articles you read, are marked as read.

The marking was made in the laziest way possible: it just changes the article opacity to 50%. But in my opinion it works alright. Of course you can manually set an article as read or unread by using the dedicated button in the right click or longpress popover.

Conclusions

Maybe these sound like easy things to implement, but to be honest due to the structure of the application, and to the way things work to minimize disk usage and make the whole thing more dynamic and faster overall, to implement these features I had to touch up almost every little piece of the application.

It was worth it in the end, and I’m happy of what I accomplished. Hope you like it too when it comes out. I’m thinking of doing a 0.7 release. I don’t have the feeling that Feeds is worth a 1.0 at the moment. Maybe I need someone to test it out and see how things are working.

The lazy solution is pretty obvious: Disqus the privacy nightmare.

I like the wild idea of respecting my readers’ privacy, and so I started looking for alternative solutions.

The one solution I chose to adopt is an open source comment platform called Commento. It works just like Disqus, except since it doesn’t make money from violating people’s privacy, you can’t really use it for free.

You can either choose to pay what you want for it (with a minimum of 3 USD) or host it yourself.

I already pay for a VPS for Tech Pills’ website, but it’s not subject to heavy load, so a service more running on it wouldn’t really hurt.

You can install Commento using docker-compose, which is very convenient. I made some changes to the docker-compose.yml file to better suit my needs, and put an nginx reverse proxy in front of it to add https into the mix.

After writing some CSS to adapt it to the blog’s theme, the new comment box is ready to roll.

As a nice (unexpected) bonus, Commento also provides some basic analytics like total page views and number of comments. And that’s all totally anonymous, it’s just a faceless number that’s not associated to any identity.

And that’s about it, if you’re looking for a privacy respecting, open source, powerful comment platform, that’s also pretty easy to install and offers some bonus analytics on top, Commento is the way to go.

• German translation thanks to @Etamuk
• Concurrent feeds refresh

About the translation, I know when a project starts becoming interesting, people want to contribute. And translations are in my experience one of the indication of people really getting passionate.

I am really flattered by this contribution and it really means a lot to see this project getting some love.

Moving on to the more technical stuff, concurrent refresh or parallel refresh.

It was surprisingly easy to implement, and that really shows how important having a modular and well-thought-out code structure is.

You see, the feed download and object creation (along with the creation of all the feed items) happens asynchronously already, but adding that feed, and all of its articles to the active lists doesn’t. There is this wonderful function GLib.idle_add(function, *args) that makes this whole process so easy and elegant. This function does no more than telling the main thread to run function(*args) whenever it can, no rush (although to a human it’s almost instantaneous). With this method the GUI thread doesn’t get interrupted and the UI doesn’t freeze, but the function is still ran synchronously to it, avoiding any problems of mutual exclusion to precious variables.

# https://gitlab.com/gabmus/gnome-feeds/blob/0.6/gfeeds/feeds_manager.py#L139
class FeedsManager(metaclass=Singleton):
    # ...
    def refresh(self, *args):
        # ...
        threads_pool = []
        threads_alive = []
        MAX_THREADS = self.confman.conf['max_refresh_threads']
        for f_link in self.confman.conf['feeds']:
            t = threading.Thread(
                group = None,
                target = self._add_feed_async_worker,
                name = None,
                args = (f_link, True)
            )
            threads_pool.append(t)
        while len(threads_pool) > 0:
            if len(threads_alive) < MAX_THREADS:
                t = threads_pool.pop(0)
                t.start()
                threads_alive.append(t)
            for i, t in enumerate(threads_alive):
                if not t.is_alive():
                    threads_alive.pop(i)
            while t.is_alive():
                while Gtk.events_pending():
                    Gtk.main_iteration()

This is the wonderful code that manages the parallel refresh. It’s fairly straight forward, it keeps a pool of threads to run, and runs n of them at a time, where n is the maximum number of threads set by the user (defaults to a very mild 2).

Apart from making the refresh process faster by itself, it also reduces the impact of problems like one feed taking longer than the others to download or parse. It’s not a likely occurrence, but if and when it happens, it doesn’t injure the user experience too much. That’s because the slow feed is being processed in its own thread, but the whole refresh operation doesn’t have to wait on it.

Moving on, I wanted to lay out a roadmap of where I want Feeds to go in the future.

• Read and unread articles: currently Feeds doesn’t keep track of your actions, and if you did or didn’t read an article. This would require some strcuture, like the serialization and deserialization of articles to a skinnier, more targeted data structure (probably something like tsv or json, but the latter is more likely)
• Keeping history of older articles locally: rss feeds typically don’t contain the whole archive, mostly because the resulting file would be huge and unwieldy. But people may want to be able to re-read articles they saw some time prior. That’s why there needs to be an option to store them up to the user’s preference. Again, this needs serialization/deserialization as described in the bullet point above
• Adblocking: this speaks for itself. Modern websites are a mess, disabling JavaScript helps, but it’s neither a soltion nor a silver bullet
• Saving articles: kinda like bookmarks, but not quite. Let’s say you add this awesome blog to your feeds, and you read a super interesting article about how to make feeds refreshing concurrent with just a bunch of lines of code. You surely want to save that! I mean, it could be useful someday right? That’s a likely usecase for me. Also, you’d wanna keep it offline as well, just in case you need it when you’re on a plane or something
• Suggestions: many online news readers give you suggestions on what to follow. It’s an interesing feature and I’d want to add that. People are so addicted and accustomed to social media websites that this is what they expect news consumption to be.
• Integration with GNOME Online Accounts: mostly to be able to sync with services like Nextcloud News. Would be a hell of a feature.

And that’s it folks. This is the list of what I’d want to accomplish with Feeds. Not all of these features are easy, and some are prone to make the whole app slower, and that’s one thing I 100% want to avoid.

Hey people. I finally got around at creating a static blog.

After using Hugo for a while, and initially deciding to try out Pelican, just to realize it’s in a sad, outdated state right now, I settled on Hexo.

It’s not like I’m crazy for JavaScript, quite the contrary. But I do realize it has its place sometimes. Using npm to install plugins is pretty clever, and besides at the end of the day I am the only one that has to use it.

It has a more complex structure compared to the aforementioned solutions, but if it gets the job done I can’t complain too much.

Recap

This is an interesting point in my life. In July I got my bachelor’s in Computer Science, it was a pretty great achievement, and soon I’ll be heading to Milan to get a master degree.

About my projects, things are going very well. I am focusing a lot on GTK/GNOME apps, probably because I’m making things I want to use in the first place.

HydraPaper got a pretty substantial update, introducing libhandy into the mix to spice up its looks somehow, and mostly to make use of some comodity widgets it offers, namely the awesome HdyPreferencesWindow.

For the thesis of my bachelor’s, I presented another interesting app called Unifydmin. It’s a control center and administration panel for servers. It’s a very interesting project, but it’s still quite rough around the edges. I have to find the motivation to pick it up again, but right now I’m focused on another project.

And this project is Feeds, a feed reader. It may sound dumb, but I couldn’t find a single feed reader app for linux that I liked. Everything is either old, slow or electron based. After some time complaining about this (my girlfriend and friends can tell you about it), and basically using reddit and the podcasts I follow to get the latest news, I said F it, and made my own thing. It’s going pretty well and the people that tried it seem to like it, and that makes me actually very proud of it.

And I think that’s about it for now. I hope I manage to get my S together and start blogging more frequently, because I quite enjoy being able to share dev stuff online.

Let’s see where that goes.