Plan 9 didn't catch on for a lot of reasons -- bad licensing, bad marketing, being too different from unix which was "good enough", etc. The fact that your average nix sysadmin, who can manage pretty well between BSDs, Linux, AIX, HPUX, etc, would be utterly puzzled when given the task of managing a plan 9 system, probably discouraged a lot of businesses from adopting it.

If you are not married to your current editor of choice, give Acme a try -- it's quite different, but I've been using it as my primary for about 5 years (I write mostly write C, Bash, Python, Go, Puppet. Hesitant to use it for more editor-dependent languages like Java and C#), and I've been very happy with it. It's available for Linux, BSD, and OS X as part of plan9port. For me, secret to being productive in Acme was learning to write my own plumbing rules, which let you turn plain text into hyperlinks based on pattern matching.

Plan 9 does not have to be a purely historical endeavor; If you manage to write a 9P file server, you can actually mount it on other OSes, either through the native 9P support in the Linux kernel, or through a wrapper program like 9pfuse. For example, I recently saw a 9P file server that turned jira into a file tree of tickets that you could edit with a text editor.

With the garbage ticketing systems I am used to, JIRA as a file tree, 9p or FUSE on Linux/OSX, has me almost aroused.

People wonder why I cannot do things fast in their GUI world, and then I show them a bash script that obviates 10x per page operation filing a ticket, and then they do not understand, but respect my annoyance at the "user-friendly" way.

http://9front.org/ is the most actively developed fork, and is the most likely to work on your hardware. They don't take themselves seriously, though, and are perfectly fine with being niche, so they don't put much effort into being welcoming to people who don't do their reading.

I got curious when you said they don't take themselves seriously. There are some pretty funny files in the /lib/ directory of their source tree. https://code.9front.org/hg/plan9front/file/0d00dd23c9db/lib/... for example.

I think at least part of the problem was the hardware required to run a more complete installation where you'd start to see the benefits of the approach. As the paper outlines, a Plan 9 network needed at least a CPU server, file server and one or more terminals, plus possibly an authentication server (the CPU server might have been able to do this too). I seem to remember that the installation instructions assumed you'd have this kind of hardware available too, so getting a working system was quite an investment.

The file server was somewhat specialised too: the Plan 9 one used an optical WORM jukebox to provide its long-term storage. If you didn't have one of those you could simulate it with disk storage, but there's a cost trade off there.

Without this investment in hardware it was like trying to understand how NFS or web infrastructure works with only a single machine to work with.

In some ways it's similar to the obstacles that hobbyists face investigating the Hadoop ecosystem today: the hardware required to build a realistic installation on which to experiment is quite costly. With Hadoop you can use virtual machines and/or cloud hosting to try things out. When Plan 9 came out you didn't have that option so you needed to assemble physical hardware yourself.

> As the paper outlines, a Plan 9 network needed at least a CPU server, file server and one or more terminals, plus possibly an authentication server (the CPU server might have been able to do this too).

... which can just be run on the same machine.

> Without this investment in hardware it was like trying to understand how NFS or web infrastructure works with only a single machine to work with.

Network transparency is an important feature, but not the only one. You are saying running X makes no sense because your X server and client are on the same machine.

> You are saying running X makes no sense because your X server and client are on the same machine.

No, I'm saying that it's hard to properly understand the advantages Plan 9 (or NFS or X or Hadoop) brings if all you have is one machine to run it on.

>From what I've read it seems like the lack of ubiquity forced the Plan 9 guys out of Plan 9 and back into Ubuntu or OpenBSD

That's… interestingly ahistorical. No one was force back from plan 9 to ubuntu or openbsd because when plan 9 "lost" neither existed. Plan 9's window of opportunity existed in the early '90s when linux and the web weren't firmly established.

Unfortunately Plan 9 wasn't released with a proper license until 2002, at that point Linux had already won the war (for half a decade), the problems that plan 9 solved had been solved in other ways (perhaps less elegantly) by the rest of the world, plan 9 lagged behind on a number of important areas and bell labs were being downsized significantly.

I said this after reading this conversation [0] on comp.os.plan9 about rc. Though it does appear that I misread that as well. However, my point was that it seems like the shift away from Plan 9 or 9front or whatever took place in the late 2000s when they moved to Ubuntu or OpenBSD due to work concerns because it was easier to support the masses. (I cannot find the conversation on comp.os.plan9 to support that though.)

[0] https://groups.google.com/forum/#!topic/comp.os.plan9/g2qBh0...

> my point was that it seems like the shift away from Plan 9 or 9front or whatever took place in the late 2000s

I didn't see that happen.

> From what I've read it seems like the lack of ubiquity forced the Plan 9 guys out of Plan 9 and back into Ubuntu or OpenBSD.

Sigh. Really?