Latest Posts

Tonight's game on OpenPOWER: Shadow Warrior

Well, it's been awhile since we expanded our games library, so let's go back to our regular fast food diet of FPSes and select one from the Build side of the house this time: Shadow Warrior. Build games have a reputation starting with Duke Nukem 3D (a game for another day) and that reputation is well-deserved, so let's get this out of the way: if you found these games iffy in the 1990s, rest assured they've aged badly, because you'll find the content level positively radioactive now between the adult humor, graphic violence and (this game in particular) incredibly inappropriate cultural stereotypes. Stop reading this article now and look at some of our other game builds.

On the other hand, Shadow Warrior was probably the most technically superior of the Build games (with the possible exception of Monolith's Blood): more sophisticated sector effects, coloured lighting, true transparency (including water, though used sparingly to avoid spoilers and performance issues), fog and clouds, larger levels, room-over-room effects and the part I liked the most (and was curiously missing from the classic Mac OS port by MacPlay-Westlake Interactive), voxel-based objects that were truly 3D. All of these features plus OpenGL have made it to JonoF's Shadow Warrior Port (JFSW), using Ken Silverman's Build and Polymost engines (more info).

JFSW builds pretty much out of the box with SDL 2; just type make (or make -j24 or such to exercise your other cores), then copy the .GRP group file from either the 3DRealms shareware install or a registered or retail version to ~/.jfsw (I used my MacPlay CD and named it swmac.grp). Shadow Warrior used redbook audio for the retail version, so for music, rip the tracks and save them as track02.ogg (intro) to track14.ogg ("Lo Wang Raps") in the same directory. Then go to where you've built JFSW and start the game with ./sw, and a configuration window will appear to select your resolution. Note that while widescreen resolutions are supported (and look good), the game still uses 4:3 assets, so things like Lo Wang's sword will be cut off.

A note on resolutions and colour depth: 8bpp modes are rendered 100% in software, which is very fast even on Blackbirds with just BMC graphics, and works beautifully on virtually any system. If you select a 24bpp mode, the game will try to use OpenGL. On my system this caused a freeze (actually an infinite loop, once I stepped through it in a debugger) whenever it attempts to render reflections in a mirror. This appears to be related to non-POT texture support which virtually every card anybody would be running probably supports properly. If you get the same freeze, kill the game and edit jfbuild/src/polymost.c. On line 4903 or thereabouts you'll see if ((method & METH_POW2XSPLIT) && (tsizx != xx)) which if you change to if (0) will get around the code that glitches. I can't tell if this is specific to my card, to OpenPOWER or to gcc, and it doesn't happen in software mode, which plays 100% fine all the way to the end including nuking Zilla himself.

Don't mess with Lo Wang.

Firefox 109 on POWER

Firefox 109 is out with new support for Manifest V3 extensions, but without the passive-aggressive deceitful crap Google was pushing (yet another reason not to use Chrome). There are also modest HTML, CSS and JS improvements.

As before linking still requires patching for bug 1775202 using this updated small change or the browser won't link on 64-bit Power ISA (alternatively put --disable-webrtc in your .mozconfig if you don't need WebRTC). Otherwise the browser builds and runs fine with the LTO-PGO patch for Firefox 108 and the .mozconfigs from Firefox 105.

In case you thought AIX had a future

In case you thought IBM AIX had a future, IBM's legacy proprietary Unix, IBM apparently doesn't. The Register reported Friday that IBM has moved the entire AIX development group to IBM India, apparently their Bangalore office, and placing 80 US-based developers into "redeployment." That's a fairly craven way of replacing layoffs with musical chairs, requiring the displaced developers to either find a new position within the company (possibly relocating as well) within some unspecified period, or retire. About a third of IBM's global staff is on the Indian subcontinent. IBM didn't publicly announce this move and while it's undoubtedly good news for IBM India it seems bad news for AIX's prospects: the technologies IBM thinks are up and coming IBM tends to spend money on, and so an obvious cost-cutting move suggests IBM doesn't think AIX is one of those things.

We've got a long history with AIX here at Floodgap Orbiting HQ when I first worked with AIX 3.2.5 and 4.1 in my University employment and consulting days, and I've run personal installations of AIX as my primary personal server since 1998, first on an Apple Network Server 500 and now on a 8203-E4A POWER6 p520. AIX 3 and 4 were surprisingly compelling workstation and server OSes for the time, but AIX 5L was where it started to feel "legacy" and unloved, and IBM has always been tightfisted about APARs and other kinds of updates if you don't buy a support contract. Combine that with nonsense like Capacity on Demand, where my second CPU was locked out after a system planar update until IBM coughed up a new set of keys, and I've already concluded this will be my last AIX server. While the next one will almost certainly be OpenPOWER, I'll probably run FreeBSD instead.

