
The Plan 9 Effect or why you should not fix it if it isn't broken - terminalcommand
http://www.di.unipi.it/~nids/docs/the_plan-9_effect.html
======
cantrevealname
One of the messages of the article is to identify if there is a market. I must
have read this a thousand times so far in my life. It's as if so many product
failures and millions of developer-hours could have been saved if we followed
this advice and thought really really hard about the market. It's so simple
and we're morons for not embracing this wisdom.

The problem is _you just don 't know_. You might create a new market where
none existed or completely take over a very crowded market, or (much more
likely) fail regardless of what your marketing research told you.

How does the author explain the huge success of the original UNIX? It violates
everything he says. Certainly Dennis Ritchie and Ken Thompson weren't thinking
about the size of the market for a new OS. UNIX was incompatible was
everything that existed at the time and AT&T could have used an existing OS
for everything they needed done.

Facebook is another good example of _you just don 't know_. Probably there
were a thousand other equally smart Zuckerbergs trying to create a social
whatever in 2004. One succeeded and 999 failed. Was it because Zuckerberg was
thinking hard about the market and the others weren't? Many of the factors you
don't understand, don't control, can't predict, and can't even explain more
than a decade later.

~~~
wpietri
>How does the author explain the huge success of the original UNIX? It
violates everything he says.

The original Unix was not created as some sort of grand solve-the-
world's-problems vision. It happened because some people on project like that,
Multics, said, "fuck it, let's spend a month building something simple that we
can actually use." Market 1: themselves.

From there, they found other people with needs and they solved them. Market 2
was another department that needed a word processor; they made one. Then more
Bell Labs departments needed an OS for their shiny new computers, so that was
market 3.

So yes, the history of Unix very much fits with the "find a market and solve
their problems" notion. It's true that they weren't thinking strategically
about long-term world domination. But that's sort of the point of the
"identify a market" notion: vast, airy thoughts about strategy often lead to
product that nobody uses. Whereas focusing solving very specific needs of
actual users (that is, your chosen market) is frequently a path to success.

It's basically the same deal with Facebook. Facemash was just Zuckerberg
fucking around. When he found that it had real resonance for people, he tried
something more ambitious in the space. But he didn't say, "I'm going to
totally change the way humans interact by creating a technological marvel." He
didn't spend millions of dollars or years building amazing infrastructure. He
made a small, basic product for a single school. Only when he had proof that
he had product-market fit did he worry about scaling up. And he got that
product-market fit by paying attention to the market, his fellow students.

~~~
richardboegli
MVP and shipping. Then add value adding features and review customer fedback.

~~~
wpietri
Yes. I think both also proceeded by making major inroads into very small
markets before expanding. Facebook in particular didn't get their first users
by launching something adequate for a lot of people. They launched something
that was a home run for a small group. Then they went school by school,
dominating each as they went.

The truth is that each adopter makes their own decision; the more you can make
something that's stellar for one person, the better a base you have to expand
from.

------
hodgesrm
> The first one is not to try to fix things that are not broken or better, if
> you want to fix them, only fix the broken pieces and do not try to fix what
> is clunky but it does, somehow, work as it is intended to. For instance,
> UTF-8 is a wonderful idea and you need to do that but you can implement that
> in libraries or subsystems in such a way that you can use it in other
> operating systems more than create an operating system all around an
> encoding system.

I disagree 100%. The Plan9 use of Unicode and UTF8 was visionary.

Character set handling was seriously broken on all Unixen in the 1980s. One
major problem was the range of character sets available on most hosts which
constrained the type of character data applications could handle easily.
Another was the plethora of competing, overlapping encodings like EUC-JIS and
SJIS or the myriad of ISO-8859 encodings. This required constant mapping (or
rather partial mapping) between different layers of the stack with attendant
hits on usability, configuration problems, data corruption, etc.

Unicode with UTF-8 storage encoding almost completely solves these problems,
the more so as software up and down the stack adopts the same conventions. At
least on the projects I worked on then in the DBMS industry we would have
gladly taken the hit to upgrade.

[edit] corrected typo

~~~
bhaak
The article almost makes it sound like UTF-8 was a Plan9 invention.

I also don't understand why using UTF-8 was a bad idea. If I start a new OS
from scratch, I would have to be brain-damaged to not use UTF-8 as the sole
encoding (and other encodings being treated as second class citizens).

I can understand the issue with taking the file abstraction to perfection. If
by doing that you are incompatible to most of the software there is, you're
going to have a hard time getting developers to develop for your OS. This
could be somewhat alleviated with a ioctl compatibility library for the time
being.

