4 ms·

Plan 9 is mostly Rob Pikes idea and did not involve Ritchie heavily. https://doc.cat-v.org/plan_9/1st_edition/designing_plan_9 https://doc.cat-v.org/plan_9/1st_

Plan 9 is mostly Rob Pikes idea and did not involve Ritchie heavily. https://doc.cat-v.org/plan_9/1st_edition/designing_plan_9 https://doc.cat-v.org/plan_9/1st_edition/designing_plan_9 Recently, Pike commented that he designed Plan 9 so he could build the windowing system he wanted. (edit: oops, link) https://9fans.topicbox.com/groups/9fans/T4fec171fec7e3845-M2aa08b2665722b7fb587bb13/principia-softwarica-fourth-book-on-the-windowing-system-rio https://9fans.topicbox.com/groups/9fans/T4fec171fec7e3845-M2...

pram 2mo ago
That XTerm readme is pretty funny "Abandon All Hope, Ye Who Enter Here"
- scoot 2mo ago
  It's a quote from Dante's Inferno
lproven 2mo ago
I knew this about Pike, but not Ritchie. Thanks. I think, though, that one of the vastly underestimated aspects of Plan 9/9front is its simplified C. AIUI one of the biggest differences is that a file is not allowed to `#include` anything that has already been #included in a parent project. You are not allowed to nest #includes. The result is vastly reduced compile times. I have read claims of over 1000x fewer lines of code going through the compiler. (Sure, disk caching helps a lot, but it still has to go through CPU.) Cleaning up a codebase is a massive PITA but it's a one-time job and I have read comments that once you learn this, it quickly becomes habit. Imagine if that was put into C29 as an advisory. Decades and centuries of compute-time saved. This is standard in Go, which is of course Pike's more recent baby. ANSI C let you get away with this, which sounds like one of the more epic mistakes: https://go.dev/talks/2012/splash.article#TOC_5 https://go.dev/talks/2012/splash.article#TOC_5.
- MisterTea 2mo ago
  If only Go were as simple as the Plan 9 compilers it is derived from. Go is so big it is used as a disk thrashing benchmark for the new 9front gefs disk file system. In addition to disk thrashing it also helped shake out some deep kernel bugs. It also frequently breaks, most recently the bootstrap, likely stack corruption issues. Go also keeps threatening to drop Plan 9. Go: The good, the bad and the ugly - Plan 9 edition. Last time I built it, it took forever (like 15-20 min) vs rebuilding ALL of 9front from source, kernel included (see below.) Plan 9 C is wonderful to work in. I really enjoy its simplicity and how the system design has trimmed away a lot of the ugly API's (select and poll, thank god they're gone...) and replaced them by modern multi-process solutions like thread(2) and ioproc(2). Plan 9 was designed ground up for multi-processor machines and it's all channels (if Go were an OS...) > Decades and centuries of compute-time saved. Rebuild all of 9front user space from source: 'cd /sys/src; mk clean; time mk install' - 51.48u 36.14s 51.23r mk install. almost 51.5 seconds, under a minute on a measly quad core i5-6500T CPU @ 2.50GHz - a Dell micro desktop with a SATA SSD. 9front amd64 PC kernel build: 'cd /sys/src/9/pc64; mk clean; time mk' - 5.38u 1.16s 4.19r mk. FIVE FUCKING SECONDS. Same machine as above. Time to build the Arm64 Pi kernel: 4.66u 0.83s 3.99r mk. About one second faster. Edit, I should add the kernel sizes: 9pc64 - 5,412,046 bytes, 9pi3 - 4,443,400 bytes. About a second per megabyte of executable machine code generated.
