It’s only been in the last couple of years that I’ve begun to dig deep into the inner workings of how terminal emulators, and the applications that run inside of them, really work. I’ve learned that there is a lot of innovation and creative problem solving happening in this space, even though the underlying technology is over half a century old.

I’ve also found that many people who use terminal based tools (including shells like Bash and editors like Vim) know very little about terminals themselves, or some of the modern features and capabilities they can support.

In this article, we’ll discuss some of the problems that terminal based applications have historically had to deal with (and what the modern solutions are) as well as some features that modern terminal emulators support that you may not be aware of.

↫ Gregory Anders

I don’t use the terminal much – usually just to update my systems – but on occasion I’ve had to really sit down and explore them more than usual, especially now that my workstation runs OpenBSD, and the depth and breadth of features, options, and clever tricks they possess is amazing. Over the past half century they’ve accumulated a lot of features along the way, and even though its unlikely to ever be for me, I can somewhat begin to appreciate why some people just tile a bunch of terminals on their screens and do all their computing that way.

I grew up with MS-DOS and Windows 3.x and later, so I’m just too attached to my mouse and pretty icons to switch to a terminal lifestyle, but over the years I’ve seen some pretty amazing terminal applications, from Mastodon clients to complex mail applications and web browsers, and you can be sure none of them steal your data or show you ads.

Maybe the terminal people are right after all.

There’s a new 9front release! So, what exactly is 9front, you may ask? Well, after it became clear that Bell Labs wasn’t doing much with plan9, a group of developers took matters into their own hands and created 9front, a fork of plan9. Their latest release is called DO NOT INSTALL, and brings things like more USB audio support, DNS over TLS, WiFi support for the Raspberry Pi, I2C support, and much more.

I’m not particularly well-versed in the world of plan9, and more often than not it feels like a form of high-level programming performance art that I’m just not smart enough to understand. The whole community and its associated web sites have a very unique feel to it, and I always feel like I’m just not cool enough to be part of it. That’s not a dig at the plan9 community – it’s more of an indictment of my lack of coolness.

Which really shouldn’t come as a surprise.

VMS Software, the company developing OpenVMS, has announced some considerable changes to its licensing program for hobbyists, and the news is, well, bad. The company claims that demand for hobbyist licenses has been so high that they were unable to process requests fast enough, and as such, that the program is not delivering the “intended benefits”. Despite this apparent high demand, contributions from the community, such as writing and porting open-source software, creating wiki articles, and providing assistance on their forums, “has not matched the scale of the program”.

Now, I want to stop them right here. The OpenVMS hobbyist program was riddled with roadblocks, restrictions, unclear instructions, restrictive licensing, and similar barriers to entry. As such, it’s entirely unsurprising that the community around a largely relic of an operating system – with all due respect – simply hasn’t grown enough to become self-sustainable. The blame here lies entirely with VMS Software itself, and not at all with whatever community managed to form around OpenVMS, despite the countless restrictions.

So, you’d expect them to expand the program, right? Perhaps embrace open source, or make the various versions and releases more freely and easily available?

No, they’re going to do the exact opposite. To address not getting enough out of their community, they’re going to limit that community’s options even more. First, they’re ending the community program for the Alpha and Itanium (which they call Integrity, since it covers HP’s Integrity machines), effective immediately, so they won’t be granting any new licenses for these architectures. Existing licenses will continue to work until 2025.

Effective immediately, we will discontinue offering new community licenses for non-commercial use for Alpha and Integrity. Existing holders of community licenses for these architectures will get updates for those licenses and retain their access to the Service Portal until March 2025 for Alpha and December 2025 for Integrity. All outstanding requests for Alpha and Integrity community licenses will be declined.

↫ VMS Software announcement

This sucks, but with both Alpha and Itanium being end-of-life, there’s at least some arguments that can be made for ending the program for these architectures. Much less defensible are the changes to x86-64 community licensing, which basically just come down to more bureaucracy for both users and VMS Software.

