"There are two levels of operating software in the system: the Monitor (in EPROM) and the Operating System. The monitor is a simple, single user system that is in effect when the system is powered on. The Monitor uses terminal 0 and provides extensive diagnostic and management functions. The Operating System, IX™ (IX is a trademark of NCUBE Corporation), is automatically invoked if the system is in Normal mode and passes the diagnostic tests. IX™ is a fully protected multiuser, multitasking operating system with complete resource management including memory, main array, graphics and file system. The file system has a hierarchical structure and is distributed across all the disk drives in the system. Thus, a user can access his files regardless of which terminal (or Peripheral Controller) he uses.
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]
I must correct myself, after a visit to moar of the Internets.
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
Transit is used to distribute content processing across interconnected CPU and I/O modules, interface to hardware devices, and manage the Oracle Video Server processes on each node. Transit also provides a file service, u9fs, that creates a special file hierarchy on the system console available to processes running on the MediaCUBE processors. This provides access to non-video files."[2]
They are two completely different projects with completely different goals. Indeed Go was started by Rob Pike, Ken Thompson and Robert Griesemer, the first two of which also worked on Plan 9, and the Go compilers can trace their lineage back to the Plan 9 C compilers (with some pit-stops between there). Plan 9 was designed with the retrospective on UNIX and it's trappings, with a focus on networked distributed systems.
Fuchsia is by a completely different team not involving Plan 9 alumni (as far as a I know) and has a different target, mostly aimed at embedded systems. If I recall correctly fuchsia development involved some alumni from the BeOS/Haiku world but don't quote me on that.
Fuchsia is having a mainstream browser ported to it, as one can see by searching the Chromium project's commit logs for the string "fuchsia," whereas a mainstream browser has never run on Plan 9, nor is there a realistic chance of it happening in the future. My definition of "mainstream" is having had more than 1000 users on its best day ever and able to render most popular web sites without tons of glitches and bugs.
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).
>Porting a mainstream browser to Plan 9 is about 50 times more labor than has ever been put into Plan 9
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.
When I worked at Google the efforts to port Chromium over were seemingly tied in large part to needing to have parts of it to get the Chromecast ecosystem running on it. Because the devices they were targeting for Fuchsia to use were built on top of that. (though a lot of that UI also got rewritten in Dart/Flutter instead, so)
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.
>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.
I guess the advantage is that other apps can still take advantage of the OS's unique features. As I understand it Fuchsia has a POSIX compatibility layer which maybe they'll have to use for Chrome, but they wouldn't need to use it for new apps.
These "mainstream" browsers being so complicated is a large part of why I don't like them, but the reality is that no matter how much I don't like it, the web is unavoidable with the result that if I were to run Plan 9, I would need to run a second OS with which to browse the web (and I like to save snippets of the web, so I either need to keep those snippets on the second OS or rig something up to make it easy to send the snippets to my Plan 9 install). (And I regularly need to upload documents and images stored on my computer to the web, so I'd either need to keep my documents and images on the second OS or rig something up to avoid the tedium of manually copying the document or image every time from Plan 9 to the second OS so I could upload it.)
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.
Indeed, thankfully using a 9front system from another OS is quite nice. My workstation at home is a Linux machine with a drawterm window open fullscreen. You can think of drawterm like our version of windows RDP, with a shared clipboard and a way of sharing files seamlessly between the host and the remote system. Under the hood, drawterm is just an implementation of /dev/draw that gets given to a remote system, so you're not forwarding compressed images but individual draw RPC messages. Over a LAN connection you can even play doom at 1080p.
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.)
As for secure boot, assuming plan9 can boot from a read-only volume, that shouldn't be hard to implement. The (simplified) way it works on most systems is that secure boot is implement in the SOC and that's used to verify the installed bootloader and then the verified bootloader verifies that the boot volume is unmodified (think checksum, but a bit more complicated to make it boot faster. :) There isn't anything about that that couldn't be incorporated into almost any boot process.
If it isn't hard to implement why does no Linux distro besides bottlerocket (specialized for use on AWS and other cloud services) Android and ChromeOS do it?
Debian, Ubuntu, Red Hat, Fedora, Suse, Arch, Gentoo, and Slackware all support secureboot. After that I got tired of looking up linux distributions, so there are likely more.
That's not part of secureboot's remit, but distros who do it are generally referred to as 'immutable distros'. Fedora Silverblue, CarbonOS, NixOS, GUIX, Endless OS, and Vanilla OS are a few.
None of the distros you list verifies the software installed by the package manager (except sometimes the kernel and the initrd) at boot time and refuses to finish the boot process if the verification fails. I guess an argument can be made that immutability would make it easier to achieve such a "verified boot process", but none of the distros you list has done the work.
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.)
Most plan 9 users have no desire to ever see a major browser ported. Ever. The best we have is netsurf and works for 90% of what people need which is simply viewing static text, information.
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.
> 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.
My favorite explanation for the well known “worse is better” observation about systems software is that it’s a downstream of the fact that worse is free.
There have been vastly superior systems to Unix but with commercial licenses.
Unix itself was a commercial system, licensed by AT&T to various other companies, that nearly fragmented itself to death before being resurrected by the free/open variants (*BSD, GNU, and Linux). See https://en.wikipedia.org/wiki/Unix_wars
Everything was commercial back then. My point is that mature free implementations of Unix (BSD, Linux) came before free implementations of any superior systems and so they won.
Interesting question. I'm always curious at these other operating systems.
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.
Inferno is based on plan 9 (shares kernel code)with a user space that fully runs in the VM. However, it can run on very small systems like microcontrollers and someone is currently actively exploring this: https://dboddie.gitlab.io/inferno-diary/index.html
It's all about the neckbeard, typing slowly and deliberately, coming across as semi-helpfully opinionated in a monotone register, craning ones eyes and neck down to the monitor, and wearing a gray hoodie, or so I've been told. Maybe it's writing an HP 48 emulator in LISP with a brainfuck microarchitecture that also produces itself as a quine. ¯\_(ツ)_/¯
what is the easiest way to get up and running with plan 9 right now? A virtual machine? It seems based on it's architecture it really benefits from multiple machines connected at once
A virtual machine + drawterm is a good way to dip your toes in, we distribute a amd64 qcow2 image that should be ready to go in QEMU. If you want to try on hardware an old thinkpad is probably the easiest, but we should run on most sensible PCs (but perhaps without wifi).
I also wrote a nix flake (https://github.com/majiru/9front-in-a-box/) for setting up stuff a bit more automatically if that happens to jive with your system.
The system is capable of networking a bunch of systems together, but doing so is not a requirement to experience a lot of what the system has to offer.
Run it in a VM and then setup a CPU server so you can drawterm in.
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.
There was a lot of neat work presented at the one held last year: https://9e.iwp9.org/