Liam Proven reports via The Register: The latest version of the systemd init system is out, with the openly confrontational tag line: "Available soon in your nearest distro, now with 42 percent less Unix philosophy." As Lennart Poettering's announcement points out, this is the first version of systemd whose version number is a nine-bit value. Version 256, as usual, brings in a broad assortment of new features, but also turns off some older features that are now considered deprecated. For instance, it won't run under cgroups version 1 unless forced. Around since 2008, cgroups is a Linux kernel containerization mechanism originally donated by Google, as The Reg noted a decade ago. Cgroups v2 was merged in 2016 so this isn't a radical change. System V service scripts are now deprecated too, as is the SystemdOptions EFI variable. Additionally, there are some new commands and options. Some are relatively minor, such as the new systemd-vpick binary, which can automatically select the latest member of versioned directories. Before any OpenVMS admirers get excited, no, Linux does not now support versions on files or directories. Instead, this is a fresh option that uses a formalized versioning system involving: "... paths whose trailing components have the .v/ suffix, pointing to a directory. These components will then automatically look for suitable files inside the directory, do a version comparison and open the newest file found (by version)." The latest function, which The Reg FOSS desk suspects will ruffle some feathers, is a whole new command, run0, which effectively replaces the sudo command as used in Apple's macOS and in Ubuntu ever since the first release. Agent P introduced the new command in a Mastodon thread. He says that the key benefit is that run0 doesn't need setuid, a basic POSIX function, which, to quote its Linux manual page, "sets the effective user ID of the calling process." [...] Another new command is importctl, which handles importing and exporting both block-level and file-system-level disk images. And there's a new type of system service called a capsule, and "a small new service manager" called systemd-ssh-generator, which lets VMs and containers accept SSH connections so long as systemd can find the sshd binary -- even if no networking is available. The release notes are available here.

Read more of this story at Slashdot.

The very short version: Unix PIDs do start at 0! PID 0 just isn’t shown to userspace through traditional APIs. PID 0 starts the kernel, then retires to a quiet life of helping a bit with process scheduling and power management. Also the entire web is mostly wrong about PID 0, because of one sentence on Wikipedia from 16 years ago.

There’s a slightly longer short version right at the end, or you can stick with me for the extremely long middle bit!

But surely you could just google what PID 0 is, right? Why am I even publishing this?

↫ David Anderson

What a great read. Just great.

Michael 'Mike' Karels, one of the authors of "The Design and Implementation of the 4.4Bsd Operating System" and a part of the Computer Systems Research Group at Berkeley, who received the USENIX Association Lifetime Achievement Award, has died. Longtime Slashdot reader bplipschitz shared the news. The FreeBSD Foundation issued a statement in memory of Karels: "We are deeply saddened about the passing of Mike Karels, a pivotal figure in the history of BSD UNIX, a respected member of the FreeBSD community, and the Deputy Release Engineer for the FreeBSD Project. Mike's contributions to the development and advancement of BSD systems were profound and have left an indelible mark on the Project. Mike's vision and dedication were instrumental in shaping the FreeBSD we know and use today. His legacy will continue to inspire and guide us in our future endeavors."

Read more of this story at Slashdot.

The ELF object file format is adopted by many UNIX-like operating systems. While I’ve previously delved into the control structures of ELF and its predecessors, tracing the historical evolution of ELF and its relationship with the System V ABI can be interesting in itself.

↫ MaskRay

The article wasn’t lying. I had no reason to know this – and I’m pretty sure most of you didn’t either – but it turns out the standards that define ELF got caught up in the legal murkiness and nastiness of UNIX. After the dissolution of the committee governing ELF in 1995, stewardship went from one familiar name to the next, first Novell, then The Santa Cruz Operation, then Caldera which renamed itself to The SCO Group, and eventually ending up at UnXis (now Xinuos) in 2011. In 2015, the last maintainer of ELF left Xinuos, and since then, it’s been effectively unmaintained.

Which is kind of wild, considering ELF is a crucial building block of virtually all UNIX and UNIX-like operating systems today. The article mentions there’s a neutral Google Group that discusses, among other things, ELF, but that, too, has seen dwindling activity. Still, that group has reached consensus on some changes; changes that are now not reflected in any of the official texts. It’s a bit of a mess.