~~~
qwertyuiop924
Character indexing in UTF-8 is O(n). That's not enough to kill the awesome
parts of it, though.

~~~
nickpsecurity
Is there a list of alternatives with various tradfoffs mentioned?

~~~
qwertyuiop924
UTF-32 is kinda-sorta O(1), but not really if you want to get what a user
logically claims to a character.

------
avmich
Reading the article it's tempting to say sometimes it borders on
ridiculousness :) .

> No one, in the Unix world, ever complained about the Unix's missed promise
> about file abstraction.

The whole world, sans programmers, keeps moaning on complexity of computers,
and Unix, and how hard it is to learn all those arcane commands and
abstractions and why things can't be just plain and simple. I'll skip rants
about how it's related to file abstractions :) .

Being fully aware how the same things could look very different from different
angles, I'd still maintain the "not broken - don't fix" approach has been
countered then and now.

~~~
pcwalton
> The whole world, sans programmers, keeps moaning on complexity of computers,
> and Unix, and how hard it is to learn all those arcane commands and
> abstractions and why things can't be just plain and simple. I'll skip rants
> about how it's related to file abstractions :) .

There are a lot of things about Plan 9 that really aren't that good in 2016.
The compiler, for example, lacks a modern optimization pipeline and generates
code that is unacceptably slow by modern standards. The windowing system is
not a compositing window manager; it's a '90s design through and through and
cannot perform as well as solutions like Wayland (that are arguably simpler).
The browser doesn't support dynamic changes and would have to be rearchitected
to support anything more than simple pages with acceptable performance.

None of this is meant to bash the great work that the Plan 9 team did while at
Bell Labs/Lucent, mind you. With the team they had they did a really great
job, and they're all top-notch developers. I only want to counter the notion
that Plan 9 is all around a technically better OS than the ones we use today.
It isn't.

As sad as it sounds, most complexity exists for a reason. There is a good
amount of cruft that could be dropped if not for backwards compatibility, but
when e.g. compilers are concerned, you depend on that complexity for
performance.

~~~
f2f
> The windowing system is not a compositing window manager

8½ perhaps wasn't, but Rio is a compositing window manager.

~~~
pcwalton
Not in the modern sense of compositing GPU buffers.

~~~
mveety
Since when does the window manager have to use the gpu to be considered a
compositing window manager?

~~~
pcwalton
This has devolved into a fairly pointless semantic debate. What I'm saying is
that rio is not built around compositing hardware surfaces, like all modern
windowing systems (DWM, Mac CGS, Wayland) are. A windowing system that is not
architected this way will always have inferior performance, and retrofitting
the proper design onto an existing one based on memory buffers and drawing
commands is difficult to do (see all the problems with XCOMPOSITE).

------
random778
[http://plan9.bell-labs.com/plan9/about.html](http://plan9.bell-
labs.com/plan9/about.html)

"Introduction

Plan 9 from Bell Labs is a research system..."

It does not seem that it was ever meant to compete with or replace
commercialized operating systems. The direct output of research is not
something you sell - but it does give the world better things which can be
industrialized.

~~~
kgwgk
> It does not seem that it was ever meant to compete with or replace
> commercialized operating systems.

UNIX was also a research system. The following paragraph from the article
would also by applicable:

"One of the major problems with Plan-9 was that AT&T and the people behind
Unix, while they were incredible scientists and programmers, they were not
used to create commercial software and AT&T has never been in the software
business. (...) They used software and they used to produce internal software
to run their high end network appliances but they never created software to be
sold to someone else and it never was major source of revenue (...). This just
means that they never had a sense of what could have been needed into the
outside world."

If anything, this problem was relatively less important for Plan 9 given that
they already had some experience in creating research systems that would
become mainstream.

Edit: By the way, saying that "AT&T used software and they used to produce
internal software to run their high end network appliances" seems a bit of an
understatement. Quoting wikipedia: "Researchers working at Bell Labs are
credited with the development of radio astronomy, the transistor, the laser,
the charge-coupled device (CCD), information theory, the operating systems
Unix, Plan 9, Inferno, and the programming languages C, C++, and S. Eight
Nobel Prizes have been awarded for work completed at Bell Laboratories."

~~~
random778
I'm not sure that I follow your argument. Are you saying that because a
similar research project was successfully commercialized Plan-9 should be
judged akin?

Even if you accept that, UNIX was not developed to what it became by AT&T. Let
arguments about how they managed licensing UNIX vs how Plan-9 was licenced
commense!

~~~
kgwgk
I'm not trying to argue with what you said, but pointing at the weakness of
the article's conclusions. As another commenter just wrote "How does the
author explain the huge success of the original UNIX? It violates everything
he says."

