Monday, June 27, 2022

Guide: Setting up zswap

This is a guide to setting up zswap on Linux-based operating systems. What is zswap and why should you use it? Zswap is a way of giving your computer additional virtual memory, like increasing your RAM. It is very useful for systems with low RAM (< 8 GB) and quite useful even for systems with more RAM. This guide will show you how to setup zswap with the lz4 compression algorithm, which is very fast. But first, to answer some questions.

Warning for BTRFS users: read the wiki before creating a swapfile. It is easier to use ZRAM instead.

Does this come with a performance penalty?

There is no such thing as free lunch – compressing and decompressing pages in virtual memory will tax your CPU. However, using compressed memory is faster than swapping to an SSD, and orders of magnitude faster than swapping to a spinning hard disk. It is also better than running out of memory, which results in either your system locking up or the out-of-memory killer killing some important process. As oom killers are not very intelligent, it is wise to avoid this.

Note: there is no performance penalty until you actually start swapping, just so we’re clear.

What about ZRAM?

ZRAM is good too; I have used it. But zswap does not compress pages which are incompressible, instead sending them to your swap file. This is a good thing, as it avoids wasting CPU cycles compressing pages that are not compressible anyway. ZRAM is good for hard disk or SD-backed computers; I feel zswap is more appropriate for SSD-backed devices as swapping to an SSD is not such a big problem.

Step 1

Note: run all the commands below in the terminal, copying them one line at a time and hitting enter. Make sure they are copied correctly.

First check if you have a swap file by running free -h. If you do have a swap file, continue to the next step. Otherwise run the code below.

sudo su
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' | tee -a /etc/fstab

Step 2

Note: the following assumes are you are using grub. PopOS users should follow the instructions here.

Run sudo nano /etc/default/grub and edit the line GRUB_CMDLINE_LINUX_DEFAULT to read:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=50 zswap.zpool=z3fold"

What does the max pool percent variable mean? This refers to the maximum % of your RAM that will be taken up with compressed storage. It is dynamically allocated, so it doesn’t take up any space until you actually start using it. For most systems, 50% is a good maximum. For really low memory systems, you can try 70%. Anything higher will make the system unusably slow (Google has actually benchmarked this for Chrome OS).

Save your changes (type Ctrl+X and type y and then enter). Now run:

sudo update-grub

Step 3

Run the following:

sudo su
echo lz4 >> /etc/initramfs-tools/modules
echo lz4_compress >> /etc/initramfs-tools/modules
echo z3fold >> /etc/initramfs-tools/modules
update-initramfs -u

You are done! Reboot and run cat /sys/module/zswap/parameters/enabled. If zswap is working, you should see a Y printed.

Sources

LKML

Linux Kernel Documentation

Make Tech Easier

IBM

Guide: Using gpu-screen-recorder with your NVIDIA GPU

GPU screen recorder is an awesome open source program that allows you to record a window or screen using NVENC, a technology specific to Nvidia cards that is used to encode video without using the CPU. This is extremely useful for any low-spec PC, and you would otherwise need a very powerful multicore processor to be able to game and record at the same time – especially if you game at 4K. Furthermore, this tool records in h.265, a very bandwidth efficient compression algorithm that does wonders for your disk space.

Why not OBS?

Gpu screen recorder uses less CPU, and does not harm your fps, unlike OBS. It also feels smoother, with less stuttering. This is because OBS has to copy frames between the host and device; whereas GSR uses CUDA and runs entirely on the GPU. Furthermore, I’ve experienced a lot of difficulty getting OBS to record in h.265 (I believe OBS depends on ffmpeg which may not be packaged correctly for your distribution).

Is Wayland supported?

Not as far as I know. I attempted to run it on the Plasma Wayland session but was unable to get it to work.

Does it work with PRIME?

Yes, but it can only record a window. Make sure your game is running in borderless window mode instead of true fullscreen.

Installation guide

If you are on Arch, install the AUR package of the same name. Else, clone the git repository with git clone https://repo.dec05eba.com/gpu-screen-recorder. Make sure to install git if it isn’t already installed (sudo apt install git on Ubuntu). Also install xdotool if it is not already installed, using your package manager.

Change to the newly created directory. If you are an Ubuntu user, run sudo ./install_ubuntu.sh Otherwise you will have to install the dependencies yourself and compile the program.

Now, go to this Github link and select Code -> Download ZIP. PRIME users, SKIP this step. Extract the archive, then run sudo ./patch-fbc.sh.

Usage

To record the whole screen:

gpu-screen-recorder -w "screen" -c mp4 -f 60 -a "$(pactl get-default-sink).monitor" -o test_video.mp4

You may replace test_video.mp4 with a more useful name.

To record a window:

gpu-screen-recorder -w $(xdotool selectwindow) -c mp4 -f 60 -a "$(pactl get-default-sink).monitor" -o test_video.mp4

Make sure to start the game beforehand and select its window by clicking on it. Note: xdotool can only see XWayland windows, not native Wayland windows. And I haven’t tested it with Gamescope yet.

Why does this guide exist?

Because documentation is scarce and it took me a lot of time to setup. Also, a lot of people don’t know this tool exists, and may be struggling with OBS.

