Evaluating Plan 9 (and Inferno)

[Repurposed HN comments. May grow into an article. Saving for my own reference.]

There are a lot of things in Plan 9 which are not improvements over conventional Unix... but it seems to me that this is partly because it's stuck in its tiny little niche and never got the rough edges worn down by exposure to millions.

I was a support guy, not a programmer. I started Unixing on SCO Xenix and later dabbled in AIX and Solaris, and they were all painful experiences with so many rough edges that I found them really unpleasant to use.

Linux in the 1990s was, too. Frankly WinNT was a much more pleasant experience.

But while Win2K was pleasant, XP was a bloated mess of themes and mandatory uninstallable junk like Movie Maker. So I switched to Linux and found that, 5-6 years after I first tried Slackware and RHL and other early distros with 0.x or 1.0 kernels, it was much more polished now.

By a few years later, the experience for non-programmers was pretty good. It uses bold and underline and italics and colour and ANSI block characters, right in the terminal, because it assumes you're using a PC, while the BSDs still don't because you might be on a dumb terminal or a VAX or a SPARCstation or something. (!)

Linux just natively supports the cursor keys. It supports up and down and command-line editing, the way Windows does, the way PC folk expect. BSD doesn't do this, or very poorly.

Linux just natively supports plain old DOS/Windows style partitions, whereas BSD did arcane stuff involving "slices" inside its own special primary partitions. (GPT finally banishes this.)

I've taken this up with the FreeBSD and OpenBSD devs, and they just plain do not understand what my problem is.

But this process of going mainstream on mainstream hardware polished the raw Unix experience -- and it was very raw in the 1990s. Linux from the 2nd decade of the 21st century onwards got refined into something much less painful to use on

Plan 9 never got that. It still revels in its 1990s-Unix weirdness.

If Plan 9 went mainstream somehow, as a lightweight Kubernetes replacement say, it would soon get a lot of that weirdness eroded off. The purists would hate it, of course, just as BSD purists still don't much like Linux today.

Secondly, Plan 9 did a tonne of cleaning up the C language, especially (AFAICT) after it dropped Alef. No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned.

The other vital thing to remember is that despite 9front (and HarveyOS and Jeanne and so on), Plan 9 was not the end of its line.

After Plan 9 came Inferno.

I have played around with both and just by incorporating late-1990s GUI standardisation into its UI, Inferno is much more usable than Plan 9 is.

Plan 9 made microkernels and loosely-couple clustering systems obsolete >25y ago.

A decade or so later, Inferno made native code compilation and runtime VMs and bytecode and all that horrible inefficient 1980s junk obsolete. It obsoleted WASM, 2 decades before WASM was invented.

With Plan 9, all the machines on your network with the same CPU architecture were parts of your machine if you wanted.

(A modernised one should embed a VM and a dramatically cut-down Linux kernel so it can run text-only Linux binaries in system containers, and spawn them on other nodes around the network. Inelegant as all get-out, but would make it 100x more useful.)

But with Inferno, the restrictions of CPU architecture went away too. The dream of Tao Group's Taos/Intent/Elate, and AmigaDE, delivered, real, and FOSS.

When considering Plan 9, also consider Inferno. It fixed some of the issues. It smoothed off some of the rough edges.

I feel, maybe wrongly, that there could be some mileage in somehow merging the two of them together into one. Keep Plan 9 C and native code as an option for all-X86-64 or all-Arm64 clusters. Otherwise, by default, compile to Dis. Maybe replace Limbo with Go.

-----

It doesn't need cgroups or containers, because every process has its own namespace, its own view of the network-global filesystem, so everything is in a container by default.

It doesn't need a microkernel, because the concept of microkernels is to split a big monolithic kernel into lots of small simple "servers" running in user space, and have them communicate by passing messages over a defined communications protocol, some kind of RPC type thing. It works, and QNX is the existence proof. But it's really hard and it's really inefficient -- of which, the HURD and Minix 3 are the existence proofs.

So most of the actual working "microkernel" OSes kludge it by embedding a huge in-kernel "Unix server" that negates the entire microkernel concept but delivers compatibility and performance. Apple macOS and iOS are the existence proof here. (It could be argued that Windows NT 4 and later are also examples.)

Plan 9 achieves the same result, without the difficulties, by default by having most things user space processes and communicating via the filesystem.

Disclaimer: this is my very rudimentary understanding. I am not an expert on Plan 9 by any means.

------

