Personally I see Plan9 just as a plain transition step between UNIX and Inferno, where the goodies in terms of architecture actually are.
It contains quite some useful information, including the book "Inferno Programming with Limbo" http://doc.cat-v.org/inferno/books/inferno_programming_with_...
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.
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.
With a type safe language, being used alongside isolation mechanisms, I get two layers of protection, at language level and at the sandbox level.
Like Android or ChromeOS do with their managed environments + Linux SE and on Samsung's case Knox.
If the language is unsafe, everything outside the jail might be safe, but the program integrity or the data inside of the container are exposed to the attackers.
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.
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.
obviously you would call this DisGo and the resulting system would be DisGo Inferno
My X Windows is a bit rusty, but I remember most managers use all three buttons.
The real issue for me is laptop trackpads. It's impossible to use Plan 9 (or derived works) with one in a natural fashion.
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...)
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.
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?
It would be nice if Plan 9 had vim or emacs.
Furthermore there exists "A Posix Emulator" (ape) that is serviceable.
Or maybe it just shows my bias for IDEs. :)
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.
> Same with your window manager.
> You don't need to build your own programming language for Acme, because Acme's state is visible as a filesystem.
I don't see how it's good programming practice to expose your internal state to direct read/write access from other programs. It seems to violate basic encapsulation principles.
Your quotes are making me think of some really important takeaways from the Longhorn disaster with WinFS, detailed in a recent submission:
> More profoundly, Bill’s vision of an ecosystem of applications that all store and share their data in this relational store is in direct conflict with how applications build their data models. While some desktop applications (and almost all internal IT-written ones) use relational stores for their internal data model, they do not want to expose those data models for unmonitored read and write by other applications. I detailed some of the fundamental reasons in the post referenced above, Leaky by Design.
Solutions like this... "what if application state were like a relational data store, or hierarchical FS, that other programs can access", sounds great as a fun programming exercise, but it isn't often how people actually want to design applications.
The development seems active, the last commit was made 7 hours ago.
Last time I checked the project was still in its early stages. Docs and stability have improved a lot since then.
Sidenote: I think 9P protocol and plan9 userland like ACME editor is available on linux.
I don't have a ton of cash but I believe in the hacker culture and as an aspiring developer I figure I'd put my money where my mouth is.
It would be nice, if they'd provide an ISO. The thing I noticed about Plan9 clones and Inferno is that, they almost always run entirely in the userland. I think that's the reason HarveyOS does not provide an iso. I am not sure they are building a standalone operating system.
If you're interested you could also try inferno, however getting it up and running is also a hassle.
Lastly, in the case you're not aware, Plan9 and inferno also have a very interesting history. Inferno and Java were once direct competitors. Limbo a programming languages invented for Plan9 is also mentioned in the Dan Brown's best seller Digital Fortress.
IMHO Plan9 spirit still lives in Golang, like the Lisp Machines' spirit lives in Emacs. Maybe with cloud based OS's we could see the ideas behind Plan9 in everyday world. But other than that Plan9 remains an OS for hobbyists and idealist computer folk :).
This is a property exclusive to inferno.
Right down to the TCP/IP stack... you can run a program called "sshnet" and connect to a remote unix box, the /net in that process' namespace now has a tunnel to the remote box, and all children of that process that opt-in to share the namespace now have a VPN-like to the network you just ssh'd to.
Because the network stack is a file system you can do basic open, read, write, close stuff to dial up remote services and work with them. As such there's IRC clients written in the shell, without evil extensions like /dev/tcp in bash.
It's fun, but it doesn't outrun any other OS I've seen. Maybe that's changed.
9p is v9fs in linux. There's FUSE 9p stuff for other platforms. There's a virtualized Erlang runtime that sits directly on Xen as the OS that uses 9p. 9p is part of QEMU's way of talking to the guest (or is it the host?) OS.
It's been on a lego mindstorm brick too.
To me, kernel dbus is a bit more like mach_ports. Those have their own advantages too. As did Solaris Doors.
That kind of pervasiveness involve replacing all i/o through the entire system with dbus. File systems, netlink, sun rpc, mmap, signals and kill, tcp, and so on.
And then making dbus sanely deal with networking and authentication.
9p isn't just pervasive: it's the only way to talk to the system, which means that if you want to mess with namespacing things, all you need to think about is 9p.
So with that in mind, I would rephrase that as "Inferno is basically a better Unix".
You can learn more about it, including the programming manual with lots of Limbo examples at:
You can easily see some of Go's pedigree on Limbo's design.
Nowadays Inferno is still being sold by Vita Nuova, the company that acquired the rights after Bell Labs folded the project.
Alef was pretty neat too and was also on Plan 9
It really is a neat idea, and shows what can be done when you take an idea to its logical extreme. But the interface is not human friendly. Real-world workloads are complicated and require kernels that handle the weird edge cases so you can't reduce a production kernel to a simple idea. And 9p performance lags behind other networked file systems. So it's really more of a prototype and a laboratory for generating ideas to be used in other systems, rather than a replacement for production Unix.
Distributed name spaces, distributed computing, compute servers, distributed file servers and so on.
Remember the SUN slogan 'the network is the computer'? Plan 9 makes that a reality.
- Truly everything is a file. No exceptions; no special cases.
- Symlinks do not feel like a hack causing trouble. If you need a reference to a directory in another path, you mount it. If your software writes its binaries into its custom directory and you want the binaries within the $PATH, you mount that custom directory into /bin (or so, from what I remember).
- Namespace isolation for processes.
- Distributed file system
This is seriously underappreciated IMO. You can entirely replace access control with private namespaces without any real loss in generality. In fact, they're more flexible and secure.
You see some of these ideas in Linux, but as with all Linux kernel technologies they all feel like they've not been written with a design in mind from the start (just look at epoll, namespaces, /proc, and so on).
As graphics fan, I wonder how this would work out with modern GPU driver layers.
Though Rob Pike might have not been very cooperative or
He goes on about some interesting architectural advantages
already in Plan 9 from a graphics programming standpoint and
capitalizing on them someday.
It'd be interesting to hear about how far along he got.
Here he talks about trying to hack Plan 9 to run Quake
> "Unix allows file systems to be built up from disparate resources using concepts such as links and file system mounts. These features masked the original directory; if one mounts a new filesystem on the directory named "net", one can no longer access its previous contents until the operation is reversed.
> Plan 9 introduced the idea of union directories, directories that combine resources across different media or across a network, binding transparently to other directories. For example, another computer's /bin (applications) directory can be bound to one's own, and then this directory will hold both local and remote applications and the user can access both transparently.
> Using the same system, under Plan 9 external devices and resources can be bound to /dev, allowing any device to be shared over the network without any additional code."
So, you can union mount other machines /dev/cpu/ folders into your machine's /dev/cpu folder and then have access to all the CPU's. Same for all other hardware, software and storage.
Just these two things - Union Mounts and 9P - when built into the whole system, create a very dynamic distributed computing environment. I really, really wish more of this would make it into Linux. We've kinda got some of it, but without joining up all the other bits, the real power isn't quite there.
Union mounts and 9P are already available in Linux. What other things would you like to see?
 - https://lwn.net/Articles/325369/
 - https://www.mjmwired.net/kernel/Documentation/filesystems/9p...
