[HN Gopher] What is Plan 9?
___________________________________________________________________
What is Plan 9?
Author : AlexeyBrin
Score : 152 points
Date : 2026-01-18 13:32 UTC (9 hours ago)
(HTM) web link (fqa.9front.org)
(TXT) w3m dump (fqa.9front.org)
| Eikon wrote:
| ZeroFS [0] is very thankful for what it brought to Linux with the
| v9fs [1] subsystem which is very nice to work with (network
| native) compared to fuse :)
|
| [0] https://github.com/Barre/ZeroFS
|
| [1] https://docs.kernel.org/filesystems/9p.html
| watersb wrote:
| I believe that the Windows Subsystem for Linux (WSL, really a
| Linux subsystem on Windows) uses the Plan 9 network protocol,
| 9p, to expose the host Windows filesystem to the Linux virtual
| environment.
| franciscator wrote:
| I would love to see more Rust on Plan9 implementations, IMHO,
| could be a good modern combination.
| AlexeyBrin wrote:
| AFAIK there is no Rust compiler for Plan 9 or 9front. The
| project is using a dialect of C and its own C compiler(s). I
| doubt adding Rust to the mix will help. For a research OS, C is
| a nice clean language and the Plan 9 dialect has a some
| niceties not found in standard C.
|
| If you really want Rust, check this https://github.com/r9os/r9
| it is Plan 9 reimplemented in Rust (no idea about the project
| quality):
|
| _R9 is a reimplementation of the plan9 kernel in Rust. It is
| not only inspired by but in many ways derived from the original
| Plan 9 source code._
| euclaise wrote:
| There isn't, though you can run it over wasm on it. I tried
| it a while back with a port of the w2c2 transpiler
| (https://github.com/euclaise/w2c9/), but something like
| wazero is a more obvious choice
| solarexplorer wrote:
| I don't know. I use a lot of Swift and C++ and while both are
| OK languages there is an absurd amount of complexity in these
| languages that doesn't seem to serve any real purpose. Just a
| lot of foot traps, really. Coming back to Plan9 from that world
| is a breeze, the simplicity is like a therapy for me. So
| enjoyable.
|
| If "modern" means complex, I don't think it fits Plan9.
| einpoklum wrote:
| I don't know about Swift, but in C++, the complexity serves
| at least three purposes:
|
| 1. Backwards compatibility, in particular syntax-wise. New
| language-level functionality is introduced without changing
| existing syntax, but by exploiting what had been mal-formed
| instructions.
|
| 2. Catering to the principle of "you don't pay for what you
| don't use" - and that means that the built-ins are rather
| spartan, and for convenience you have to build up complex
| structures of code yourself.
|
| 3. A multi-paradigmatic approach and multiple, sometimes
| conflicting, usage scenarios for features (which detractors
| might call "can't make up your mind" or "design by
| committee").
|
| The crazy thing is that over the years, the added complexity
| makes the code for many tasks simpler than it used to be. It
| may involve a lot of complexity in libraries and under-the-
| hood, but paradoxically, and for the lay users, C++ can be
| said to have gotten simpler. Until you have to go down the
| rabbit hole of course.
| flopsamjetsam wrote:
| As a Swift noob, I would appreciate hearing what these foot
| traps are. This is in the context of Swift as a systems
| programming language?
| exitb wrote:
| I'm fairly sure that Rust compiler is bigger than the entire
| 9front (and 9front has Doom in it).
| VorpalWay wrote:
| Since Rust depends on LLVM, which is massive, that is almost
| certainly true. It seems likely even if you don't include
| LLVM though.
| anthk wrote:
| You would like Golang more than Rust. At leat the authors (and
| ex-authors) for sure they are aware of Go, they invented it
| too.
| irusensei wrote:
| >9front.org frequently questioned answers
|
| Knowing that project am I going to be rickrolled?
| rcarmo wrote:
| People wanting a Retina-capable drawterm to access Plan9/9front
| from their Macs are welcome to have a look at
| https://github.com/rcarmo/drawterm
| tucnak wrote:
| Ooh la la
| pjmlp wrote:
| The transition step between UNIX and Inferno, and between C and
| Limbo as main userspace language, by its authors.
|
| Which tends to be forgotten when praising Plan 9.
| krmboya wrote:
| Is it correct to say Golang is bringing Limbo to the masses?
| pjmlp wrote:
| Partially, Go still doesn't support a few Limbo features.
|
| However the influence is quite clear, plus the Oberon-2 style
| methods and SYSTEM package.
| rcarmo wrote:
| No, it's bringing Aleph to the masses. Limbo is a cousin, and
| Dis was certainly very interesting and something I wish had
| caught on.
| pjmlp wrote:
| Aleph lacked GC, which Rob Pike considered the main reason
| for its implementation failure on Plan 9, and initially
| bounds checking was also missing.
|
| Two key design difference from Go and its two predecessors.
|
| Dis is an implementation detail, Go could offer the same
| dynamism with AOT toolchain, as proven by other languages
| with ahead of time toolchains available.
| rcarmo wrote:
| Dis is not an implementation detail for Inferno, though.
| And I wish it had gone much further.
| pjmlp wrote:
| I agree, but that is another matter.
|
| However I will commit the sacrilege to suggest Android is
| the closest we got there on mainstream OSes.
| 9rx wrote:
| That might be Rust, actually. They have more in common with
| thoughts about type systems, built-in constructs,
| deterministic memory usage, etc.
|
| Limbo looks more like Go on the concurrency front, but that
| was inherited from Alef/Plan 9. That wasn't what Limbo
| brought to the table.
| pjmlp wrote:
| Limbo uses a garbage collector, though.
| 9rx wrote:
| So does Rust. Rust is 'smarter' than Limbo, in that it
| can avoid using its GC in a lot of cases (but not all,
| hence why it still has GC to fall back on when
| necessary), but, I mean, that discovery was the reason
| for why Rust was created. Limbo was already there
| otherwise. Every new language needs to try to add
| something into the mix.
|
| Still, the thoughts were in common, even though the final
| solution didn't end up being exactly the same.
| maleldil wrote:
| Are you trying to say that Rc/Arc are GCs? I guess you're
| technically correct, but no one sees it that way.
| 9rx wrote:
| I would say that RC is GC, yes, as it is most definitely
| technically true. But it was pjmlp who suggested it
| originally (Limbo also uses reference counting), so we
| have clear evidence that others also see reference
| counting as being GC. We wouldn't have a discussion here
| otherwise.
| arghwhat wrote:
| Rust does not have a garbage collector in any way or
| form. It's just automatic memory like we're used to
| (e.g., stack in C++), with the compiler injecting
| free/drop when an object goes out of scope.
|
| What Rust brings is ownership with very extensive
| lifecycle tracking, but that is a guard rail that gives
| compile-time failures, not something that powers memory
| management.
|
| (If you consider the presence of Rc<T> to make Rust
| garbage collected, then so is C garbage collected as
| developers often add refcounting to their structs.)
| ruslan wrote:
| Is there Plan9 port for RISC-V (RV32I) ?
| chrsw wrote:
| Probably not. And there aren't many 32-bit RISC-V cores with an
| MMU. I guess you can use a simulator if you found one.
| ruslan wrote:
| I use one written in SpinalHDL. :-)
|
| Next question is how much RAM it needs to boot and can it be
| used without rio ?
| ori_b wrote:
| There's a 9legacy port, and an in-progress 9front port.
|
| https://m.youtube.com/watch?v=EOg6UzSss2A
| ruslan wrote:
| That's interesting, thanks. I feel a need for simple
| multitasking/networking OS for synthesizable RV32I core (not
| RTOS like, but more like Unix or CP/M). Would be nice to try
| Plan9 on it once port is out.
| rramadass wrote:
| IMO, the biggest curse of the Internet age is how Distributed
| OS's did not become mainstream. Maybe we should repackage these
| as Unikernels and run our apps using their distribution services
| directly on a hypervisor.
| zozbot234 wrote:
| k8s is really just a distributed OS implemented on top of Linux
| containers, only with extra facilities for automated tuning,
| scaling and overall management that are lacking on bare plan9.
| anthk wrote:
| 9front it's far ahead of docker and crappy namespaces running
| on a libre reimplementation of a dead end Unix version. They
| did things right from the start. bind it's far superior to
| anything else.
| bitwize wrote:
| But... muh scalability!
| ori_b wrote:
| Plan 9 is still alive and kicking -- The next Plan 9 conference
| will be in Victoria, BC in Canada later this year.
|
| https://iwp9.org/
|
| 9front averages several commits a day:
|
| https://git.9front.org/plan9front/9front/HEAD/log.html
| __turbobrew__ wrote:
| https://git.9front.org/plan9front/9front/b18221b10c83d81a9eb...
| i4k wrote:
| > Theo is more specific than troll; it presents insults from
| OpenBSD founder Theo de Raadt.
|
| check fortune(1) command.
| tombert wrote:
| I've been on/off playing with 9front on an old laptop. I've
| been having a lot of fun with it, it's fun to write code for,
| but i have had a hard time using it as anything but a toy.
|
| I would love to use it as my main desktop, but ultimately (and
| kind of unsurprisingly), the blocker is the lack of a modern
| browser and a lack of video acceleration.
|
| I'm sure I could hobble something together with virtualization
| for the former but I don't see a fix for video acceleration
| coming.
|
| Maybe I could install it on a server or something.
| wkjagt wrote:
| I did the same with an old Thinkpad but somehow found it
| relies too heavily on the mouse. I might still go back to it
| because I love how far they've taken the "everything is a
| file" idea and would like to experiment more with that.
| jes5199 wrote:
| I'm not sure it still makes sense to do OS research so close to
| the metal. Most computing is done up on the application level,
| and our abstractions there suck, and I haven't seen any evidence
| that "everything is a file" helps much in a world of web APIs and
| SQL databases
| marssaxman wrote:
| Some of us are still interested in the world underneath all
| that web stuff!
|
| Multiple experimental operating systems at multiple abstraction
| levels sounds like a good idea, though. What sort of system
| software would _you_ like to build?
| ogogmad wrote:
| Operating systems are where device drivers live. It sounds
| awfully impractical to develop alternatives at this stage. I
| think OP is right.
|
| I think OSes should just _freeze all their features right
| now._ Does anyone remember all the weird churn in the world
| of Linux, where (i) KDE changed from version 3 to 4, which
| broke everyone 's KDE completely unnecessarily (ii) GNOME
| changed from version 2 to 3, which did the same (iii) Ubuntu
| Linux decided to change their desktop environment away from
| GNOME for no reason - but then unchanged it a few years
| later? When all was said and done, nothing substantive really
| got done.
|
| So stop changing things at the OS level. Only make
| conservative changes which don't break the APIs and UIs. Time
| to feature-freeze, and work on the layers above. If the upper
| layers take over the work of the lower layers, then over time
| the lower layers can get silently replaced.
| GrowingSideways wrote:
| > I haven't seen any evidence that "everything is a file" helps
| much in a world of web APIs and SQL databases
|
| Well for one thing, such an abstraction enables you to avoid
| web apis and sql databases!
| moron4hire wrote:
| You're going to have to explain to me how a parametrized
| request/response system like calling a Web API or making a
| SQL query can be mapped to reading files. I've seen some
| stuff that people do with FUSE and it looks like ridiculous
| circus hoop jumping to making the Brainfuck-is-Turing-
| complete version of a query system. We have syntax for a
| reason.
| ori_b wrote:
| Typically, if you were writing your hypothetical sql client
| in rc shell, you'd implement an interface that looks
| something like: <>/mnt/sql/clone{
| echo 'SELECT * from ...' >[1=0] cat
| /mnt/sql/^`{read}^/data # or awk, or whatever }
|
| This is also roughly how webfs works. Making network
| connections from the shell follows the same pattern. So,
| for that matter, does making network connections from C,
| just the file descriptor management is in C.
| moron4hire wrote:
| This is... I don't know. I don't get why I would care to
| sling SQL over a file system versus a network socket.
|
| I mean, Postgres _could_ offer an SSH interface as a dumb
| pipe to psql to just have you push text SQL queries in
| your application. But it doesn 't, it offers a binary
| protocol over a network socket. All the database engines
| have had the same decision point and have basically gone
| down the same path of implementing a wire protocol over a
| persistent socket connection.
|
| So yeah, I don't get what doing things this way would
| give me as either a service provider or a service
| consumer. It looks like video game achievements for OS
| development nerds, "unlocked 'everything is a file'." But
| it doesn't look like it actually enables anything
| meaningful.
| ori_b wrote:
| How would you connect to Postgres in 4 lines of shell
| normally? How would you do it for a rest api? How about
| any other systems?
|
| For Plan 9, it's all the same, all using the same
| interfaces, with little library glue.
|
| Opening a window, and running a command in it? Similar
| interfaces. Adding LSP to your editor? Got it, you mount
| it and write to the files.
|
| Universal shared conventions are powerful.
| GrowingSideways wrote:
| In addition to the sibling comment, you might also consider
| simply not using the APIs or SQL queries to begin with.
| Many people have entire careers without touching either.
| moron4hire wrote:
| Why would I ever consider doing that?
| GrowingSideways wrote:
| That's up to you. Why ask me?
| ogogmad wrote:
| I think you're failing to get that using a filesystem API
| to work with things that aren't naturally anything like
| filesystems might get perverse. And standard filesystems
| are a pretty unnatural way to lay out information anyway,
| given that they force everything into a tree structure.
| moron4hire wrote:
| This is what I was trying to get at. A lot of the data I
| deal with is directed, cyclic graphs. Actually, I
| personally think most data sets we care about are
| actually directed graphs of some kind, but we've gotten
| so used to thinking of them as trees that we force the
| metaphor too far. I mean, file systems are an excellent
| example of a thing we actually want to be a graph but
| we've forced into being a tree. Because otherwise why
| would we have ever invented symlinks?
| zozbot234 wrote:
| Plan9 allows for implementing file servers in user space
| and exporting a whole file tree as a virtual "folder", so
| it's really more of "everything as a file server". No
| different than FUSE, really.
| moron4hire wrote:
| From what I've seen, Plan 9 fans turn their noses up at
| FUSE. They say FUSE is not "it", but don't really seem to
| explain what "it" is to differentiate it from FUSE.
|
| And as Feynman said, you don't truly understand a thing
| until you can teach it. So that leaves us in a weird
| predicament where the biggest proponents of Plan 9
| apparently don't understand Plan 9 well enough to teach
| it to the rest of us.
| zozbot234 wrote:
| It depends what you mean by "it". FUSE clearly doesn't
| give you _every_ feature in plan9, and in fact you can 't
| have that without giving up the current Linux syscall API
| completely and replacing it with something vastly simpler
| that leaves a lot more to be done in user space. That's
| not something that Linux is going to do by default,
| seeing as they have a backward compatibility guarantee
| for existing software. Which is totally OK as far as it
| goes; the two systems just have different underlying
| goals.
| moron4hire wrote:
| You're frustrating me. You replied to me saying "it's
| basically FUSE" and then after I replied to you, you come
| back and say, "it's not really FUSE."
| zozbot234 wrote:
| Plan 9 supports file server processes natively, and
| that's the part that's most FUSE-like. The full OS also
| has many other worthwhile features that are not really
| addressed by FUSE on its own, or even by Linux taken as a
| whole.
| Tor3 wrote:
| The "everything is a file" approach is nice in many cases, I'm
| worried though if it works everywhere. Maybe if done right.
| Subversion (SVN) shows branches as separate file trees.. and
| ClearCase too (though I'm on thin ice with ClearCase, having
| used it very little). And I just can't stand the file-oriented
| way SVN works, I could never get used to it. But there are a
| lot of other cases where "it's a file" does work, I've
| experimented with creating Fuse filesystem interfaces to some
| stuff now and then.
| tombert wrote:
| I didn't really see the appeal until I learned how to use FUSE.
|
| There's something elegant about filesystems. Even more than
| pipes, filesystems can be used to glue programs together. Want
| to control your webcam with Vim? Expose a writable file. Want
| to share a device across the network? Expose it as a file
| system, mount that filesystem on your computer.
| written-beyond wrote:
| Idk I still find low level OS stuff super interesting because
| it hasn't had a rework in so long. With everything we've learnt
| since the age of modern computing, drives larger than a few
| MBs, super fast memory and fast cryptography to name a few.
|
| It's interesting to imagine a new OS that incorporates these
| changes from it's infancy.
|
| I appreciate all of the effort put in by Linux, BSD, Android,
| QNX and closed source OSs' have put in to building upon
| existing ideas and innovating gradually on them. But man I
| really want to see something better than everything is a file.
| I really enjoyed the stuff BeOS was pitching.
| zozbot234 wrote:
| Well, on the file system side BeOS was pitching "virtual
| folders" that are really no different than what plan9
| provides.
| lizknope wrote:
| Why did BSD make Unix sockets something outside of the file
| system?
|
| I can do this in bash but I always thought it would be more
| elegant to do a similar thing in C. I thought Plan 9 handled it
| more like this?
|
| cat < /dev/tcp/localhost/22
|
| SSH-2.0-OpenSSH_10.0
| somat wrote:
| They did not have the original unix vision. and it is a lot
| easier to to design an interface as a programming interface
| than shoehorn it into a filesystem interface.
|
| I think having a filesystem interface is pretty great, and
| plan9 showed it could be done. but having to describe all your
| io in the [database_key, open(), close(), read(), write(),
| seek()] interface. can be tricky and limiting for the
| developer. It is pretty great for the end user however. Having
| a single api for all io is a super power for adaptive access
| patterns.
|
| I think the thing that bothers me the most about the bsd socket
| interface is how close it is to a fs interface.
| connect()/bind() instead of open(), recv()/send() instead ot
| read()/write() but it still uses file discripters so that stuff
| tends to work the same. We almost had it.
|
| As much as I like BSD and as great an achievement that the
| socket interface was, I still think this was their big failure.
| enriquto wrote:
| > can be tricky and limiting for the developer. It is pretty
| great for the end user however.
|
| This seems to be a great general principle of api design! The
| best apis are those that are _hated_ by the developer and
| loved by the end users.
| arghwhat wrote:
| > The best apis are those that are hated by the developer
| and loved by the end users.
|
| No, just those loved by the API consumer. Negative emotions
| on one end doens't do anything positive.
|
| In the case of plan9, not everything _can_ be described
| elegantly in the filesystem paradigm and a lot of things
| end up having really awkward "ctl" files which you write
| command strings to that the fileserver needs to parse. It
| also handicaps performance due to the number of filesystem
| operation roundtrips you usually end up making.
|
| Maybe if combined with something io_uring-esque, but the
| complexity of _that_ wouldn 't be very plan9-esque.
| enriquto wrote:
| can you give a few examples of this "lot of things"? What
| operations do not map naturally to file access?
| zozbot234 wrote:
| > a lot of things end up having really awkward "ctl"
| files which you write command strings to that the
| fileserver needs to parse.
|
| These are no different in principle than ioctl calls in
| *ix systems. The `ctl` approach is at least a proper
| generalization. Being able to use simple read/write
| primitives for everything else is nonetheless a
| significant gain.
| lizknope wrote:
| I just think this sounds very elegant
|
| https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#/net
|
| > Plan 9 does not have specialised system calls or ioctls for
| accessing the networking stack or networking hardware.
| Instead, the /net file system is used. Network connections
| are controlled by reading and writing control messages to
| control files. Sub-directories such as /net/tcp and /net/udp
| are used as an interface to their respective protocols.
|
| > Combining the design concepts
|
| > Though interesting on their own, the design concepts of
| Plan 9 were supposed to be most useful when combined. For
| example, to implement a network address translation (NAT)
| server, a union directory can be created, overlaying the
| router's /net directory tree with its own /net. Similarly, a
| virtual private network (VPN) can be implemented by
| overlaying in a union directory a /net hierarchy from a
| remote gateway, using secured 9P over the public Internet. A
| union directory with the /net hierarchy and filters can be
| used to sandbox an untrusted application or to implement a
| firewall.[43] In the same manner, a distributed computing
| network can be composed with a union directory of /proc
| hierarchies from remote hosts, which allows interacting with
| them as if they are local.
|
| > When used together, these features allow for assembling a
| complex distributed computing environment by reusing the
| existing hierarchical name system
|
| I remember first setting up NAT or IP masquerading around
| 1998. It seemed like an ugly hack and some custom protocols
| did not work.
|
| I use a bunch of VPNs now and it still seems like a hack.
|
| The Plan 9 way just seems very clean although you now have to
| secure the server more strongly because you are exporting
| filesystems from it and others are mounting it.
| mentalgear wrote:
| Modern Plan9 web version https://github.com/tractordev/apptron
| flippyhead wrote:
| > A printed version of the proceedings will be provided to the
| attendees
|
| How adorable!
___________________________________________________________________
(page generated 2026-01-18 23:01 UTC)