
What Is Not in Plan Nine (2012) - ColanR
http://wiki.c2.com/?WhatIsNotInPlanNine
======
dleslie
Reads like what's missing is all the quality of life tools and polish that
developers rely on daily.

Unix hating, or Unix environment hating, is an uphill battle these days.
Nowadays every major desktop and most phones have, or can have, some kind of
Unix or Unix-like shell.

It's a bit like hating C. I'll probably still be writing C in ten years. I'm
not so certain about _any other language_.

~~~
pushpop
Plan 9 isn’t UNIX hating. It’s a _successor_ to UNIX. Many of the things we
take for granted in UNIX and UNIX-like systems are actually kludge written to
address a short coming of UNIX. Plan 9 was invented to take lessons learned
from that and build on UNIX from a ground up reimagining. Thus it is going to
differ in some ways while feeling very similar in others.

I think it’s fair to say that Plan 9 is a bit less exciting these days because
some of the really great ideas from Plan 9 has seeped its way into Linux and
UNIX. But there is also some degree of “momentum lock-in” going on too where
UNIX is what people are familiar with so it’s what people expect. Though it’s
probably more accurate to say “GNU” these days rather than UNIX (if the
conversations about people loading GNU coreutils on Macs via homebrew are
anything to be believed)

~~~
jacquesm
Plan 9 is more UNIX than UNIX itself. It did away with all the special cases
and the result is a beautiful way to create systems components.

There are only two operating systems that I've worked with that I actually
really enjoyed, the one is QnX and the other is Plan 9, everything else feels
like a series of kludges.

~~~
pushpop
I can sympathise with that. UNIX does get a lot right and if you’re just
scratching the surface of things it feels a very powerful system. There is a
lot to like there but the more I delved deeper in my career the more ugliness
I’d run into. The thing with UNIX is it’s “good enough” in most areas that
people don’t always notice those pain points and it’s ingrained enough that
the alternatives often feel “worse” just by virtue of being different.

------
userbinator
A browser that supports JavaScript.

This appears to be one of those sites that should ostensibly be just static
text, but the source has none of the content and not even Google's text-only
cache manages to show anything. Rather ironic this page is itself inaccessible
to users of Plan9...

~~~
setr
It used to be a very simple static website, and much more likely than not was
just that at the time people were writing to the wiki

Like last year or something they apparently decided to migrate to this mess of
a system, for reasons unknown to me. I think it might be mediawiki software?

~~~
msla
> I think it might be mediawiki software?

What? Wikipedia uses MediaWiki, and it looks nothing like that.

It's also functional without JavaScript.

~~~
setr
I’m thinking of whatever is used for every wikia site

------
JadeNB
> find

> The unix find is a SwissArmyKnife. In PlanNine, the TreeWalking is done by
> du -- a unix `find . -print` is in PlanNine: `du -a|awk '{print $2}'`

Ah, a clearly much more natural replacement.

EDIT: I got downvoted, but I'm not complaining about it, but rather happy to
acknowledge the error of my ways. I cut and pasted what I thought was `du
-alawk '{print $2}'`, a mish-mash of 5 unexplained command-line switches, one
of them duplicated. (I thought the occurrence of the name `awk` among the
switches was just a coincidence.) It wasn't until I noticed the downvote that
I realised that what I cut and pasted contained not an `l` switch but a pipe,
and was _much_ more simple than what I thought. So, thanks, downvoter!