For x86 community licenses, we will be transitioning to a package-based distribution model (which will also replace the student license that used to be distributed as a FreeAXP emulator package). A vmdk of a system disk with OpenVMS V9.2-2 and compilers installed and licensed will be provided, along with instructions to create a virtual machine and the SYSTEM password. The license installed on that system will be valid for one year, at which point we will provide a new package. While this may entail some inconvenience for users, it enables us to continue offering licenses at no cost, ensuring accessibility without compromising our sustainability.

↫ VMS Software announcement

The vibe I’m getting from this announcement is that by offering some rudimentary and complicated form of community licensing, OpenVMS hoped to gain the advantages of a vibrant open source community, without all the downsides. They must’ve hoped that by throwing the community a bone, they’d get them to do a bunch of work for them, and now that this is not panning out, they’re taking their ball and going home. That’s entirely within their right, of course, but I doubt these changes are going to make anyone more excited to dig into OpenVMS.

All of this feels eerily similar to the attempts by QNX – before being acquired by BlackBerry – to do pretty much the same thing. QNX also tried a similar model where you needed to sign up and jump through a bunch of hoops to get QNX releases, and the company steeped it in talks of building a community, but of course it didn’t pan out because people are simply not interested in a one-way relationship where you’re working for free for a corporation who then takes your stuff and uses it to sell their, in this case, operating system.

This particular mistake is made time and time again, and it seems VMS Software simply did not learn this lesson.

Hurd, the kernel that is supposed to form the basis of the GNU operating system, is perpetually a research project that doesn’t get anywhere close to being a replacement for Linux, but that doesn’t mean the project doesn’t make progress and has a place in the world of operating systems. Their most recent major improvement has been porting GNU Hurd to AArch64, spearheaded by Hurd developer Sergey Bugaev.

Since then, however, I have been (some may say, relentlessly) working on filling in the missing piece, namely porting GNU Mach (with important help & contributions by Luca D.). I am happy to report that we now have an experimental port of GNU Mach that builds and works on AArch64! While that may sound impressive, note that various things about it are in an extremely basic, proof-of-concept state rather than being seriously production-ready; and also that Mach is a small kernel (indeed, a microkernel), and it was designed from the start (back in the 80s) to be portable, so most of the “buisness logic” functionality (virtual memory, IPC, tasks/threads/scheduler) is explicitly arch-independent.

Despite the scary “WIP proof-of-concept” status, there is enough functionality in Mach to run userland code, handle exceptions and syscalls, interact with the MMU to implement all the expected virtual memory semantics, schedule/switch tasks and threads, and so on. Moreover, all of GNU Mach’s userspace self-tests pass!

↫ Sergey Bugaev

On top of all this, glibc works on the AArch64 port, and several important Hurd servers work as well, namely ext2fs, exec, startup, auth, and proc, as a do a number of basic UNIX programs. This is an exceptional effort, and highlights that while people tend to make fun of Hurd, it’s got some real talent working on it that bring the platform forward. While we may not see any widely usable release any time soon, every bit of progress helps and is welcome.

Speaking of progress, the progress report for GNU Hurd covering the first quarter of 2024 has also been published, and it lists a number of other improvements and fixes made aside from the AArch64 port. For instance, the console will now use xkbcommon instead of X11 for handling keyboard layouts, which reduced code complexity a lot and improved keyboard layout coverage, to boot. The port of GDB to the 64 bit version of Hurd is also progressing, and SMP has seen a ton of fixes too.

Another awesome bit of news comes from, once again, Sergey Bugaev, as he announced a new Hurd distribution based on Alpine Linux. Work on this project has only recently begun, but he’s already had some success and about 299 Alpine packages are available. His reasons for starting this new project is that while Debian GNU/Hurd is a great base to work from for Hurd users and developers, Debian is also a bit strict and arcane in its packaging requirements, which might make sense for Debian GNU/Linux, but is annoying to work with when you’re trying to get a lot of low-level work done. For now, there’s no name yet, and he’s asking for help from the Hurd community for name ideas, hosting, and so on.

That’s a lot of GNU Hurd progress this quarter, and that’s good news.