vintagedave 2mo ago
So that would be 'rio'?[0] I can find screenshots but haven't found much that explains how or why it's different -- what I've read explains it's not how it looks so much as how it functions, eg, each process genuinely own a console or mouse rather than getting events from the OS as you might in, say, Windows. I can't tell if I am understanding this correctly, of course. I do know that in Plan9, 'everything is a file' is literally correct. So owning a mouse would mean reading from /path/to/mouse. But what I've also read is that every process can do so believing they own it - it's theirs exclusively? For anyone reading this comment in future please do not trust it, I don't know what I'm talking about, except that standard references I've found don't fully explain. [0] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Graphical_programs https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Graphica...
- bitwize 2mo ago
  What I think you're referring to is, every process has its own view of the file system. So you can control what a process has access to simply by controlling what the file tree visible to it looks like. The upshot of this is that each process talking to rio can open a file called '/dev/draw' if it wants to draw to its window, but each process sees its own '/dev/draw' and can thereby only draw to its own window! This can't be done very well in a POSIX OS, for which the file system namespace is global; extensions like Linux containers are a (shitty) workaround for this flaw.
  - vintagedave 2mo ago
    That is a very nice explanation. Thankyou!
- MisterTea 2mo ago
  > I do know that in Plan9, 'everything is a file' is literally correct. Almost correct. There are also shared memory segments via segment(3). You segattach(2) to a segment from a user space process then read/write that memory as a file from a user space process [1]. Drivers can expose memory mapped IO (e.g. PCI cards) using a physical segment and segattach to that from a user space process. The vga(8) program does this to do low level register tweaking. Sometimes, a file server is either too tedious, or not the right abstraction. It also enables memory sharing between processes and user space programs. You can share it over the network with rexport(1) but it gets weird (networked PCI/RAM out of the box...) > So owning a mouse would mean reading from /path/to/mouse. But what I've also read is that every process can do so believing they own it - it's theirs exclusively? Rio and other window managers like Lola, multiplex it [2]. This is how each window only sees the mouse when the cursor is within its border window. If I open two windows and run 'cat /dev/mouse' in each window then move the mouse around, cat only outputs data when the mouse is over the window it's running in. 1. https://man.9front.org/3/segment https://man.9front.org/3/segment 2. https://man.9front.org/3/mouse https://man.9front.org/3/mouse (2nd to last paragraph)
pjmlp 2mo ago
Additionally, the end stop was Inferno and not Plan 9. Rob Pike also acknowledged that leaving GC out of Alef and going back to C was a mistake, speaking of which the Plan 9 C compilers continued to be their own thing instead of blindly following the new language standard.

pram 2mo ago

That XTerm readme is pretty funny "Abandon All Hope, Ye Who Enter Here"

scoot 2mo ago
It's a quote from Dante's Inferno

lproven 2mo ago

I knew this about Pike, but not Ritchie. Thanks. I think, though, that one of the vastly underestimated aspects of Plan 9/9front is its simplified C. AIUI one of the biggest differences is that a file is not allowed to `#include` anything that has already been #included in a parent project. You are not allowed to nest #includes. The result is vastly reduced compile times. I have read claims of over 1000x fewer lines of code going through the compiler. (Sure, disk caching helps a lot, but it still has to go through CPU.) Cleaning up a codebase is a massive PITA but it's a one-time job and I have read comments that once you learn this, it quickly becomes habit. Imagine if that was put into C29 as an advisory. Decades and centuries of compute-time saved. This is standard in Go, which is of course Pike's more recent baby. ANSI C let you get away with this, which sounds like one of the more epic mistakes: https://go.dev/talks/2012/splash.article#TOC_5 https://go.dev/talks/2012/splash.article#TOC_5.

