
Plan9-9k: 64-bit Plan 9 - gkya
https://bitbucket.org/forsyth/plan9-9k
======
pjmlp
Actually I would rather see someone pick up Inferno and replace Limbo with Go.

Personally I see Plan9 just as a plain transition step between UNIX and
Inferno, where the goodies in terms of architecture actually are.

~~~
Crontab
I think you are the first person I've seen speak highly of Inferno. I've
played with Plan 9 from time to time, so if you have a moment, can you tell me
what you like about it?

~~~
pjmlp
Sure, are you aware of Inferno's web site?

[http://doc.cat-v.org/inferno/4th_edition/](http://doc.cat-v.org/inferno/4th_edition/)

It contains quite some useful information, including the book "Inferno
Programming with Limbo"
[http://doc.cat-v.org/inferno/books/inferno_programming_with_...](http://doc.cat-v.org/inferno/books/inferno_programming_with_limbo/)

Being a security oriented developer, I like that they decided to use a managed
language for the whole userspace (Limbo) leaving C for the kernel and
compatibility with UNIX software.

Basically, the distributed computing ideas and Oberon influences from Plan 9,
merged with type safety.

In a certain way, what Android came to be, almost 20 years before it existed.

~~~
bluejekyll
Do you see a difference between a "managed language" vs. isolation (by means
of containers and/or VMs).

Personally I don't; meaning it should be as good to run software in a jailed
environment and not force the choice of language on developers.

I am curious to see what others think of this, though.

~~~
wbl
If I get RCE in your mail client I read your email. Not letting me persist
doesn't help much more.

~~~
bluejekyll
How does the choice of language prevent that? Sure different languages might
make that harder, but I don't know of many that don't allow arbitrary code,
written by a random developer, to execute poorly defined HTML parser to
possibly exec some hostile code.

There are facilities and standards in most languages to help prevent this, but
can you point out why this is not possible in Limbo? I'm not personally
familiar with it.

~~~
pjmlp
Sure preventing logical errors is hard, but it is already an improvement that
typical C errors aren't possible.

Limbo does not support this, but both Java and .NET allow for security control
at class and method level, however they tend to be misunderstood by most
developers, which don't regularly use such features.

------
qubex
I've always had a soft spot for Plan9 (on account of its architectural purity)
but I've never managed to make it a ”daily driver” despite sincerest efforts
(this coming from somebody who fondly remembers using BeOS pretty exclusively
for at least a couple of years in the latter half of the nineties).

Maybe this will reignite interest in the platform? Maybe somebody will go
ahead to port it to 64 bit ARM so it can be tried on the latest Raspberry Pi?
(Yes I know the 32 bit version exists and works, but...)

~~~
butterisgood
There's Plan 9 Front.

[http://9front.org](http://9front.org)

I've used Plan 9 a few times in the last handful of years.

Someone got a reasonably good Linux emulator working enough to run Firefox.
What more could you need? (ok it was fairly limited in some ways, but shoot
once you have a web browser, most of the rest is cake... especially if it's
Chrome, because then you can install Mosh inside it!)

Not sure if that's practical on Plan 9 right now.

~~~
qubex
Call me odd, but I like native software — web-apps _et al_ are not my style.
Similarly, bastardising everything so Linux binaries run on it kind of defeats
the point (at least in my mind). But yeah, I'm odd.

~~~
derefr
> bastardising everything so Linux binaries run on it kind of defeats the
> point

Is there all that much of a difference between the kind of "secondary syscall
ABI" approaches that allow OSes like Windows and Illumos to virtualize Linux
binaries, and autoconf-based porting of those projects so they compile for the
target OS, if they only use POSIX facilities that both OSes offer the same way
anyway?

I mean, I agree with you when it comes to e.g. programs that use heavy amounts
of OS-specific concurrency or IPC primitives. Postgres in WSL on Windows does
not have the same concurrency semantics as MSSQL on Windows does, because
Postgres is using POSIX concurrency primitives and MSSQL is using NT
concurrency primitives.

But if there's a subset of your kernel's syscall ABI, that already _has_ those
same semantics, and really can just be 1:1 mapped with maybe a few extra
instructions to handle different argument passing conventions—then does
porting such a program _to_ the OS really achieve anything?

------
tombert
I've read a lot of places that say "Plan 9 is basically a better Unix", but
I'm not entirely sure why. Can someone explain what made Plan-9 special? I'm
not asking in a passive aggressive sense, I genuinely want to know.

~~~
fusiongyro
Plan 9 shows that you can reduce the complexity of Unix by changing the idea
behind mount slightly (mounts are inherited by processes rather than global)
and creating a simple network filesystem protocol that applications can use to
expose their state through.

In Unix you often get stuck having to create these walled-off systems. Your
editor's inner state, for instance, is not visible to other applications, so
you need to come up with your own whole programming scheme. Same with your
window manager. And all your networking happens through a separate set of APIs
that are similar to the file descriptor APIs but different enough that nothing
works transparently.

Once you have per-process mounts and a simple network filesystem, all your
applications and devices can start exposing their state over that protocol.
All your software and hardware are automatically networkable if you follow the
design. And you can use Unix utilities to do things that previously would
require whole subsystems to be built. You don't need to build your own
programming language for Acme, because Acme's state is visible as a
filesystem. Same with the window manager. And you don't need to build a custom
networking scheme for sharing Acme with your friend on another machine,
because you can export Acme's filesystem to that machine (or have your friend
export their keyboard onto your machine as a child of the Acme process).

"Everything really is a file" is a good way to sum it up. But that's only
possible and relatively safe because of 9P and per-process namespaces.

~~~
ianai
Wait, are people actually taking plan9 seriously now?

~~~
dullgiulio
All the Docker (namespaces and cgroups) in Linux seems like a bad copy of
Plan9. I'd say yes, but not seriously enough.

~~~
ianai
That's a really good way of putting it. I could see Plan9 being relevant
today. A "unified system" is pretty much what all the cloud stuff is
attempting to approximate (and more poorly, of course).

------
f2f
A little bit of history: Forsyth did the 64-bit compiler for the Plan 9 on
Blue Gene project.

[http://doc.cat-v.org/plan_9/blue_gene/](http://doc.cat-v.org/plan_9/blue_gene/)

(I contributed to the project too: I did the photochop of glenda on the side
of the BG racks! ;)

~~~
butterisgood
Forsyth is also "the Inferno guy" (well, one of them!). I've had a lot of fun
playing around with that little OS over the years.

[http://vitanuova.com/inferno/index.html](http://vitanuova.com/inferno/index.html)

It can run without an MMU too. It's been ported to the Nintendo DS.

------
kruhft
I'd love to be able to sit down and learn Plan9. The shell is awesome (rc),
the commands are somewhat familiar, but the networking is totally foreign and
security setup (factotum I think) I obtuse. I want a Plan9 kernel with no
security for playing and architecting with...they took a great idea and ruined
with security. That should be the outer layer of the system.

~~~
bakul
Richard Miller's port of plan9 runs on every RaspberryPi (pi0 to pi3 - where
it uses all the cores). This may be the easiest way to experience plan9 and to
build a small distributed system. You can experiment with device drivers or do
other kernel hacking fairly quickly -- compiling p9 kernel from scratch takes
about a minute on a 'Pi. This is good enough if you just want to play with
plan9. You need not bother with an x86 system unless you want to use plan9 as
your main system or for some serious work.

~~~
kruhft
Linkage: [http://raspi.tv/tag/richard-miller-
plan-9](http://raspi.tv/tag/richard-miller-plan-9)

------
bloaf
I hope someone can find a niche for Plan 9, be it on the RPi or somewhere
else. So many of its ideas seem to me to be _obviously correct_ in the sense
that they logically and conceptually-purely fix the warts other Unix-like OSes
have.

~~~
cnnrro
Could you expand on that point? While I'm not knowledgeable on the topic I'm
genuinely curious to hear a few examples.

~~~
bloaf
I think this says it very well:

[http://www.catb.org/esr/writings/taoup/html/plan9.html](http://www.catb.org/esr/writings/taoup/html/plan9.html)

>One of the examples from the Plan 9 survey paper is the way FTP access to
remote sites is implemented. There is no ftp(1) command under Plan 9. Instead
there is an ftpfs fileserver, and each FTP connection looks like a file system
mount. ftpfs automatically translates open, read, and write commands on files
and directories under the mount point into FTP protocol transactions. Thus,
all ordinary file-handling tools such as ls(1), mv(1) and cp(1) simply work,
both underneath the FTP mount point and across the boundaries with the rest of
the user's view of the namespace. The only difference the user (or his scripts
and programs) will notice is retrieval speed.

------
someSven
Short question: What were the downsides to use Plan9 or Inferno as the
fundament of a distro insted of Linux? Of course with Linux programms where it
would be necessary.

~~~
gkya
Plan 9 is a complete OS, so things like coreutils are not really necessary
(tho plan 9 utilities are not strictly POSIX compatible). The killer app would
be a good enough web browser, if you're talking about a workstation OS. Other
than that it already has a vast set of utilities, including an extensible text
editor (acme), mail, etc. for development work .

