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.

FreeBSD 15.0-RELEASE arrived this week, notes this report from The Register, which calls it the latest release "of the Unix world's leading alternative to Linux." As well as numerous bug fixes and upgrades to many of its components, the major changes in this version are reductions in the number of platforms the OS supports, and in how it's built and how its component software is packaged. FreeBSD 15 has significantly reduced support for 32-bit platforms. Compared to FreeBSD 14 in 2023, there are no longer builds for x86-32, POWER, or ARM-v6. As the release notes put it: "The venerable 32-bit hardware platforms i386, armv6, and 32-bit powerpc have been retired. 32-bit application support lives on via the 32-bit compatibility mode in their respective 64-bit platforms. The armv7 platform remains as the last supported 32-bit platform. We thank them for their service." Now FreeBSD supports five CPU architectures — two Tier-1 platforms, x86-64 and AArch64, and three Tier-2 platforms, armv7 and up, powerpc64le, and riscv64. Arguably, it's time. AMD's first 64-bit chips started shipping 22 years ago. Intel launched the original x86 chip, the 8086 in 1978. These days, 64-bit is nearly as old as the entire Intel 80x86 platform was when the 64-bit versions first appeared. In comparison, a few months ago, Debian 13 also dropped its x86-32 edition — six years after Canonical launched its first x86-64-only distro, Ubuntu 19.10. Another significant change is that this is the first version built under the new pkgbase system, although it's still experimental and optional for now. If you opt for a pkgbase installation, then the core OS itself is installed from multiple separate software packages, meaning that the whole system can be updated using the package manager. Over in the Linux world, this is the norm, but Linux is a very different beast... The plan is that by FreeBSD 16, scheduled for December 2027, the restructure will be complete, the old distribution sets will be removed, and the current freebsd-update command and its associated infrastructure can be turned off. Another significant change is reproducible builds, a milestone the project reached in late October. This change is part of a multi-project initiative toward ensuring deterministic compilation: to be able to demonstrate that a certain set of source files and compilation directives is guaranteed to produce identical binaries, as a countermeasure against compromised code. A handy side-effect is that building the whole OS, including installation media images, no longer needs root access. There are of course other new features. Lots of drivers and subsystems have been updated, and this release has better power management, including suspend and resume. There's improved wireless networking, with support for more Wi-Fi chipsets and faster wireless standards, plus updated graphics drivers... The release announcement calls out the inclusion of OpenZFS 2.4.0-rc4, OpenSSL 3.5.4, and OpenSSH 10.0 p2, and notes the inclusion of some new quantum-resistant encryption systems... In general, we found FreeBSD 15 easier and less complicated to work with than either of the previous major releases. It should be easier on servers too. The new OCI container support in FreeBSD 14.2, which we wrote about a year ago, is more mature now. FreeBSD has its own version of Podman, and you can run Linux containers on FreeBSD. This means you can use Docker commands and tools, which are familiar to many more developers than FreeBSD's native Jail system. "FreeBSD has its own place in servers and the public cloud, but it's getting easier to run it as a desktop OS as well," the article concludes. "It can run all the main Linux desktops, including GNOME on Wayland." "There's no systemd here, and never will be — and no Flatpak or Snap either, for that matter.

Read more of this story at Slashdot.

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.