The keyboard I purchased is a Keychron K8 Max with “Super Brown” - tactile - switches. The purchase was actually catalyzed by another purchase: my Commodore 64 Ultimate. It made me remember the feeling of high-quality, long-stroked keys, and caused me to look up what’s available on the PC side. Luckily, just when I was researching keyboards, I found this specific Keychron keyboard for about one third off MSRP, and decided to try it out.

I’ve had a cheap gaming keyboard with blue - clicky - switches for years, but it wasn’t much to write home about: Loud, cheap-feeling, but completely decent for its intended purpose, which was mashing keys in games without encountering rollover issues. Unsurprisingly, this keyboard feels radically different, from its physical heft, via the much nicer-feeling key surfaces and keyboard curvature, to the rewarding “thock” of the keys if fully depressed with some force.

The Commodore 64 Ultimate I mentioned earlier comes with linear switches (“Red” or similar). The tactile switches of the Keychron keyboard are relatively similar: strike the keys fast, and you probably won’t notice a lot of a difference, but if you work them slowly, you’ll feel a slight change in pressure a couple of millimeters down - that’s the tactile bit. Typing fast, you get a slightly muffled sound if you allow the keys to bottom out. That can be avoided with some practice by not depressing the buttons all the way, or at least already having slowed the finger movement down by the way the key hits its bottom position. The other, slightly lighter sound, comes from the keys returning to their upmost position. None of the noises is jarring: to me as a user, it becomes an almost meditative background sound when typing like this. I’d say this keyboard should be completely acceptable to your neighbors in an open office environment too.

Using the keyboard with a Mac

Compared to a canonical Magic Keyboard, the layout of the Control, Option and Command keys is a bit off: Since on the Magic keyboard they are inset by the width of an additional key (the Fn/Globe key to the left of the left Control key), I needed to spend some more time with the keyboard to see whether I’d get used to it or not. Could I get used to doing mostly with my pinky finger what I used to do with my thumb? It turns out about one working day was enough to get comfortable, if not fluent with the new key arrangement. Getting there included making some changes to the keyboard’s default configuration.

Using the Keychron Launcher web app, I made the Caps Lock key take over as a mode toggle, to give access to the keyboard’s second layer. I then mapped Del to the second layer’s backspace key - mimicking the functionality of Fn+backspace on the Magic Keyboard. I also mapped the arrow keys in Vim style (left, down, up, right) to HJKL on the second layer. Combined with the Shift, Option and Command keys, this means I don’t have to move my fingers over to the separate arrow keys and ins/del/home/end/PgUp/PgDn cluster in normal use. They’re still available, but not necessary.

The second thing that takes some getting used to with this keyboard, is using it alongside a Magic Trackpad. The latter is, of course, designed to be flush with the Magic Keyboard, while the Keychron K8 Max sits several centimeters higher, especially with its rear feet down. It’s more of a stretch, and I’m sure someone who was more bothered by the difference could 3D print a stand for the trackpad, to raise it to the level of the top of the keyboard, but honestly it’s not that bad, if you ask me.

In short, this keyboard turned out to be a joy to work on with the Mac.

Using the keyboard with a Linux PC

When switched to “Windows/Android” mode, the Keychron K8 Max behaves just like any standard PC keyboard. Alt and Windows key caps are included in the box, to replace the default Mac keys between the Control keys on either side, and the space bar. I would prefer a choice of OS agnostic meta keys, but Windows is undeniably the default choice on the PC side, so I guess I can’t complain too much about this. In PC mode too, the keyboard is programmable using the Keychron Launcher web app; utilizing the keyboard´s banks 2 and 3 rather than banks 0 and 1 that are used in Mac mode.

One thing that isn’t immediately obvious, is that the security model of Linux by default prevents software from making changes to the keyboard’s programming. The workaround is to either make the requested changes from the Mac, or to configure a udev rule for the keyboard:

First I created a file, /etc/udev/rules.d/99-keychron.rules; and then I filled it with the following information, partly based on the output of the lsusb command, and partly based on advice from a Kagi search:

KERNEL=="hidraw", SUBSYSTEM=="hidraw", ATTRS{idVendor}=='3434', ATTRS{idProduct}=="0a81", MODE=="0666", GROUP=="users", TAG+="uaccess", TAG+="udev-acl"

Then I restarted the udev service and forced it to re-read its rules:

sudo udevadm control --reload-rules && sudo udevadm trigger

After this, I could use the Keychron Launcher via a Chromium-based browser to update the keyboard configuration as I wanted: At this point I only added the same shortcuts to the keyboard’s upper memory banks that I already had for the Mac, as I think I’ll enjoy them.

Other notes

The Max model of the Keychron K8 has three connection types available: Wired via an included USB-C to USB A cable, wireless via a 2.4 GHz dongle - similar to what Logitech has done for many years - and wireless via Bluetooth, where the keyboard allows pairing with up to three different devices.

The 1000Hz polling rate - nice for gaming - is only available via wired or 2.4GHz wireless connections. Using Bluetooth, polling rate is lowered to one tenth of that: Still plenty for regular productivity use. The way I’ve set it up today, is I use the 2.4GHz dongle in my Linux gaming computer, and then I use two of the available Bluetooth connections for my private and work Macs respectively. I never use both Macs docked to my screen simultaneously, so there’s really no extra hassle switching the keyboard between them; and when I want to play a game, I flip the two mode switches on the left-hand side of the keyboard, and I’m ready to go.

Summary

The Keychron K8 Max was a very nice upgrade for my typing experience. It rewards sticking to good typing form, and I really enjoy the feedback it provides when I type on it. For a PC user, it can be used out-of-the-box with no changes required at all. A Mac user may use it as-is, but if you are a power user, accustomed to making the most of the keyboard on your laptop, or of the smaller model Magic Keyboard, you may want to slightly adjust some of its default behaviors.

This could turn out to be an expensive purchase, though: While this keyboard is perfect for my Linux gaming computer, I’m already toying with the idea of purchasing a more compact model for use with my Macs: I will keep experimenting with my writing form and with customizing the key maps to see what I can get away with: I don’t think I’ll want to live with the compromises of going all the way down to a 60-key keyboard like the Happy Hacking Keyboard, but you never know…

I couldn’t find any good resource describing the complete process, so I’ve documented my setup, and am sharing the documentation via my Projects page.

Happy monitoring!

Up until now, I’ve created my VMs as QCOW2 files in a single ZFS filesystem; e.g. all VMs have lived in /ssdpool/vmimages. The vmimages directory wasn’t a child ZFS file system to ssdpool, but a plain directory created by VirtManager once upon a time.

There are a couple good reasons to deepen the structure, though:

First of all, it simplifies rollbacks from snapshots as each VM lives in its own ZFS filesystem.

Second, VM storage can be assigned its own ZFS properties that fit with the type of data stored in it - though honestly that’s less of an issue for me, as I generally just use QCOW2 images, as I mentioned.

Third, it makes it possible to purge unused disk images from my backups before the end of my backup retention, serving as an improvement to my storage utilization in cases where I’m sure I won’t need the data again.

So how do I go about changing this behavior, then?

Creating ZFS file systems

The first step is to create a new ZFS file system under my ssdpool. I set up the existing structure when I had less experience with ZFS, and the vmimages substructure is actually just a directory in ssdpool, rather than being its own file system, as is the way I would set it up today.

I will create a new pool, ssdpool/vdisks. Then I will create separate ZFS file systems in this structure for each VM and migrate them into their new home.

As described by Jim Salter in a Klara Systems article on ZFS recordsize tuning, the QCOW2 images I use for my virtual machines should work best with a recordsize parameter that coincides with the native block size of the QCOW2 image; 64KB.

sudo zfs create ssdpool/vdisks -o recordsize=64K

We can verify that it went well:

$ sudo zfs get recordsize ssdpool/vdisks
NAME            PROPERTY    VALUE    SOURCE
ssdpool/vdisks  recordsize  64K      local
$

