[HN Gopher] Introduction to Plan 9
___________________________________________________________________
Introduction to Plan 9
Author : andsoitis
Score : 137 points
Date : 2024-01-02 14:10 UTC (8 hours ago)
(HTM) web link (fqa.9front.org)
(TXT) w3m dump (fqa.9front.org)
| andsoitis wrote:
| And introduction to 9front (actively maintained fork of Plan 9):
| http://fqa.9front.org/fqa1.html
| mannyv wrote:
| I used plan9 for a while, because the video servers for
| nCube/C-Cor ran plan9.
|
| 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.
| sillywalk wrote:
| "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(tm) (IX is a trademark of NCUBE Corporation), is
| automatically invoked if the system is in Normal mode and
| passes the diagnostic tests. IX(tm) 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(tm) (UNIX
| is a Bell Laboratories trademark), and therefore will not be
| described in detail herein. The IX(tm) System does, however,
| have additional facilities including: system
| temperature sensing distributed file system
| array management uniform file protection"[0]
|
| I believe the plan9 based OS was called Transit.
|
| [0] https://ncube.systems/software.html
| torcete wrote:
| Following links I came across with this:
|
| https://lsub.org/nix/
|
| I cannot really understand what is it for, but this Nix is
| different from the Nix package manager used in Nixos.
| dang wrote:
| I put 2015 because
| https://web.archive.org/web/20240000000000*/http://fqa.9fron...
| but perhaps this was written earlier?
|
| Edit: well, it has content from 2022 so I'll just take the year
| down for now.
| ori_b wrote:
| It's a living document. 9front gets a few commits a day, and
| this document updates to keep up to date with the system.
| dang wrote:
| Ok thanks!
| alberth wrote:
| Is there any comparison to be made between Plan 9 and Fuchsia
| (Google's OS)?
|
| https://fuchsia.dev
|
| This might be orthogonal but doesn't Go Lang (another Google
| creation) have roots in Plan 9.
| randomdata wrote:
| _> 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.
| hollerith wrote:
| 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).
| moody__ wrote:
| >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.
| hollerith wrote:
| 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.
| moody__ wrote:
| 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.
| hollerith wrote:
| What's the security story like for 9front?
|
| 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.)
| eschneider wrote:
| 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.
| cmrdporcupine wrote:
| 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.
| moody__ wrote:
| >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.
| IshKebab wrote:
| 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.
| MisterTea wrote:
| 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.
| ori_b wrote:
| > _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_
|
| https://orib.dev/interject.html
| moody__ wrote:
| 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.
| sctb wrote:
| Yep, I think the primary BeOS connection is Travis
| Geiselbrecht: https://tkgeisel.com.
| pjmlp wrote:
| The roots are in Inferno and Limbo, Plan 9's successor people
| keep forgetting about.
| ori_b wrote:
| I should take the opportunity to plug the upcoming International
| Workshop on Plan 9 conference: https://iwp9.org.
|
| There was a lot of neat work presented at the one held last year:
| https://9e.iwp9.org/
| Decabytes wrote:
| 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
| moody__ wrote:
| 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.
| MisterTea wrote:
| 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.
___________________________________________________________________
(page generated 2024-01-02 23:00 UTC)