On Sep 2, 2026, at 3:32 PM, [email protected] wrote:
> 
> On Wednesday, September 02, 2026, at 1:19 PM, Bakul Shah wrote:
>> What I would love to see is not a rewrite but a rethink and a new take on 
>> plan9 concepts with a new implementation. Not likely though.
> 
> There are now many fascinating responses to this thread.  This is one of 
> them.  My belief is that a comment like this is unlikely to get written by 
> somebody who doesn't already have, possibly buried deep at the back of their 
> mind, one or more ideas for what some of the components of this rethink and 
> new take would be.  Those of us who don't blithely dismiss the likelihood of 
> this actually happening would very much appreciate hearing about some of 
> these components.  I mean, this thread already contains reasonably solid 
> evidence that a re-write in zig would not be a waste of time.  That being the 
> case, if there is more that could be done, beyond that, to further improve 
> the system, then the sooner any such ideas start getting talked about, the 
> better!

Here are some random ideas:
- can we combine the simplicity of plan9 and still provide linux/bsd
  api (but not a step child like ape).
- can we integrate object capabilities as a security model (where
  a file-descr == an ocap & no other way to circumvent security).
  Note that redox people are making some noises about this as well.
- can we further simplify plan9 (but not in the sense of Inferno).
- can we replace 9p with a more scalable, efficient protocol
- can we further modularize the kernel so that we can mix and match
  components for specific applications (but not in the sense of
  kernel loadable modules).
- can we provide a unified "virtual machine" composed of a number
  of compute nodes of various kinds. The idea: to be able to add
  or remove component nodes without bringing down the VM.
- also allow secure sharing of parts of a VM with other VMs.
- can we make memory mapping integral (we had a bit of a discussion
  on this...).
- can we structure things such that device driver (resource FS)
  code can be supervisor or usermode resident with no/little change.
- can we structure things so that latency/bandwidth guarantees
  can be provided for some subsets of apps.
- can the system allow dynamic updates (ala Lisp Systems).
- can we provide network / architecture transparency where we don't
  care about latency or throughput.
- can we configuration / orchestration / management of zillions
  of nodes in an easy to understand manner / data language.



------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td859d3c6cefc922f-M52d88d8ad7d99f45a380b784
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to