At this point it is prudent to set the correct permissions on the new file system for KVM:

sudo chown -R libvirt-qemu:kvm /ssdpool/vdisks

Child file systems will, by default, inherit ZFS properties from their parents, so to create a filesystem for one of my virtual machines shouldn’t require me to explicitly define the record size. Let’s test that hypothesis:

sudo zfs create ssdpool/vdisks/testsrv1
sudo zfs get recordsize ssdpool/vdisks/testsrv1
NAME                        PROPERTY    VALUE    SOURCE
ssdpool/vdisks/testsrv1     recordsize  64K      inherited from ssdpool/vdisks
$ 

Perfect. this simplifies our future VM creation.

Migrating KVM virtual machines

Changing the storage path for a VM seems to require the following steps:

• Shut down the VM
• Move the VM files to their new location
• Edit the VM to find its files in their new location
• Start the VM back up

Let’s do this.

sudo virsh shutdown testsrv1

Then we wait until the machine has shut down:

$ sudo virsh list --all
 Id   Name                      State
------------------------------------------
 -    testsrv1                  shut off

We move the VM virtual disk(s) to its new home, and ensure the permissions are correct:

sudo mv testsrv1.qcow2 /ssdpool/vdisks/testsrv1/
sudo chown libvirt-qemu:kvm /ssdpool/vdisks/testsrv1/testsrv1.qcow2 

We edit the virtual machine to update its disk location:

virsh edit testsrv1

In the file, we locate the disk block(s) and update the path found in the source file XML block, and then save and exit the editor.

Finally we start the VM again, and hopefully we haven’t messed anything up:

virsh start testsrv1

Of course migrating the VM is only the most visible step of this change. We’re not done until we have confirmed our backups. Let’s revisit that in the next post.

I use Sanoid and Syncoid for this purpose. Let’s see how that may look.

Primary backup

My backup strategy is multi-pronged. I take frequent snapshots of the file system where my VMs live. This is convenient for oupsies, but of course doesn’t protect me should a catastrophic storage failure occur. Snapshots and the eventual cleanup of them are managed by Sanoid.

The relevant parts of my /etc/sanoid/sanoid.conf:

[ssdpool]
        use_template = ssdpool
        recursive = yes
        process_children_only = no

[template_ssdpool]
        frequently = 0
        hourly = 36
        daily = 30
        monthly = 0
        yearly = 0
        autosnap = yes
        autoprune = yes

We can see that the ssdpool file system gets recursive snapshots every hour plus daily. Thirty-six of these hourly snapshots are kept, and then I keep 30 of the daily snapshots on the primary storage.

In every step, I can verify that this actually works by listing ZFS snapshots:

sudo zfs list -t snapshot

Secondary backup

To protect against pool failures, I have a secondary pool in my hypervisor host, set up for backup storage. I call Syncoid from cron for this purpose.

This is handled by this part of my /etc/cron.d/syncoid:

02 * * * * root syncoid -r --no-sync-snap --compress=lzo --quiet ssdpool backuppool/ssdpoolbackup

On the second minute of every hour of every day, I recursively send ZFS snapshots from ssdpool to backuppool/ssdpoolbackup.

Of course, I also have to ensure the backup volume doesn’t fill up with snapshots. Sanoid to the rescue again:

        
[backuppool/ssdpoolbackup]
        use_template = backuppoolssd
        recursive = yes
        process_children_only = no

[template_backuppoolssd]
        frequently = 0
        hourly = 36
        daily = 30
        monthly = 0
        yearly = 0
        autosnap = no
        autoprune = yes

For backuppool/ssdpoolbackup I don’t create new snapshots, but I keep the same pruning configuration that I have for the primary snapshots.

Tertiary backup

Finally I have a completely separate physical server where I store an additional copy of my backups. This one is configured to connect to the primary server and fetch snapshots, again using syncoid. This way of doing things makes it slightly harder to mess things up on the backup server from the primary server.

