r9: Plan 9 in Rust | Hacker News Reader

r9: Plan 9 in Rust

github.com

120 pointsnoja45 comments

It may be that I didn’t “get” Plan 9, but it feels very tied to its GUI the same way Windows does. Yet, the way it treats the network transparently is fascinating and I wish we had more diversity in the OS space and Plan 9 would be brilliant in a cloud setting where you could just extend your workstation’s capabilities to whatever cloud service you can pay for.

There has to be more in the OS space than Unixes and MVS-derived OSs

It’s not at all tied to the GUI (rio). It’s more tied to the idea that resources can be exposed as file systems and distributed via 9p.

Rio is a file system service providing GUI capabilities (kind of). You still need libraries to draw frames in windows etc.

The network stack is a file system.

HTTP clients can use a file system (webfs) to access servers.

And so on.

One could make a replacement for rio if they wanted to.

The protocol used to draw stuff on the screen isn’t 9p though, curiously.

> The network stack is a file system.

See this[1] document for details on how that's done.

Pretty much as I expected, eg connections are directories with the parent directory being the protocol, and there's separate files for control messages and the data. Control files are read and written in ASCII to avoid endian issues.

How would you expose something like OpenGL though? I mean, would you serialize the individual GL calls into a custom RPC and feed it to a "gpu/0/opengl/data" file? Exposing the GL calls as separate files could work I guess, if there's guarantees that writes to separate files maintain order (can't seem to find any clear discussion on this right now), but given the number of calls available that seems like it might generate a lot of overhead.

edit: on the upside, exposing the calls as files means it's easy to expose GL extensions, either the respective files are there or they're not.

[1]: https://plan9.io/sys/doc/net/net.pdf

In a sense yes, but also no.

Plan 9 was built with the observation that high-resolution, bitmapped graphics displays were ubiquitous, and there was little motivation to keep the dated "tty" model as a basis for interaction. So you're expected to a graphical interface for working with the system, but it doesn't _need_ to be `rio`.

I wrote a bit about this a few years ago: http://pub.gajendra.net/2016/05/plan9part1 (I guess I should get around to actually supporting HTTPS here....)

> Plan 9 was built with the observation that high-resolution, bitmapped graphics displays were ubiquitous

