Plan 9’s filesystem is a very simple network filesystem protocol to share files between systems. They are specifically using 9P2000.L.
They considered using Samba and SMB instead but can’t rely on Samba being installed and usable in the Linux guest OS and didn’t want to ship it because Samba is GPL licensed.
They picked Plan 9 because it’s much simpler to implement. Also Microsoft already had Plan 9 server code for some other Linux container project they’d done.
The \\wsl$\ path is handled in the Windows system by the MUP, an existing hook for network-like filesystems. They added a new one for Plan 9.
The $ is in the name so that it can’t be confused with a computer whose hostname is wsl.
The Plan 9 server in Linux communicates with the Windows Plan 9 client via a Unix socket. (Windows supports Unix sockets; who knew?)
Windows can access your Linux files even if no Linux is instance is running. There’s a new Windows service called LXSManagerUser that mediates user identity and permissions.
Only since Windows 10 build 17063 (December 2017 pre-release) [0] [1], which was released as Windows 10 April 2018 Update. So for the first 25+ years of Windows' existence, it didn't.
And although it does implement the basic functionality, it is missing features found on mainstream Unix-like platforms, e.g. file descriptor passing (SCM_RIGHTS)
> Plan 9 lives on as the filesystem network interface that allows Windows and Windows Subsystem for Linux cross-platform access to your C drive.
Same with other hypervisors, virtualbox etc do the same. If you have docker installed on macOS it also uses 9p to share data with the host.
But IMO 9p is a terrible choice for this, particularly because it doesn’t support hard links. It breaks a lot of software like sccache etc which rely on hardlinks to work.
The reply from the plan9 devs on why this is the case hits staggering levels of arrogance:
> If you look at what a hard link is, you'll realize why they are not in Plan 9.
I can accept that someone considers a hard link a sort of insanity or deliberate corruption, or at best an undesirable feature, but I think they should just say that rather than go to the next level and act like this is the only possible position.
rminnich is a lot of things (including a 9front developer) but not a plan9 developer.
He is right however, you are also right: it's because Windows and Docker publish 9p server in a stupid way. It shouldn't be just the guest fs, you should be able to make any file server you like so hard links would be useless (as they are in plan9) because you would decide what filesystem organization layout you need.
You could make do with FUSE inside the virtualized OSes I guess.
Plan9 is one of those things I go back to every Summer and that is somewhere between completely mind-blowing (check out the GIF at https://taoofmac.com/space/blog/2020/09/02/1900 to see how fast it boots in real-time on a single-core Pi) and almost completely unfit for purpose because it just doesn’t integrate well (or easily enough) with modern systems (I also considered using it for a writing “appliance” - https://taoofmac.com/space/blog/2023/09/22/1230 - but syncing data off it was a blocker, and three-button mouse chording GUIs are just not a thing I want to deal with).
One of the “stupid” ideas I have in my back-burner is to rewrite rio so that it works like Mac OS 7 (the platinum look with window shading), which in my mind was always a very sane and efficient way to manage windows — but time is not on my side…
I have one of my usual lists of resources for it on https://taoofmac.com/space/os/plan9 - comment here if it’s missing anything you particularly like.
Your link for 9front mentions that ssh2 is not included. This is because the code was rewritten and the program is now just called ssh(1). Other features of ssh are accessible through sshfs(4), and sshnet(4). The only difference in features compared to the original Plan 9 is that 9front does not currently have code for an ssh server. I know some users who are interested in this capability so it'll likely happen at some point.
> The Plan 9 implementations tend to not be as feature rich as the proper upstream variants.
This is IMO the biggest drawback. Why wouldn't any user want the software to be feature rich? In fact, looking at Plan 9, I often feel that the provided software is just a MVP.
Counterpoint: Plan 9 is supposed to be the ultimate realization of the Unix philosophy. One important aspect of the Unix philosophy is composable software. Instead of large, feature-rich programs where functionality is often siloed off from other programs, users have a toolbox of small, composable programs that “do only one thing and do it well” and that they could connect together using pipes and other inter-process communication primitives.
Composable software is something I’m highly interested in. There were efforts in the 1990s to make desktop software more composable, such as COM from Windows and OpenDoc from Apple, but the desktop world is still dominated by large applications such as those that constitute Microsoft Office and the Adobe Creative Suite. It would have been a wonderful opportunity for the Linux desktop world to embrace components, but, alas, the community embraced OpenOffice, GIMP, and other large applications.
COM is everywhere on Windows, specially since Vista, as the WinDev regained the control they thought Longhorn was going to take away from them.
One of Powershell strengths is the easy access to COM, just like .NET, frameworks.
Linux could do the same with D-Bus, but alas so is the distributions wars, and hate on anything like proprietary OSes, that it only has a minor role on systemd, GNOME and KDE.
The irony is that Acorn's RISC OS arguably came the closest to this ideal with any pragmatism. The way that file choosers worked effectively allowed one to pipe a saved file from one application to another and then do it again through the same workflow in the next application and so on.
Agreed. And one could argue that Unix wasn't really popular because of the "philosophy", but because it would get out of the way and let you run big monolithic applications like OracleDB or CAD software or even Emacs and etc. So no popular application using "Plan 9 philosophy" ever emerged.
Python's `venv` Just Works (and is standard), while whatever it was that I dug up to get the same effect in Perl mostly didn't. I somewhat prefer Perl for things where this isn't an issue.
I should probably make time look again in case I missed something or it's improved in the last decade.
> Why wouldn't any user want the software to be feature rich?
Users want feature rich systems. Individual programs are best feature-complete, but focused on a single task and capable of cooperating with others when something out of scope is desired.
From my personal viewpoint: It's not easy to hack on large monoliths, even for senior software engineers. But if every logical piece of the monolith tries to be as small as it meaningfully could, the barriers are drastically lower.
Because there's diminishing returns on effort for each feature and some features just don't fit well with in plan9. And sometimes there's a workable alternative.
Lastly, it's really not for general users. It's for (academic?) computer people who are dexterous and willing to try new things.
I closely studied plan 9 many times, I unfortunately can't use it because of accessibility issues but from what I read and heard it feels more like a time capsule from the 90s, which is ironic considering it was meant to be a future path for os research. And even in the 90s there were developments in unix that the labs seemingly completely ignored, like DJB's daemon supervision.
To talk about the article itself, the only reason plan 9 can achieve such a design is because it's developed and used by the same small group of people. If linux is a bazaar and BSDs are cathedrals, then 9front is a monastery's citadel. Another thing that isn't mentioned is that both linux and BSD (and pretty much anything based on posix) has a lot of third party software that would be hard to maintain along with the rest of the system, if the monks even include it to begin with. And that software could include something like jq which a lot of software depends on and would love to just assume it's there.
And really, what more does someone get from something like this over, say, having a more or less formal standard on what a true plan9 system includes and waving it in someone's face when they choose to ignore it? This is pretty much what modern unices do and it works out great in cases when it's actually important. Most people don't care what commit your system is built from as long as it works as their programs expect it to.
I didn't directly mention third party software but when I talk about the various levels of default software the implication is that those with less built in typically rely more heavily on third party software. Even those who do ship a more batteries included base still have to provide mechanisms for using third party software given the ecosystem.
> ... has a lot of third party software that would be hard to maintain along with the rest of the system
This is the point that the article is trying to challenge. I think 9front proves that it's doable.
> Most people don't care what commit your system is built from as long as it works as their programs expect it to.
The former helps the later a lot. Everything is tested with each other and for a lot of functionality there is only one option.
I've played with Plan9 several times, but never used it seriously. The aesthetics that puts me off. Would have been great if they had taken guidance from BeOS / Haiku-OS for the look and feel. Heck, even Windows 95 would have been an improvement.
That would have been difficult since Plan 9 predates each of those other systems. Also Plan 9 took place in Bell Labs as a research project, was based on their own UI research, and was not intended to be a commercially familiar UI. There are interesting ideas in the write ups about the UI that could be applied in nearly any UI today.
Plan 9 was heavily influenced by the Xerox PARC Mesa/Cedar interface, which influenced Wirth’s Project Oberon. I forget whether Project Oberon directly influenced Plan 9, but I’ve heard people argue that Rob Pike, one of the leaders of the Plan 9 project at Bell Labs, was heavily influenced by Wirth when it came to programming language design, even if the syntax was closer to C instead of Wirth languages like Pascal, Modula-2, and Oberon. With that said, there are major similarities between the interfaces of Cedar/Mesa, Project Oberon, and Plan 9.
A few years ago I thought about what it would take to implement a more conventional desktop GUI on top of Plan 9, but I’ve oscillated back and forth between wanting Plan 9 with a Mac-like desktop versus wanting a modern Lisp/Smalltalk machine (with object-oriented underpinnings instead of Plan 9’s “everything is a file” interfaces) with a Mac-like desktop.
Not an expert in OS development whatsoever but I do know that it's not intended for common usage, so how its UI looks is not something devs would take much care of.
Though I do know that it puts some strong emphasis on mouse usage, something that for someone that grew to use the keyboard a lot like me (ironically, as a graphic designer) seems to be really awkward, to say the less. Its strengths seem to be its overlaying concepts and that it intended to be "the next gen Unix" - alas it won't take over for a myriad of reasons, and some would argue Unix-es have already borrowed some of its concepts for themselves.
The UI is called Rio. It’s simple yet functional and the plumbing thing is kinda cool. The thing that irks me with Plan9 (I have tried 9front) is the lack of tab completion on the shell. It’s easy to input garbage on the screen and contrary to most modern shells where you can just skip a line you need to use your mouse to put the cursor back where the prompt is.
The author is putting "upstream" on some weird pedestal. The whole point of foss is that any upstreams have very limited privileges compared to downstreams.
> Put in another way, if someone wanted the ability to touch every line of code (in the upstream sense), they would have to be a member of some non trivial amount of communities.
On a typical distro you can just download sources and start hacking, you don't need to be member of any community.
While something like Debian might not be monorepo in the strictest sense, on a conceptual level it is very close. They still have all the sources under their control and are not dependent on anything outside. They are at full liberty to accept or reject any patches regardless of where they come from, from "upstream" or "downstream".
This idea that distros are actually independent full-featured operating systems is an idea that I think is getting forgotten way too often. Distros are (or rather can be) much more than mere repackaging of upstream software.
There is a direct correlation between the amount of power exerted by a project like Debian over an upstream project, and the amount of effort and upkeep required in doing so. I think of this like a sliding scale between shipping things with zero patches and a full on fork. From my understanding distribution patches on top of upstream projects tend to be typically just bug or portability fixes and stop short of adding features. The point I was trying to communicate was that in order to fully interact with the software you either have to be part of the upstream community or essentially fork.
The illustrate how I think Plan 9 is different in this regard. A patch for 9front could include a new feature for our compilers and then also show how useful it is by using it within other parts of our code. In plan 9 you can interact fully with every component.
So is there something (social or technical) that makes it tricky to independently provide apps for plan 9, or is it just that the only people who care already have commit access?
Readit News
Only since Windows 10 build 17063 (December 2017 pre-release) [0] [1], which was released as Windows 10 April 2018 Update. So for the first 25+ years of Windows' existence, it didn't.
And although it does implement the basic functionality, it is missing features found on mainstream Unix-like platforms, e.g. file descriptor passing (SCM_RIGHTS)
[0] https://devblogs.microsoft.com/commandline/af_unix-comes-to-...
[1] https://betawiki.net/wiki/Windows_10_build_17063
Same with other hypervisors, virtualbox etc do the same. If you have docker installed on macOS it also uses 9p to share data with the host.
But IMO 9p is a terrible choice for this, particularly because it doesn’t support hard links. It breaks a lot of software like sccache etc which rely on hardlinks to work.
The reply from the plan9 devs on why this is the case hits staggering levels of arrogance:
> If you look at what a hard link is, you'll realize why they are not in Plan 9.
https://groups.google.com/g/comp.os.plan9/c/24mMVoy6wXA/m/JW...
I'd even suggest it reflects humility not arrogance.
He is right however, you are also right: it's because Windows and Docker publish 9p server in a stupid way. It shouldn't be just the guest fs, you should be able to make any file server you like so hard links would be useless (as they are in plan9) because you would decide what filesystem organization layout you need.
You could make do with FUSE inside the virtualized OSes I guess.
One of the “stupid” ideas I have in my back-burner is to rewrite rio so that it works like Mac OS 7 (the platinum look with window shading), which in my mind was always a very sane and efficient way to manage windows — but time is not on my side…
I have one of my usual lists of resources for it on https://taoofmac.com/space/os/plan9 - comment here if it’s missing anything you particularly like.
This is IMO the biggest drawback. Why wouldn't any user want the software to be feature rich? In fact, looking at Plan 9, I often feel that the provided software is just a MVP.
Composable software is something I’m highly interested in. There were efforts in the 1990s to make desktop software more composable, such as COM from Windows and OpenDoc from Apple, but the desktop world is still dominated by large applications such as those that constitute Microsoft Office and the Adobe Creative Suite. It would have been a wonderful opportunity for the Linux desktop world to embrace components, but, alas, the community embraced OpenOffice, GIMP, and other large applications.
COM is everywhere on Windows, specially since Vista, as the WinDev regained the control they thought Longhorn was going to take away from them.
One of Powershell strengths is the easy access to COM, just like .NET, frameworks.
Linux could do the same with D-Bus, but alas so is the distributions wars, and hate on anything like proprietary OSes, that it only has a minor role on systemd, GNOME and KDE.
It's pleasant to use a minimalist, viable product.
9front is not the only OS I use, but it is one of my daily drivers.
https://www.youtube.com/watch?v=6m3GuoaxRNM
I should probably make time look again in case I missed something or it's improved in the last decade.
Users want feature rich systems. Individual programs are best feature-complete, but focused on a single task and capable of cooperating with others when something out of scope is desired.
From my personal viewpoint: It's not easy to hack on large monoliths, even for senior software engineers. But if every logical piece of the monolith tries to be as small as it meaningfully could, the barriers are drastically lower.
Lastly, it's really not for general users. It's for (academic?) computer people who are dexterous and willing to try new things.
Deleted Comment
To talk about the article itself, the only reason plan 9 can achieve such a design is because it's developed and used by the same small group of people. If linux is a bazaar and BSDs are cathedrals, then 9front is a monastery's citadel. Another thing that isn't mentioned is that both linux and BSD (and pretty much anything based on posix) has a lot of third party software that would be hard to maintain along with the rest of the system, if the monks even include it to begin with. And that software could include something like jq which a lot of software depends on and would love to just assume it's there.
And really, what more does someone get from something like this over, say, having a more or less formal standard on what a true plan9 system includes and waving it in someone's face when they choose to ignore it? This is pretty much what modern unices do and it works out great in cases when it's actually important. Most people don't care what commit your system is built from as long as it works as their programs expect it to.
> ... has a lot of third party software that would be hard to maintain along with the rest of the system
This is the point that the article is trying to challenge. I think 9front proves that it's doable.
> Most people don't care what commit your system is built from as long as it works as their programs expect it to.
The former helps the later a lot. Everything is tested with each other and for a lot of functionality there is only one option.
A few years ago I thought about what it would take to implement a more conventional desktop GUI on top of Plan 9, but I’ve oscillated back and forth between wanting Plan 9 with a Mac-like desktop versus wanting a modern Lisp/Smalltalk machine (with object-oriented underpinnings instead of Plan 9’s “everything is a file” interfaces) with a Mac-like desktop.
Though I do know that it puts some strong emphasis on mouse usage, something that for someone that grew to use the keyboard a lot like me (ironically, as a graphic designer) seems to be really awkward, to say the less. Its strengths seem to be its overlaying concepts and that it intended to be "the next gen Unix" - alas it won't take over for a myriad of reasons, and some would argue Unix-es have already borrowed some of its concepts for themselves.
Of course lots of it might be skill issue.
https://web.archive.org/web/20240728004832/https://posixcafe...
> Put in another way, if someone wanted the ability to touch every line of code (in the upstream sense), they would have to be a member of some non trivial amount of communities.
On a typical distro you can just download sources and start hacking, you don't need to be member of any community.
While something like Debian might not be monorepo in the strictest sense, on a conceptual level it is very close. They still have all the sources under their control and are not dependent on anything outside. They are at full liberty to accept or reject any patches regardless of where they come from, from "upstream" or "downstream".
This idea that distros are actually independent full-featured operating systems is an idea that I think is getting forgotten way too often. Distros are (or rather can be) much more than mere repackaging of upstream software.
The illustrate how I think Plan 9 is different in this regard. A patch for 9front could include a new feature for our compilers and then also show how useful it is by using it within other parts of our code. In plan 9 you can interact fully with every component.
I would say introducing a backdoor (xz) without downstream knowing is probably the biggest "privilege" you can have on a system or distribution no?