The cron configuration line for syncoid on this machine looks like this:

20 * * * * root syncoid --sshkey=/root/.ssh/syncoid -r --no-sync-snap --compress=lzo --quiet syncoid@prodsrv1:backuppool/ssdpoolbackup backuppool/prodsrv1/ssdpool

It’s very similar to the one running on the main server, but fetches the snapshots from the backup pool on the main server over an ssh tunnel, and then stores them in a local backup pool. As you see, I’ve given it a delay of a few minutes compared to the crontab on the main server, so in most circumstances we should manage to have the backup copy done in a timely manner for minimal data loss in case of an issue.

Of course here too, I make sure to clean up snapshots to avoid filling the disks over time:

[backuppool/prodsrv1/ssdpool]
        use_template = backupssd
        recursive = yes
        process_children_only = no
        
[template_backupssd]
        frequently = 0
        hourly = 36
        daily = 90
        monthly = 0
        yearly = 0
        autosnap = no
        autoprune = yes

The only big difference to the primary and secondary backup copies, is that I store daily snapshots for longer on the backup server.

Testing backups

To verify that the backup works, we can perform a small experiment: I have an otherwise empty VM, where I’ve simply created a text file in my home directory:

$ echo Test > is_this_file_gone.txt
$ cat is_this_file_gone.txt
Test

After waiting for a snapshot to be made, I remove the test file:

$ rm is_this_file_gone.txt
$ cat is_this_file_gone.txt
cat: is_this_file_gone.txt: No such file or directory

Now let’s restore the VM from my tertiary copy. If that works, we know that the intermediate backup routines work too.

From my backup server, I will send the snapshot back to the production machine, then see if I can start the VM from the snapshot.

First we find the relevant snapshots:

$ zfs list -t snapshot
NAME                                                                                 USED  AVAIL  REFER  MOUNTPOINT
backuppool/prodsrv1/ssdpool/vdisks/testsrv1@autosnap_2025-11-16_11:00:25_daily         0B      -    96K  -
backuppool/prodsrv1/ssdpool/vdisks/testsrv1@autosnap_2025-11-16_11:00:25_hourly        0B      -    96K  -
backuppool/prodsrv1/ssdpool/vdisks/testsrv1@autosnap_2025-11-16_12:00:25_hourly        0B      -  2.84G  -

Now let’s take a specific snapshot and send it back:

sudo syncoid --sshkey=/root/.ssh/syncoid \
    -r \
    --no-sync-snap \
    --compress=lzo \
    --include-snaps=autosnap_2025-11-16_12:00:25_hourly \
    backuppool/prodsrv1/ssdpool/vdisks/testsrv1 \
    syncoid@prodsrv1:ssdpool/restoretest

To test the contents of the snapshot non-destructively, on the main server, we’ll stop the VM, move its expected disk image out of the way, and copy in the disk image we pulled from our backup.

cd /ssdpool/vdisks/testsrv1
sudo virsh shutdown testsrv1
# After waiting for the VM to stop:
sudo mv testsrv1.qcow2 testsrv1.qcow2.actual
sudo cp --sparse=always /ssdpool/restoretest/testsrv1.qcow2 ./
sudo virsh start testsrv1

Once the machine starts up, we can test our backup:

$cat is_this_file_gone.txt
Test

As we’re happy everything works, we clean up the VM directory and restart the machine

sudo virsh shutdown testsrv1
sudo rm testsrv1.qcow2
sudo mv testsrv1.qcow2.actual testsrv1.qcow2
sudo virsh start testsrv1

I always like to perform a dry-run before running destructive ZFS changes:

$ sudo zfs destroy -nvpr ssdpool/restoretest
destroy	ssdpool/restoretest@autosnap_2025-11-16_12:00:25_hourly
destroy	ssdpool/restoretest

This looks like exactly what we want to do. Remove the n argument to execute the command:

sudo zfs destroy -vpr ssdpool/restoretest

And that’s it, really. I’ve confirmed that snapshots work and that I can restore them.