If you ever wanted to know the status of ELF as a standard, this article’s for you.

I needed a bit of a break from “real work” recently, so I started a new programming project that was low-stakes and purely recreational. On April 21st, I set out to see how much of a Unix-like operating system for x86_64 targets that I could put together in about a month. The result is Bunnix. Not including days I didn’t work on Bunnix for one reason or another, I spent 27 days on this project.

↫ Drew DeVault

Bunnix’ creator, Drew DeVault, has quite a bit of experience with writing operating systems, as they’re also the creator of Helios, an experimental microkernel operating system. Bunnix is remarkably capable for a 30-day project, and comes with support for both BIOS and UEFI boot, and it’ll boot on real hardware too. It doesn’t have USB support though, so if you’re going the real hardware route, you’ll need to take that into account for mouse and keyboard input.

Bunnix has a relatively solid set of drivers, taking the short development time into account: among other things, there’s PCI, AHCI block devices, serial ports, framebuffers, and ext4 support. The kernel supports a virtual filesystem, a /dev filled with block devices, a terminal emulator, and more. Bunnix is single-user for now, so it doesn’t enforce file permissions, but DeVault states it should be relatively easy to implement multiuser support.

A unique characteristic of Bunnix is that’s written mostly in Hare, complemented by some C. Hare is a relatively new programming language, which we touched on late last year when it was ported to OpenBSD. Implementing file systems proved to be one of the difficulties during development, partly due to Hare.

I also learned a lot about mixing source languages into a Hare project, since the kernel links together Hare, assembly, and C sources – it works remarkably well but there are some pain points I noticed, particularly with respect to building the ABI integration riggings. It’d be nice to automate conversion of C headers into Hare forward declaration modules. Some of this work already exists in hare-c, but has a ways to go. If I were to start again, I would probably be more careful in my design of the filesystem layer.

↫ Drew DeVault

DeVault’s post about Bunnix gives a lot more insight into the development of Bunnix, so I’d highly suggest to head on over to read more. Do note that DeVault considers Bunnix “done”, in the sense that the learning experience is over, and aside from a few random developments here and there, they won’t be doing any work on it anymore.

MacRelix is a Unix-like environment that runs in classic Mac OS.

MacRelix natively supports classic 68K and PPC Mac OS, as well as Mac OS X on PPC via Carbon.

↫ MacRelix website

The creator of MacRelix, Josh Juran, published an article in 2019 detailing the origins of the project. As a Mac OS developer, he was so unhappy with both CodeWarrior and Apple’s Macintosh Programmer’s Workshop (MPW), that he set out to create what would become MacRelix in 1999. Reading through the limitations and roadblocks he experienced with CodeWarrior and MPW, it’s not hard to see why he got frustrated – CodeWarrior’s targets were apparently a mess and a half to deal with.

Then came target multiplication. Whereas the initial CodeWarrior developer releases shipped with each combination of language (C and Pascal) and architecture (68K and PPC) supported in a separate application, a later version of the IDE unified these, allowing the developer to have a single project file per project. To allow the same project to be built for both 68K and PPC architectures, the project data model included targets: One target would compile for 68K and link against 68K libraries, another would do the same for PPC. Targets could also be used to select an optimized build versus one for debugging. Combining both dichotomies yields four targets: 68K debug, 68K optimized, PPC debug, and PPC optimized. Then if your project involves multiple executables, like a code resource or shared library in addition to an application, you now have eight targets. Or, if you support one of, say, 68020 optimization, profiling, or a third executable, make that twelve. Or, for all of them, twenty-seven.

↫ Josh Juran

Changing an option in your application required you to change it in every single target, too, which I can easily see is incredibly frustrating. MPW, for its part, was a massive improvement, he argues, but while it was clearly inspired by UNIX, it didn’t seem to actually implement any of the features and characteristics of UNIX.

