Fedora 33 mini-review on the Blackbird and Talos II
We test it on both the Blackbird and Talos II, for which T2 Lite owners will have a similar experience. However, one important configuration change for this review compared to my previous go-around for F32 is that I'm no longer running gdm on the Blackbird either (I've never run it on the T2). This was largely an accident of a F32 reinstall I did, where I installed the server variant and converted it to Fedora Workstation, same as I had originally done for my T2 back with F28. In this setup the system comes up in a text boot, you log in that way, and then manually startx or dbus-run-session gnome-session (with XDG_SESSION_TYPE=wayland or as appropriate) to launch GNOME. Besides speeding startup a bit, you avoid pitfalls with a graphical start and can much more easily recover without having to do an emergency boot into the installer. This and future reviews of Fedora will be done in this configuration which just eliminates a whole class of issues I used to have on the Blackbird in particular.
As before, the general upgrade steps are
sudo dnf upgrade --refresh # upgrade DNF
sudo dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
sudo dnf system-upgrade download --refresh --releasever=33 # download F33 packages
sudo dnf system-upgrade reboot # reboot into upgrader
When the system reboots, manually select the kernel directly from Petitboot to get a more verbose boot rather than just waiting for it to automatically start. This let me watch the install in text mode for a change. If you don't do this, your system may go to a black screen; pick another VTY with CTRL-ALT-F2 or something, log in as root and periodically issue dnf system-upgrade log --number=-1 to watch the hot hot action.
The Blackbird is my "early warning" system to catch bad updates before I tank this daily driver T2. However, perhaps because it has a vanilla install of F32 on it, it updated without any problems whatsoever, and all applications that I usually use on it (Firefox, LibreOffice, etc.) ran without issues under Xorg in 1920x1080 with the usual manually specified xorg.conf. I didn't notice much performance improvement or change, but nothing seemed to regress particularly either.
I also usually do a token test of Wayland on the Blackbird as well, which because I run it "stripped" with no GPU and with only the BMC as a framebuffer, is invariably an unusable catastrophe. But, to my surprise, not this time:
I'm a Never Wayland and I acknowledge my biases, but there has been clear improvement in its useability without a GPU, which right now is essential to run these systems "fully libre" (or at least as cheaply as possible). I suspect the LLVM update is responsible and sufficiently juices llvmpipe accordingly, but regardless of the reason the system was much more responsive and all default applications seemed to work.What didn't, though, was the screen resolution, which remained stuck at 1024x768 because support for the Blackbird's HDMI transceiver is still not in the shipping kernel. I grabbed edid-generator and tried making an EDID out of the known-working Xorg modeline, which was ignored at bootup and dmesg said it didn't even load:
platform VGA-1: Direct firmware load for edid/bmc.bin failed with error -2
(Yes, the port name is VGA-1, despite being connected over HDMI.)
I also tried video=VGA-1:1920x1080@60e on the kernel command line and while the text boot obligingly came up in 1920x1080, when I started the GNOME session it just hung and never jumped to the graphic display, so back to Xorg. But credit where credit is due that it's getting better, whether Wayland or LLVM is responsible for the improvement.
The T2 is more complex because I have a lot more packages installed and a somewhat customized GNOME theme. Although I lost a few packages in F32, no packages were broken or needed to be backed out for F33, and the 5.0GB installation proceeded uneventfully. With fast reboots off it also properly restarts as well.
Restarting into the new installation for the first time is usually where the problems start, though, and that's what happened again this go-around. The first problem was a crapload of SELinux warnings over and over, which turned out to be another permissions clash and was eventually fixed with a restorecon -RFv /var/lib/rpm after a lot of totally family friendly cursing. The second problem is the usual GNOME extension breakage as F33 moves from 3.36 to 3.38; Dash-To-Dock again refused to update and had to be manually reinstalled from the command line as well as User Themes. However, my hacked version of Argos survived without any changes. The drag-to-reorder feature new in 3.38 mostly works as advertised, though I'm used to apps moving to close the gap and that didn't seem to happen, but I do like the changes to Screenshot.
On the T2's BTO WX7100 GPU, GNOME 3.38 under Xorg was nice and snappy as always. I didn't notice really any performance improvement, but it seemed no worse either. Wayland did improve in this iteration and the games it used not to launch now seem to start properly under Xwayland, but it seemed a little less sprightly this time. Likewise, I'm highly reliant on appmodmap for my muscle memory which won't work with any current Wayland compositor, and while GNOME's new ability under Wayland to run multiple displays at different refresh rates is a nice new feature, I don't need it for my two displays. So back to Xorg. (If maintaining Xorg is such a paper cut with hydrochloric acid on it, then why don't we use Wayland for the low-level display stuff and just run everything in Xwayland on top of it? Why must we throw the baby out with the bathwater? I like all the hacks X lets me do.)
Anyway, F33 was a largely uneventful release and I consider that a positive: while the normal little polish issues are still there it didn't seem to require pulling more teeth than usual and overall has been working well for the last couple days. What I really want, though, is for 128-bit long doubles to finally arrive and I'd really like to see a push for this in F34. Me personally I'm tired of having to hack MAME all the time just to play the same games my G5 can with MacMAME, but there are more practical and less first-world-problemy concerns for needing this feature as well. And it would really be a boon to the platform if we weren't still stuck in the Alternative Architectures penalty box every time too.
Maybe an idea for further review would be runing some Blender rendering as benchmark? It seems to be popular test on mainstream multicore CPUs.
ReplyDeleteI don't mind doing that, but is that a Fedora question, or more a general POWER9 performance question?
DeleteMight be both. It's up to you. I think both aspects may found their readers. I'm Debian guy myself.
Delete