My impression is that Plan 9 was a child of the technical workstation age - when we thought that the endgame was having ever more powerful desktops who did most things locally and connected over a network to send and receive files. In the end, our desktops and laptops have been fast enough for the past decade or so, while servers are becoming increasingly more like the mainframes we thought had their days counted and a lot of the heavy lifting is done remotely. A lot of what I do includes firing up a surreally large cloud machine, run a couple data transformations, and then unceremoniously delete that big workstation (that's actually a small slice of a humongous server). And, the rest, is mostly applications running on what I assume are clusters of cloud machines that expose an HTTP interface to my browser (a lot like the beloved 3278 terminal, but not nearly as clicky and tactile).

Plan 9 definitely wasn't built with the thought that the endgame was ever more powerful desktops doing most things locally. "Connected over a network to send and receive files" is only technically true, yeah it's all around the 9P protocol which is a filesystem protocol, but it's a world where everything is a file. A window on your screen is a file. A CPU is a file. And app is a directory with files in it. The Plan 9 vision is all the things you describe, but more seamless. Firing up a a surreally large cloud machine isn't starting a VM with its own separate OS and configuration, it's connecting to a cloud CPU and your tasks transparently running on it. Mostl applications running on a cluster of machines that expose an HTTP interface to your browser are instead applications running on a cluster of machines that expose a 9P interface to your OS. Your impression of "the endgame was having ever more powerful desktops who did most things locally" was the Unix trajectory, and steering away from that was the big departure of Plan 9 from Unix.

>There has to be more in the OS space than Unixes and MVS-derived OSs

Haiku which comes from BeOS. I don't recall the linage of BeOS and the wikipedia entry is lacking but it is not Unix, anyone?

It is not Unix or even Unix-like but they added a POSIX compatibility layer so that you can use a variety of familiar programs.

(Haiku developer here.) This is a pretty common misconception, but it isn't true; Haiku doesn't have a "POSIX compatibility layer", it's just natively POSIX under the hood. You can find some elaboration on an old forum thread: https://discuss.haiku-os.org/t/is-haiku-a-unix-like-os/8801/...

I think what I meant is that the OS model of what a program is constrains what we think can be done on it. I can't think of anything that couldn't be done in Haiku that can be done on Windows or a Unix.

When I think of non-Unix and non-MVS i'm thinking more on the line of the IBM i, PalmOS, or the Newton OS. All three are quite alien under the hood to anyone who grew up on a Windows/Unix world.

If that is what he meant than iOS and Android are that, their touch interface allows you to do things which can not be done in the Windows/Unix world which is why the Windows/Unix world is bringing in touch.

Does Haiku/BeOS have a lineage, were they built off of some other OS in anyway or just their own thing which took what it liked from what was already around and started from the ground up?

At the time, Be often talked about it being clean, legacy-free, ground-up etc.

The main _inspiration_ was the Amiga, but not really AmigaOS.

BeOS was built in the still-new C++ but AIUI predates a lot of standardisation of C++ which subsequently happened -- as was Psion's EPOC32 and its later rebranding as Symbian.

Android, ChromeOS, iOS and iPad OS have very little correlation to UNIX userspace, if any at all.

Same applies to cloud native development, when going serverless, or deploying language runtimes directly into cloud infrastructure.

So there is some hope beyond UNIX and MVS derived OSes.

I’m not sure I understand what you mean (well to be honest if blunt I think I understand and believe it doesn’t really make sense).

Android has bsd-derived core utils on top of a souped up Linux kernel. That’s pretty much a textbook Unix-like. Meanwhile Darwin is Unix-certified and a significant part of XNU was originally lifted from BSD.

Unless you meant the Java based/NDK development experience? But then you can have the same thing on a Unix machine: once you are removed enough from the OS what it is doesn’t really matter.

In a way, I think I agree with you in that I also believe that what’s happening at the lower-level matters less and less for the majority of developers.

Try to write a pure, classical, UNIX application and sell it on the Play Store.

Without rooting devices.

Likewise, try the same on iOS/iPad OS/watchOS.

Only C and UNIX/POSIX APIs, nothing else.

"Transcending POSIX: The End of an Era?"

https://www.usenix.org/publications/loginonline/transcending...

"POSIX has become outdated"

https://www.usenix.org/publications/login/fall2016/atlidakis

By that standard, desktop Linux isn't real unix either (X11 isn't POSIX, and Wayland certainly isn't).

It’s not, that is why it’s considered Unix-like

Okay, then Android can be unix-like too.

Try to write full compliant POSIX CLI in Android.

I use termux on a daily basis.

> what’s happening at the lower-level matters less and less for the majority of developers.

Kind of. It constrains what you can do by constraining what you can represent by the semantic model the OS defines. Unix-like OSs think of processes, threads, files, networks, etc. Plan 9 unifies a lot of that - everything is represented as a file system and, in that sense, it frees one to think of networked resources as nothing more than files. Now think about the IBM i, where there is really no distinction between memory and disk storage - everything lives in a single address space. In that sense, the distinction between in-memory structures and files gets blurry. Or we can think of Smalltalk with something like the Roar VM hiding the OS the way Smalltalk always did.

The OS limits the approaches we take to solve problems because our programs must fit in their various fixtures to run.

We should probably one-up Steve Jobs and "Think Differenter".

Aren’t all of them based on Linux, which itself is based off UNIX? So while they’re more detached, they’re still UNIX under the hood.

None of Apple’s operating systems are based on Linux. iOS, MacOS, TVOS, and WatchOS are all based on XNU/Darwin, which is in the BSD lineage (predates Linux), but also incorporates the Mach Microkernel (though the OS is not a microkernel style system)

> None of Apple’s operating systems are based on Linux

Not now, but before Apple was sold to NeXT for a Steve Jobs minus $400 million, there was MkLinux. It was an interesting way to run Linux on beige PowerMacs and many places I've worked with gladly adopted it giving new life to abandoned Macs as X terminals and lightweight workstations.

Oddly enough, it has a newer Mach kernel than NeXT's OS.

It hardly matters when userspace doesn't expose any POSIX layer, beyond ISO C and ISO C++ standard library.

Apple stuff is unrelated to Linux.

iOS & iPadOS are Mac(NeXT)-derived, thus are UNIX under the hood.

Unix like and only mildly for iOS.

Not just Unix like. For example macOS is fully unix certified:

https://www.opengroup.org/openbrand/register/brand3683.htm

It says iOS not macOS and now I’m getting downvoted for reading. Brilliant. MacOS is fully certified allowing for all that sweet government contract money.

Where is this mild part coming from?

http://newosxbook.com/home.html

https://www.amazon.com/Mac-OS-iOS-Internals-Programmer/dp/11...

Basically the C, C++ and Objective-C stuff, nowadays Swift as well, completly unrelated to UNIX.

Could you elaborate a little? I don’t understand why the libraries make macOS less UNIX than some other Unixlike.

Who mentioned macOS?!?

My original statement was,

> Android, ChromeOS, iOS and iPad OS have very little correlation to UNIX userspace, if any at all.

Those books show how iOS and iPad OS have very little UNIX across the whole stack, and how much was taken from OS X.

There doesn't seem to be much there? Seems to be just a basic kernel that they eventually want to turn into Plan 9 in Rust.

Not to diminish their accomplishment, but this is not Plan 9 just yet.

It’s also 18% assembly so both “not quite all rust” and big kudos for their efforts.

Yeah, it's really more just a shell at the moment.

It's fun to redo Plan 9, is very gimmicky between the name and the 9front fork and its memelords, but even the creators of Plan 9 have moved on to Inferno OS from what they've learned.

Yes,and usually keeps being forgotten, even though having an UNIX like OS, with a mix of Plan 9 and Oberon ideas, developed by UNIX authors, is a much cooler idea.

inferno had the misfortune if being implemented during the time when all the gui frameworks were copying windows, so it's retro clunky in all the wrong ways. I strongly believe that's the main reason why it doesn't have builder community behind it, mucking in its internals and writing apps. as superficial as it sounds, this position is supported by the many variously hacked up screenshots that come out from the various 9front cool kids. a e s t h e t i c takes priority of everything else, at the end of the day

Well, its UI predates Windows, by being based on Tk, so maybe that is your point?

>The Inferno Business Unit closed after three years [1999-2000], and was sold to Vita Nuova Holdings.[1]

From what I can understand, Inferno was wanted by corporate to compete with Java, the original Bell Labs team kept working on Plan 9 until the last 4th edition released in 2002 (the year when Rob Pike left for Google).

[1] https://en.wikipedia.org/wiki/Inferno_(operating_system)

ISTM that bringing Go to Inferno would be the single best thing to make it a bit more mainstream...

And porting the Dis VM to the Linux kernel, so that you could run Inferno binaries on Linux.

So I grabbed the sources, built r9. When I run it under QEmu it hangs. I looked for documentation but didn't find much. Any ideas?

Regarding LOCs, how many Plan9s are there in LLVM/Rust?

I wouldn't mind a Plan9-ish Rust compiler setup, though.

Reply on news.ycombinator.com