It's also not really a central concept. plan9 doesn't have a $PATH env var, for example - you just union mount all your binaries into `/bin`.
Again, yes there's an implementation on 9p for linux - but it's not baked in and it's not used by the system as a unifying abstraction - this makes it fairly useless:
> Unlike most other operating systems, Plan 9 does not provide special application programming interfaces (such as Berkeley sockets, X resources or ioctl system calls) to access devices.
> Instead, Plan 9 device drivers implement their control interface as a file system, so that the hardware can be accessed by the ordinary file input/output operations read and write.
> Consequently, sharing the device across the network can be accomplished by mounting the corresponding directory tree to the target machine.
It's really having this stuff baked in and then combining them that gives you the power & elegance: https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Combinin...
C replaced by Go, as Inferno replaced it with Limbo for userpace applications.
As for your SML hint, I leave here "Unix system programming in OCaml" :)
(I contributed to the project too: I did the photochop of glenda on the side of the BG racks! ;)
It can run without an MMU too. It's been ported to the Nintendo DS.
I've just begun experimenting with it on my personal server and like it so far. Its still an early project though.
You can put the camera into upspin by running a little directory storage server nearby -- or on the camera depending on how much control you have -- and then you've got access to the data whether it's a video stream or a series of static frames. Whatever it is. But it's encrypted, it's accessible only by the people in your family, which might be the name of an upspin group you created. It has you your wife and your other kids, or whatever. " - Rob Pike on Upspin at GopherCon 2017
https://youtu.be/giUatBmmb_Y?t=1h38m3s (talk starts at 1:19 https://youtu.be/giUatBmmb_Y?t=1h19m19s)
There is currently a little research into what it looks like to expose something like a webcam as a file and how streaming interfaces look in the system, but, the client to stream the webcam file is a little hacky still.
That said, I think the goal of upspin is that you easily can re-use its interfaces to do things like this. There are already some guides about writing custom shim storage servers like that (the main example being a webcam server), but I think this sort of experimentation is still in the early phases.
>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.
So the Linux programs that would be necessary are glibc and gcc, and if you had those you would be able to compile most command line software except for anything that used anything but the standard C library (which would now have been ported to Plan9). Of course, anything accessing most files in a Linux filesystem would break, since Plan9 uses a different layout, and anything that called Linux system calls directly would also break, even UNIX ones, because Plan9 is not Unix.
Going up the stack just makes things worse. You couldn't use any GUI program because you don't have GLX or EGL support for render targets. You don't have OpenGL, so anything written against that can't work.
So you are basically restricted to command line programs that are isolated and make no attempt to use kernel features or arbitrary files in the file system. Even simple things you don't innately think of, like XDG directories, aren't available in a Plan9 environment because its not an X system, so software that uses those won't be able to find the standard config or local cache directories (they will just pull blank envrionment variables and at best write to the current working directory). If you set those variables up manually, you could run stateful software... that didn't use direct Unix system calls.
On the bright side, you could probably get some programming language runtimes to work. Depends on if, say, your Python interpreter uses platform specific system calls or only depends on libc. CPython at least absolutely does have platform specific code paths that would break on Plan9 (because they would assume Unix defaults in the absence of Darwin or NT) but I'm not sure about, say, Pypy. Those runtimes would still be constrained to text only, since the Plan9 graphics layer isn't related to anything in Linux.
Plan9 isn't a kernel, its an operating system in the RMS GNU/Linux sense. Linux distros really depend more in general software on the GNU part than the Linux part, which is both why projects like Debian can drop in Hurd and not have billions of man hours of porting work to do to make it happen and why traditional desktop Linux applications aren't all over Android.