------
Animats
It's interesting to look at QNX's implemention of POSIX. In QNX, the POSIX
library mostly makes calls for interprocess communication, using MsgSend and
MsgRecv. That's the real underlying primitive. Not files. MsgSend works like a
remote procedure call - you send data and wait for a reply. (There's a timeout
mechanism available, and you can time out anything that blocks. Real-time OS,
remember.)

QNX lets you make anything look like a file, by writing what QNX calls a
"resource manager". This takes over a subtree of the pathname space, and the
library turns create, open, close, read, write, and ioctl calls into the
appropriate MsgSend calls. That's how you write a file system under QNX as a
user process. But there's no reason to turn things into files unnecessarily.
Displays are not files, for example.

QNX has what looks like a Berkeley sockets interface, but "send" and "recv"
call the same thing as "write" and "read". You can use read and write on a
socket. I think you can use "send" and "recv" on a file system, too.

If you're going to have one primitive, MsgSend and MsgRecv are a better choice
than files. But it's easy to get that wrong. Mach botched it, and for decades,
microkernels had a bad rep.

~~~
jacquesm
QnX is one of the under-appreciated gems in the OS landscape. I still hope
that RIM will entirely open-source it and I'd happily contribute a good sized
chunk of money towards a ransom.

~~~
Animats
It was open source for a while under Harmon, and free for non commercial use.
I wish I'd downloaded it all back then. I'd like to see a QNX-like OS in Rust.

~~~
jacquesm
> I wish I'd downloaded it all back then.

IIRC there were some license issues.

> I'd like to see a QNX-like OS in Rust.

Hm... now that would be an interesting 'side project'.

------
webkike
> I am quite sure that you do not know what Plan-9 is and that, probably, you
> never have heard of it too.

Right off the bat with a failed assumption. Of course I know what Plan 9 is,
I've used it lots. Why make this assumption? Just say "most people" and you've
already hedged your bets.

~~~
nitrogen
If you already know you aren't the target for someone's writing, and you could
figure out what it meant anyway, why bother complaining about it? It's a
rhetorical device, not a declaration of fact. Read like a human, not a
computer, and you might enjoy life a lot more.

~~~
chrismonsanto
Oh please, it's a poor use of rhetoric, and calling that out doesn't mean that
you are somehow a robotic emotionless monster.

~~~
wpietri
I think hyperbole is a fine use of rhetoric. And I think "read like a human,
not a computer" is not talking about a computer's lack of emotion, but its
need for precision and order. In contrast to human adaptability.

~~~
nitrogen
Thank you, that is what I intended.

------
ktamura
>Moreover, in Plan-9, many of the "good old things" were removed and a lot of
incompatibility was introduced in the system with respect to the other Unixes.
This prevented many different companies to even start thinking of porting
their applications to Plan-9.

This is fundamentally why plan9 didn't take off. It was too different and not
better enough.

Platform technology marketing is being on the right side of a nuanced
dichotomy:

1\. You need to be different enough to be noticed and given attention 2\. And
better in the eye of the user (which implies familiar)

For example, OSX was a great success among hacker types for this very reason:
It was different yet familiar (Most UNIX-y stuff just worked on OSX thanks to
its FreeBSD lineage).

Another example is Go: It's different enough from the previous generation of
server-side languages to command attention, but its syntax was very much in
the C language tradition (And it articulated its "betterness" well, such as
performance gain over Python/Ruby and ease of use over C/C++/Java).

Fundamentally, Plan9 was way too different from the incumbent without any
clear advantage.

~~~
davidjnelson
I find your point 1 and 2 to be very insightful. It strikes me as why react
native is doing so well on it's platform technology marketing. Different
enough: mostly javascript and a consistent mental model for ios, android, and
perhaps web. Better in the eye of the user: More shared code, faster tooling
and workflow due to compile speed improvements.

------
protomyth
Let's say for the sake of alternatives, that Plan 9 was released to the public
in 1995 under the MIT license. I think at least one of the BSDs would have
used the C compiler, but I think it would have been bigger than that.

------
bakul
Another view is plan9 didn't become popular because it was not freely
available. If it had been "freed" prior to when 386bsd was first released,
history might've been different. I knew about it much before 386bsd came out
and would've jumped at the chance to use it....

------
massysett
Seems to be saying that Plan 9 introduced one thing now on most unix-like
systems (/proc) and another thing now on most systems period (UTF-8). However
Plan 9 was a total failure and a waste of time and teaches us not to solve
problems if they aren't a big deal. ?

~~~
coldtea
Yes. Those two (and a few more) good things about it that solved real problems
were adopted.