In general, what I am getting at is that Unix is a (?) uniquely weird situation that happens to have grown like Kudzu. It's an early generation of a long running project, where that early generation caught on and became massive and thus ignores simple but profound improvements from later versions of the same project.

And since in that ecosystem, almost everything is built on a foundation of C, problems with C affect everything layered on top... even though they do not in any other ecosystem. But something like 99% of inhabitants of the ecosystem are not even aware that other ecosystems even exist, let alone knowing anything about them.

If they know of any, it's macOS or Windows. macOS is also UNIX, and modern Windows is NT, which is Windows built with Unix tools and a Unix type design... so they are not really different at all.

So what I am getting at is that Plan 9 has aspects other than the namespaces and the cosmetic aspects of the design. It makes changes to the language and how it's compiled that are just as important, and hacks to gain some of that on modern versions of the parent OS family are not of comparable significance.

Famous quote:

<<

So... the best way to compare programming languages is by analogy to cars. Lisp is a whole family of languages, and can be broken down approximately as follows:

* Scheme is an exotic sports car. Fast. Manual transmission. No radio.

* Emacs Lisp is a 1984 Subaru GL 4WD: "the car that's always in front of you."

* Common Lisp is Howl's Moving Castle.

>>

Comparison: if somehow you make a pruned-down Howl's Moving Castle, you can probably never ever, whatever you do, no matter how much effort you invest, make it into something as small and light as the Subaru, let alone the sports car.

In more detail:

Let's imagine one team invented first the train, then the bicycle, then the car.

The bicycle takes the idea of a wheeled vehicle from the train but reduces it down to an incredibly minimal version. It needs no fuel, just 2 wheels, but it is very simple, very light, and can go almost anywhere.

Although you do need 1 per passenger, it's true, whereas a single carriage train can carry 100 people, you can make 100 bicycles for those 100 people with fewer materials than that 1 train, even excluding consideration of the rails etc.

If someone still making trains looked at bicycles and inspired by them came up with a train with just 2 wheels, that balanced or hung from the track, they do not get to claim that they have successfully imported the simplicity of the bicycle.

They have retained just one aspect and may have achieved savings in moving parts, or slight reduction of complexity, or a slightly simpler machine... but it's still a train.

If you tweak a conventional C compiler to not waste time rereading text that has already been read once, or a disk cache obviates it, then you have not caught up with the advance I am trying to discuss here.

For clarity, this is not my original thinking. This idea is from a Go talk over a decade ago:

https://go.dev/talks/2012/splash.article#TOC_5.






               

Comparing niche programming languages to the mainstream

[Another repurposed HN comment, saved for my own reference as much as anything]

I think you are focusing on the trees and so not seeing the size and the shape of the forest.

Most organisations use C and languages implemented in C, on OSes implemented in C, because they do the job, the people are cheap and readily available, and the dominant OS is free and costs nothing to deploy.

Which can be reduced to:

Most people use the tools most people use.

That's not a very useful observation, but it poses an interesting question:

Why?

That's easier.

Here is the shape of the outside of the answer:

They use them not because they are good -- they aren't very good, measured objectively -- but because they are ubiquitous and cheap.