And, well, IBM would rather you ran Linux anyway on Power hardware, and so would their subsidiary Red Hat. If you're still an AIX institutional customer and you're still paying the bills, you'll still get support (just as you would with IBM i, the other white meat), but newly migrating to AIX is increasingly more trouble than it's worth paying for. Apparently IBM thinks so too.

Your X server may no longer swing both ways by default

As a long-time PowerPC and Power ISA bigot, there's a lot of Power-based hardware in this house — primarily Apple, but some IBM, and of course several Raptor systems. While many CPUs are capable of running big-endian or little-endian, Power ISA is probably the last architecture where there is still notable interest in running it in both modes: AIX, IBM i (a/k/a i5, AS/400), AmigaOS and OpenBSD run it big, FreeBSD primarily runs it big (but work exists to run it little), and most Linux distros run it little. Compare with the ostensibly bi-endian ARM and MIPS, which virtually all run little, and SPARC, which virtually all runs big (versus s390x, which only runs big, and of course x86 and x86_64 only runs little). Little-endian is gradually displacing big-endian even in the Power world (sorry), but it's still important.

When it was more commonplace for a discrepancy to exist, such as between mainframes and desktop X terminals or PCs, a feature was added to the X protocol where a connecting X client would advertise its endianness and if this did not match the server's, the server would byteswap for it. (Note that current Xorg may not allow remote connections without passing -listen tcp either from gdm/your display manager of choice or on the command line. On my Fedora 37 system, I do startx -- -listen tcp to enable incoming connections on my secured wired network. Don't forget anything you need to do with xhost or other authorizations. ssh forwarding is of course an alternative means.) This makes running X clients from my AIX POWER6, which is strictly big, possible on my Fedora 37 Talos II, which Fedora runs little. Here's the old beast now from the "WalMart server rack" next door.

And here's proof of connection in my usual KDE Plasma desktop (running aixterm and xlogo), showing that even the most current Xorg still supports it.
A new change to Xorg will now prohibit automatic byteswapping in the X server by default. A client connecting to a server that advertises a different endianness will be kicked off with an error. If you want this support, you'll either need to pass +byteswappedclients on the command line to the X server, or put "AllowByteSwappedClients" "on" in the Options stanza in your xorg.conf. This is also a change request for Fedora 38 which of this writing is still proposed and not accepted.

This means not only will this usage of a big-endian client to a little-endian server, which I use infrequently but not rarely, not work without changes, but will also fail for anyone running a bleeding-edge version of Xorg on a big-endian host (say, Linux on your Power Mac G5) that wants to run clients like a more current web browser from a little-endian server. The latter case is certainly less common than the former (mostly retrocomputing, whereas there are mainframe apps that people will want to have a local interface for), but I think there's more out there of both than folks suspect. Chesterton's fence and all that.

I will say that I appreciate this being turned into an option rather than outright removed, keeping in mind this is usually a prelude for outright removal later. After all, the code seems to have no test coverage in a codebase poorly covered by testing generally, and has caused documented security problems in the past. To the extent this is a better compromise than talking to the hand I support it. However, it also makes Wayland even less attractive than it already is because the ability to pass an option to Xwayland is compositor-specific (see this bug for, among others, GNOME Mutter), meaning you're at the mercy of what you're running and may not be able to change it easily yourself. Well, we're Xorg unto death around here anyway.

Fedora 37 mini-review on the Blackbird and Talos II

It's been kind of a wild ride getting the Talos II and the Blackbird upgraded to Fedora 37, but we're there, so it's finally time for a mini-review to summarize the current state. As I always like to remind folks, Fedora was one of the first mainstream distributions to support POWER9 out of the box, it's still one of the top distributions OpenPOWER denizens use and its position closest to the bleeding, ragged edge is where we see problems emerge first and get fixed (hopefully) before they move further downstream. That's why it's worth caring about it even if you yourself don't run it.

Another important reminder is both my 'Bird and T2 are configured to come up in a text boot instead of gdm and I start GNOME (Blackbird) or KDE (T2) manually from there. I still test GNOME on both systems, but I've pretty much entirely migrated over to KDE Plasma on the T2, so I'll talk about both the GNOME and KDE experience in this and future mini-reviews. I strongly recommend a non-graphical boot as a recovery mechanism in case your graphics card gets whacked by something or other. On Fedora this is easily done by ensuring the symlink /etc/systemd/system/ points to /lib/systemd/system/

As usual, the process is, from a root prompt:

dnf upgrade --refresh # upgrade prior system and DNF
dnf install dnf-plugin-system-upgrade # install upgrade plugin if not already done
dnf system-upgrade download --refresh --releasever=37 # download F37 packages
dnf system-upgrade reboot # reboot into upgrader