Most others, including its central premise about everything actually being a
file, were not (adopted or successful), and turned out they weren't a big
deal.

If from one product with 1 central premise and 10 new features the world only
adopts 2 of those features, I'd still call it a "total failure" market-and-
adoption wise, and a waste of time for those building it.

They could have built those 2 features independently anyway.

~~~
mwfunk
Plan 9 was not a product though. You seem to be arguing against the concept of
research in the software world.

~~~
coldtea
It was packaged into a product called Inferno later on.

And it was only "research" because AT&T (or Lucent at the time?) couldn't sell
it.

~~~
jff
Inferno isn't Plan 9. Written by the same people, yes, but it's a different OS
running on a virtual machine rather than x86, different programming language,
etc. The main commonality is 9P, which enables some other similarities such as
Acme, synthetic filesystems, etc.

------
SixSigma
Not "was" but "is".

Just because _you_ don't use it doesn't mean _we_ don't. Pop by the #plan9 irc
channel on Freenode some time, or lurk in #9front as see the daily commits.

~~~
keithpeter
9front has _brilliant_ propaganda.

If I could get texlive, a graphical browser and an rdp client running under it
I could live there after I retire. Until then it remains something of a toy
system _for me_ (others may disagree). I'd be delighted to hear from those
using it for actually creating stuff.

~~~
msingle
I know that
[kertex]([http://www.kergis.com/en/kertex.html](http://www.kergis.com/en/kertex.html))
works on plan9, if there are parts missing between kertex and texlive, Thierry
(the creator of kertex) could probably give you some pointers on getting those
working too.

~~~
keithpeter
Main issue would be TizK for diagrams. I might try building it under a fresh
slackware (I noticed a slackbuild script) and see what I get.

------
rectang
It's _still_ beautiful. Damn this world of network effects.

~~~
agumonkey
We should have a group of people dedicated in catering to beauty whether or
not it manages to create a large market.

------
donatj
So never simplify anything? Let everything become more and more complicated
with band aid fixes until no one has any idea how the hell the whole thing
works or any clue why things happen. Sell people a faster horse, because
that's what we've really wanted all along? Is that the moral of this?

~~~
eumoria
Don't try to fix things. Just pile more garbage on top of it until it sort of
works. Sounds like modern programming

------
mwfunk
It was a research OS. That by itself renders the entire article moot. It's
akin to someone writing an article about how Minix "lost" vs. Linux- it's
apples and oranges. You can't call something a failure if it was never
intended to be the thing you claim it failed at being.

~~~
hollerith
Some of the people behind Plan 9 lobbied AT&T's management very hard for years
to get permission to open-source it, which they obtained in 2002. (Lucent
Public License 1.02 satifies the Open Source Definition and the Debian Free
Software Guidelines.)

Some of the people posting to the Plan 9 mailing list at that time from
plan9.bell-labs.com addresses certainly hoped that Plan 9 would catch on.

In the 1990s Rob Pike tried to persuade one of the major browser vendors to
support Plan 9.

------
qwertyuiop924
Yeah. The compatability problem, or why Windows is still crazy after all these
years. Build it close to right the first time: the world won't give you a
second chance.

I really like Plan9's ideas, but its community gravitates to catv.org, which
is full of assholes who believe that if it hasn't been blessed by Murray Hill,
it has no merit, no matter what the real world has to say.

I'm going to get crucified for this, aren't I?

~~~
jff
cat-v is full of assholes, yes, and most of the Plan 9 community retains what
I call "a sad devotion to an ancient religion"\--anything written at Bell Labs
is holy writ, anything written outside is suspect and probably tainted, must
purge the heretics.

However, most of your objections down-thread are "People are used to X/Y/Z, it
is literally impossible to change them now."

~~~
qwertyuiop924
Some of them are, but replacing image formats with PS is just a Bad Idea. And
non-csp concurrency is necessary, like it or not.

------
jff
I'm sure the guy who thinks it's spelled "Plan-9" has some very insightful
things to say. Maybe it's time for me to blog about Ruby/On/Rails, the latest
web-dev hotness.

------
yegortimoshenko
With such conclusions you are not going any further than PDP-11 assembly
language.

------
wavefunction
You need to structure your brilliance to focus it in one direction.

------
necessity
Assuming ignorance out of your audience is a great way to make people close
your website's tab before reading anything else.

------
MustardTiger
I don't think the assumption of brilliance is warranted. Plan 9 was facing an
uphill battle due to the lack of conformity, sure. But it wasn't a brilliant
system, it was pretty bad. If it had been brilliant, maybe it would have won
that battle. But I don't think it is far to say brilliance fails without
conformity based on a single example whose brilliance is very debatable.

