I understand why they wonder but it should be a 10 minute thought exercise in most cases.

You have to define "better". Is it synonymous with "easier", "type safe", "less resource intensive", "object oriented", "functional", "faster" or some combination thereof.

How will you maintain backwards compatibility? Because, despite the fact that you may have just graduated, there are scripts and programs that rely on scripts that go back decades and people are NOT going to rewrite them just because of your new whiz-bang solution.

You may use it and if you represent a large enough organization, it might be viable for that use case but if you're only shopping a solution in search of a problem, you may as well not waste your time.

Plan 9 is not "better enough". The other ones had fundamental non-technical problems that hurt their adoption (Plan 9 had those at the beginning too).

Back to Plan 9, you can expect something that is just slightly better than your current options, and that keeps being this way to steadily gain adoption until it's popular. But that requires it being no worse than the current on any popular use case. Plan 9 may have a great architecture (I'm not sure about that anymore), but OSes compete on many different fronts, like portability, performance, software availability...

If the Plan 9 architecture were something amazingly better that solved a lot of problems, you could be sure some people would have adopted it, and then it would start improving on the other dimensions. But it's not. It's better. It will make your life easier. Yet it will bring no order of magnitude change. So, people simply take a deep breath and write (again and again) the 3 or 4 lines of code required to solve their problem in Unix, instead of changing everything.

I'll say that if you could run a web browser on Plan 9 and maybe there was a POSIX or a Linux compat layer, it could've become popular. It'd be a boost to porting efforts if it was a usable desktop OS. Give me the best OS, but if I have to write a whole desktop/server stack on it to make use of it, I'll stick with what I have at hand.

A plethora of software is available for Unix and it's why it's here still. Had I the chance to switch to, say HaikuOS, without a big/complete productivity loss, I would.

Your stated reasons aren't valid. I think they ported Mozilla until 2002 (Russ Cox, maybe?). There was also a compat layer: APE.

As a counter to your argument: a system that has little capability compared to the well-established alternatives, starts from nothing, yet takes over the world: Linux.

I really believe there was no greater reason for Plan 9's failure to catch on (or at least it's ideas) than my peers not being interested in their own education.

I read the plan-9 papers and was excited to play with it. I had a .edu affiliation and it was still $500 for a tap eand license and a letter saying what you planned to do with it... or some such. I had no budget, so we used linux.

They did open it up eventually, after linux had quite the following. It it had been open/available it would have had a chance.

It sounded fine the first time I heard it, but I don't buy the "it wasn't free and Linux was available" argument any more. If more Linux users had read the papers like you, and done so early enough, they might have had an aggregate influence on Linux's design when it was still malleable. A Plan9-like Linux would have been just as good as Plan9 eventually.

Plan 9 had fundamental technical problems too. Like most of the systems of that time it was designed with small single-building kind of networks in mind and didn't offer any value once large planet scale networks came to life. Also everything could have being implemented on top of any unix system, but wasn't that interesting for anyone to bother.

Didn't Plan 9 eventually get some mechanisms to facilitate interactions between such local-only networks around the world? 9grid and such.

In any case, Plan 9 is still ahead on quite a few fronts, with federated authentication that is simple(-ish) and works, a versioned filesystem by default, a unified namespace (the new interpretation of "filesystem") to access any resource you might want to use (instead of, today: DNS + TCP ports + HTTP URL's), and security by only exposing the necessary resources to processes, instead of exposing everything and then making up contrived access restriction schemes on top. (Smells of capabilities by Pike's own admission, I believe). That last part was mostly thanks to namespaces which Linux has picked up and popularised in a simple form with Docker... after 20+ years.

The important bits of the new architecture were also about the parts that were left out. No disk usage utility, based on the rapidly decreasing price of a giga bytes. Go and try to make contemporary sysadmins, who still partition their drives to this day, accept this highly distruptive simplification. Gotta create ourselves our busywork!

In the end, Plan 9 was made by /educated/ people with /resources/, and much of today's software isn't. No surprise it's better made.

(edit: some structure added to my rambling.)

Most of them were fixed in Inferno, but by then most stop paying attention.

To the point even on HN many seem to be unaware that the line ended on Inferno and not Plan9.

Personally, I tend to slot Inferno closer to Java than to Plan9, even though I'm clear about the lineage. In that sense, the line of "real" operating systems ended at Plan9.

For me it is Inferno.

If you look at the architecture of mobile OSes, they were in the right direction.