However, very much unlike Unix, the MPW Shell had only a single thread of execution — only one program could be running at once. Not only that, but there was no way for MPW’s compiled plugins (called tools) to invoke other tools or scripts — not even via system() (which blocks the calling program until the called program exits). Therefore, Make couldn’t actually do anything, but only printed out the commands for the user to run manually. You could code in Perl instead of the built-in language, but then your scripts couldn’t run other programs — only MPW shell scripts could do that.

↫ Josh Juran

The limitations Juran was experiencing with these two tools pushed him to create his own solution, which went well beyond what MPW offered, even in 2019 when this article was published.

Nowadays, MacRelix has pipes, signals, system calls, TCP sockets, and more. It works on both 68K and PowerPC Mac systems and builds as Carbon to run natively in OS X. It can be used on any Mac OS version from System 7 to Mac OS X 10.6 “Snow Leopard” (after which Apple removed the Rosetta PowerPC emulator). I haven’t implemented fork() yet, but I know how to do it. In addition to a Unix-like file system interface (which even handles long names by storing them in Desktop database comment fields)), MacRelix has a /proc filesystem (with human readable stack crawls) and also maps various parts of Mac OS (e.g. the ROM image in /sys/mac/rom).

↫ Josh Juran

I had never heard of MacRelix, but it seems like an amazing tool Juran put a lot of thought, effort, and love into. Sadly, with the number of PowerPC Mac OS X users being vanishingly small, and the number of classic Mac OS users even smaller so, the future of MacRelix seems uncertain. I wonder what parts of it can be salvaged and upgraded to work on ARM macOS or even Intel macOS, because I think the ideas and concepts are incredibly cool.

A related project by Juran is something called FORGE, a portable windowing API that used a virtual file system, meaning that instead of using functions as objects, it uses files. Juran mentions the example of a window title – which is a file, and if you want to change the title of that window you just change the file, which will be instantly reflected in the GUI. Here’s a Hello World example:

cd $FORGE/gui/port/hello        # select a window port named "hello"
exec 9> lock                    # exclusively retain the port for our use
ln new/caption view             # add a caption as the window’s view
echo Hello world > v/text       # set the caption text
touch window                    # create the window

Even though I’m not a programmer, this little tidbit of code makes perfect sense to me, and I understood it instantly. Of course, anything more complex will quickly leave my wheelhouse, but intuitively, I really like this. FORGE exists as a prototype inside MacRelix, so you can play with this concept while using MacRelix.

Back when I was working on my article about PA-RISC, HP-UX, and UNIX workstations in general, I made extensive use of OpenPA, Paul Weissmann’s invaluable and incredibly detailed resource about HP’s workstation efforts, HP-UX, and tons of related projects and products. Weissmann’s been doing some serious digging, and has unearthed details about a number of essentially forgotten operating system efforts.

First, it turns out HP was porting Windows NT to PA-RISC in the early ’90s.

Several magazine sources and USEnet posts around 1993 point to HP pursuing a PA-RISC port to NT, modified the PA-RISC architecture for bi-endianess and even conducted a back-room presention at the ’94 Comdex conference of a (modified HP 712?) PA-7100LC workstation running Windows NT. Mentions of NT on PA-RISC continued in 1994 with some customer interest but ended around 1995.

↫ Paul Weissmann at OpenPA

The port eventually fizzled out due to a lack of interest from both customers and application developers, and HP realised its time was better spent on the future of x86, Intel’s Itanium, instead. HP also planned to work together with Novell to port NetWare to PA-RISC, but the work took longer than expected and it, too, was cancelled.

The most recent secretive effort was the port of HP-UX to x86, an endeavour that took place during the final days of the UNIX workstation market.

Parts of the conversation in these documents mention a successful boot of HP-UX on x86 in December of 2009, with porting efforts projected to cost 100M+ between 2010 and 2016. The plan was for mission-critical x86 systems (ProLiant DL980 and Superdome with x86) and first releases projected in 2011 (developer) and 2012 (Superdome and Linux ABI).

↫ Paul Weissmann at OpenPA

I’m especially curious about that last one, as porting HP-UX to x86 seems like a massive effort during a time where it was already obvious Linux had completely obliterated the traditional UNIX market. It really feels like the last death saving throws of a platform everybody already knew wasn’t going to make it.