Personally, however, I’m a heavy user of bookmarks, at least for work purposes, and I’ve long been arranging them by category and subcategory. After the Safari 26 update, my logically arranged tree was a complete mess.

In the default view there are three usability issues:

• Actual bookmarks are a completely different size and format from folders.
• Folders and bookmarks are separated.
• The folder tree is invisible - you only see the folders and bookmarks that exist inside the specific folder where you currently are.

I have good news and bad news: The bad: I think this is unfixable in macOS 15, so if you’re stuck on that version, you’re probably SOL. The good: There’s a workaround in macOS 26.

There are two steps required to make the Bookmarks menu become readable again:

• Via the ellipsis menu, select Compact view to make bookmarks not stand out as a sore thumb.
• Via the ellipsis menu, un-select Show folders on top, to restore the tree view.

This doesn’t preclude the ability to search bookmarks, which is good, but it allows you to visually identify categories again even if you have more than a handful of bookmarks and more than one level of folders.

Please keep in mind that I’ve been ignoring my own advice to run a system the way its creators intended, and I’ve been using it with Gnome rather than with Plasma, so what I say here may not necessarily be valid if you choose the default desktop environment.

Compared to Fedora, which is very Gnome-centric, openSUSE clearly wants you to use the various tools provided under the YaST umbrella to manage the machine and its installed software. The tools clearly have been thought through, and being GUI tools, they provide a lot of discoverability to a new user. However, there’s always the feeling that they’re rooted in the UX mindset of late nineties/early noughties Microsoft. Think of a setting and you’ll probably find it, but first you need to find the right YaST sub-program.

Compared to Fedora’s Gnome Software interface, the YaST software installer is clearly superior at providing an overview of what’s installed and what will be installed to fulfill the dependencies if you add another software package to your computer. The issue is that again, the experience is.. practical? Definitely. Nice? Not really. Add to this that the SUSE software manager has no integration at all with Gnome Software, and you get weirdness like Gnome notifying you that there are software updates available, but when you click the notification, Software opens and tells you there are no updates to be had.

Weirdly, if you search for update, one of the early hits is the YaST2 online_update tool. That doesn’t show any available patches either. If you by chance open YaST2 Software Management, you can install new software, but there’s nowhere there to update installed packages. So down to the terminal we go, and then we need to know that zypper update and zypper dup (“dist upgrade”) are distinct functions, and while you’re warned against using the dist upgrade command on “regular” SUSE, on Tumbleweed, conversely, you may apparently see negative consequences if you happen to try a regular update rather than a dist upgrade for keeping your system updated.

All in all, I see how for someone who came from Windows to Linux, SUSE - and especially SUSE with the Plasma desktop environment - could be of help in extending their comfort zone to include a discoverable and serious-feeling Linux distribution. But after a couple of weeks of usage, I have a hard time seeing where it would improve my own life. And as I’ve alluded to in both this post and in a previous one, this system isn’t exactly user friendly enough that I would recommend it to a novice Linux user either. So what am I missing? Who is it for?

A while back I had an out-of-band discussion with a visitor to this website, where he pointed out that the procedure I had documented in my previous article on triggering a Jekyll build via a Git hook on FreeBSD didn’t really work anymore. I couldn’t replicate the issue with my setup, so although the report was valid, I didn’t follow up on my own server at that time.

Unfortunately, the underlying issue seems to do with a) how FreeBSD handles Ruby, and b) how specific Jekyll dependencies in Ruby seem to be built only for Linux nowadays. As could be expected, a recent update to Ruby on FreeBSD broke the Jekyll builds on my Git forge.

Possible solutions

From where I was, I saw two immediate ways forward: I could set up a new Forgejo server on some common Linux operating system, or I could set up a Linux based Forgejo runner instead of using Git hooks. And then @mpts pinged me a comment:

When it comes to the Linux-only SASS library, a solution might be to run it with #Linuxulator on #FreeBSD.

