Reads like what's missing is all the quality of life tools and polish that developers rely on daily.
Unix hating, or Unix environment hating, is an uphill battle these days. Nowadays every major desktop and most phones have, or can have, some kind of Unix or Unix-like shell.
It's a bit like hating C. I'll probably still be writing C in ten years. I'm not so certain about _any other language_.
Plan 9 isn’t UNIX hating. It’s a successor to UNIX. Many of the things we take for granted in UNIX and UNIX-like systems are actually kludge written to address a short coming of UNIX. Plan 9 was invented to take lessons learned from that and build on UNIX from a ground up reimagining. Thus it is going to differ in some ways while feeling very similar in others.
I think it’s fair to say that Plan 9 is a bit less exciting these days because some of the really great ideas from Plan 9 has seeped its way into Linux and UNIX. But there is also some degree of “momentum lock-in” going on too where UNIX is what people are familiar with so it’s what people expect. Though it’s probably more accurate to say “GNU” these days rather than UNIX (if the conversations about people loading GNU coreutils on Macs via homebrew are anything to be believed)
Plan 9 is more UNIX than UNIX itself. It did away with all the special cases and the result is a beautiful way to create systems components.
There are only two operating systems that I've worked with that I actually really enjoyed, the one is QnX and the other is Plan 9, everything else feels like a series of kludges.
I can sympathise with that. UNIX does get a lot right and if you’re just scratching the surface of things it feels a very powerful system. There is a lot to like there but the more I delved deeper in my career the more ugliness I’d run into. The thing with UNIX is it’s “good enough” in most areas that people don’t always notice those pain points and it’s ingrained enough that the alternatives often feel “worse” just by virtue of being different.
This appears to be one of those sites that should ostensibly be just static text, but the source has none of the content and not even Google's text-only cache manages to show anything. Rather ironic this page is itself inaccessible to users of Plan9...
It used to be a very simple static website, and much more likely than not was just that at the time people were writing to the wiki
Like last year or something they apparently decided to migrate to this mess of a system, for reasons unknown to me. I think it might be mediawiki software?
When he took down the c2 wiki I believe it was discussed on HN. I could have sworn this "remodel" site was supposed to be a temporary solution while he moved to a new server.
Try: http://c2.com/wiki/remodel/pages/WhatIsNotInPlanNine There is a JSON representation, and you could presumably write your own parser for the c2 wiki syntax, in whatever programming language you want to do. (They could make the <noscript> to tell you that you can either enable JavaScript or you can access it under http://c2.com/wiki/remodel/pages/ and parse it yourself.)
> The unix find is a SwissArmyKnife. In PlanNine, the TreeWalking is done by du -- a unix `find . -print` is in PlanNine: `du -a|awk '{print $2}'`
Ah, a clearly much more natural replacement.
EDIT: I got downvoted, but I'm not complaining about it, but rather happy to acknowledge the error of my ways. I cut and pasted what I thought was `du -alawk '{print $2}'`, a mish-mash of 5 unexplained command-line switches, one of them duplicated. (I thought the occurrence of the name `awk` among the switches was just a coincidence.) It wasn't until I noticed the downvote that I realised that what I cut and pasted contained not an `l` switch but a pipe, and was much more simple than what I thought. So, thanks, downvoter!
I dunno, I agreed with your comment even comprehending the syntax. Using a -a flag to a disk usage utility seems like an odd way to frame an essential building block. Plan 9 doesn’t have a recursive ls?
I would guess not, given how the article notes later on that "cp" has no recursion flag:
> Imagine how many separate Unix commands have the TreeWalking built into them... RefactorMercilessly.
And suggests the following shell script instead:
#!/bin/rc
switch ($#*) {
case 2 @{ cd $1 && tar c . } | @{ cd $2 && tar x }
case * echo usage: dircp from to >[1=2]
}
Which is horrifying (how would you ever figure out what " $#* " means?), even without the context of the article's own dislike and distrust of system customization:
> The wide variety of superusers allowed each of them to inflict their style guidelines on the structure of the file system... Now where did that @#!$ superuser put gcc or perl or ...
So what's going to happen here? Every time someone wants to list or copy or search or whatever recursively, they're going to have to either write their own potentially buggy variation on this script, or use someone else's. Is there a convention for where they put that script? Every time someone deploys a new Plan9 box, they're probably going to remember that this was a problem before and provide some kind of script like this. Now where did that @#!$ sysadmin put it?
The solution to the repeated code problem is a library, not stripping critical functionality from core system utilities and burdening users with unnecessary complexity. Why is this 40 year old operating system making me so angry!? I should get out more.
> (how would you ever figure out what " $#* " means?)
The same way you figured out what "$@" or "$*" mean on unix: Reading the manual. For that matter, the variable's meaning is the same as on Unix, except with a 'count length of list' operator in there.
Because the plan 9 shell has proper lists, integrated in nicely. Which means that the script above will work even if the arguments have spaces in the filenames.
> Now where did that @#!$ sysadmin put it?
Doesn't matter, I bound it in to my /bin. All binaries are in /bin after you're done setting up your namespace.
> (how would you ever figure out what " $#* " means?)
It's in the manual.
> Now where did that @#!$ sysadmin put it?
The point of Plan 9 is that you don't rely on the sysadmin to put things places for you. You'd mount your home filesystem from wherever it lives and everything would be back to where you expect it. You could even mount /bin from whatever machine you wanted.
Plan 9 does not work in pieces. It only works if you're all-in, which is the reason I don't use it. But when you're all-in, it's very nice. None of the things you're objecting to turn out to be problems in practice. The problems in practice come from not having a c++ compiler or a web browser.
It has more to do with nobody getting paid to teach you about systems engineering. Some search engine keywords to get you started are "distributed systems fault tolerance".
I'm not sure I follow the argument about symbolic links. What do they have to do with the root UNIX thinking that it owns the whole filesystem? I don't often see symlinks used in the context of crossing "imported" (mounted?) parts of the filesystem - instead, I use them most often to provide aliases so that the same file/directory can be accessed with multiple names.
If you want the same thing to have multiple names you can just use a hard link. Symlinks are a broken idea in Plan9 because whether they’re relative or absolute they may not point to the same thing depending on how you have your namespace set up.
In plan9 each user has their own set of bound file systems (like mounts, but for users not the system as a while), and so has their own logical view of the local and remote file systems, applications, devices, and so on, all presented as a file system rooted at /. It’s a very powerful and elegant design. Symbolic links are kind of stupid and broken in that context.
On Unix I much prefer using symlinks to hard links. Hard links are super confusing when you don't know/remember that they're there. AFAIK there's no easy way to get ls to display them for what they are. If you suspect that something is a hardlink you have to squint at the inode numbers and see if you have duplicates. But if you use symlinks, ls will just tell you, and give you both the link name and destination by default.
I suppose you could use ls_colors to colorize hard links to make them more visible, but then you have to configure that on every server you ssh to.
The comment about Rio vs X Windows would make a lot more sense if you could do the same things in Plan 9 as you could in X Windows. Motif was a giant sack of crap, but you could make an application that was roughly identifiable as a "computer application" of the time to a non-technical user, and even customize/internationalize it (more or less). You'd pretty much be hand-painting every last UI widget in Plan 9. Ridiculous.
Also this comparison was often used as a celebration of not having objects, C++, shared libs, etc. on Plan 9. Again, this would be less ridiculous if any of the large complex things done on other systems that merited shared libs had ever been done at all on Plan 9.
Unfortunately, many of the good ideas in Plan 9 sank alongside this. If they had made "APE" a first-class project they wouldn't have been swivelling back and forth from non-Plan 9 boxes to use the web and the better ideas might have grown into something. :-(
> Motif was a giant sack of crap, but you could make an application that was roughly identifiable as a "computer application" of the time to a non-technical user, and even customize/internationalize it (more or less).
Motif is also not part of X11. If you want something vaguely like it, there's libcontrol which is used by a few applications. Nothing about rio prevents something even thicker from being written (or something like GTK from being ported), other than a strong distaste for that kind of gui.
> Again, this would be less ridiculous if any of the large complex things done on other systems that merited shared libs had ever been done at all on Plan 9.
That's kind of missing the point: The complexity doesn't carry it's weight. I can do most things I care about just fine on plan 9. The major exception is a good web browser, which is an OS on its own, and is best when towed beyond the system and isolated with the birds and fish and tons of crude oil.
> If they had made "APE" a first-class project they wouldn't have been swivelling back and forth from non-Plan 9 boxes to use the web and the better ideas might have grown into something. :-(
The better ideas were largely centered around the simplicity you were just bemoaning. If plan 9 had focused on APE, there would be little of value they could have done.
"other than a strong distaste for that kind of gui"
I would suspect that the process of writing a full-fledged windowing system and graphics layer that people might recognize as behaving roughly like a modern computer (even running a web browser, yet), while holding true to the Plan 9 Received Wisdom, would be a intriguing journey of discovery for someone.
Whether they would emerge as a true believer with their faith strengthened by this trial, or as a Plan 9 heretic, would be an interesting question.
Porting GTK would be similarly doable, all that's really needed is getting a GDK port to do the window management, and porting pixman and cairo for the drawing. I'm not aware of anything that devdraw+rio is missing for a working implementation.
And, if you really want, there were multiple ports of X11 to plan 9 that could be revived -- Equis, for example, , so you could in theory just get did of Gnu-isms, revive one of those unused bits of code, and run it that way.
Again, there are existence proofs -- nothing about plan 9 prevents any of what you're talking, other than the people using plan 9 don't want it, and the people that want it don't want plan 9, or are almost entirely "ideas people" that aren't going to contribute a line of code towards making what they want work.
Web browsers are a different story. The problem with a web browser is that a modern web browser is tens of millions of lines of code to implement a turd that's churning at an incredible rate; Last I looked, Chrome was 20 million lines of code, and needed upwards of 600 substatial out-of-tree patches to even build on BSD. And my bank's website breaks on versions below 70 or so, which means running constantly just to stay with a working version.
We don't have resources to maintain that shit.
For a while, there was 'linuxemu', which emulateds the linux syscall ABI, but even that had a ton of churn, and nobody put in the effort to keep up to date.
Given that plan 9 is all volunteer driven (especially today), if nobody writes the code, nothing happens.
> Whether they would emerge as a true believer with their faith strengthened by this trial, or as a Plan 9 heretic, would be an interesting question.
The question is "what do you want out of this"? To me, this sounds like an awful lot of pointless work that makes the system quite a bit less pleasant, with code that's too big to really understand and easily debug, and a UI model that I don't even use regularly on Unix if I can avoid it. It gives me the same reaction as someone proposing making Linux compatible with MVS (IBM's mainframe operating system), complete with JCL and the data set file system.
You have to bare in mind the era Plan 9 was released in. The concepts of decoupling the OS from your choice of user space tools is actually quite a modern one. Back in the 89s and 90s things were a lot more fragmented. You had a whole plethora of home computers, from 8bit micro computers, whose implementation of BASIC were largely incompatible with each other, through to entirely different designs of personal computers (back when PC didn’t just mean “IBM compatible”). So machines like Atari ST/Falcon, Amiga’s various machines, Apple Macintosh/Lisa/etc, Acorn Electron et al. Even on the IBM PC, there wasn’t really the breadth of choice that there is now.
So people did choose their OS based on what software why wanted to run.
Even in the enterprise space things were more fragmented with less compatibility across the various UNIXes and Linux wasn’t really a viable option until the late 90s.
It’s very easy to judge Plan 9 through the perspective of modern ideals and the expectation of POSIX everywhere but that wasn’t the case when Plan 9 was written. For its era, Plan 9 is has a number of very pioneering concepts.
> The idea that your OS determines your text editor is fundamentally broken.
> Both of those notions destroy loose coupling, which is a fundamental design principle.
The available text editors on the system determines your text editor. If you want a different editor, nothing stops you from porting it.
You should try porting Emacs to Plan 9 but I think you'll find that it isn't so loosely coupled itself. Meanwhile, you can run sam and acme in your favorite Unix clone. Not a huge fan of them, personally
You will find the following Easter egg in the distribution, though:
term% man 1 emacs
EMACS(1) EMACS(1)
NAME
emacs - editor macros
SYNOPSIS
emacs [ options ]
DESCRIPTION
This page intentionally left blank.
SOURCE
MIT
SEE ALSO
sam(1), vi(1)
BUGS
Yes.
Reads like what's missing is all the quality of life tools and polish that developers rely on daily.
Unix hating, or Unix environment hating, is an uphill battle these days. Nowadays every major desktop and most phones have, or can have, some kind of Unix or Unix-like shell.
It's a bit like hating C. I'll probably still be writing C in ten years. I'm not so certain about _any other language_.
Plan 9 isn’t UNIX hating. It’s a successor to UNIX. Many of the things we take for granted in UNIX and UNIX-like systems are actually kludge written to address a short coming of UNIX. Plan 9 was invented to take lessons learned from that and build on UNIX from a ground up reimagining. Thus it is going to differ in some ways while feeling very similar in others.
I think it’s fair to say that Plan 9 is a bit less exciting these days because some of the really great ideas from Plan 9 has seeped its way into Linux and UNIX. But there is also some degree of “momentum lock-in” going on too where UNIX is what people are familiar with so it’s what people expect. Though it’s probably more accurate to say “GNU” these days rather than UNIX (if the conversations about people loading GNU coreutils on Macs via homebrew are anything to be believed)
Plan 9 is more UNIX than UNIX itself. It did away with all the special cases and the result is a beautiful way to create systems components.
There are only two operating systems that I've worked with that I actually really enjoyed, the one is QnX and the other is Plan 9, everything else feels like a series of kludges.
I can sympathise with that. UNIX does get a lot right and if you’re just scratching the surface of things it feels a very powerful system. There is a lot to like there but the more I delved deeper in my career the more ugliness I’d run into. The thing with UNIX is it’s “good enough” in most areas that people don’t always notice those pain points and it’s ingrained enough that the alternatives often feel “worse” just by virtue of being different.
A browser that supports JavaScript.
This appears to be one of those sites that should ostensibly be just static text, but the source has none of the content and not even Google's text-only cache manages to show anything. Rather ironic this page is itself inaccessible to users of Plan9...
It used to be a very simple static website, and much more likely than not was just that at the time people were writing to the wiki
Like last year or something they apparently decided to migrate to this mess of a system, for reasons unknown to me. I think it might be mediawiki software?
> I think it might be mediawiki software?
What? Wikipedia uses MediaWiki, and it looks nothing like that.
It's also functional without JavaScript.
I’m thinking of whatever is used for every wikia site
It's custom, by Ward Cunningham IIRC.
I complained about there being no static site anymore but that was not a priority.
When he took down the c2 wiki I believe it was discussed on HN. I could have sworn this "remodel" site was supposed to be a temporary solution while he moved to a new server.
http://c2.com/wiki/remodel/pages
Try: http://c2.com/wiki/remodel/pages/WhatIsNotInPlanNine There is a JSON representation, and you could presumably write your own parser for the c2 wiki syntax, in whatever programming language you want to do. (They could make the <noscript> to tell you that you can either enable JavaScript or you can access it under http://c2.com/wiki/remodel/pages/ and parse it yourself.)
curl -s http://c2.com/wiki/remodel/pages/WhatIsNotInPlanNine | jq -r .text
works and is GoodEnough
> find
> The unix find is a SwissArmyKnife. In PlanNine, the TreeWalking is done by du -- a unix `find . -print` is in PlanNine: `du -a|awk '{print $2}'`
Ah, a clearly much more natural replacement.
EDIT: I got downvoted, but I'm not complaining about it, but rather happy to acknowledge the error of my ways. I cut and pasted what I thought was `du -alawk '{print $2}'`, a mish-mash of 5 unexplained command-line switches, one of them duplicated. (I thought the occurrence of the name `awk` among the switches was just a coincidence.) It wasn't until I noticed the downvote that I realised that what I cut and pasted contained not an `l` switch but a pipe, and was much more simple than what I thought. So, thanks, downvoter!
There's also walk, at least in 9front: http://man.9front.org/1/walk
UNIX: To recursively traverse directories, use find(1)
Plan 9: find(1) is bloat, use du -a | awk '{print $2}'
UNIX: this is complicated to remember and type
Plan 9: oh you can also use walk(1) to recursively traverse directories
UNIX: so... like find(1) ?
Compare the manpages for find and walk.
Much better.
I dunno, I agreed with your comment even comprehending the syntax. Using a -a flag to a disk usage utility seems like an odd way to frame an essential building block. Plan 9 doesn’t have a recursive ls?
I would guess not, given how the article notes later on that "cp" has no recursion flag:
> Imagine how many separate Unix commands have the TreeWalking built into them... RefactorMercilessly.
And suggests the following shell script instead:
Which is horrifying (how would you ever figure out what " $#* " means?), even without the context of the article's own dislike and distrust of system customization:> The wide variety of superusers allowed each of them to inflict their style guidelines on the structure of the file system... Now where did that @#!$ superuser put gcc or perl or ...
So what's going to happen here? Every time someone wants to list or copy or search or whatever recursively, they're going to have to either write their own potentially buggy variation on this script, or use someone else's. Is there a convention for where they put that script? Every time someone deploys a new Plan9 box, they're probably going to remember that this was a problem before and provide some kind of script like this. Now where did that @#!$ sysadmin put it?
The solution to the repeated code problem is a library, not stripping critical functionality from core system utilities and burdening users with unnecessary complexity. Why is this 40 year old operating system making me so angry!? I should get out more.
> (how would you ever figure out what " $#* " means?)
The same way you figured out what "$@" or "$*" mean on unix: Reading the manual. For that matter, the variable's meaning is the same as on Unix, except with a 'count length of list' operator in there.
Because the plan 9 shell has proper lists, integrated in nicely. Which means that the script above will work even if the arguments have spaces in the filenames.
> Now where did that @#!$ sysadmin put it?
Doesn't matter, I bound it in to my /bin. All binaries are in /bin after you're done setting up your namespace.
> (how would you ever figure out what " $#* " means?)
It's in the manual.
> Now where did that @#!$ sysadmin put it?
The point of Plan 9 is that you don't rely on the sysadmin to put things places for you. You'd mount your home filesystem from wherever it lives and everything would be back to where you expect it. You could even mount /bin from whatever machine you wanted.
Plan 9 does not work in pieces. It only works if you're all-in, which is the reason I don't use it. But when you're all-in, it's very nice. None of the things you're objecting to turn out to be problems in practice. The problems in practice come from not having a c++ compiler or a web browser.
> You could even mount /bin from whatever machine you wanted.
Neat! Now my system is completely unusable if another computer is down or unreachable!
And to think people around here bad-mouth cloud computing.
The fact this got downvoted without discussion must prove it completely discredits Plan 9.
It has more to do with nobody getting paid to teach you about systems engineering. Some search engine keywords to get you started are "distributed systems fault tolerance".
That's utterly irrelevant to my point, but thanks for playing.
`du`, `ls -r` and `find` are all tools which recursively walk and stat directory trees. In that light, it can make sense to pick just one.
I'm with you. The mantra is "do one thing and do it well"
So why is du being generalised to a file system walker?
I'm not sure I follow the argument about symbolic links. What do they have to do with the root UNIX thinking that it owns the whole filesystem? I don't often see symlinks used in the context of crossing "imported" (mounted?) parts of the filesystem - instead, I use them most often to provide aliases so that the same file/directory can be accessed with multiple names.
If you want the same thing to have multiple names you can just use a hard link. Symlinks are a broken idea in Plan9 because whether they’re relative or absolute they may not point to the same thing depending on how you have your namespace set up.
In plan9 each user has their own set of bound file systems (like mounts, but for users not the system as a while), and so has their own logical view of the local and remote file systems, applications, devices, and so on, all presented as a file system rooted at /. It’s a very powerful and elegant design. Symbolic links are kind of stupid and broken in that context.
On Unix I much prefer using symlinks to hard links. Hard links are super confusing when you don't know/remember that they're there. AFAIK there's no easy way to get ls to display them for what they are. If you suspect that something is a hardlink you have to squint at the inode numbers and see if you have duplicates. But if you use symlinks, ls will just tell you, and give you both the link name and destination by default.
I suppose you could use ls_colors to colorize hard links to make them more visible, but then you have to configure that on every server you ssh to.
Also, I sometimes have files cross-referenced with a different indexing or names through symbolic links; is there a better UNIX way of doing that?
The comment about Rio vs X Windows would make a lot more sense if you could do the same things in Plan 9 as you could in X Windows. Motif was a giant sack of crap, but you could make an application that was roughly identifiable as a "computer application" of the time to a non-technical user, and even customize/internationalize it (more or less). You'd pretty much be hand-painting every last UI widget in Plan 9. Ridiculous.
Also this comparison was often used as a celebration of not having objects, C++, shared libs, etc. on Plan 9. Again, this would be less ridiculous if any of the large complex things done on other systems that merited shared libs had ever been done at all on Plan 9.
Unfortunately, many of the good ideas in Plan 9 sank alongside this. If they had made "APE" a first-class project they wouldn't have been swivelling back and forth from non-Plan 9 boxes to use the web and the better ideas might have grown into something. :-(
> Motif was a giant sack of crap, but you could make an application that was roughly identifiable as a "computer application" of the time to a non-technical user, and even customize/internationalize it (more or less).
Motif is also not part of X11. If you want something vaguely like it, there's libcontrol which is used by a few applications. Nothing about rio prevents something even thicker from being written (or something like GTK from being ported), other than a strong distaste for that kind of gui.
> Again, this would be less ridiculous if any of the large complex things done on other systems that merited shared libs had ever been done at all on Plan 9.
That's kind of missing the point: The complexity doesn't carry it's weight. I can do most things I care about just fine on plan 9. The major exception is a good web browser, which is an OS on its own, and is best when towed beyond the system and isolated with the birds and fish and tons of crude oil.
> If they had made "APE" a first-class project they wouldn't have been swivelling back and forth from non-Plan 9 boxes to use the web and the better ideas might have grown into something. :-(
The better ideas were largely centered around the simplicity you were just bemoaning. If plan 9 had focused on APE, there would be little of value they could have done.
"other than a strong distaste for that kind of gui"
I would suspect that the process of writing a full-fledged windowing system and graphics layer that people might recognize as behaving roughly like a modern computer (even running a web browser, yet), while holding true to the Plan 9 Received Wisdom, would be a intriguing journey of discovery for someone.
Whether they would emerge as a true believer with their faith strengthened by this trial, or as a Plan 9 heretic, would be an interesting question.
There's really nothing preventing anyone from implementing what you're talking about. Some of it's already been done, and undone, at various times.
Rio (well, devdraw, really) presents a similar drawing model to Xrender -- in fact, Plan 9's draw is listed directly as the inspiration for Xrender. If you want a fancy GUI, nuklear is ported (https://github.com/vurtun/nuklear, https://bitbucket.org/mischief/libnuklear/src/default/).
Porting GTK would be similarly doable, all that's really needed is getting a GDK port to do the window management, and porting pixman and cairo for the drawing. I'm not aware of anything that devdraw+rio is missing for a working implementation.
And, if you really want, there were multiple ports of X11 to plan 9 that could be revived -- Equis, for example, , so you could in theory just get did of Gnu-isms, revive one of those unused bits of code, and run it that way.
Again, there are existence proofs -- nothing about plan 9 prevents any of what you're talking, other than the people using plan 9 don't want it, and the people that want it don't want plan 9, or are almost entirely "ideas people" that aren't going to contribute a line of code towards making what they want work.
Web browsers are a different story. The problem with a web browser is that a modern web browser is tens of millions of lines of code to implement a turd that's churning at an incredible rate; Last I looked, Chrome was 20 million lines of code, and needed upwards of 600 substatial out-of-tree patches to even build on BSD. And my bank's website breaks on versions below 70 or so, which means running constantly just to stay with a working version.
We don't have resources to maintain that shit.
For a while, there was 'linuxemu', which emulateds the linux syscall ABI, but even that had a ton of churn, and nobody put in the effort to keep up to date.
Given that plan 9 is all volunteer driven (especially today), if nobody writes the code, nothing happens.
> Whether they would emerge as a true believer with their faith strengthened by this trial, or as a Plan 9 heretic, would be an interesting question.
The question is "what do you want out of this"? To me, this sounds like an awful lot of pointless work that makes the system quite a bit less pleasant, with code that's too big to really understand and easily debug, and a UI model that I don't even use regularly on Unix if I can avoid it. It gives me the same reaction as someone proposing making Linux compatible with MVS (IBM's mainframe operating system), complete with JCL and the data set file system.
> vi, emacs, ...
>> Try acme or sam.
The idea that your OS determines your text editor is fundamentally broken.
The idea that your OS determines your GUI model is also fundamentally broken.
Both of those notions destroy loose coupling, which is a fundamental design principle.
And this...
> objects
>> BellLabs didn't need them since the complexity is back under control.
... is really too incoherent to refute.
You have to bare in mind the era Plan 9 was released in. The concepts of decoupling the OS from your choice of user space tools is actually quite a modern one. Back in the 89s and 90s things were a lot more fragmented. You had a whole plethora of home computers, from 8bit micro computers, whose implementation of BASIC were largely incompatible with each other, through to entirely different designs of personal computers (back when PC didn’t just mean “IBM compatible”). So machines like Atari ST/Falcon, Amiga’s various machines, Apple Macintosh/Lisa/etc, Acorn Electron et al. Even on the IBM PC, there wasn’t really the breadth of choice that there is now.
So people did choose their OS based on what software why wanted to run.
Even in the enterprise space things were more fragmented with less compatibility across the various UNIXes and Linux wasn’t really a viable option until the late 90s.
It’s very easy to judge Plan 9 through the perspective of modern ideals and the expectation of POSIX everywhere but that wasn’t the case when Plan 9 was written. For its era, Plan 9 is has a number of very pioneering concepts.
> The idea that your OS determines your text editor is fundamentally broken.
> Both of those notions destroy loose coupling, which is a fundamental design principle.
The available text editors on the system determines your text editor. If you want a different editor, nothing stops you from porting it.
You should try porting Emacs to Plan 9 but I think you'll find that it isn't so loosely coupled itself. Meanwhile, you can run sam and acme in your favorite Unix clone. Not a huge fan of them, personally
I'd say that emacs would be the main thing missing for me.
As an Emacs user myself, I share your pain.
You will find the following Easter egg in the distribution, though:
http://man.cat-v.org/plan_9/1/emacs