On Monday, 13 May 2024, at 1:11 PM, hiro wrote:
> i mean contributing to the plan9 team. i don't share in your
discrimination of 9front vs. non9front code.
i bet if all of us can be gainfully employed to work on "real plan9"
we can all stop contributing to 9front. please enlighten me who my
future coworkers might be. who else is going to join the team? 

I don't discriminate 9front at all. What I'm trying to say is if we want contribute to each other we need a compatibility layer and the simplest choice is the final edition of plan9. Its well defined and well documented. 

There won't ever be a real plan9 interpretations satisfying all who are interested in plan9. My fork makes use of segments dynld I use a binary interface instead of 9p to achive higher performance regarding data transfer between processes and especially the framebuffer. I have a gui which is portable to linux, windows aso. I can compile my software for plan9 linux and windows without a single change of lines. I use wrapper interfaces to achive this and a preprocessor which produces C code for the compiler on the destination system. My users need shortcut keys so I have a further device which reflects keystates parallel to the operation of keyboard. All those changes differ from the concepts of plan9.  My fork is making use of concept possible with plan9 but not really the plan9 way of doing things. I don't use fossil and others as my filesystem and I don't have a 9fat partition anymore. So how could we possibly agree on a real plan9 we can't. Each fork has its own use case and there is nothing wrong about this.

I never asked you to stop 9front in favour of a real plan9 no one has the right to make such a demand any more. You have your user community and are doing a great job. 

If we want to share contributions between forks we need a compatibility layer if we don't want to we don't have to.

I don't have a problem respecting any fork of plan9. I will give back to other forks as much as I take from them. And if I contribute code to plan9 than I will make sure that it doesn't make use of enhancements I am using within my fork respect the coding styles of such a compatibility layer if one is ever defined. The whole discussion is about interoperability between forks. 
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M42e70cabcf18e8b68a5b30c7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription