Introduction to Plan 9
fqa.9front.org
fqa.9front.org
There was a lot of neat work presented at the one held last year: https://9e.iwp9.org/
SDF once or twice a year always runs a month long event around Plan9 and even offers accounts on Plan9 VMs.
I can't remember much about it, except that in ran two OSs at a time, but I can't remember which half did which. It also had great I/O performance.
I'm pretty sure they ditched plan9 for linux by the time they were bought by Arris, or soon after.
In may ways the Operating System is similar to UNIX™ (UNIX is a Bell Laboratories trademark), and therefore will not be described in detail herein. The IX™ System does, however, have additional facilities including:
system temperature sensing
distributed file system
array management
uniform file protection"[0]
Looks like the 1st versions of nCube ran Arix (perhaps shortened to IX), a Unix clone) on a 286 which was the front end and controlled the actual processing elements, and IO. Each compute node ran a 4KB kernel called Vertex[0].
The 2nd version had a Sun Workstation as the front-end and the nodes ran an a 200 KB microkernel called nCX[1]
The nCube 3 / mediaCube nodes ran Transit[2] (hurray for archive.org! )
" Transit is the operating system that runs on each node of the MediaCUBE system. Based on AT&T;'s Plan 9 Unix derivative, it's light-weight microkernel architecture provides a small footprint that minimizes memory consumption. Transit's features include:
Streamlined internal code paths
Hypercube communications software
Algorithms optimized for hardware
Flexibility of UNIX-like environment
Optimized for Oracle Video Server
High performance
Reliability
And an overview of mediaCube [3].
[0] http://tnm.engin.umich.edu/wp-content/uploads/sites/353/2017...
[1] https://en.wikipedia.org/wiki/NCUBE
[2] https://web.archive.org/web/19970204220447/http://www.ncube....
[3] https://web.archive.org/web/19970204220335/http://www.ncube....
This might be orthogonal but doesn't Go Lang (another Google creation) have roots in Plan 9.
They come from the same people (Ken Thompson, Rob Pike). The Go compiler was the first program written for Plan 9, although it processed C code at that time – the Go language would come later. Eventually it was machine translated into Go sources.
Plan 9 has its own low-level graphics and windowing libraries that have never received any porting effort by any of the mainstream browsers. Porting a mainstream browser to Plan 9 is about 50 times more labor than has ever been put into Plan 9 even when Bell Labs was footing the bill (in the early 1990s or earlier).
People put a lot of effort in to Plan 9 (and 9front specifically these days), so I want to point out that this is mostly the fault of these "mainstream" browsers being so complicated. It is actually easier for us to emulate an entire virtual machine and run a linux + chrome setup within it then it would be for us to port all the code over.
I also find it no surprise that Fuchsia is getting some chrome dev time, but I have a hard time of believing that it's due to popularity. Google has little interest in maintaining chrome for other more used systems like the BSD's. Seems like they are only interested as a byproduct of wanting to sell appliances running Fuchsia.
I.e., not having any mainstream browser is a big deal for an OS, so when someone asked for a comparison between Plan 9 and Fuchsia, I thought I'd mention it. More precisely, it is a big deal for a user-facing OS, and Plan 9 is mostly user-facing. In fact, I've never heard of anyone using it as, e.g., a web server.
For years, Android, iOS, Windows, MacOS and ChromeOS has used a verified boot process that prevents any malware from surviving a reboot in any of the system software, i.e., anywhere except for the user's home directory and maybe other directories created by the user that the user is responsible for maintaining. I don't suppose 9front has that?
Also when I used drawterm (as part of Plan 9 from Userspace on a Mac) the drawterm windows had no anti-aliasing, which I might have been able to get used to, except that the native-Mac windows used anti-aliasing and switching back and forth I found a jarring experience (and I was never able to figure out how to configure the Mac (and my browser) not to do the anti-aliasing).
(Technically, my browser was doing its own low-level drawing, but it had been carefully tuned by the maintainers of the browser to visually resemble the results of the native Mac drawing systems.)
Also, Silverblue's home page does not even list "secure" or "security" as one of the benefits of Silverblue. (They list reliable, atomic, the ability to revert the system, containerized, developer-friendly, no ads, "all your data belongs to you", and open-source.)
I wasn't directly involved but was a tiny bit of a voyeur. I seem to recall (this was 3-4-5 years ago) that there was a lot of push to try to componentize things in a more Fuchsia-ish way, but this naturally ran up against the realities of how huge and big the Chrome codebase is. And Chrome has its own IPC system (mojo) and its own component model(s), its own threading system, etc. and assumes POSIX stuff throughout, etc.
My suspicion at the time was that as something like Chromium gets ported to Fuchsia the result will be less that Chrome becomes friendly to Fuchsia, as much as that Fuchsia becomes less distinct, and more a "typical" OS, out of pragmatism.
I dunno, I'm curious to see how that effort is going. But I think it accords with your point. Porting big applications to "alternative" operating systems with more interesting or exotic models... you either end up losing the OS's distinctiveness (in which case why not just run in a VM), or having to rewrite a lot from scratch.
Very well said.
The why is simple: We can run Linux or BSD in a VM and run a browser in there. Besides, the goals of most users is to explore new and exciting ways to share information that doesn't require the efforts of a billion dollar commercial entity with an army of programmers.
The people who come to plan 9 don't come to it because it runs chrome or steam. We're here because we like the architecture. There's so much more work to do and things to explore. Complaining something doesn't work means you're not really interested in OS design so that's fine, just move along and find what you want. That or patches welcome.
And Inferno/Limbo, which made up for Alef being removed from Plan 9.
https://en.wikipedia.org/wiki/Inferno_(operating_system)
TL;DR: The Unix people make a Java.
I was a teen at the time, but in hindsight, in '96-97 'open source' from commercial vendors wasn't the norm, and Lucent finding income from openInferno would've been big change in business model.
Java was meant to be familiar to C/C++ programmers, of which there were a lot. I'm not sure how Limbo would compare in terms of learning / productivity. And would there have been a Windows native "Inferno/Limbo" IDE type thing. (If there was one, please let me know)
Inferno would've needed a killer app. I assume it'd perform better than Java, and at the time it would've competed with small Java applets. Java desktop didn't happen, I recall Corel trying and failing to port Word Perfect to Java. I don't know how if anybody ever tried to write an office suite in Limbo.
There have been vastly superior systems to Unix but with commercial licenses.
I cannot really understand what is it for, but this Nix is different from the Nix package manager used in Nixos.
Introduction to Plan 9 - https://news.ycombinator.com/item?id=38841727 - Jan 2024 (37 comments)
Running 9front on an emulated SGI Indy via MAME - https://news.ycombinator.com/item?id=38838369 - Jan 2024 (18 comments)
Edit: well, it has content from 2022 so I'll just take the year down for now.
If you have issues you can go onto the 9fans discord or ##9fans on oftc.net which are more casual channels and newby friendly or #cat-v on oftc which is pretty much the official 9front channel where the devs mainly gather.
Plan 9 is … different. She’s a weird little creature.