Plan 9 shows that you can reduce the complexity of Unix by changing the idea behind mount slightly (mounts are inherited by processes rather than global) and creating a simple network filesystem protocol that applications can use to expose their state through.
In Unix you often get stuck having to create these walled-off systems. Your editor's inner state, for instance, is not visible to other applications, so you need to come up with your own whole programming scheme. Same with your window manager. And all your networking happens through a separate set of APIs that are similar to the file descriptor APIs but different enough that nothing works transparently.
Once you have per-process mounts and a simple network filesystem, all your applications and devices can start exposing their state over that protocol. All your software and hardware are automatically networkable if you follow the design. And you can use Unix utilities to do things that previously would require whole subsystems to be built. You don't need to build your own programming language for Acme, because Acme's state is visible as a filesystem. Same with the window manager. And you don't need to build a custom networking scheme for sharing Acme with your friend on another machine, because you can export Acme's filesystem to that machine (or have your friend export their keyboard onto your machine as a child of the Acme process).
"Everything really is a file" is a good way to sum it up. But that's only possible and relatively safe because of 9P and per-process namespaces.
> Your editor's inner state, for instance, is not visible to other applications, so you need to come up with your own whole programming scheme.
> Same with your window manager.
> You don't need to build your own programming language for Acme, because Acme's state is visible as a filesystem.
I don't see how it's good programming practice to expose your internal state to direct read/write access from other programs. It seems to violate basic encapsulation principles.
Your quotes are making me think of some really important takeaways from the Longhorn disaster with WinFS, detailed in a recent submission[1]:
> More profoundly, Bill’s vision of an ecosystem of applications that all store and share their data in this relational store is in direct conflict with how applications build their data models. While some desktop applications (and almost all internal IT-written ones) use relational stores for their internal data model, they do not want to expose those data models for unmonitored read and write by other applications. I detailed some of the fundamental reasons in the post referenced above, Leaky by Design.[2]
Solutions like this... "what if application state were like a relational data store, or hierarchical FS, that other programs can access", sounds great as a fun programming exercise, but it isn't often how people actually want to design applications.
By "inner state", the parent didn't mean literally the RAM or disk storage used internally by the application, just the logical state that belongs to it. A Plan 9 filesystem is just an interprocess communication API that happens to be structured in terms of virtual 'files' and file operations, kind of like what REST does with HTTP. The application handles all requests itself so it can always limit access or enforce invariants, which was absent in the Microsoft examples you linked.
This isn't really a ’project’ in the sense you seem to intend: it was a 1990s AT&T research project that was abandoned and released under an open source licence in the mid-2000s.
Congratulations, HarveyOS is really an intriguing project to support.
It would be nice, if they'd provide an ISO. The thing I noticed about Plan9 clones and Inferno is that, they almost always run entirely in the userland. I think that's the reason HarveyOS does not provide an iso. I am not sure they are building a standalone operating system.
If you're interested you could also try inferno, however getting it up and running is also a hassle.
Lastly, in the case you're not aware, Plan9 and inferno also have a very interesting history. Inferno and Java were once direct competitors. Limbo a programming languages invented for Plan9 is also mentioned in the Dan Brown's best seller Digital Fortress.
IMHO Plan9 spirit still lives in Golang, like the Lisp Machines' spirit lives in Emacs. Maybe with cloud based OS's we could see the ideas behind Plan9 in everyday world. But other than that Plan9 remains an OS for hobbyists and idealist computer folk :).
> It would be nice, if they'd provide an ISO. The thing I noticed about Plan9 clones and Inferno is that, they almost always run entirely in the userland. I think that's the reason HarveyOS does not provide an iso. I am not sure they are building a standalone operating system.
That's a really good way of putting it. I could see Plan9 being relevant today. A "unified system" is pretty much what all the cloud stuff is attempting to approximate (and more poorly, of course).
In Unix you often get stuck having to create these walled-off systems. Your editor's inner state, for instance, is not visible to other applications, so you need to come up with your own whole programming scheme. Same with your window manager. And all your networking happens through a separate set of APIs that are similar to the file descriptor APIs but different enough that nothing works transparently.
Once you have per-process mounts and a simple network filesystem, all your applications and devices can start exposing their state over that protocol. All your software and hardware are automatically networkable if you follow the design. And you can use Unix utilities to do things that previously would require whole subsystems to be built. You don't need to build your own programming language for Acme, because Acme's state is visible as a filesystem. Same with the window manager. And you don't need to build a custom networking scheme for sharing Acme with your friend on another machine, because you can export Acme's filesystem to that machine (or have your friend export their keyboard onto your machine as a child of the Acme process).
"Everything really is a file" is a good way to sum it up. But that's only possible and relatively safe because of 9P and per-process namespaces.