~~~
ori_b
There's also walk, at least in 9front:
[http://man.9front.org/1/walk](http://man.9front.org/1/walk)

~~~
rakoo
UNIX: To recursively traverse directories, use find(1)

Plan 9: find(1) is bloat, use du -a | awk '{print $2}'

UNIX: this is complicated to remember and type

Plan 9: oh you can also use walk(1) to recursively traverse directories

UNIX: so... like find(1) ?

~~~
ori_b
Compare the manpages for find and walk.

------
brianpgordon
I'm not sure I follow the argument about symbolic links. What do they have to
do with the root UNIX thinking that it owns the whole filesystem? I don't
often see symlinks used in the context of crossing "imported" (mounted?) parts
of the filesystem - instead, I use them most often to provide aliases so that
the same file/directory can be accessed with multiple names.

~~~
enneff
If you want the same thing to have multiple names you can just use a hard
link. Symlinks are a broken idea in Plan9 because whether they’re relative or
absolute they may not point to the same thing depending on how you have your
namespace set up.

In plan9 each user has their own set of bound file systems (like mounts, but
for users not the system as a while), and so has their own logical view of the
local and remote file systems, applications, devices, and so on, all presented
as a file system rooted at /. It’s a very powerful and elegant design.
Symbolic links are kind of stupid and broken in that context.

~~~
brianpgordon
On Unix I much prefer using symlinks to hard links. Hard links are super
confusing when you don't know/remember that they're there. AFAIK there's no
easy way to get ls to display them for what they are. If you suspect that
something is a hardlink you have to squint at the inode numbers and see if you
have duplicates. But if you use symlinks, ls will just tell you, and give you
both the link name and destination by default.

I suppose you could use ls_colors to colorize hard links to make them more
visible, but then you have to configure that on every server you ssh to.

------
glangdale
The comment about Rio vs X Windows would make a lot more sense if you could do
the same things in Plan 9 as you could in X Windows. Motif was a giant sack of
crap, but you could make an application that was roughly identifiable as a
"computer application" of the time to a non-technical user, and even
customize/internationalize it (more or less). You'd pretty much be hand-
painting every last UI widget in Plan 9. Ridiculous.

Also this comparison was often used as a celebration of not having objects,
C++, shared libs, etc. on Plan 9. Again, this would be less ridiculous if any
of the large complex things done on other systems that merited shared libs had
ever been done at _all_ on Plan 9.

Unfortunately, many of the good ideas in Plan 9 sank alongside this. If they
had made "APE" a first-class project they wouldn't have been swivelling back
and forth from non-Plan 9 boxes to use the web and the better ideas might have
grown into something. :-(

~~~
ori_b
> _Motif was a giant sack of crap, but you could make an application that was
> roughly identifiable as a "computer application" of the time to a non-
> technical user, and even customize/internationalize it (more or less)._

Motif is also not part of X11. If you want something vaguely like it, there's
libcontrol which is used by a few applications. Nothing about rio prevents
something even thicker from being written (or something like GTK from being
ported), other than a strong distaste for that kind of gui.

> _Again, this would be less ridiculous if any of the large complex things
> done on other systems that merited shared libs had ever been done at all on
> Plan 9._

That's kind of missing the point: The complexity doesn't carry it's weight. I
can do most things I care about just fine on plan 9. The major exception is a
good web browser, which is an OS on its own, and is best when towed beyond the
system and isolated with the birds and fish and tons of crude oil.

> _If they had made "APE" a first-class project they wouldn't have been
> swivelling back and forth from non-Plan 9 boxes to use the web and the
> better ideas might have grown into something. :-(_

The better ideas were largely centered around the simplicity you were just
bemoaning. If plan 9 had focused on APE, there would be little of value they
could have done.

~~~
glangdale
"other than a strong distaste for that kind of gui"

I would suspect that the process of writing a full-fledged windowing system
and graphics layer that people might recognize as behaving roughly like a
modern computer (even running a web browser, yet), while holding true to the
Plan 9 Received Wisdom, would be a intriguing journey of discovery for
someone.

Whether they would emerge as a true believer with their faith strengthened by
this trial, or as a Plan 9 heretic, would be an interesting question.

~~~
ori_b
There's really nothing preventing anyone from implementing what you're talking
about. Some of it's already been done, and undone, at various times.

Rio (well, devdraw, really) presents a similar drawing model to Xrender -- in
fact, Plan 9's draw is listed directly as the inspiration for Xrender. If you
want a fancy GUI, nuklear is ported
([https://github.com/vurtun/nuklear](https://github.com/vurtun/nuklear),
[https://bitbucket.org/mischief/libnuklear/src/default/](https://bitbucket.org/mischief/libnuklear/src/default/)).

Porting GTK would be similarly doable, all that's really needed is getting a
GDK port to do the window management, and porting pixman and cairo for the
drawing. I'm not aware of anything that devdraw+rio is missing for a working
implementation.

And, if you _really_ want, there were multiple ports of X11 to plan 9 that
could be revived -- Equis, for example, , so you could in theory just get did
of Gnu-isms, revive one of those unused bits of code, and run it that way.

Again, there are existence proofs -- nothing about plan 9 prevents any of what
you're talking, other than the people using plan 9 don't want it, and the
people that want it don't want plan 9, or are almost entirely "ideas people"
that aren't going to contribute a line of code towards making what they want
work.

Web browsers are a different story. The problem with a web browser is that a
modern web browser is tens of millions of lines of code to implement a turd
that's churning at an incredible rate; Last I looked, Chrome was 20 million
lines of code, and needed upwards of 600 substatial out-of-tree patches to
even build on BSD. And my bank's website breaks on versions below 70 or so,
which means running constantly just to stay with a working version.

We don't have resources to maintain that shit.

For a while, there was 'linuxemu', which emulateds the linux syscall ABI, but
even that had a ton of churn, and nobody put in the effort to keep up to date.

Given that plan 9 is all volunteer driven (especially today), if nobody writes
the code, nothing happens.

> _Whether they would emerge as a true believer with their faith strengthened
> by this trial, or as a Plan 9 heretic, would be an interesting question._

The question is "what do you want out of this"? To me, this sounds like an
awful lot of pointless work that makes the system quite a bit less pleasant,
with code that's too big to really understand and easily debug, and a UI model
that I don't even use regularly on Unix if I can avoid it. It gives me the
same reaction as someone proposing making Linux compatible with MVS (IBM's
mainframe operating system), complete with JCL and the data set file system.

------
msla
> vi, emacs, ...

>> Try acme or sam.

The idea that your OS determines your text editor is fundamentally broken.

The idea that your OS determines your GUI model is also fundamentally broken.

Both of those notions destroy loose coupling, which is a fundamental design
principle.

And this...

> objects

>> BellLabs didn't need them since the complexity is back under control.

... is really too incoherent to refute.

~~~
pushpop
You have to bare in mind the era Plan 9 was released in. The concepts of
decoupling the OS from your choice of user space tools is actually quite a
modern one. Back in the 89s and 90s things were a lot more fragmented. You had
a whole plethora of home computers, from 8bit micro computers, whose
implementation of BASIC were largely incompatible with each other, through to
entirely different designs of personal computers (back when PC didn’t just
mean “IBM compatible”). So machines like Atari ST/Falcon, Amiga’s various
machines, Apple Macintosh/Lisa/etc, Acorn Electron et al. Even on the IBM PC,
there wasn’t really the breadth of choice that there is now.

So people did choose their OS based on what software why wanted to run.

Even in the enterprise space things were more fragmented with less
compatibility across the various UNIXes and Linux wasn’t really a viable
option until the late 90s.

It’s very easy to judge Plan 9 through the perspective of modern ideals and
the expectation of POSIX everywhere but that wasn’t the case when Plan 9 was
written. For its era, Plan 9 is has a number of very pioneering concepts.

------
pmoriarty
I'd say that emacs would be the main thing missing for me.

~~~
nicklaf
As an Emacs user myself, I share your pain.

You will find the following Easter egg in the distribution, though:

    
    
      term% man 1 emacs
    
         EMACS(1)                                                 EMACS(1)
    
         NAME
              emacs - editor macros
    
         SYNOPSIS
              emacs [ options ]
    
         DESCRIPTION
              This page intentionally left blank.
    
         SOURCE
              MIT
    
         SEE ALSO
              sam(1), vi(1)
    
         BUGS
              Yes.
    

[http://man.cat-v.org/plan_9/1/emacs](http://man.cat-v.org/plan_9/1/emacs)

