The Front Fell Off
On actual hardware, I’d no luck getting Plan 9 to boot properly, until coming across 9front . 9front is extremely fun times, having been updated to boot more easily and support more hardware, among other things (and thanks, in part, to Erik Quanstrom’s fork, 9atom which is a bit more modest in scope). Its hardware support is pretty good, and although there are still some kinks being worked out, it’s coming along nicely. I recommend trying out a nightly build, as it’s stable enough and the development is active. I had some oddness during the install (a crash, and some driver issues), but the wonderful devs in the #cat-v channel on freenode were kind enough to fix them immediately, pass me a kernel, and look at photos I took of my laptop’s screen to debug. So, after a couple of hours, I had my first working Plan 9 installation on actual hardware.
9front contains a number of userland updates, most notably a port of the Go Programming Language and some package management facilities.
It’s also, as far as I can tell, the only OS that has built-in trolling. It comes with a copy of “Mein Kampf” in /lib, for example. There is also a troll command:
cpu% troll New people are unwelcome. Please do not get involved.
Another Plan 9 fork, Nix is also undergoing pretty active development. Where 9front is wonderfully pragmatic (which is great if you want to, you know, actually run the software) Nix is a little more research-oriented and largely focused on the kernel, experimenting with performance on multi-core CPUs with an eye towards HPC, and some interesting filesystem work. It’s interesting stuff, and they have some PDFs. There’s also a blog that’s full of interesting reads. If you want to actually run Nix, though, you’ll need to build a system from inside Plan 9 or using 9vx.
Virtualization: The Network is the Computer, but the Computer is Fake.
Which is a great segue to talking about 9vx . 9vx is built atop vx32, an unconventional (but not exactly new) approach to virtualization: segmentation registers and instruction translation. An excellent introduction to this is provided by No Execute , and if you are interested in creating or working with virtual machines (from interpreters to emulators), I can’t recommend No Execute enough. In particular, the Nostradamus article is an addictive read for coders.
9vx uses vx32 to emulate enough of a PC that you can run Plan 9 in a window under your host OS. It certainly feels much more comfortable than using QEMU/KVM for the same task, and it runs a little more speedily.
If you’re interested, Ron Minnich’s repo seems to be the most up-to-date.
Digression: Just Forget Mixing a 32-bit Userland with a 64-bit One on Linux
I had build failures and segfaults for vx32 and the provided 9vx, sadly, until I built out a 32-bit chroot and jumped inside there. Every Linux distribution I’ve ever tried has caused severe pains when trying to handle 32- and 64-bit systems on the same box; un-tarring a bunch of CRUX packages inside /opt/32 and tweaking /etc/ld.so.conf has been wonderful, though: there’s no conflation of libraries, you can run 32-bit programs fairly easily, and life is beautiful forever. You’ve got to chroot into it to build 32-bit binaries (glibc and gcc are largely to blame for this), but it’s worth it to have things Just Work. Sure, it’s semi-hacky, but it’s easier than debugging other people’s Makefiles.
9P2000: The Network really is the Computer. The Network is also a Filesystem.
Back to Plan 9, though, it’s worth learning about, if for no other reason than to understand where Unix could have gone. I’m more convinced than I was before that it is where Unix might go in a few years, so it is definitely worth learning if you agree. For one thing, the underlying protocol, 9P2000, now has support in the Linux kernel, as well as in the Plan 9 from User Space tools as a set of userland programs. I’ll spare you the details about the interesting bits of Plan 9 for now; there is plenty out there to read, and DuckDuckGo is a fine place to start if you’d like to see what you can accomplish when everything actually is a file, there is no root user, and the network (which is represented by a filesystem) actually is the computer (which is also a filesystem).
Building distributed computing into a programming language seems silly when you could have it built into the OS. GNU’s attempts to bolt TCP onto bash and gawk seem somewhat pointless if networking can be handled by the OS. (Seriously they did this to both programs.) And if the OS does handle these things, then even cat and echo can talk to the network.
Inferno Has the Best Names for Things
Most of the interesting ideas in Plan 9, as well as some new and also interesting ideas, made it into Inferno . Inferno’s Styx protocol extended the original 9P, and was the basis for 9P2000. (As with 9vx, building it required a 32-bit chroot, sadly.) What makes it interesting here are four things: portability, Limbo, Dis, and the shell.
As far as portability, you can build or download Inferno for Unixes, Plan 9, MacOSX, and Windows. It runs on a variety of chips, but most importantly (for the time being) are x86 and ARM. There’s even a port to Android if that’s your thing.
Limbo is the systems programming language for Inferno. If you have caught any of the interesting concepts from Go , you might be pleasantly surprised to find that most of them (e.g., channels, lightweight processes, and a host of others) are in Limbo, one of the languages that influenced Go heavily. Coding in Limbo, much like using Plan 9 on the desktop, feels a lot like a strange amalgamation of the past and the future. Channels, for example, for communicating between processes, are a lot like a combination of Unix pipes and Erlang’s “!” operator. On the flip side, Limbo is verbose in places, requiring some amount of boilerplate for programs as simple as “Hello, World!”. (After a few Limbo programs, I typed out my last chunk of boilerplate for a program to generate Limbo’s boilerplate for me.)
The Dis VM , the next fun Inferno feature, is a lightweight VM for running Inferno processes. It can run in “hosted” or “native” mode, meaning that a full Inferno OS can be started up as a userspace program in Linux/OSX/Windows/Plan 9/etc., or you can boot Inferno on hardware by itself. It features JIT, exact garbage collection (so that memory is freed immediately after the last accessible reference disappears), speed, and a small footprint. As in Plan 9, everything is a file in ways that modern Unix only dreams of, and the network is the computer in ways that 1990s Sun Microsystems could also only dream of. Speaking of Sun, there is a JVM to Dis bytecode translator if you’re intested. (I wonder if any of the hip new JVM languages have been attempted on Dis.)
The Inferno shell is one of the most interesting features, however. It’s based on the rc shell by none other than Tom Duff of Duff’s Device fame. rc is a great shell, especially for scripting, runs almost everywhere, and is the default shell for Plan 9. Inferno’s version introduces an FFI to Limbo. Re-read that sentence if your jaw and the floor haven’t connected yet.
Through the Inferno shell builtin “load”, you can load modules that expand the shell’s builtins. For example, Inferno comes with a module to add regex support to the shell, one to add CSV support, and another to add support for Tk . I’ve not seen a feature quite like this in a shell, although I mostly stick to bash or rc, not having tried out the slightly more exotic ksh or zsh shells, which for all I know also have that feature.
So I’ve been doing quite a bit of playing with Inferno recently. As usual when learning a language, the first thing I do is implement a couple of solutions to Project Euler problems, and the solutions can be found on Github (as usual). I’ll be discussing Inferno in depth in a future post, probably a few posts.
There are a number of cool things that are simple in Inferno, and they’re worth writing up. In particular, I want to discuss a fun (and useful) hack to illustrate the power of the Inferno/Plan 9 approach to filsystems. I’ve also had trouble finding good information about getting off the ground with Inferno, so I anticipate writing a few entries about that. I’ve also started a small project using it, since it’s the nicest way to bring these facilities to a wide number of platforms.
<< Previous: "In Which are Discussed Hosting and Wikis"
Next: "Inferno Part 0: Namespaces" >>