Other tools are better, and just as free, but then the people cost more, and the associated tooling costs more. (Frameworks, supporting libraries, deployment costs, whatever. E.g. it's very cheap to deploy Javascript because all you need is a reasonably modern browser, and those are free and almost all OSes have them.)

Those are the externalities, in a manner of speaking.

But the other side of the answer is the inside: the area, not the shape.

The mainstream, conventional, software industry is huge, and hugely lucrative.

Writing just-barely-good-enough apps, minimum viable products, gets you out there and making money. Then you can put a share of your revenues into incrementally improving it.

Every now and then you can push out a big new version, with disruptive changes. You can charge for getting the new major releases, but more to the point, once an old version is officially obsolete, you can charge for continued fixes to the now-obsolete versions.

It makes money. It's an ecosystem, a food chain or more accurately a web. Some members are predators, some are prey, but they all work together and if you just eliminate either predators or prey, the system collapses.

In other words:

Most people use the tools most people use, because most people use them, because you can make big money from volume of cheap junk.

But there is another model of making and selling stuff: make small volumes of really good products, using highly skilled workers, and sell those high-quality products in very small volumes but for very high prices, to discerning customers who know they're buying something built to last and who may not come back to you for new versions every couple of years, but that's fine if you made a couple of decades' revenue from them on the original sale.

Because cars are a long standing metaphor in computers and computing:

If you have a mass market for cars, then you get cheap cars, and everyone's cars are much the same because they are built down to a price and mass produced.

These car consumers can be upsold some extra buttons and minor features, and a lot of those combined may double the price of the car.

(This is how different Linux distros survive. Some have more buttons. Some have A/C. Some are fully automatic, others have fully manual controls. Some have power steering, some don't.)

But such a market also supports hand-made sports cars (and, inevitably, superficially similar cheaper sports cars from the mass-producers). It also supports vast tanklike cars that weigh as much as 10 normal cars, but produce 10x the engine power of those cars so they still perform.

Very different products, but they cost an order of magnitude more than the mass-produced cars... and do the same job. Some owners of mass-produced cars aspire to own fancy sports cars, and some aspire to own luxury behemoths. Most never will.

People who don't care much for cars and just see them as a tool for getting from A to B do not see why anyone would pay for fancier cars. That's OK, too.

Some people live in other countries and see more clearly, because for them trains and bicycles are a perfectly viable way of getting from A to B, and are both cleaner, healthier, use less resources and create less waste.

Tools like Lisp are the artisanal hand-made cars compared to the mass market. People who've never used anything but cheap mass-produced tin boxes can't even imagine that there are things that are so much better, let alone that in the long run, you might be better off using them.

As Terry Pratchett put it:

« “The reason that the rich were so rich, Vimes reasoned, was because they managed to spend less money.

Take boots, for example. He earned $38 a month plus allowances. A really good pair of leather boots cost $50. But an affordable pair of boots, which were sort of OK for a season or two and then leaked like hell when the cardboard gave out, cost about $10. Those were the kind of boots Vimes always bought, and wore until the soles were so thin that he could tell where he was in Ankh-Morpork on a foggy night by the feel of the cobbles.

But the thing was that good boots lasted for years and years. A man who could afford $50 had a pair of boots that'd still be keeping his feet dry in ten years' time, while the poor man who could only afford cheap boots would have spent a $199 on boots in the same time and would still have wet feet.

This was the Captain Samuel Vimes 'Boots' theory of socioeconomic unfairness.” »

Some of us live in countries with really good public transport, and know that it's possible to replace the entire category of personal automobiles with something better for everyone...

But try telling that to an American. They won't even try to understand; they will instead earnestly explain why they need cars, and their country is better because everyone has cars.

More wild generalisation:

In the late 20th century, there was another model of software construction, an alternative to the "Worse is better" model. The WIB model is that one type of software fits all, and build one (or a very few) minimum viable operating systems, from minimal viable programming languages, and make them cheap or give them away for free.

The artisanal software model was more common in Europe and Japan: pick the best language for the job, and build tiny bespoke OSes for each category of device. Have multiple whole incompatible families of desktop OSes, and families of totally different unrelated server OSes, and families of different OSes for handhelds and games consoles and school computers for teaching kids, and so on.

Unify them, minimally, with some standard formats: network protocols, disk and file formats, maybe some quite similar programming languages in lots of weird little nonstandard dialects.

iTron, RISC OS, SiBO/EPOC/EPOC32/Symbian, QDOS/Minerva/SMSQe, Con-Tiki, Symbos, GEOS, Novell Netware.

Keep the complexity are the market level, in which multiple radically different products compete for sales in their market segments. Lots of overlap, lots of duplication... but also competition, evolution, rivalry, advancement.

The software remains small and relatively simple. This aids development, but mainly, it keeps the resource requirements low, so the devices are cheaper. Human brainpower is cheap: spend it on clever software to enable cheap hardware.

The approach I am calling WIB is of vast general-purpose OSes which can do anything, so you only need a handful of them... but you need massive hardware to run it, so devices powered by WIB software are expensive, and very complicated, and the software is vastly complicated, so you need armies of programmers to maintain it, meaning frequent updates, so you need lots of storage and fast connections.

And there is no overview, because it's much too big to fit into a single human head, so improvement is incremental, not radical.

The end result is a handful of vast monoliths, full of holes and leaks, but a vast economic machine that generates continuous income and lots of jobs.

When you live in one of these monoliths, the fact that there are happy accomplished people working in weird tools making weird little products for tiny markets seems incomprehensible. Why would they?

Most people use the standard tools, meaning the ones most people use. So obviously they are good enough: look at these trillion-dollar corporations that use them!

So obviously, there isn't really any point to the weirdoes.