Unix Archive
Many of us are interested in retrocomputing. There’s such a rich history of eras and machines to choose from, and countless niches and nuances to get lost in. Some people make it easy for themselves and are into old computers that are readily available at low prices, like the Commodore 64 or mid-’90s Macs, while others make it a bit harder on themselves by focusing on, say, computers from the former Soviet Union or NEC machines from Japan, which are harder to find and probably require a bigger purse, too. And then there’s people like me. I’m making things incredibly hard on myself, because I am obsessed with a very specific set of computers – just five machines, to be exact. “Surely,” I hear you think, “collecting a mere five specific machines can’t be that hard, no? That’s how many spare Pismos I have in a box in case my primary one needs spare parts!” Sadly for me, the five computers I want to own more than any other are not particularly easy to find, and even when you do find one of them, pricing can easily reach the level of a decent used car. Regular OSNews readers will know: I am infatuated with UNIX workstations, or more specifically, UNIX workstations of the early 2000, and even more specifically, the final five models built by the last commercial UNIX vendors. So far, I’ve managed to get my hands on a mere two of them, but before my time on this earth come to an end, I intend to complete my Holy Quinity of UNIX Workstations. Let’s go down the list, roughly ordered by attainability. HP c8000: PA-RISC/HP-UX The HP c8000 is the absolute pinnacle of HP’s long-running line of workstations based on the PA-RISC architecture. The first PA-RISC workstation was launched in 1986, and HP would continue to improve the architecture and release new workstations all the way up until 2004, when the c8000 would be their last model. For the c8000, HP actually went all-out: it came with two dual-core PA-RISC processors running between 900MHz and 1.1GHz (depending on configuration), a maximum of 24GB of RAM, and a variety of graphics cards to choose from. It was a veritable swan song for the architecture. HP’s commercial UNIX operating system, HP-UX, is even older than PA-RISC, with the first version being released in 1982, and its final version, HP-UX 11i v3 (or 11.31) released in 2007. This final version of HP-UX was updated and supported all the way up until 31 December 2025, but things are actually a bit more complicated than that. The last workstation release of HP-UX for PA-RISC was 11i v1 (released in 2000), while the last workstation release for Itanium workstations was 11i v2 (released in 2005). Do note that HP would provide updates, fixes, and patches to these versions long after the mentioned release dates. Speaking of Itanium, HP’s final Itanium workstation was the zx6000, released in 2002, which can pack up to two single-core 1.5Ghz Itanium 2 processors. There’s a very real case to be made that the zx6000 should also be part of this list, since it’s both a little faster than the c8000 (in its dual 1.5GHz configuration) and runs a newer version of HP-UX. However, since Itanium workstations never really had much of an impact in the market (even HP only ever released two models), and since it lacks the decades of pedigree that comes with PA-RISC, I consider them a mere curiosity. A very cool curiosity that I’d love to own, but a curiosity nonetheless. Anyway, this is one of the two machines I already own. I have a new-in-box (when I bought it a few years ago) HP c8000 with two dual-core 1.0Ghz PA-RISC processors, 8 GB of RAM, and an ATI FireGL X3 AGP graphics card with 256 MB, the fastest the c8000 will take. It’s also got two SCSCI 74 GB hard drives in a striped RAID for better performance, and I added an LTO 4 tape drive so I could create bootable backups that will restore the machine if anything ever goes wrong. It’s running HP-UX 11i v1, with as many of the updates, patches, and fixes I could find – which is one of the major roadblocks for anyone trying to get into HP-UX. Installation media are relatively easy to come by if you know where to look (assuming you know which specific version you need), but any updates, patches, and fixes from roughly later than 2005 are almost impossible to find. Some can be discovered through My HPE Software Center, if you have the patience of an angel and the perseverance of a honey badger (it’s a really terrible website), but most things are all locked away behind expensive support contracts or just gone entirely. I’ve contacted HPE several times in several different ways about the preservation of HP-UX, but they never replied – clearly, they just don’t care about the preservation of their legendary UNIX platform or the enthusiast community buying PA-RISC hardware on eBay for personal use and experimentation. Sad, but par for the course. The c8000 is quite easy to find on eBay, but do be aware that the “cheap” offerings of around €800 are the versions with just one processor. To get the version with two processors, expect to shell out twice as much. Spare parts and upgrades are readily available, too. Sun Ultra 45: SPARC/Solaris The Sun Ultra 45 needs no introduction here on OSNews, as I published an in-depth article about this machine and all the cool things you can do with it late last year. My Ultra 45 was an incredibly generous gift by Adriaan de Groot, who owned this machine as part of his work on porting KDE to Solaris way back in the day. I then ordered various upgrades to the machine to max it out with two UltraSPARC IIIi processors running at 1.6GHz, 8 GB of RAM, and the Sun XVR-2500 with 256MB, the fastest
Over the last few days and weeks or so, a few of the people I follow and interact with on Fedi have been talking about centralising information, tools, applications, and expertise from the Motif (and Xt, Xlib, and X11) ecosystem. There’s a ton of information, resources, and actively maintained applications out there, but it’s all spread out and sometimes difficult to find, and so Thomas Adam – one of the core developers of FVWM, among other things, as well as creator of CoW (FVWM for Wayland, more or less) – has created an effort to centralise all of this. Motif Central brings together information about Motif, Xt, Xlib and X11: how they fit together, how to program with them, and where to find the manuals, examples and historical material that explain them. Begin with the X programming stack, build your first Motif application, or explore the programming resources. The history pages describe the libraries’ origins, while the archive guide helps you navigate older documentation. ↫ MotifCentral There’s been a whole flurry of activity around Motif lately, including the updated and maintained fork we talked about a few weeks ago. The people loosely collaborating on MotifCentral also submitted patches to CDE to make sure it works on the new Motif fork, with the CDE developers setting up a build pipeline for easier testing. Making sure CDE, the classic Motif desktop environment, works well with the maintained Motif fork quite a few people seem to be rallying around is a worthwhile effort. We’re still quite far from a complete(-ish) modern Motif ecosystem, but it’s very heartwarming to see just how many people are actually still interested in it. My perhaps misguided hope is that we can somehow get to a modernised Motif/CDE desktop environment and applications, making it possible to more easily run a modern Motif environment on Linux and the BSDs. One may dream.
Motif is great, I love how it looks and feels, and I want it to be actively maintained. I want a healthy ecosystem of Motif applications and even window managers and desktop environments, so I can run a real Motif environment. Sadly, while Motif has been open source for a while, the project itself stalled years ago, with little to no activity from anyone involved. That may be changing, as a number of developers decided to take matters into their own hands last year. This fork of Motif was born of a desire to keep Motif (and other X11 technologies) alive and well. The original upstream Sourceforge project hasn’t had any activity in over two years, none of the project admins have been active for at least that amount of time, the official bug tracker has disappeared into the void; and the user forum was closed way back in 2017. Sadly, it appears that the original upstream has abandoned the project. I’ve incorporated some fixes from upstream that have laid dormant for years, a few others from Gentoo, and made a few improvements of my own. I intend to maintain this fork, and in doing so advocate for the continued use of the user interface toolkit that defined an era, and influenced many of the user interfaces that came after it. ↫ Tim Hentenaar at the Motif fork’s GitHub page Some of the people involved are people I know online, so I have a bit of faith in this fork being able to stand the test of time, but of course, managing a complex project like this is hard, so who knows how long the enthusiasm remains. Still, this fork has seen five releases since its inception a little over a year ago, which seems promising. It may seem weird for some to have a love for Motif, but I’m the kind of person who installs weird, outdated corporate and industrial software I don’t understand on my HP c8000 dual PA-RISC workstation running HP-UX just to enjoy the Motif interfaces they sometimes ship. We all have our quirks. From my experiences talking to people online, I know there’s actually a rather solid number of people like me, and I hope that at some point the developers in this group can gain enough critical mass to build something like a basic Linux distribution or desktop environment using the disparate, actively-maintained Motif projects out there that yes, still exist. It’s a long shot, but in today’s computing landscape, where more and more people feel uncomfortable with “modern” software, I really feel like there’s a niche for something like this to exist. A really small niche, surely, but a niche all the same.
I’ve mentioned it before, but Chris Siebenmann is basically the Raymond Chen of the UNIX world, and today he’s filling that role perfectly once again. I recently read Simon Tatham’s Nitpicking the shell history scene in Tron: Legacy, where one thing that surprised Tatham was the film using ‘login -n root‘ to become root instead of ‘su‘. This surprised me because I found that perfectly ordinary, and this turns up both a bit of Unix history and a difference between modern Unixes. Plain ‘su‘ can let you become another user, including root, but what it explicitly doesn’t do by default is create a new login shell for that user. If you do ‘su root‘, the new root shell normally inherits most of your environment, your current directory, and so on. Sometimes this is what you want and sometimes you really want a new login environment, and originally in Unix how you got the latter was to run ‘login‘ from your existing shell session (and this meant that login was setuid root, like su). ↫ Chris Siebenmann Unsurprisingly, this distinction has persisted to this day in various UNIX-like operating systems, but in different ways. Some maintain the explicit distinction, while others have more or less standardised on using su for both use cases. It’s an interesting bit of UNIX archeology.
Many Bourne shells go slightly beyond the POSIX sh specification to also support a ‘-l’ option that makes the shell act as a ‘login shell’. POSIX’s omission of -l isn’t only because it doesn’t really talk about login shells at all, it’s also because Unix has a special way of marking login shells that goes back very far in its history. The -l option isn’t necessarily what login and sshd and so on use, it’s something that you can use if you specifically want to get a login shell in an unusual circumstance. Bourne shells also have a ‘-c <command string>’ option that causes the shell to execute the command string rather than be interactive (this is a long standing option that is in POSIX). It may surprise you to hear that most or all Bourne shells that support -l also allow you to use -l and -c together. Basically all Bourne shells interpret this as first executing your .profile and so on, then executing the command string instead of going interactive. One use for this is to non-interactively run a command line in the context of your fully set up shell, with $PATH and other environment variables ready for use. ↫ Chris Siebenmann Now, what if you want to detect the use of these two options combined, for instance to make it so certain parts of your .profile are ignored? It turns out very few Bourne shells actually support this, and that’s what Siebenmann’s latest post is about.
So vi only has one level of undo, which is simply no longer fit for the times we live in now, and also wholly unnecessary given even the least powerful devices that might need to run vi probably have more than enough resources to give at least a few more levels of undo. What I didn’t know, however, is that vi’s limited undo behaviour is actually part of POSIX, and for full compliance, you’re going to need it. As Chris Siebenmann notes, vim and its derivatives ignore this POSIX requirement and implement multiple levels of undo in the obviously correct way. What about nvi, the default on the BSD variants? I didn’t know this, but it has a convoluted workaround to both maintain POSIX compatibility and offer multiple levels of undo, and it’s definitely something. Nvi has opted to remain POSIX compliant and operate in the traditional vi way, while still supporting multi-level undo. To get multi-level undo in nvi, you extend the first ‘u’ with ‘.’ commands, so ‘u..’ undoes the most recent three changes. The ‘u’ command can be extended with ‘.’ in either of its modes (undo’ing or redo’ing), so ‘u..u..’ is a no-op. The ‘.’ operation doesn’t appear to take a count in nvi, so there is no way to do multiple undos (or redos) in one action; you have to step through them by hand. I’m not sure how nvi reacts if you want do things like move your cursor position during an undo or redo sequence (my limited testing suggests that it can perturb the sequence, so that ‘.’ now doesn’t continue undoing or redoing the way vim will continue if you use ‘u’ or Ctrl-r again). ↫ Chris Siebenmann Siebenmann lists a few other implementations and how they work with undo, and it’s interesting to see how all of them try to solve the problem in slightly different ways.
For me, vim is a combination of genuine improvements in vi’s core editing behavior (cf), frustrating (to me) bits of trying too hard to be smart (which I mostly disable when I run across them), and an extension mechanism I ignore but people use to make vim into a superintelligent editor with things like LSP integrations. Some of the improvements and additions to vi’s core editing may be things that Bill Joy either didn’t think of or didn’t think were important enough. However, I feel strongly that some or even many of omitted features and differences are a product of the limited environments vi had to operate in. The poster child for this is vi’s support of only a single level of undo, which drastically constrains the potential memory requirements (and implementation complexity) of undo, especially since a single editing operation in vi can make sweeping changes across a large file (consider a whole-file ‘:…s/../../’ substitution, for example). ↫ Chris Siebenmann I have only very limited needs when it comes to command-line text editors, and as such, I absolutely swear by the simplicity of nano. In other words, I’m probably not the right person to dive into the editor debate that’s been raging for decades, but reading Siebenmann’s points I can’t help but agree. In this day and age, defaulting an editor that has only one level of undo is insanity, and I can’t imagine doing the kind of complex work people who use command-line editors do while being limited to just one window. As for the debate about operating systems that symlink the vi command to vim or a similar improved variant of vi, I feel like that’s the wrong thing to do. Much like how I absolutely despise how macOS hides its UNIX-y file system structure from the GUI, leading to bizarre ls results in the terminal, I don’t think you should be tricking users. If a user enters vi, it should launch vi, and not something that kind of looks like vi but isn’t. Computers shouldn’t be lying to users. If they don’t want their users to be using vi, they shouldn’t be installing vi in the first place.
It’s 31 December 2025 today, the last day of the year, but it also happens to mark the end of support for the last and final version of one of my favourite operating systems: HP-UX. Today is the day HPE puts the final nail in the coffin of their long-running UNIX operating system, marking the end of another vestige of the heyday of the commercial UNIX variants, a reign ended by cheap x86 hardware and the increasing popularisation of Linux. HP-UX’ versioning is a bit of a convoluted mess for those not in the know, but the versions that matter are all part of the HP-UX 11i family. HP-UX 11i v1 and v2 (also known as 11.11 and 11.23, respectively) have been out of support for exactly a decade now, while HP-UX 11i v3 (also known as 11.31) is the version whose support ends today. To further complicate matters, like 11i v2, HP-UX 11i v3 supports two hardware platforms: HP 9000 (PA-RISC) and HP Integrity (Intel Itanium). Support for the HP-UX 11i v3 variant for HP 9000 ended exactly four years ago, and today marks the end of support for HP-UX 11i v3 for HP Integrity. And that’s all she wrote. I have two HP-UX 11i v1 PA-RISC workstations, one of them being my pride and joy: an HP c8000, the last and fastest PA-RISC workstation HP ever made, back in 2005. It’s a behemoth of a machine with two dual-core PA-8900 processors running at 1Ghz, 8 GB of RAM, a FireGL X3 graphics card, and a few other fun upgrades like an internal LTO3 tape drive that I use for keeping a bootable recovery backup of the entire system. It runs HP-UX 11i v1, fully updated and patched as best one can do considering how many patches have either vanished from the web or have never “leaked” from HPE (most patches from 2009 onwards are not available anywhere without an expensive enterprise support contract). The various versions of HP-UX 11i come with a variety “operating environments” you can choose from, depending on the role your installation is supposed to fulfill. In the case of my c8000, it’s running the Technical Computing Operating Environment, which is the OE intended for workstations. HP-UX 11i v1 was the last PA-RISC version of the operating system to officially support workstations, with 11i v2 only supporting Itanium workstations. There are some rumblings online that 11i v2 will still work just fine on PA-RISC workstations, but I have not yet tried this out. My c8000 also has a ton of other random software on it, of course, and only yesterday I discovered that the most recent release of sudo configures, compiles, and installs from source just fine on it. Sadly, a ton of other modern open source code does not run on it, considering the slightly outdated toolchain on HP-UX and few people willing and/or able to add special workarounds for such an obscure platform. Over the past few years, I’ve been trying to get into contact with HPE about the state of HP-UX’ patches, software, and drivers, which are slowly but surely disappearing from the web. A decent chunk is archived on various websites, but a lot of it isn’t, which is a real shame. Most patches from 2009 onwards are unavailable, various software packages and programs for HP-UX are lost to time, HP-UX installation discs and ISOs later than 2006-2009 are not available anywhere, and everything that is available is only available via non-sanctioned means, if you know what I mean. Sadly, I never managed to get into contact with anyone at HPE, and my concerns about HP-UX preservation seem to have fallen on deaf ears. With the end-of-life date now here, I’m deeply concerned even more will go missing, and the odds of making the already missing stuff available are only decreasing. I’ve come to accept that very few people seem to hold any love for or special attachment to HP-UX, and that very few people care as much about its preservation as I do. HP-UX doesn’t carry the movie star status of IRIX, nor the benefits of being available as both open source and on commodity hardware as Solaris, so far fewer people have any experience with it or have developed a fondness for it. HP-UX didn’t star in a Steven Spielberg blockbuster, it didn’t leave behind influential technologies like ZFS. Despite being supported up until today, it’s mostly forgotten – and not even HPE itself seems to care. And that makes me sad. When you raise your glasses tonight to mark the end of 2025 and welcome the new year, spare a thought for the UNIX everyone forgot still exists. I know I will.
Almost two months ago, a tape containing UNIX v4 was found. It was sent off to the Computer History Museum where bitsavers.org would handle the further handling of the tape, and this process has now completed. You can download the contents of the tape from Archive.org – which is sadly down at the moment – while squoze.net has a readme with instructions on how to actually run the copy of UNIX v4 recovered from the tape.
Unix has been enormously successful over the past 55 years. It started out as a small experiment to develop a time-sharing system (i.e., a multi-user operating system) at AT&T Bell Labs. The goal was to take a few core principles to their logical conclusion. The OS bundled many small tools that were easy to combine, as it was illustrated by a famous exchange between Donald Knuth and Douglas McIlroy in 1986. Today, Unix lives on mostly as a spiritual predecessor to Linux, Net/Free/OpenBSD, macOS, and arguably, ChromeOS and Android. Usenet tells us about the height of its early popularity. ↫ Gábor Nyéki There are so many amazing stories in this article, I honestly have no idea what to highlight. So first and foremost, I want you to read the whole thing yourself, as everyone’s bound to have their own personal favourite section that resonates the most. My personal favourite story from the article – which is just an aside, to illustrate that even the asides are great – is that when Australia joined Usenet in 1983, new posts to Usenet were delivered to the country by airmail. On magnetic tape. Once per week. The overarching theme here is that the early days of UNIX, as documented on Usenet, were a fascinating wild west of implementations, hacks, and personalities, which, yes, clashed with each other, but also spread untold amounts of information, knowledge, and experience to every corner of the world. I hope Nyéki will write more of these articles.
The contents of this repository allow older versions of UNIX (ancient UNIX) to run easily on modern Unix-like systems (Linux, FreeBSD, macOS, among others). ↫ Run ancient UNIX GitHub page With the guides in this repository, you can easily run Versions 1/5/7 UNIX and 2.11BSD UNIX for the PDP-11 and Version 7 UNIX for x86 (ported to x86 by Robert Nordier in 1999, with patches in 2006-2007). That’s it.
Jonathan Pallant got lucky and managed to score a massive haul of ’90s UNIX workstations, one of which was an HP 9000 Model 340, a HP-UX workstation built around a Motorola 68030 processor at 16.7 MHz. It doesn’t come with a hard drive or even a floppy controller, though, so he decided to borrow a PA-RISC-based HP 9000 Model 705 to set up an HP-UX 9 cluster. But wait, how does that work, when we’re dealing with two entirely different architectures? What’s more fun though, is putting it into a cluster with the Model 705 and network booting it. Yes, that a 68030 machine network booting from a PA-RISC machine … and sharing the same root filesystem. But aren’t PA-RISC binaries and 68K binaries quite different? Oh yes, they really are. So, how does that work? ↫ Jonathan Pallant HP-UX is far more interesting and fascinating than a lot of people give it credit for, and while my interest lies with HP-UX 11i, I find what Pallant is doing here with HP-UX 9 just as fascinating. You first need to install HP-UX 9 for PA-RISC on the 700 series machine, convert it to a cluster server, and then install HP-UX 9 for 68k on top of that PA-RISC installation. After this is done, you effectively end up with a single root file system that contains both PA-RISC and 68k binaries, and you can network boot the 68k-based Model 340 right from it – using the same root filesystem on both machines. Absolutely wild. No, these are not universal binaries or some other trick you might know of from more modern system. In fact, installing the 68k version of HP-UX 9 “into” the PA-RISC HP-UX 9 cluster server, you end up with something called a Context Dependent Filesystem. To get a better idea of what this means and how this works, you should really head on over to Pallant’s excellent article for all the details.
A unique and very important find at the University of Utah: while cleaning out some storage rooms, the staff at the university discovered a tape containing a copy of UNIX v4 from Bell Labs. At this time, no complete copies are known to exist, and as such, this could be a crucial find for the archaeology of early UNIX. The tape in question will be sent to the Computer History Museum for further handling, where bitsavers.org will conduct the recovery process. I have the equipment. It is a 3M tape so it will probably be fine. It will be digitized on my analog recovery set up and I’ll use Len Shustek’s readtape program to recover the data. The only issue right now is my workflow isn’t a “while you wait” thing, so I need to pull all the pieces into one physical location and test everything before I tell Penny it’s OK to come out. ↫ bitsavers.org It’s amazing how we still manage to find such treasures in nooks and crannies all over the world, and with everything looking good so far, it seems we’ll soon be able to fill in more of UNIX’ early history.
This is a conversion of the original V7 pwd program for use on POSIX systems (tested primarily on Linux). This is mostly of historical interest — modern systems have a library routine or system call for getting the current directory, and don’t need this. I’ve attempted to make the minimum set of logic/functionality changes needed to make the program work, preserving the core of the original logic. I’ve made slightly more aesthetic changes, to make reading easier for a post-standardization C speaker. ↫ Cliff L. Biffle Over on Fedi, Cliff L. Biffle provides more details as to why he undertook this project.
Chris Siebenmann with another interesting look at a tiny detail of UNIX history. A few years ago I wrote about the divide in chown() about who got to give away files, where BSD and V7 were on one side, restricting it to root, while System III and System V were on the other, allowing the owner to give them away too. The answer is that the restriction was added in V6, where the V6 chown(2) manual page has the same wording as V7. In Research Unix V5 and earlier, people can chown(2) away their own files; this is documented in the V4 chown(2) manual page and is what the V5 kernel code for chown() does. This behavior runs all the way back to the V1 chown() manual page, with an extra restriction that you can’t chown() setuid files. ↫ Chris Siebenmann The deeper levels of this particular rabbit hole need more exploring, though, as eventually Siebenmann hits a roadblock when trying to figure out why, exactly, the restriction was added, and why certain versions chose to not adopt the new restriction. This may be part of the lore of UNIX we won’t uncover, until one of the people involved speaks up.
I’ve been working on developing an operating system for the TI-99 for the last 18 months or so. I didn’t intend this—my original plan was to develop enough of the standard C libraries to help with writing cartridge-based and EA5 programs. But that trek led me quickly towards developing an OS. As Unix is by far my preferred OS, this OS is an approximation. Developing an OS within the resources available, particularly the RAM, has been challenging, but also surprisingly doable. ↫ UNIX99 forum announcement post We’re looking at a quite capable UNIX for the TI-99, with support for its sound, speech, sprites, and legacy 9918A display modes, GPU-accelerated scrolling, stdio (for text and binary files) and stdin/out/err support, a shell (of course), multiple user support, cooperative tasks support, and a ton more. And remember – all of this is running on a machine with a 16-bit processor running at 16MHz and a mere 16KB of RAM. Absolutely wild.
It may be arcane knowledge to most users of UNIX-like systems today, but there is supposed to be a difference between /usr/bin and /usr/sbin; the latter is supposed to be for “system binaries”, not needed by most normal users. The Filesystem Hierarchy Standard states that sbin directories are intended to contain “utilities used for system administration (and other root-only commands)”, which is quite vague when you think about it. This has led to UNIX-like systems basically just winging it, making the distinction almost entirely arbitrary. For a long time, there has been no strong organizing principle to /usr/sbin that would draw a hard line and create a situation where people could safely leave it out of their $PATH. We could have had a principle of, for example, “programs that don’t work unless run by root”, but no such principle was ever followed for very long (if at all). Instead programs were more or less shoved in /usr/sbin if developers thought they were relatively unlikely to be used by normal people. But ‘relatively unlikely’ is not ‘never’, and shortly after people got told to ‘run traceroute’ and got ‘command not found’ when they tried, /usr/sbin (probably) started appearing in $PATH. ↫ Chris Siebenmann As such, Fedora 42 unifies /usr/bin and /usr/sbin, which is kind of a follow-up to the /usr merge, and serves as a further simplification and clean-up of the file system layout by removing divisions and directories that used to make sense, but no longer really do. Decisions like these have a tendency to upset a small but very vocal group of people, people who often do not even use the distribution implementing the decisions in question in the first place. My suggestions to those people would be to stick to distributions that more closely resemble classic UNIX. Or use a real UNIX. Anyway, these are good moves, and I’m glad most prominent Linux distributions are not married to decisions made in the ’70s, especially not when they can be undone without users really noticing anything.
Earlier this year, I was trying to get actual daily work done on HP-UX 11.11 (11i v1) running on HP’s last and greatest PA-RISC workstation, the HP c8000. After weeks of frustration caused first by outdated software no longer working properly with the modern web, and then by modern software no longer compiling on HP-UX 11.11, I decided to play the ace up my sleeve: NetBSD’s pkgsrc has support for HP-UX. Sadly, HP-UX is obviously not a main platform or even a point of interest for pkgsrc developers – as it should be, nobody uses this combination – so various incompatibilities and more modern requirements had snuck into pkgsrc, and I couldn’t get it to bootstrap. I made some minor progress here and there with the help of people far smarter than I, but in the end I just lacked the skills to progress any further. This story will make it to OSNews in a more complete form, I promise. Anyway, in May of this year, it seems Brian Robert Callahan was working on a very similar problem: getting pkgsrc to work properly on IBM’s AIX. The state of packages on AIX genuinely surprises me. IBM hosts a repository of open source software for AIX. But it seems pretty sparse compared to what you could get with pkgsrc. Another website offering AIX packages seems quite old. I think pkgsrc would be a great way to bring modern packages to AIX. I am not the first to think this. There are AIX 7.2 pkgsrc packages available at this repository, however all the packages are compiled as 32-bit RISC System/6000 objects. I would greatly prefer to have everything be 64-bit XCOFF objects, as we could do more with 64-bit programs. There also aren’t too many packages in that repository, so I think starting fresh is in our best interest. As we shall see, this was not as straightforward as I would have hoped. ↫ Brian Robert Callahan Reading through his journey getting pkgsrc to work properly on AIX, I can’t help but feel a bit better about myself not being to get it to work on HP-UX 11.11. Callahan was working with AIX 7.2 TL4, which was released in November 2019 and still actively supported by IBM on a maintained architecture, while I was working with HP-UX 11.11 (or 11i v1), which last got some updates in and around 2005, running on an architecture that’s well dead and buried. Looking at what Callahan still had to figure out and do, it’s not surprising someone with my lack of skill in this area couldn’t get it working. I’m still hoping someone far smarter than I stumbles upon a HP c8000 and dives into getting pkgsrc to work on HP-UX, because I feel pkgsrc could turn an otherwise incredibly powerful HP c8000 from a strictly retro machine into something borderline usable in the modern world. HP-UX is much harder to virtualise – if it’s even possible at all – so real hardware is probably going to be required. The NetBSD people on Mastodon suggested I could possibly give remote access to my machine so someone could dive into this, which is something I’ll keep under consideration.
The most unlikely subsystem of contention is definitely the init system used by Linux, with most popular distributions opting for systemd, while a vocal minority prefers to use something else. Neither of these two groups are wrong or right, as we live in a free world and different people have different needs and desires. Personally, I don’t think there’s a more utterly pointless and meaningless debate than this, and people who make the init system they use their entire personality more often than not come across as really, really sad. It’s a tool; use the one you like and move on with life. A brand new init system was recently released by Leah Neukirchen, who among a ton of other things, contributes to Void Linux. It’s called nitro, and it’s a “tiny process supervisor that also can be used as pid 1 on Linux”, and it also can be used on FreeBSD supervised by FreeBSD’s init. There’s some overlap with runit here, so Neukirchen published a blog post detailing the differences between the two, which should help in getting a better understanding of what makes nitro stand apart. While both use a directory of services managed by small scripts, nitro seems to opt for a more contained, monolithic approach, as it keeps everything in a single process. On top of that, Nitro contains some new features runit doesn’t have. The focus seems to be on integrating a few capabilities that on runit require hacks, but on nitro are just built-in, like “support for one-shot ‘services’, i.e. running scripts on up/down without a process to supervise (e.g. persist audio volume, keep RNG state)”, running service directories multiple times, and more. Nitro also maintains its runtime state in RAM and provides an IPC service to query it, meaning it can be run on read-only filesystems without special configuration. There’s a lot more information in Neukirchen’s blog post, including a look at some of the current limitations of Nitro. I highly suggest reading it, and perhaps we will see nitro as another valid alternative to the popular systemd.
The first prototype was ready in just six months. By October 1986, the project was announced, and in January 1987, the first NEWS workstation, the NWS 800 series, officially launched. It ran 4.2BSD UNIX and featured a Motorola 68020 CPU. Its performance rivaled that of traditional super minicomputers, but with a dramatically lower price point ranging from ¥950,000 to ¥2.75 million (approximately $6,555 to $18,975 USD in 1987). Competing UNIX workstations typically cost closer to ¥10 million (around $69,000 USD). NEWS caught on quickly in universities and R&D labs, where cost sensitive researchers needed real performance. The venture team had invested ¥400 million into development (about $2.76 million USD), and remarkably, they recouped those costs within just two months of launch. That same year, Sony introduced a lower cost version called POP NEWS (PWS 1550). With a GUI shell named NEWS Desk, a document sharing format called CDFF (Common Document File Format), and a focus on Japanese language desktop publishing, PopNEWS aimed to make UNIX more accessible to general business users. Targeted at the Desktop Publishing market, it showed Sony’s desire to bridge consumer and professional segments in ways no other UNIX vendor was trying at the time. ↫ Obsolete Sony’s Newsletter I’ve been fascinated by Sony’s NEWS workstations, and especially the NEWS-OS operating system, for a long time now. Real hardware is hard to find and prohibitively expensive, but some of these Sony NEWS workstations can be emulated through MAME. Sadly, as far as I can tell, you can only emulate NEWS-OS up to version 4.x, as I haven’t been able to find any information about emulating version 5.x and the final version, 6.x. If anyone knows anything about how to emulate these, if at all possible, please do share with the rest of us. What’s interesting about Sony’s UNIX workstation efforts from the ’80s and ’90s is that they played an important role in the early development of the PlayStation. The early development kits for the PlayStation were modified NEWS workstations, with added PlayStation hardware. To further add to the importance of the NEWS line for gaming, Nintendo used them to develop several influential and popular first-party SNES titles, which isn’t surprising considering Nintendo and Sony originally worked together on bringing a CD-ROM drive to the SNES, which would later morph into the PlayStation as Nintendo cancelled the agreement at the last second.