MisterTea 2mo ago
If only Go were as simple as the Plan 9 compilers it is derived from. Go is so big it is used as a disk thrashing benchmark for the new 9front gefs disk file system. In addition to disk thrashing it also helped shake out some deep kernel bugs. It also frequently breaks, most recently the bootstrap, likely stack corruption issues. Go also keeps threatening to drop Plan 9. Go: The good, the bad and the ugly - Plan 9 edition. Last time I built it, it took forever (like 15-20 min) vs rebuilding ALL of 9front from source, kernel included (see below.) Plan 9 C is wonderful to work in. I really enjoy its simplicity and how the system design has trimmed away a lot of the ugly API's (select and poll, thank god they're gone...) and replaced them by modern multi-process solutions like thread(2) and ioproc(2). Plan 9 was designed ground up for multi-processor machines and it's all channels (if Go were an OS...) > Decades and centuries of compute-time saved. Rebuild all of 9front user space from source: 'cd /sys/src; mk clean; time mk install' - 51.48u 36.14s 51.23r mk install. almost 51.5 seconds, under a minute on a measly quad core i5-6500T CPU @ 2.50GHz - a Dell micro desktop with a SATA SSD. 9front amd64 PC kernel build: 'cd /sys/src/9/pc64; mk clean; time mk' - 5.38u 1.16s 4.19r mk. FIVE FUCKING SECONDS. Same machine as above. Time to build the Arm64 Pi kernel: 4.66u 0.83s 3.99r mk. About one second faster. Edit, I should add the kernel sizes: 9pc64 - 5,412,046 bytes, 9pi3 - 4,443,400 bytes. About a second per megabyte of executable machine code generated.

vintagedave 2mo ago

So that would be 'rio'?[0] I can find screenshots but haven't found much that explains how or why it's different -- what I've read explains it's not how it looks so much as how it functions, eg, each process genuinely own a console or mouse rather than getting events from the OS as you might in, say, Windows. I can't tell if I am understanding this correctly, of course. I do know that in Plan9, 'everything is a file' is literally correct. So owning a mouse would mean reading from /path/to/mouse. But what I've also read is that every process can do so believing they own it - it's theirs exclusively? For anyone reading this comment in future please do not trust it, I don't know what I'm talking about, except that standard references I've found don't fully explain. [0] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Graphical_programs https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs#Graphica...

bitwize 2mo ago
What I think you're referring to is, every process has its own view of the file system. So you can control what a process has access to simply by controlling what the file tree visible to it looks like. The upshot of this is that each process talking to rio can open a file called '/dev/draw' if it wants to draw to its window, but each process sees its own '/dev/draw' and can thereby only draw to its own window! This can't be done very well in a POSIX OS, for which the file system namespace is global; extensions like Linux containers are a (shitty) workaround for this flaw.
- vintagedave 2mo ago
  That is a very nice explanation. Thankyou!
MisterTea 2mo ago
> I do know that in Plan9, 'everything is a file' is literally correct. Almost correct. There are also shared memory segments via segment(3). You segattach(2) to a segment from a user space process then read/write that memory as a file from a user space process [1]. Drivers can expose memory mapped IO (e.g. PCI cards) using a physical segment and segattach to that from a user space process. The vga(8) program does this to do low level register tweaking. Sometimes, a file server is either too tedious, or not the right abstraction. It also enables memory sharing between processes and user space programs. You can share it over the network with rexport(1) but it gets weird (networked PCI/RAM out of the box...) > So owning a mouse would mean reading from /path/to/mouse. But what I've also read is that every process can do so believing they own it - it's theirs exclusively? Rio and other window managers like Lola, multiplex it [2]. This is how each window only sees the mouse when the cursor is within its border window. If I open two windows and run 'cat /dev/mouse' in each window then move the mouse around, cat only outputs data when the mouse is over the window it's running in. 1. https://man.9front.org/3/segment https://man.9front.org/3/segment 2. https://man.9front.org/3/mouse https://man.9front.org/3/mouse (2nd to last paragraph)

pjmlp 2mo ago

Additionally, the end stop was Inferno and not Plan 9. Rob Pike also acknowledged that leaving GC out of Alef and going back to C was a mistake, speaking of which the Plan 9 C compilers continued to be their own thing instead of blindly following the new language standard.