I had read about the Linuxulator but never implemented it before, and this sounded like a fun way to spend a Saturday, so I decided to attempt this approach.

Implementation steps

First off, I simply followed the instructions for installing the Linuxulator in the FreeBSD handbook. I elected to use Ubuntu, and of course chose Jammy (22.04 LTS) rather than Focal (20.04 LTS), as the latter is EOL. I would have preferred to use 24.04 simply for not having to touch the solution again in a while, but it isn’t yet supported by the Linuxulator.

I fixed the FreeBSD server’s /etc/fstab as per instructions, and of course made the necessary changes to the apt config in the Linuxulator environment.

The next step was to chroot into the Linuxulator environment and install the necessary packages:

• build-essential
• git
• ruby
• ruby-dev

I also copied the lines for the git user and group from the FreeBSD machine’s /etc/passwd and /etc/group into the corresponding files in the Linuxulator environment.

The next step was to create a home directory for the git user and populate it so that my git hook script (see further down) would work.

At this point, though, the Linuxulator could only be used as root, and that’s unworkable, for the very obvious reason that the Git hook script will run as the git user - and of course because it will be executing the Ruby bundler, which isn’t happy running as root.

To allow non-root users to chroot, I added the following line to /etc/sysctl.conf.local:

security.bsd.unprivileged_chroot=1

My current post-receive git hook for the website repo looks like this:

#!/usr/bin/env sh

export WEBSERVER=websrv2.oxcrag.net
export PRE_CHROOT_HOME=/compat/ubuntu/usr/local/git
if [ ! -d $PRE_CHROOT_HOME/tmp ]; then
    mkdir $PRE_CHROOT_HOME/tmp
fi
export PRE_CHROOT_TMP_GIT_CLONE=$PRE_CHROOT_HOME/tmp/oxcrag.net
export POST_CHROOT_PUBLIC_WWW=$PRE_CHROOT_TMP_GIT_CLONE/_site
# Verify target dir is really empty
rm -Rf $PRE_CHROOT_TMP_GIT_CLONE
git clone $GIT_DIR $PRE_CHROOT_TMP_GIT_CLONE

chroot -n /compat/ubuntu bin/bash -c '

export HOME=/usr/local/git

# Install Ruby Gems to ~/gems
export GEM_HOME=$HOME/gems
export PATH=$GEM_HOME/bin:$PATH

TMP_GIT_CLONE=$HOME/tmp/oxcrag.net
GEMFILE=$TMP_GIT_CLONE/Gemfile
PUBLIC_WWW=$TMP_GIT_CLONE/_site
gem install bundler --no-document
BUNDLE_GEMFILE=$GEMFILE bundle install
BUNDLE_GEMFILE=$GEMFILE bundle exec jekyll build -s $TMP_GIT_CLONE -d $PUBLIC_WWW

exit
'
if scp -r $POST_CHROOT_PUBLIC_WWW deployer@$WEBSERVER: ; then 
    echo "Website deployment finished"
else
    echo "Website deployment failed"
    exit
fi

rm -Rf $PRE_CHROOT_TMP_GIT_CLONE
exit

Background

While I’m more or less fluent across the Debian derivatives, RHEL derivatives, and FreeBSD, I have never really used a SUSE Linux, despite the company being based here in Europe where I live.

Since Fedora is my normal choice, I figured the rolling release of openSUSE, Tumbleweed, would make the best comparison and what I would use if I was to switch.

I’ve been involved in some discussions regarding the novice friendliness and usability of Linux based operating systems related to the upcoming end-of-life of Windows 10, and I thought I’d try to approach this operating system from that perspective.

Installation

openSUSE is surprisingly hard to find. A web search for “suse” on DuckDuckGo shows the Wikipedia article for the company, and the web site for the commercial SUSE Linux Enterprise offerings. These are of course utterly pointless for a hobbyist wanting to set up a regular laptop. You need to know that what you’re looking for is called openSUSE.