Monday, June 20, 2022

The Problem with Manjaro/Arch

I have been using Manjaro for about a year. My initial love for Manjaro came about because of three things. One, it made the installation of the Nvidia driver as painless as possible – by allowing you to boot directly using the binary driver and avoiding the need to mess with nouveau and nomodeset (looking at you, Fedora).

Two, Manjaro ships the latest Linux software in its repositories. This is a welcome change from Ubuntu or Debian; the packages in the repositories can be badly out of a date on an Ubuntu LTS, and even the latest Ubuntu might run a version or two behind. Related to this, I am shocked by how many packages in the Ubuntu repositories just don’t work. For example: Back In Time, a popular backup tool, does not work on the latest Ubuntu 22.04.

Thirdly, Manjaro also ships the latest releases of various desktop environments, allowing the user to try out different UIs if they don’t like the one they started with. (Or because they wanted to find out which DE actually supports fractional scaling properly… signed, yours truly.)

Alas, it was not to be. A few days ago, the Manjaro install on my Nvidia-powered desktop PC imploded after I upgraded using pamac. I do not mean to say that something was broken after an update; I mean to say that the pamac froze halfway through, and rendered the entire system unrecoverable. Firefox stopped working. KDE wouldn’t respond to mouse and keyboard input. After a force restart, I was left with an unbootable system with no kernel.

This tells us a few things. Firstly, pamac is a horrible program. But these were not the only issues that troubled my Manjaro experience. For example, GPG signature errors are depressingly common on both Arch Linux and Manjaro.

Another problem, inherent to the very design of pacman/Arch Linux, is that you cannot perform partial upgrades safely. Need to grab a small package/program in order to accomplish a task? You may well have a multi-gigabyte update that needs to be applied first, with a real risk of bricking your system, as I found out when I innocently tried to install a 100KB package.

Furthermore, if the update command pacman -Syu fails, it will not fail gracefully like on, say, Fedora, where dnf will rollback the transaction. No, it will leave your system in the before-mentioned partially upgraded state. From the Arch Wiki:

Note that if pacman -Syu does not perform the upgrade because of an error, the end result is the same as running pacman -Sy. Therefore, the error must be resolved and the upgrade operation completed as soon as possible.

Yikes!

In fact, the more I read about pacman, the less I like it. Common operations lack human-readable names, like -Syu instead of dnf update or apt’s update && upgrade. Pacman is not designed to keep multiple versions of a library installed, which causes conflicts if program X needs library version 0.12 but program Y needs version 0.13. (It is possible to fix this manually with various solutions like LD_LIBRARY_PATH, symlinks, chroots etc, but nothing user-friendly.) Contrast this to Flatpak, which can not only keep multiple runtimes installed, like org.Gnome.Platform 41 and 42—but deduplicate them as well.

It is my opinion that these technical problems render the very idea of a user-friendly Arch distribution like Manjaro or Endeavour laughable. Updating is just too dangerous, especially since many users like to install a lot of programs. I am guilty of this as well.

The AUR

There are three problems with the AUR. Firstly, it is insecure because anyone can publish a package there. Secondly, a lot of AUR software is distributed in source form, which takes ages to compile — and might fail. The third Manjaro-specific problem is that since Manjaro holds packages back for two weeks, this can cause AUR programs to fail because the system is not up-to-date enough.

The sad reality is that a lot of software is missing from the Arch repositories and the AUR is the only convenient way to get this software. Who wants to fiddle around with alien or compile software manually?

So what’s the alternative?

Flatpak is the best package manager I have ever used. It will never brick your system (it doesn’t mess with system files); it handles dependency conflicts and deduplication beautifully; it just works! About the only bad things I can say are that sometimes, I have to use Flatseal to change permissions, and there are some small theming issues.

But not every program can be distributed as a self-contained Flatpak. So what Linux should I use for the base system?

Currently, I am using Kubuntu on the desktop because it distributes a recent kernel, allows easy installation of the Nvidia driver, and has reasonably up-to-date packages. But some packages are still out of date—KDE software, ironically enough. I also think the apt package manager could be improved. Maybe I should try aptitude.

But is there really an alternative to the Ubuntu/Mint/Pop world?

  • Fedora KDE: The live session froze before it even got to the installer. The problem is that they made Wayland the default on KDE, which does not work with the nouveau drivers. (Fedora refuses to ship the Nvidia binary drivers or patent-encumbered codecs.) This does not inspire confidence in the level of QA and testing that went into the distro.
  • OpenSUSE Leap: too out of date.
  • OpenSUSE Tumbleweed: I’ve read mixed reviews on this one. It pushes updates really, really frequently. No human QA goes into it, only automated QA – and even a really good automated system like openQA can’t replace humans. Arch at least has humans testing its packages. Even with its fancy btrfs snapshots, I am not adventurous enough to try it.

The only alternative to Ubuntu I would consider is a Fedora with sane defaults. But then, I guess there’s a reason Ubuntu and its deriatives have been more popular than Fedora and Arch for a very long time.

EVs are not the future—hybrids are

There has been a wild surge in optimism in EVs—really, a kind of hysteria—with the EU and UK governments hoping to ban combustion engines in...