On 5/13/24 06:56, ibrahim via 9fans wrote: > 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.
Are you interested in sharing code between your fork and us? If you have no intention of making your fork freely available then I don't think there is really much of a point in having some sort of compatibility layer. If there were a couple of open source Plan 9 forks that each saw active development and we were having issues with keeping the source code ported between them sure I could see this as a reason to do that. We have however never found that the source code proved much of a challenge for porting things from 9legacy et all. > > 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. Well that is the topic of discussion now, after you got bored of making incorrect claims about our license, and after we got here from some new user asking about whether or not they should use 9legacy or 9front. Your initial objection to 9front being recommended was licensing issues, that was proven false, so now the goal posts have moved to "well you're not REAL plan 9" as if that has any sort of impact to any user asking for which code to use to learn the system. Seems like not wanting to call OpenBSD a "UNIX" because it's not technically a direct release from AT&T/Nokia/whoever. While technically true, you'd get a pretty similar response if you went around telling people to use research UNIX over OpenBSD. Fine my dude, you don't have to call us Plan 9, you don't have to want to use our code. However I ask that you be mindful in how you talk to new users and don't assume that they have this same level of care for authenticity and "pure" code origins as you. If these things are a showstopper for people they are usually explicitly stated. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mfe4bba2bf6b9ee5d32d4978b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
