I wish we had the same visibility and community around Inferno. I’d especially love to understand what they changed after Plan9 to have a better appraisal of what’s worth keeping. Inferno had a pot of significant software written for it even though it didn’t realy see production.
I hoped to do a talk about it at FOSDEM but I wanted to talk to Dr Charles Forsyth at Vita Nuova, and get my facts straight, first – but he was too busy to talk.
The evidence suggests that the popularity of an operating system (indeed, of most
software) is inversely proportional to its technical excellence.
You know, this is true - the more people use an OS, the more crappy things they discover about it. After all, it’s easy to imagine a particular OS is flawless if nobody has ever used it.
I’ve spent some time pondering the Plan 9 code and would lean toward this take. It is cute, borderline quaint, and often enough annoying in (to me) awkward terseness. The stuff I care a lot about in an OS like architecture support, bus and device drivers, complications like block storage and networking stacks (which is where all the pain is if you want to be relevant) are nowhere near industrial grade even adjusting for the era it was written. So if you acknowledge that it was a research project with some interesting ideas, particularly around exposing various system resources over a network namespace, that part is cool – a trendy academic topic in the early 1990s – and that alone wasn’t enough to loft into the category of a better mousetrap.
I was not being duplicitous, this file existed as such under the commercial stewardship of the OS. 9Front looks like it has begun an abstract PCI into a MI layer which is a fundamental, but the code is still largely the same broken out into a few files i.e. https://git.9front.org/plan9front/plan9front/2b8e615cfc98718314ddc1151934ef2f24db8de3/sys/src/9/pc/pcipc.c/f.html. It is not an industrial grade bus implementation and this is the most important bus of 30 years.
The bus is an industry standard - in this case it means meeting the needs of real world system construction. The inverse, not meeting the industry standard, would be a prototype, experiment, demonstration, limited use system, toy, etc.
Death by 1000 cuts. If you don’t need to see it, blissful ignorance is still bliss which is what the quoted comment was all about.
Offhand MI: AER, various bridge and affinity topology, iommu, sr-iov, passthrough, various link power management. So if you could even boot on a modern 8000-series epyc server (which I am skeptical), you are going to use more power to do significantly less work before we even get into MI things like lock/lockless scaling primitives, NUMA, scheduling.
Just a heads up that these topics and more will be discussed in Paris in May:
http://iwp9.org/
The linked paper has been submitted to the conference and is currently under review.
Please come and see it live :)
I wish we had the same visibility and community around Inferno. I’d especially love to understand what they changed after Plan9 to have a better appraisal of what’s worth keeping. Inferno had a pot of significant software written for it even though it didn’t realy see production.
Absolutely.
I hoped to do a talk about it at FOSDEM but I wanted to talk to Dr Charles Forsyth at Vita Nuova, and get my facts straight, first – but he was too busy to talk.
You know, this is true - the more people use an OS, the more crappy things they discover about it. After all, it’s easy to imagine a particular OS is flawless if nobody has ever used it.
I’ve spent some time pondering the Plan 9 code and would lean toward this take. It is cute, borderline quaint, and often enough annoying in (to me) awkward terseness. The stuff I care a lot about in an OS like architecture support, bus and device drivers, complications like block storage and networking stacks (which is where all the pain is if you want to be relevant) are nowhere near industrial grade even adjusting for the era it was written. So if you acknowledge that it was a research project with some interesting ideas, particularly around exposing various system resources over a network namespace, that part is cool – a trendy academic topic in the early 1990s – and that alone wasn’t enough to loft into the category of a better mousetrap.
An example https://github.com/plan9foundation/plan9/blob/main/sys/src/9/pc/pci.c
To be fair, you are pointing to a 20 to 30 years old source. 9front is under active development, this file doesn’t even exist there anymore:
https://git.9front.org/plan9front/plan9front/2b8e615cfc98718314ddc1151934ef2f24db8de3/sys/src/9/pc/f.html
I was not being duplicitous, this file existed as such under the commercial stewardship of the OS. 9Front looks like it has begun an abstract PCI into a MI layer which is a fundamental, but the code is still largely the same broken out into a few files i.e. https://git.9front.org/plan9front/plan9front/2b8e615cfc98718314ddc1151934ef2f24db8de3/sys/src/9/pc/pcipc.c/f.html. It is not an industrial grade bus implementation and this is the most important bus of 30 years.
“Industrial grade” is something I typically use as an insult when describing code. What do you mean by that?
The bus is an industry standard - in this case it means meeting the needs of real world system construction. The inverse, not meeting the industry standard, would be a prototype, experiment, demonstration, limited use system, toy, etc.
And, in what ways does the 9front code not meet the needs of a real world system?
Death by 1000 cuts. If you don’t need to see it, blissful ignorance is still bliss which is what the quoted comment was all about.
Offhand MI: AER, various bridge and affinity topology, iommu, sr-iov, passthrough, various link power management. So if you could even boot on a modern 8000-series epyc server (which I am skeptical), you are going to use more power to do significantly less work before we even get into MI things like lock/lockless scaling primitives, NUMA, scheduling.
To be also fair that file has been rewritten in http://www.collyer.net/who/geoff/9/9k-pf.tgz as per the comment:
I suggested adding the historical tag.