Fedora 34 XFCE: Are miracles still possible?
After a story from my times with Fedora, as Béranger, and after a previous hint at Fedora (“Maybe it’s time to rediscover Fedora and the RPM-land, after all these years of looking elsewhere.”), it was time to spend a couple of days with it. Despite what some people might believe to be the future, I don’t intend to touch Fedora Silverblue yet, but a Workstation live installable Spin, namely XFCE.
In the good old times
In the good old times, I liked
yum, and I loved YumEx on both Fedora and CentOS. This is how YumEx looked liked circa 2005, in version 0.99.x, although the “new” YumEx with versions like 1.9.0-1.9.2 wasn’t much different:
Now, here’s the thing. Not having followed the evolution of Fedora since DNF replaced
yum, I have found contradictory info:
- There was an even newer “NG”
- No, there wasn’t anymore,
dnfdragorakilled it. There was a bug report meant to track a change request in 2007, for Fedora 27. So
yumex-dnfwasn’t anymore in active development.
- Hey, but yumex.dk, despite being frozen since 2015, points to the
yumex-dnfCopr repository, which includes recent builds for Fedora 34!
So it’s not dead. By some miracle, the development of YumEx started one more time!
Back to the future
May 6, 2021, after having used
xfce4-panel-profiles to switch to a Windows-like bottom panel:
sudo dnf copr enable timlau/yumex-dnf sudo dnf install yumex-dnf
But YumEx is ugly, especially its colors; by the way, the color codes aren’t obvious:
As I’m not brain-dead yet, I’ve found what they mean:
/*Package Type Colors */ @define-color color_install @Material_Indigo; @define-color color_update @Material_Pink; @define-color color_downgrade @Material_Lime; @define-color color_normal @Material_Orange; @define-color color_obsolete @Material_Green;
Next surprise: no GUI wrapper for
systemctl, despite it being a Red Hat technology! Abandoned GUI tools throughout Linuxland include systemd-ui, SystemdGenie, kcmsystemd. The only viable solutions are the Web-based cockpit, included in Fedora, and the ncurses-based chkservice, for which another COPR (Fedora’s equivalent of a PPA) must be added:
sudo dnf copr enable srakitnican/default sudo dnf install chkservice
chkservice has another set of stupid colors, and some unintuitive symbols reflecting a service’s status:
Ridiculous, but somewhat usable.
Let’s not forget RPM Fusion:
sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm sudo dnf install rpmfusion-free-release-tainted sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin sudo dnf groupupdate sound-and-video sudo dnf install libdvdcss
I’m not sure I need all of this:
sudo dnf groupupdate multimedia --setop="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin
sudo dnf groupupdate sound-and-video
sudo dnf install libdvdcss
Still to ponder over the potential use of another 3rd-party repo, RPM Sphere. There are arguments against using it (or for using it sporadically, à la
sudo dnf --enablerepo=rpmsphere install some-app), but it seems to include a few “exotic” packages.
LATE EDIT: Oh, it looks like this might help too:
sudo dnf install fedora-workstation-repositories
Generally speaking, things work as expected:
Printing and scanning now, namely Epson EcoTank ET-M2170. No, that price is dumb. The street price is around €210, and only an idiot can complain that it’s B&W (duh) or that it’s “complicated” to set up.
On WiFi (I didn’t try USB), it could work completely driverless, but for scanning it really requires their shit. (Funny thing, by default
simple-scan will use my webcam for a scanner.) So I went here, and I found this:
epsonscan2: error while loading shared libraries: libQt5Widgets.so.5: cannot open shared object file: No such file or directory
…with the immediate fix:
sudo dnf install qt5-qtbase-gui
Now I could not only print, but also scan the printed page:
Oh, no theming of Qt/KDE apps! That’s an XFCE spin, and the base distro is GNOME-based, so it doesn’t come as a surprise.
sudo dnf install qt5ct qt5-qtstyleplugins
echo "export QT_QPA_PLATFORMTHEME=qt5ct" >> ~/.profile
Logout, login, run
qt5ct (Qt5 Configuration) and select “gtk2” for a style:
Then, as expected…
A predictable fail: I tried to use
Nautilus Files, and my brain barely avoided an implosion!
The good news is that GNOME’s file manager doesn’t bring many dependencies (unlike e.g.
gnome-tweaks, which would install 48 packages). The bad ones is that, for the life of me, I still cannot understand how an intelligent biped could use a castrated file manager that lacks a Compact List (multicolumn list) view, in which I couldn’t find a way to configure the columns (e.g. the way the date and time are expressed in “Modified”), and whose Preferences are totally useless!
Well, I suppose most people under 30 are having a reduced common sense, a reduced exposure to anything that’s outside their tunnel vision, and therefore can’t expect more, and don’t expect more.
As a side note on designing the UI even by older people, and still borking it: configuration dialogs worse than GNOME’s can be found in Cinnamon! Compare how in Cinnamon you can only see and edit a configuration of a single item from a list (here, “Push snap left”), and the possible values take unnecessary space, whereas in XFCE, just like in MATE or GNOME2, all the items have their values simultaneously visible and quickly editable!
So there’s no way I could ever use either GNOME or Cinnamon. Not as long as they’re designed by retards.
The mandatory criticism
A small one this time, but it came as a surprise to me: Fedora Workstation doesn’t try to educate the user to use TimeShift or other snapshot-based system restoring solution! TimeShift is installed by default by Linux Mint, Manjaro, Garuda Linux, PCLinuxOS, and possibly other distros; Fedora doesn’t install nor recommend any of the alternatives either
snapper, etc.). Heck, even Windows has System Restore, despite most people not knowing much about it!
Meanwhile, I’m optimistic.
Some more criticism
Not of the distro itself, but of Red Hat. I cannot love Red Hat Inc., and I never intended to, and I also don’t expect any Fedora Project Leader to be like Max Spevack, so I visited Matthew Miller’s AMA on Reddit with a slight disgust (for Reddit), only to learn this:
I am not making this up: Red Hat marketing has kindly asked us to not use hats in our branding. This seems silly to me — in fact, “are you serious about this” was one of my first questions as FPL — and the answer turned out to be that yes, it’s very important to them. So we don’t.
So as long as Red Hat (or IBM) is concerned, a fedora is not a hat. The FPL, after some comments:
Right, that’s exactly it. Fedora isn’t Red Hat.
Crystal clear. Not. So Red Hat is using a red fedora for a logo, and it can use baseball caps for marketing purposes, but Fedora Linux (which is not Red Hat), cannot use any kind of hats. I’m sure this brings a lot of people to Fedora. Not.
It’s nonetheless true:
The hats you might have seen elsewhere were not Fedora logos. You might have seen the red hat that was passed down from Fedora’s Red Hat Linux lineage. Other hats have been community creations and never had any official connection to Fedora. Use our logo and avoid using hats to represent Fedora since we want Fedora to have its own independent brand.
The well-known blue hats from the past were never official…