Posts

Latest Posts

Introducing appmodmap: make the Command key work again (or, making Mac refugees into Talos owners)


At least in terms of sheer numbers, Power Macintoshes are still the most common Power ISA-based computers, and those of us who still used Power Macs until lately (while my trusty 13-year-old Quad G5 may no longer be my daily driver, it is still used, and it's still under my desk) may well be the Talos II's most natural audience: we gravitate to non-x86 architectures, we like PowerPC in particular, and many Power Macs nowadays run Linux too. Yes, of course there are other audiences for the T2 and it's the truly open libre nature of the architecture that's its strongest general selling point, but those folks attracted by "the next Power Mac" are going to come from the Apple world and it would be nice to help them feel more at home. Yes, the T2 has a unique advantage in that Mac OS X can be run under QEMU with KVM acceleration. But even virtualization has a speed penalty and doesn't always work, and native apps will be more current.

The screenshot at right shows GNOME OSC overlaid with my own tweaked GNOME shell theme, unmistakably still GNOME but evocative enough of early Mac OS X to make me feel at home. Having used Macs in some way or another since 1987, and still using a MacBook Air as my travel laptop (at least until 10.15 makes it impossible to run 32-bit apps, which is where I'll be getting off the fruit bus, thank you), the look isn't jarring switching back and forth and my friend Jon thought I was still on the G5 after a cursory glance at the screen.

However, the other deeply wired part of Mac users is the Command key. My muscle memory is incredibly ingrained with Command key combinations after all these years. I always feel a little hobbled on a regular PC keyboard, and since my KVM is shared between the Quad G5, the Talos II, an SGI Fuel and a Mirrored Drive Doors Power Mac G4 and I use an old-school white Mac keyboard for all of them, having to internally codeswitch back and forth from Ctrl-Q to Cmd-Q may be a first world problem but sure gets obnoxious after awhile. The tips in this article are by no means specific to the Talos systems, but speaking from my own experience I suggest they might make things a bit less alien for a Mac user in transition.

Naturally, by default most things use Control key combinations. Some users will just switch Control and Command but I find this a rather blunt solution that works for some apps but not others. GNOME's system software is somewhat more accommodating to Command key users than KDE, but at the application level rather few packages, GNOME, KDE or otherwise, will let you change their built-in keymappings. Even of those that do, it doesn't always work, or they don't allow the use of the "Super" (their alias) key except in certain specific situations. Fortunately GNOME Terminal does allow this, so I manually remapped my usual keystrokes to the standard Mac combinations. On the browser side, if you go into about:config in Firefox and set ui.key.accelKey to 91 (and possibly restart the browser and/or reset your profile), it will generally work there also mostly as you expect and menus will show the equivalent combinations with the "Win" key instead. This isn't a perfect solution since sometimes the keybindings don't stick in odd places, or some sites will sniff Linux from your user agent string and enforce Control key combinations (Blogger, ahem), but it largely works out of the box.

Unfortunately such applications are the exception and not the rule. Changing GNOME's keyboard settings to map Close Window to Super-Q (Command-Q) will at least make most other apps close in a Mac-like fashion but there isn't much otherwise for any of the other typical functions.

The usual advice people suggest is something like AutoKey. In fact, I did use AutoKey myself for awhile and I can't complain about the functionality it offers, but I found it rather fragile and prone to crashes during use and after a couple system updates it then stopped working completely. More to the point, it was labourious drudgery to manually reconstruct all the Command key combinations for the apps that needed them, and I never ended up finishing that work before it finally crapped out.

Really, all we need is just a way to dynamically determine which app is up and then transparently swap keys around as required based on it. As usual, if you want something done you do it yourself. The result is appmodmap.

appmodmap is a small daemon that watches what the topmost X11 window is and dispatches scripts to change system settings as required. I wrote it for the Talos and I haven't tested it on anything but Fedora, but it strictly uses documented calls and thus should work on anything with X11 and POSIX. It doesn't need elevated privileges and can simply run as you. As compiled out of the box (see the README), it uses setxkbmap and gsettings to alias the Control key to the Command key for the apps on my machine that need it and still provide things such as Super-Tab to switch applications regardless of whatever app is frontmost. When the remapping isn't required for an application, appmodmap will quietly switch everything back to the default, and thus most things "just work." Note that in this scheme already existing Super-key combinations may get temporarily waxed while Control-key aliasing is still in effect, so I had to change a few more shortcuts I need in GNOME's keyboard settings for things like taking screenshots (I remapped them to Alt/Option instead).

You can also use appmodmap as a general way to change any system setting dynamically based on the window class (just write the necessary primitives), but this was what I wrote it for originally, and I still include it as a useful demonstration. Best of all, rather than doing lots of hand work in the AutoKey interface, adding more applications to the daemon just means adding the window class hint name with the desired bitmask, then quickly rebuilding the daemon and restarting it.

Overall, speaking as a long-time Mac user, just a few tweaks made my T2 feel much more like I was used to and thus a lot more productive than having to untrain my fingers. If your primary interest is the Talos' strong commitment to freedom, you'll find a way to use it no matter what contortions the interface makes you do, but if you're a Power Mac user who's a little scared of Linux but yet needs more grunt than your trusty G-series Mac can muster, here's one less excuse for not moving on from the company that left you high and dry.

IBM's POWER9 retrospective is a little one-sided


I'm not going to fault IBM taking a victory lap with the POWER9 in their one-year anniversary retrospective. It's a kick-ass processor; that's why I'm typing this on one. I'm not even going to fault them for biasing it towards their own server products, because that's what IBM sells and they're a business and they want to sell their own stuff. And IBM maintaining financial health gives them the R&D capacity to make the POWER10 even more awesome, so bring on the salesdroids.

But while Google got a shout-out with their bespoke POWER9 Zaius server platform, now in production, IBM seems to have forgotten that Power ISA is making a triumphant return to the desktop in a form that's gotten at least as much press as Zaius/Barreleye, probably sold more units, and is actually in the hands of real end users who are using it as their real computers right now. Hmm, I wonder what computer that could be?

Let's consider the historical perspective: the last major Power desktop system that didn't come from IBM was of course the Power Mac G5 Quad, which was replaced by the Mac Pro in 2006. (The last Power workstations from IBM were the IntelliStation POWER 185 and 285. This pair of machines outlasted the Quad G5 until 2009 but they preferentially ran AIX, and weren't available in large numbers.) While PowerPC chips owned the game console market for a period of time (Wii/Wii U, PlayStation 3 and Xbox 360), Apple's Intel transition meant the only remaining third-party PowerPC desktops were the AmigaOne machines. I like Amigas fine, but these systems so far have been rather underpowered due to their use of embedded designs and fairly expensive due to the small market, boutique production runs and distinctly poor economies of scale. Frankly, depending on how big a detractor you are, PowerPC hadn't been competitive against x86 on the desktop since the early G4 days, and no one other than IBM had shipped a top-tier Power ISA desktop in over 12 years.

Now we have not only a Power ISA CPU that is performance-competitive with current x86_64 offerings, but an entire third-party libre workstation built around them that you can order and get shipped to your house right now. The cost of a full Talos II only seems steep until you consider how much a Xeon box in the same ballpark will run you, and the delta seems much more reasonable then. If Blackbird is successful at establishing a "low end" POWER9 machine with a more amenable price, we could see Power ISA start to become a major desktop player once again, especially as the software support situation continues to improve by leaps and bounds and people realize what a liability blackboxes like Intel Management Engine are. Even if you're not in the market for a T2 right now, you'll be more likely to have a real choice in workstations when you do. And that's good news for everybody.

Seems like IBM could have mentioned that.

Void Linux goes POWER9


A nice commit landed in Void Linux: 64-bit Power ISA support including big and little endian. Although you'll have to build it yourself and it looks like more work is needed for other packages, eventually the resulting binaries should boot on any Talos II system and the musl support is welcome for those who prefer to avoid issues with non-64-bit long double.

Related is work to get old-school 32-bit PowerPC working, so your beloved Power Mac can play too.

Who got Talos II order #1?


It wasn't me at Floodgap, though ours is an early machine (my unit on the right is serial #12, from order #8). Turns out it was Trevor Dickinson.

If the name sounds familiar to some folks in the audience, that's because Trevor is perhaps best known for his work in the Amiga scene. I'd been watching his PowerPC-based AmigaOne series for awhile to see if they were decent successors to the Quad G5 I used prior to getting the Talos II, though neither the X1000 nor the current iteration of the X5000 are a match for the G5 in raw CPU terms. (I'm also underwhelmed that the NXP P5020 the X5000 is currently using lacks AltiVec, which I think is a terrible omission. More on that in a bit.) On the other hand, if you have a substantial investment in Amiga software (I don't), then these are the gruntiest machines that natively boot AmigaOS, and they can also boot Linux.

I'm not sure if Trevor was a backer of the original POWER8 Talos (I was), but he definitely got in at the ground floor with his T2. Not only did he order a rather beefy configuration (dual 18-core POWER9 CPUs and 96GB of RAM, etc., compared to my relatively middling dual 4-core with "just" 32GB), but Raptor even sent him a cool "order #1" certificate to commemorate his getting in first.

What's Trevor doing with this machine? Well, apparently, nothing. He mentions that the "beta Linux" he was instructed to download didn't work, though I don't recall my unit coming with any such thing. Indeed, I selected Fedora precisely because it booted on the T2 out of the box, and I can't imagine my machine arrived much later than his did. But the really baffling part is that his blog post was written just a few days ago and by now almost all the distros that support ppc64/ppc64le support POWER9, so I don't know what's still got him marooned.

He makes another interesting comment: "With the price I paid including shipping and [New Zealand] import duties I could have purchased 8 or 9 complete AmigaOne X5000 systems which can actually run AmigaOS 4, MorphOS and Linux." Well, that's probably true, and despite some wishful pipe dreams I've seen on MorphOS forums, there's very little likelihood AmigaOS or MorphOS will be ported to the T2 anytime soon. But the P5020 in the X5000 isn't even remotely in the same class as the POWER9: it has just two cores with a single thread per core, it has much less cache, it doesn't have AltiVec, let alone VSX, and it doesn't have the memory bandwidth. Part of this is because it's a design dating back to 2010, but the other part of it (and one of my perpetual complaints about recent PowerPC-based Amiga systems) is that it's an embedded-class CPU being put into a desktop environment. I should point out that I actually rather like Amigas; I own several A500s, an A3000 which one of these days I'll get Amix up on, and a '060 A4000T. But eight or nine X5000s lashed together wouldn't equal even a reasonable fraction of the power of the dual 18-core SMT-4 POWER9 he's got there (that's 144 threads, kids, plus everything else the POWER9 supports that the P5020 doesn't).

Still, no one wants a big expensive doorstop, and I hope he's able to get order #1 up and running (though I dispute that "the Talos II Secure Workstation is really aimed at a Linux administrator in a data centre" -- the Talos is now unambiguously my daily driver and I'm no longer a professional system administrator nor do I work in a data centre). I suppose I could drop by if he needs a hand in Aotearoa since I'm currently in the Southern Hemisphere with my wife's family in New South Wales. We fly back to sunny Southern California via Auckland, so we'll see.

Either way, Merry Christmas (or your holiday of choice), whatever your timezone.

IBM chooses Samsung for POWER10


It's official: Samsung will manufacture the upcoming POWER10 on their 7nm EUV process thanks to an expansion of IBM and Samsung's 15-year R&D partnership. The next z microprocessors, which have some low-level microarchitectural similarities to the Power line, will also be produced on 7nm EUV. There are still relatively few details available about either CPU; POWER10 is still scheduled for around 2020-1.

This doesn't change plans for the upcoming final revision of POWER9 in 2019. More details should be forthcoming as that release date approaches.

The saga of the Power ISA 128-bit long double


Our last post on MAME's failure to build on Power yielded some interesting information in the comments which, in my copious spare time, seemed worth researching further. But first a technical digression.

128-bit long double is currently implemented in gcc for Power ISA and PowerPC using "IBM extended doubles." This datatype is actually two 64-bit doubles paired together rather than a single 128-bit value, and specially handled in software. Because this is really a pair of 64-bit floats with altered handling, although it does improve precision (two 52-bit fractions, plus signs), it does not extend the range (as this NumPy bug demonstrates). In this scheme the effective exponent is still 11 bits, and the value thus yielded is not the same as the IEEE 754R 128-bit floating point datatype, which has a 15-bit exponent and a 112-bit mantissa plus sign.

The work to implement the true 128-bit type in gcc supersedes the extended double approach and offers better mathematical performance, and thus eliminates the need on supported systems to implement constant folding for IBM extended doubles, the crux of the g++ constexpr issue that screws up building MAME. What suitable 128-bit registers exist on Power? Why, AltiVec, of course. You can then use POWER9's native quad-precision support to support the new __float128 datatype (or emulate it in software on POWER7 and POWER8). gcc currently implements this feature behind the -mfloat128 option, which requires VSX and has hardware acceleration on POWER9.

However, if you try to use true 128-bit floats as long doubles now, it won't work properly. Why? Because the OS (and in particular libc) also needs to be adjusted for the ABI change. For Fedora, the transition to true 128-bit long double is scheduled for F30, which will include backwards compatibility symbols as the original implementation of 128-bit long double did, and the problem should finally be put to rest. It is likely that other distributions supporting ppc64le are undertaking the same process (we run Fedora here at Floodgap-Talospace).

For big-endian ppc64, there doesn't seem to be an endian restriction on 128-bit float support, so it should work the same way on Talos II systems being run BE (as well as BE POWER7 and POWER8). However, for pre-VSX platforms (such as 32-bit PowerPC, G5, and POWER4 through POWER6), the best solution for compatibility may simply be to find a system that still uses 64-bit long double. By doing so you avoid the problem completely if you don't need the extra precision. Adélie Linux, as reported by its maintainer A. Wilcox, is apparently such a platform.

No love for PowerPC from MAME


MAME, the famous multi-system emulator, has been broken on Power ISA since around 0.194 due to a long-standing gcc bug with 128-bit long double. This bug hasn't been paid attention to in 12 years, and is rather beyond my personal ken to take a whack at as well. Near as I can determine, the issue affects every Power ISA platform with such a datatype including 32-bit, 64-bit and 64-bit little-endian.

Besides a minor fix for one of their upstream libraries on little-endian PowerPC, the most straightforward workaround to get MAME up on the Talos II is to simply use 64-bit long doubles by setting the compiler flag -mlong-double-64. This is admittedly a non-standard ABI option but appears to work just fine as the screenshot demonstrates. However, rather than allow this (hopefully temporary) workaround to fix the platform given that the gcc issue is longstanding and apparently difficult to resolve, the MAME team decided not to allow any such workaround even given that it clearly wouldn't affect anything else. It's their project, but I really think that sucks, because it means MAME won't build on any PowerPC system out of the box for the foreseeable near future.

You have two options. The first is to change the makefile and/or set the appropriate compile-time options to use clang instead of gcc. I haven't tested this and clang isn't my preferred compiler on Power ISA as it's less mature on this architecture, but it is a supported compiler at least for MAME on macOS, so it should work. You'll still need the bx patch below right now (read on) if you're building on ppc64le.

Otherwise, you can apply the patch that was rejected to get gcc builds working. You'll still need the bx portion of this diff right now for either compiler on little-endian systems, though hopefully at some future point the bx patch will be accepted upstream and merged back to MAME. Again, as a non-standard ABI there is the potential for conflict with code that may not expect the altered datatype, but this is the build I currently use myself and at least as of this writing seems to work.

The POWER continues in Firefox 64


If you are able to build Firefox 63, you should be able to build Firefox 64 without anything additional. Meanwhile, a whole mess of fixes for long-standing issues have landed for Firefox 65 and later, but more about that in a future post.

FreeBSD 12.0 released


FreeBSD 12.0 is released, the latest version of the venerable BSD-derived operating system, with updates to crypto, TRIM support and Clang among other features and improvements. ISO images and downloadable archives are available for ppc64, but this support does not seem to include POWER9 (yet). One of our occasional readers is on this team and perhaps could give an update?

Note that Power support in FreeBSD is big-endian; no word on whether ppc64le will be supported as well.

Fedora 29 mini-review on Talos II


Although I don't think anyone has good data on this so far, I suspect that Fedora usage among Talos II users is pretty high because it was among the first to offer POWER9 support out of the box. I believe Debian has the greatest install base overall because of its general reputation and it seems to be the one Raptor recommends, but I still wager that Fedora is in the top couple. Indeed, coming from the Power Mac world without loyalties to any particular distribution, the fact I could just throw a bootable Fedora CD into my brand-spanking-new T2 and install an OS without any fuss was pretty much the whole reason I'm using Fedora now. Fortunately, after an initially bumpy start with some weird glitches here and there, F28 Workstation has generally been a very pleasant experience and I think most distros that support Talos systems are now to that point. This review, then, is not a general review of Fedora 29, but rather a review of F29 from the perspective of a Talos II user and anything relevant to this platform that I encountered.

If you are unfamiliar with Fedora, the most important thing to remember is that there is no such thing as a Fedora LTS (if you want that kind of extended support, then you really should be using CentOS or Red Hat Enterprise Linux). Releases are maintained on an N+2 system: now that Fedora 29 is out, F28 will be supported until one month after F30 is released and F27 will be shortly unsupported since we are roughly a month after F29 emerged. In practice this means any one release is supported for roughly a year, give or take, so it really is important to stay current with official releases. On the other hand, since the cadence is somewhat quick, the chance of major breaking changes between any two consecutive releases is relatively low.

A few notes about my configuration before we begin. My high security systems are on a standalone wired network that cannot route directly to the Internet, only through proxies, and this system has the BTO AMD WX7100 workstation card as its primary console with the VGA port jumpered off. It comes up with a textual boot (not graphical) so I can do updates with high confidence of not interfering with anything running; I manually do a startx when I want to start GNOME from there. (Incidentally, I didn't like the default icky PC VGA font, so I changed it to the Sun workstation font shown in the photograph which I think befits this machine better. Just set FONT="sun12x22" in /etc/vconsole.conf.)

If you don't have your GPU's firmware loaded in to Petitboot, you may wish to consider doing so before upgrading to or installing F29. If this is not possible or feasible, you may find life a bit easier if you use the VGA port (make sure it is not jumpered off), particularly if you are installing from scratch. In my case, I don't have the firmware on the Petitboot side yet since I rarely work with Petitboot directly, but I did need to have the VGA jumpered back on to actually install Fedora for the first time. For the upgrade this is optional but requires a few more steps. I'll talk about this in a moment for the benefit of those with unusual video cards or issues with them during early IPL.

Rather than upgrade immediately when F29 was available, I waited a few weeks to ensure that updated packages were available from both Fedora and the RPMFusion repositories. When I was ready to upgrade from F28 to F29, I quit GNOME and returned to the text console, and started the upgrade process with the standard steps:

sudo dnf upgrade --refresh # upgrade DNF
sudo dnf install dnf-plugin-system-upgrade # install upgrade plugin
sudo dnf system-upgrade download --refresh --releasever=29 # download F29 packages
sudo dnf system-upgrade reboot # reboot into upgrader

(GNOME Software can apparently do this for you automatically, but I prefer to kick off such updates manually. If you are installing F29 from scratch, however, install from the ISO for the Server or Everything versions as usual for ppc64le and then convert to Workstation afterwards if desired.)

If you have the firmware loaded in Petitboot or you are using the VGA, you can see the upgrade progress automatically begin after the system reboots. If you don't, however, you can still monitor the system by pressing CTRL-ALT-F2 for an alternate console, logging in as root (other UIDs are locked out) and periodically issuing

dnf system-upgrade log --number=-1

which displays the log so far. You'll see the normal dnf strings you would ordinarily do as it goes through the packages.

On my system the upgrade process (after the reboot) took about an hour and I went to bed in the middle of it. I woke up a few hours later to find the Talos at a black screen with its fans roaring at top volume, which looked like it had gone berserk during IPL when the upgrade ended with an automatic reboot. This caused a few nervous moments when I had to hard-power it off from the front power button and bring it back up. Fortunately, the machine then booted immediately into F29 and the system upgrade log showed that dnf had completed the upgrade without any errors. All of the packages I currently use seem to have made it over, so pretty much anything else you need to have on ppc64le should "just work" at this stage.

There are many small improvements in F29 but the two big ones are Fedora Modularity, allowing shipping multiple package versions on the same platform base, and GNOME 3.30. Although this problem is not specific to the Talos, the GNOME upgrade introduces issues of its own:

One minor annoyance was that the system monitor extension I use had gone a little nuts and needed to be reconfigured. However, the big annoyance is that as you can see from the screenshot Epiphany (GNOME Web) no longer supports plugins, including the one to manage GNOME extensions. The Tweaks window demonstrates I use quite a few of them, so losing that feature really hurts their management -- especially because trying to install and use the Firefox extension instead still gives up with an error about a missing "native host connector" even after I installed and manually confirmed the native host component was present. The big one was that Dash to Dock needed an upgrade and installing GNOME extensions by hand isn't exactly an entertaining pastime.

The trick is that the Fedora package for the native host connector only includes the JSON native messaging descriptor for Chrome. Since we don't/won't use Chrome and there isn't an official release for POWER9 anyway, we have to create our own: once you have downloaded and installed the Fedora native host connector package and the GNOME shell extension for Firefox, place the contents of this gist into ~/.mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json and restart Firefox. Now, when you visit the GNOME Extensions site, it should simply "just work" and the browser should now be able to automatically enumerate, install, disable, enable and upgrade your GNOME extensions.

On the whole, a week into the installation, I don't notice a great deal else, which means the upgrade was relatively uneventful overall (the most desired attribute of any system update). One thing I do notice is that running updates is now quite a bit faster (downloading a lot less metadata) and this is very welcome. Bumps are unfortunately to be expected and we should be striving for better in Linux if we want to be a viable alternative to macOS and Windows, but I'm relieved to say that at least with this update, the update wasn't much bumpier on our unusual black beast.

CentOS 7.6.1810 available


CentOS 7.6.1810 is now available based on Red Hat Enterprise Linux 7.6 (fresh off the IBM merger). Separate ISO images are available for ppc64 and ppc64le, along with a standalone build for POWER9 which should support Talos family machines. You can read the release notes for CentOS-specific information and get more information on RHEL 7.6, from which it descends.