I did the Blackbird first, and immediately got a broken packages error because this was the system I had tested Pantheon on for Fedora 36. Just in case you didn't get the memo, new for F37 ain't no more Pantheon in Fedora (though there is a Copr). I just removed them instead (elementary-wallpapers-gnome, gala-libs and switchboard and switchboard-plug-tweaks). It booted into a graphical installer and rebooted without incident. The kernel release as of this writing is 6.0.13.

On the Talos II, which has the Raptor BTO option AMD WX7100 workstation card in it, even with GPU firmware loaded into the PNOR there was once again no graphical installation. If you manually select the kernel from Petitboot, it will at least show a text installation process. Alternatively, you can monitor on the serial port, or from a connected system viewing the serial console over the BMC's web server, or by logging into another VTY with CTRL-ALT-F2 or as appropriate as root and periodically issuing dnf system-upgrade log --number=-1 to watch log updates.

Although installation on the T2 also seemed to successfully terminate and reboot, Petitboot subsequently puked because it couldn't handle the state the updater left it in (the root is XFS and it had a stuck journal log entry). Fortunately the Blackbird was able to rectify the filesystem once the SSD was moved to an external device for recovery.

Both systems failed to update the grub2 configuration, requiring me to do so manually with grub2-mkconfig -o /boot/grub2/grub.cfg. This is a regression from bug 1921479 and can be detected in dnf with the same error message during a kernel package update (/etc/grub.d/10_linux: line XXX: test: XXXXXXX-pXXXXXXX: integer expression expected).

Additional problems were afoot on the Blackbird when starting a GUI, which is a basic 4-core using the ASPEED BMC for graphics. At least on the ASPEED, GNOME was rife with graphical abnormalities, worst of all in Wayland. (Starting Wayland from the command line also got more complex: I had to do something along the lines of XDG_SESSION_TYPE=wayland /usr/libexec/gnome-session-binary --builtin to get it to start; the regular gnome-session bombed out with an argument error.) Wayland is still restricted to 1024x768:

But that wasn't the worst of it. Trying to do even simple tasks yielded a lot of tearing and refresh problems. This is a picture of the screen because I couldn't even get the screenshot utility to work reliably.
So definitely a regression for Wayland. But even Xorg (still starts with startx, may need XDG_SESSION_TYPE=x11) had some unusual problems, like some apps' titlebars being transparent and causing graphical glitches:
Oddly, it wasn't all of them, though the Terminal was most affected. Newer or recently refreshed libadwaita-based apps seemed relatively immune, as did apps like Firefox that adhered to older GTK APIs. I keep the Blackbird as stock Fedora as possible, and I ran another update just prior to writing this up and didn't see any improvement.

KDE was not affected by that issue, though I observed — at least with Firefox and Thunderbird — that I had to grab the window and move it around a bit to get click point coordinates to be correctly reflected when the apps are full screen (then, after giving them a little shake by the titlebar, I could maximize them again and all would be well). I don't know whose bug this is exactly.

That particular irritation persisted on the Talos II, but none of GNOME's graphical problems that I saw on the Blackbird's BMC graphics. In fact, GNOME performed rather well for a change: I didn't need to force a rebuild of libgraphene this time to get improved performance and the UI was very smooth in Xorg. It also appears that the colour management issues I used to have where the screen would get blue-tinged have been rectified. Wayland GNOME had occasional animation stutters and a mild bit of lag but was otherwise useable, which is invariably the most I can say about Wayland.

Also in the positive category is that the bustage churn from the long double update in Fedora 36 is now almost all behind us, and the toolchain successfully built Firefox and other large projects without any new problems.

Overall F37 is a mixed update, more good than bad, but with some unwelcome regressions. In particular, if you are running BMC graphics only, even in Xorg GNOME has picked up some new glitches and in Wayland is once again a big mess. Systems with a GPU will largely be spared these issues — or just don't run GNOME. Likewise, be prepared with a second system to do any filesystem recovery if you're a long-time Fedora user and your root is still XFS; it may be time to convert it over to something else if you get pounded by it every time you do an upgrade.

Firefox 108 on POWER

Now that the Talos II is back in order and the Fedora 37 upgrade is largely behind me, it's now time to upgrade Firefox to version 108. There's some nice performance improvements here plus a hotkey for about:processes with Shift-Escape. Support for WebMIDI seems a little gratuitous, but what the hey (haven't tried it yet, the Macs mostly handle my music stuff), and there are also new CSS features. As before linking still requires Dan Horák's patch from bug 1775202 or the browser won't link on 64-bit Power ISA (alternatively put --disable-webrtc in your .mozconfig if you don't need WebRTC). Otherwise, we were able to eliminate one of our patches from the PGO-LTO diff, so use the new one for Firefox 108 and the .mozconfigs from Firefox 105.