Plan 9 is amazing. I just released my own ancient little operating system (see 'Show HN') which took some of Plan 9's ideas. Plan 9 was a massive inspiration at the time that it was released, I had it running on a really small machine for the time and I love the underlying concepts. It is a real pity that it never really took off.
Plan 9 is what Unix could have been, the whole idea that 'everything is a file' is so powerful that we ended up not believing it and the resulting hacks are all so ugly in comparison. Plan 9 does this so consistently that you can test a new version of the window manager in a window on the currently running window manager.
For fun I ran the Bell-Core window manager inside a Plan 9 window at some point just to see if it could be done.
"everything is a file" is unix's equivalent of the Greek's "everything is a basic geometric shape" and epicycles, or heck, "everything is an object". These kinds of reductions are naive and result in kludges of representation.
> These kinds of reductions are naive and result in kludges of representation.
I've spent a lot of time with these 'kludges' as well as all of the alternatives available and I far prefer the kludges. They make working with resources remote or local a breeze, they allow the same software to work with a COM port or a SCSI channel, they allow for all kinds of abstractions and get rid of an enormous amount of cruft in code to special case each and every device under the sun.
The 'Unix' version of that statement is the one that is kludgy, I'll give you that. But I was looking well beyond Unix, see TFA.
>the whole idea that 'everything is a file' is so powerful that we ended up not believing it and the resulting hacks are all so ugly in comparison
I agree. People find it hard to wrap their heads around simple and uniform interfaces. They can’t simplify what they want to accomplish, they want to inflict their complexity on everyone.
Simplifying is maybe emotionally deflating, it makes for a less satisfying solution. Career-wise, it is better to propose complex solutions that take lots of manpower. That’s how you climb the ladder.
yet - you still have to learn opaque crap. example
echo kill > /proc/123/ctl
Sure, that works if you know kill, but you cannot inspect ctl and understand the interface, its a write interface. so you can certainly RTFM, read the dev proc list, etc. it's not discoverable
so like /proc/net/stat or whatever, it means nothing to me... its gonna just be a TSV of bytes that mean something, unless you know it.
so for all the simplicity, it's what i would call, not very usable.
I guess in theory there is nothing stopping the system from providing yet other files, like say "/proc/123/ctl/description" which provides a human-readable description of what "/proc/123/ctl" does, and "/proc/123/ctl/schema" which provides a standardized schema for interacting with the parent, akin to a XSD or JSON Schema.
Ok, but there's nothing stopping from writing a "discoverable" GUI or TUI or CLI for this interaction.
To the user it doesn't matter.
To the developer, it makes a difference.
/proc/<pid>/ctl is not any more or less simple or discoverable for the end user than TerminateProcess or kill(2). It's all opaque esoteric stuff.
But for the developer /proc/<pid>/ctl is MORE discoverable than TerminateProcess or kill(2), since it's a file you can list, so you know it exists. Yeah, you still have to read the man page (you always have to read the docs as a developer), but you know there's a ctl file that probably controls some stuff about the process there. And you already know how to interact with it (the same IO interface as everything else).
> Applications are written in the Limbo programming language, which provides static typing, garbage collection, and built-in concurrency features. Limbo code is compiled into architecture-independent bytecode executed by the Dis virtual machine. The Dis VM can interpret the bytecode or compile it just-in-time into native instructions, allowing applications to run consistently across different platforms.
Can you port existing software to it, or do you have to rewrite everything in Limbo? Because if you do, that right there almost completely kills it IMO.
You could port as much as what was already on Plan 9, so same restrictions apply as UNIX to Plan 9.
The C compiler is there, the same way as in Plan 9, Inferno is the evolution of Plan 9, in one way it was Bell Labs response to Java, in other way it was another take to what went wrong in Plan 9 like the failure to design Alef to be usable.
Naturally Limbo was prefered as the main userspace language, from safety and usability point of view.
Ah, okay, I thought limbo was the only userspace language, which would massively hinder adoption. If that's not the case then I know of no particular technical reason inferno wouldn't be a good option. I do wonder if other people had the same misunderstanding as I did.
As someone who tried to use both, there is little you can do with it in practice when compared to Plan9. There was a _great_ baremetal port of Inferno to the Raspberry Pi, but there aren't any modern versions for other SBCs.
Plan9port is available in a lot of package managers. I've been using mk and rc for my build/task running and scripting needs for a while and have been very happy. rc in particular is such a concise scripting language that shaves off all the rough edges of sh (not to mention bash), I rarely need to reference docs.
There is likely some history there. Plan 9 is the only OS I know of that bakes in all of the documentation and there is a heavily ingrained culture of 'RTFM!' in the community.
The interesting part is the two references to a person who has long since passed, Uriel. The make file and configure files both print "read the README file." I am sure he complained that most people would blindly unpack the source and immediately run make or configure without ever reading anything. It could be a way to force people to RTFM. But that is just my opinion. If you really want an answer, drop an email to the 9fans mailing list and ask. It's still active.
Plan 9 is amazing. I just released my own ancient little operating system (see 'Show HN') which took some of Plan 9's ideas. Plan 9 was a massive inspiration at the time that it was released, I had it running on a really small machine for the time and I love the underlying concepts. It is a real pity that it never really took off.
Plan 9 is what Unix could have been, the whole idea that 'everything is a file' is so powerful that we ended up not believing it and the resulting hacks are all so ugly in comparison. Plan 9 does this so consistently that you can test a new version of the window manager in a window on the currently running window manager.
For fun I ran the Bell-Core window manager inside a Plan 9 window at some point just to see if it could be done.
https://en.wikipedia.org/wiki/ManaGeR
And yes, you could do it, and fairly easily so. This kind of structural coherency is a great feature for an operating system to have.
"everything is a file" is unix's equivalent of the Greek's "everything is a basic geometric shape" and epicycles, or heck, "everything is an object". These kinds of reductions are naive and result in kludges of representation.
> These kinds of reductions are naive and result in kludges of representation.
I've spent a lot of time with these 'kludges' as well as all of the alternatives available and I far prefer the kludges. They make working with resources remote or local a breeze, they allow the same software to work with a COM port or a SCSI channel, they allow for all kinds of abstractions and get rid of an enormous amount of cruft in code to special case each and every device under the sun.
The 'Unix' version of that statement is the one that is kludgy, I'll give you that. But I was looking well beyond Unix, see TFA.
By that logic isn’t this argument equally reductive?
>the whole idea that 'everything is a file' is so powerful that we ended up not believing it and the resulting hacks are all so ugly in comparison
I agree. People find it hard to wrap their heads around simple and uniform interfaces. They can’t simplify what they want to accomplish, they want to inflict their complexity on everyone.
Simplifying is maybe emotionally deflating, it makes for a less satisfying solution. Career-wise, it is better to propose complex solutions that take lots of manpower. That’s how you climb the ladder.
yet - you still have to learn opaque crap. example
echo kill > /proc/123/ctl
Sure, that works if you know kill, but you cannot inspect ctl and understand the interface, its a write interface. so you can certainly RTFM, read the dev proc list, etc. it's not discoverable
so like /proc/net/stat or whatever, it means nothing to me... its gonna just be a TSV of bytes that mean something, unless you know it.
so for all the simplicity, it's what i would call, not very usable.
I guess in theory there is nothing stopping the system from providing yet other files, like say "/proc/123/ctl/description" which provides a human-readable description of what "/proc/123/ctl" does, and "/proc/123/ctl/schema" which provides a standardized schema for interacting with the parent, akin to a XSD or JSON Schema.
Ok, but there's nothing stopping from writing a "discoverable" GUI or TUI or CLI for this interaction.
To the user it doesn't matter.
To the developer, it makes a difference.
/proc/<pid>/ctl is not any more or less simple or discoverable for the end user than TerminateProcess or kill(2). It's all opaque esoteric stuff.
But for the developer /proc/<pid>/ctl is MORE discoverable than TerminateProcess or kill(2), since it's a file you can list, so you know it exists. Yeah, you still have to read the man page (you always have to read the docs as a developer), but you know there's a ctl file that probably controls some stuff about the process there. And you already know how to interact with it (the same IO interface as everything else).
Why Plan 9 seems to be 'much' more popular/discussed and not Inferno?
[0]: https://en.wikipedia.org/wiki/Inferno_(operating_system)
> Applications are written in the Limbo programming language, which provides static typing, garbage collection, and built-in concurrency features. Limbo code is compiled into architecture-independent bytecode executed by the Dis virtual machine. The Dis VM can interpret the bytecode or compile it just-in-time into native instructions, allowing applications to run consistently across different platforms.
Can you port existing software to it, or do you have to rewrite everything in Limbo? Because if you do, that right there almost completely kills it IMO.
You could port as much as what was already on Plan 9, so same restrictions apply as UNIX to Plan 9.
The C compiler is there, the same way as in Plan 9, Inferno is the evolution of Plan 9, in one way it was Bell Labs response to Java, in other way it was another take to what went wrong in Plan 9 like the failure to design Alef to be usable.
Naturally Limbo was prefered as the main userspace language, from safety and usability point of view.
Ah, okay, I thought limbo was the only userspace language, which would massively hinder adoption. If that's not the case then I know of no particular technical reason inferno wouldn't be a good option. I do wonder if other people had the same misunderstanding as I did.
Here is one of the places where you can see the reference to C compiler being available.
https://inferno-os.org/solutions/embedded
Yes, it is a tragedy that so many leave the UNIX evolution[0] train at the middle station, instead of the end.
[0] - as per what its creators worked on following it
As someone who tried to use both, there is little you can do with it in practice when compared to Plan9. There was a _great_ baremetal port of Inferno to the Raspberry Pi, but there aren't any modern versions for other SBCs.
Plan9port is available in a lot of package managers. I've been using mk and rc for my build/task running and scripting needs for a while and have been very happy. rc in particular is such a concise scripting language that shaves off all the rough edges of sh (not to mention bash), I rarely need to reference docs.
Yep and p9 is used many places e.g. in WSL for access to Windows files.
Why did they put installation script in INSTALL INSTEAD OF install.sh? Most other repositories i have seen put human-readable instructions in there.
There is likely some history there. Plan 9 is the only OS I know of that bakes in all of the documentation and there is a heavily ingrained culture of 'RTFM!' in the community.
The interesting part is the two references to a person who has long since passed, Uriel. The make file and configure files both print "read the README file." I am sure he complained that most people would blindly unpack the source and immediately run make or configure without ever reading anything. It could be a way to force people to RTFM. But that is just my opinion. If you really want an answer, drop an email to the 9fans mailing list and ask. It's still active.
Pretty common in all UNIXes, which is why projects like GNU and Linux even had a starting point what to compare themselves to.
IBM systems have the famous Red Books, but ok it isn't included.
Windows before the Internet days, when the SDK came in CD, having a MSDN subscription meant receiving a box with all documentation from Microsoft.
Inferno as Plan 9's successor also included all documentation.
Niklaus Wirth OSes for Modula-2 and Oberon, had the OS documentation as hypertext.
All Xerox PARC OSes, across Smalltalk, Interlisp-D and Mesa/Cedar had online help with the system documentation.
It's plan9. It is supposed to be at once weird and somewhat fitting.
I don't think an INSTALL script with that name is common among Plan 9 software.
Also, this project is designed for operating systems other than Plan 9.
* plan9 PORT sigh the clue is in the name
Yes, it's a plan9 port; why would you expect it to change any more than is absolutely needed to get it running on the new host OS?
Yes, not plan9.
I despair at your (and GGP) lack of comprehension
I don't think it's a lack of comprehension, so much as that we disagree what a "port" means.
I was correcting the user's "plan9" comment.
It's a port of a collection of plan 9 userspace to a non-9 operating system.
Perhaps you've now learnt something
GG