Once past that hurdle, downloading the distribution and writing it to a USB stick is comparable to any other Linux distribution: Not something you’d expect just anyone to manage or even want to do, but not so hard that it would scare off a technically minded 13-year-old. I consider the first choice on any page to be the default one that most people should take, and on the openSUSE web page, Tumbleweed is that choice.

Once booted, the installer is graphical, so shouldn’t scare anybody away. Most default choices seem to be sane, but I would like to see two main changes to the installer:

• The first screen, where you choose your network settings is not intuitive. You have to highlight your preferred network connection and then click on a separate key to edit its settings. Also, setting your machine’s hostname is a completely separate flow. Nobody who understands a bit about networking will have any issues completing the task, but there definitely exists a happy-path here that the installer could guide you through rather than forcing you to discover the various options on your own.
• The default disk partitioning flow has good defaults, but I miss a choice for full-disk encryption without having to dig down into the advanced settings. Also there was no easy way to manually make changes like resizing existing partitions or similar and then get a new disk layout recommendation based on the new configuration. This is less of a problem, though, as I would expect most who install a system like this would perform a clean install of a single system.

Out-of-the-box experience

I know that SUSE has traditionally been a Plasma (KDE) Linux distribution in the same way Red Hat has defaulted to Gnome. But since I do prefer Gnome, and the installer provides Gnome as its second option, that’s what I opted to use. This means I can’t speak for the Plasma user experience for someone who starts openSUSE Tumbleweed, but in Gnome, a novice is left with very little help. There is a welcome screen, but it completely fails to guide the user to YaST - arguably SUSE’s big selling point - even for someone who knows to search for it.

Searching for Software brings up the Gnome Software app, which in this distribution only seems to be an interface for installing Flatpak apps. The next search hits are two instances of YaST Software ... which is abbreviated so the user is left to guess what each program does, and two instances of Myrlyn with no further explanation. Again, for a novice, this is not discoverable, and not a great initial user experience.

Final thoughts

I already like Tumbleweed as a Gnome-based operating system. The team behind the operating system seem to have done a very good job in many of the areas that you’re likely to care about over time. I like that they’ve seemingly implemented a variation of the FreeBSD style boot environment concept in Snapper, made possible thanks to BtrFS snapshot capability. I would frankly prefer to see more distributions than Ubuntu take ZFS seriously, but this at least goes some of the way - and further than you’d get out-of-the-box with Fedora or Ubuntu.

Again, I don’t know how the Plasma first login experience looks in Tumbleweed, but what I saw from Gnome is very likely to scare new users off - completely unnecessarily. There’s not a whole lot needed, but explain the benefits of YaST, provide a big honking icon pinned to the dock, and announce its presence and general usefulness via the Welcome screen.

I’m not sure whether it’s just my narrow social circle, but SUSE just doesn’t seem to have the mind share of Ubuntu or Fedora, and having tried it, I don’t really see why not. Again, there’s some work to be done in the new user experience, but I really think openSUSE should be more popular than it seems to be. The next time you’re bored with your operating system and want to shake things up a bit, try it out!

Turns out the fix is very similar to the one for Fedora. Just add the following line to your /boot/loader.conf:

hw.i915kms.enable_psr=0

This turns off a feature called Panel Self-Refresh which seems buggy on this computer.

I used Virtual Machine Manager to edit the XML of one of the problematic machines, and located the relevant section:

<type arch="x86_64" machine="pc-q35-4.2">hvm</type>

Next question was what version to choose. I tried the kvm command on the hypervisor and quickly found the correct parameters to use, and then also the answer to my question:

$ kvm -machine help
Supported machines are:
(...)
q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-6.2)
(...)

I replaced the relevant part of the VM definition XML, changing the machine part:

<type arch="x86_64" machine="q35">hvm</type>

Upon applying the change, the line auto changed into the expected pc-q35-6.2.

The VM had to be fully stopped and restarted for the change to apply, but after that, it could soft reboot from the command line with no issues, so I performed the same change to the other VMs that had the same problem.

The real test will be to see how they behave after the next unattended upgrade, but so far so good.