Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[sirjofri]

18.05.2024 05:33:10 vester.thac...@fastmail.fm:
> Dealing with a social issues on this mailing list is akin to standing in a 
> summer sun, if I deal with them too long I'll become sun burned, and I'll 
> find myself in need to step out of the sun to reduce the severity of the 
> pain. If I can stop getting sun burned, my chances of contributing would 
> improve. I often wonder how many more contributors there might have been if 
> the environment were different. Fostering a better environment would help 
> improve the chance for collaboration is what I'm saying. It seems that hiring 
> someone to help do this for me is a better idea. That way I can step out of 
> the sun.

Makes sense. There's a simple rule on the internet: don't feed the troll. We 
have a troll here (and if you read other threads or join the 9front 
communication channels every now and then, you'll quickly notice them). I never 
tried to change their behavior, because they're adults, and usually that kind 
of trolling stays within borders and they usually have a point (showing the 
absurdity of questions, for example).

It's important to know what you can ignore and what you can learn from it. I 
can safely say that I ignore many of those troll mails. I read them, I find the 
relevant truth, ignore everything else in that mail, then I go on with the next 
mail in that thread.

It's far from a professional environment. On the other hand, most of us do Plan 
9 as a hobby. Don't take everything so seriously. In the 9front mailing list 
some mails are just links to music or funny videos/articles. It's only natural 
that some of this relaxed behavior spills over to the 9fans mailing list. If 
you want a true™®© professional environment, just set up a slack. And yes, this 
is somewhat of a troll (I'm not good at it).

> Take care

This is very important. Take care.

Have a nice day and enjoy the sun from the shadows.

sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M95a4cb9d7708227dad7d179b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vester . thacker]

On Sat, May 18, 2024, at 00:51, Kurt H Maier wrote:
> I love this article very much.  Unhelpful, bossy blowhards should
> experience exactly these emotions.  My favorite part was the accusation
> of "cancel culture," which I have learned is Boomer code for
> "accountability."  They really hate that shit!

I'm pleased it got a conversation going. The topic needed to be addressed. I 
took it down as I realized that when dealing with others expressing 
narcissistic tendencies, the article would not have any impact on their 
behavior anyway. I think I can see now who the narcissists are, as they double 
down on their abusive behavior.  Abusers often don't realize they're abusing 
anyone. However, victims of their abuse do recognize it. 

> If 9front has constructed a culture where someone who calls themselves
> "Innovator Harnessing the Power of Open Source: Transforming Businesses,
> Empowering Solutions" does not feel welcome, then I am profoundly
> satsified with that culture, and commend everyone involved in its
> creation.

I fed my resume into an LLM and it suggested that tagline. I was amused and 
used it.   

> Anyway, just for the record, nobody in the 9front project has any ill
> will toward 9legacy.  Technical concerns like p9sk1, yes, but everyone
> agrees there should be *more* Plan 9 out there, not less.  We keep
> suggesting that people fork 9front as well, and make 9front Suit And Tie
> Edition, Empowering Harnessed Transformative Innovations, with all of
> the technical goodies and none of the humor or fun, but nobody seems to
> have the drive to make that happen.

I looked at behaviors and outcomes when making that assessment.

> If anyone wants help bootstrapping such a project, please let me know
> and I'll help however I can.  The existence of something like that might
> help deflect all the unfunded mandates people keep trying to demand of
> the 9front project, and create a nice home for the sorts of people whose
> primary qualifications are that they like to watch and they've been
> watching for decades.

9legacy can use a hand.

Dealing with a social issues on this mailing list is akin to standing in a 
summer sun, if I deal with them too long I'll become sun burned, and I'll find 
myself in need to step out of the sun to reduce the severity of the pain. If I 
can stop getting sun burned, my chances of contributing would improve. I often 
wonder how many more contributors there might have been if the environment were 
different. Fostering a better environment would help improve the chance for 
collaboration is what I'm saying. It seems that hiring someone to help do this 
for me is a better idea. That way I can step out of the sun. 

Take care.

Kind regards,
Vic

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M8a1cd9f1c0679edc3c916eb5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> you’re right, i apologize. big difference between being a total knob vs 
> exhibiting knob behavior in certain instances. and there’s no excuse for 
> aspersion.

i would not add html to your email.
thank you.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mbb35a221261c96f81367d5f1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[fig]

> i would not call people "losers"

you’re right, i apologize. big difference between being a total knob vs
exhibiting knob behavior in certain instances. and there’s no excuse for
aspersion.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M2eee0ab75d49982c2da732e8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> This mailing list pre-dates the evident new philosophy of cancel-culture. 
> Back when this was still an only mildly hostile place the policy was "don't 
> feed the troll". We did indeed believe that ignoring (at worst adding their 
> address to an "ignore" list) was sufficient to deal with it. But I am aware 
> that the times, they are a-changin'.

more like, this is where that form of trolling first got invented...
and cancel-culture always existed, just the term is new.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M002e365668421193c0228dab
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> Why can’t we remove these losers from the mailing list? Look at this mess. If 
> you want to ask ChatGPT about 9front, by all means, it’s your computer. But 
> dumping walls of verbal diarrhea into the ML and onto LinkedIn and making 
> everyone fight over it is such a waste of time. I understand it’s hard to not 
> participate in these dumpster fires, here I am piling on myself, but it’s 
> just to say, good lord, can we please stop entertaining these people? Or is 
> keeping flame wars and off-topic bickering out of a mailing list like asking 
> the bowling alley on the second floor to keep the noise down?

just lead by example.
i would not call people "losers", and what you said has been said already.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M726c5847d19b78f93f56731d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Lucio De Re]

This mailing list pre-dates the evident new philosophy of cancel-culture.
Back when this was still an only mildly hostile place the policy was "don't
feed the troll". We did indeed believe that ignoring (at worst adding their
address to an "ignore" list) was sufficient to deal with it. But I am aware
that the times, they are a-changin'.

Lucio.

On Fri, May 17, 2024 at 7:51 PM fig  wrote:

> > The document is blatantly AI-generated
> > Not accurate at all
>
> Why can’t we remove these losers from the mailing list? Look at this mess.
> If you want to ask ChatGPT about 9front, by all means, it’s your computer.
> But dumping walls of verbal diarrhea into the ML and onto LinkedIn and
> making everyone fight over it is such a waste of time. I understand it’s
> hard to not participate in these dumpster fires, here I am piling on
> myself, but it’s just to say, good lord, can we please stop entertaining
> these people? Or is keeping flame wars and off-topic bickering out of a
> mailing list like asking the bowling alley on the second floor to keep the
> noise down?
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>


-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M54493776cc3bafc0d87d98fc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[fig]

> The document is blatantly AI-generated
> Not accurate at all

Why can’t we remove these losers from the mailing list? Look at this mess.
If you want to ask ChatGPT about 9front, by all means, it’s your computer.
But dumping walls of verbal diarrhea into the ML and onto LinkedIn and
making everyone fight over it is such a waste of time. I understand it’s
hard to not participate in these dumpster fires, here I am piling on
myself, but it’s just to say, good lord, can we please stop entertaining
these people? Or is keeping flame wars and off-topic bickering out of a
mailing list like asking the bowling alley on the second floor to keep the
noise down?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M41c3f8691f153c1a9066280d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

he already admitted he's using grammarly.

On Fri, May 17, 2024 at 7:00 PM Noam Preil  wrote:
> 
> There's a clear pattern, though. The document is blatantly AI-generated,
> and I believe that the author acknowledged it as such ("the model was
> confirmed as trained on 9front sources"); even if it wasn't, the logical
> mistakes it makes are of a type humans don't generally make.
> 
> The author has many posts that _all_ feature A.I. art. The arguments
> they make have no connection to the premises, although in fairness
> that's a hallmark of bad human writing too. The sources cited have no
> connection to the arguments being made.
> 
> It is not unreasonable to assume that someone who is clearly relying so
> heavily on LLMs might be doing so on the mailing list when so many of
> their posts clearly resemble LLM output.
> 
> Hell, even if they're not using an LLM, if someone is writing with the
> _quality_ of an LLM, they're not worth engaging with. "This horrible
> spam-looking content was actually written by a person!" is not a great
> defense.
> 
> - Noam Preil
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mc1fc467d8d7d7b1873d3fc6f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Noam Preil]

There's a clear pattern, though. The document is blatantly AI-generated,
and I believe that the author acknowledged it as such ("the model was
confirmed as trained on 9front sources"); even if it wasn't, the logical
mistakes it makes are of a type humans don't generally make.

The author has many posts that _all_ feature A.I. art. The arguments
they make have no connection to the premises, although in fairness
that's a hallmark of bad human writing too. The sources cited have no
connection to the arguments being made.

It is not unreasonable to assume that someone who is clearly relying so
heavily on LLMs might be doing so on the mailing list when so many of
their posts clearly resemble LLM output.

Hell, even if they're not using an LLM, if someone is writing with the
_quality_ of an LLM, they're not worth engaging with. "This horrible
spam-looking content was actually written by a person!" is not a great
defense.

- Noam Preil


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M50b020de4168865f586f0fdb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Noam Preil]

It is not, but in fairness, some people really do write the same way
that the LLMs do, so it's not impossible for a real person to appear to
be an LLM.

I'm leaning towards LLM-generated, anyways. It's far too similar in
structure / syntax to other AI spam I've had to deal with recently.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M6b07d6fc6ad01c998e34b8ed
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Interoperating between 9legacy and 9front

[Noam Preil]

> The absence of Fossil from 9front was the one I found most difficult to
> overcome, but at least in theory only the equivalent of "fossil/conf" (an
> rc script I eventually shoehorned from plan9port) is essential. I can see
> how it would be inconvenient to need to support software that is
> significantly complex, especially when it must also be able to be embedded
> in the kernel.

Actually, adding fossil back in to 9front is extremely simple; I have a
branch at https://git.sr.ht/~pixelherodev/plan9 which has fossil
integrated.

The talk I gave at IWP9 was running from fossil on my 9front branch.

If my changes are too extensive compared to 9front (it's a personal
branch, so I wouldn't blame you for thinking that), I'm happy to even
create a branch that's just 9front+fossil. It's really not hard.

- Noam Preil


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mf4487e7706a5d7b4363ebe2e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Noam Preil]

A document that had no research put into it is not a first draft, it's
at best spam.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M636e86d3c30c32c5c186e579
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

no.

On Fri, May 17, 2024 at 4:47 PM Michael Kerpan  wrote:
>
> Could people please stop accusing people of being fake just because they 
> write verbosly? That kind of behavior is part and parcel of the incredibly 
> rude and mean-spirited behavior mentioned in that LinkedIn thing.
>
> Mike
>
> On Fri, May 17, 2024, 10:21 AM hiro <23h...@gmail.com> wrote:
>>
>> or rename that linkedin garbage to "using AI to disincentivize open
>> discussion communities"
>>
>> On Fri, May 17, 2024 at 4:16 PM Jacob Moody  wrote:
>> >
>> > https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/
>> >
>> > This linked-in article is frankly disgusting, I suggest you take this 
>> > incorrect garbage down.
>> >
>> >
>> > On 5/17/24 07:43, Samuel Reader via 9fans wrote:
>> > > It is only a first draft, and it is not a finished product. I'll correct 
>> > > the mistakes found.
>> > >
>> > > Thank you for the kind feedback.
>> > >
>> > >
>> > >
>> > >
>> > > Sent with Proton Mail secure email.
>> > >
>> > > On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> 
>> > > wrote:
>> > >
>> > >> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote:
>> > >>
>> > >>> an other interesting reading :
>> > >>> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
>> > >>
>> > >>
>> > >> I'm appalled and frankly furious about this article. It's blatant
>> > >> slander which can affect me in my professional career. I'm a phD
>> > >> candidate and my work is based on Plan 9 and developed on 9front; I
>> > >> was going to present it at iwp9 but could not once the venue was
>> > >> changed as it rendered it incompatible with my time table.
>> > >>
>> > >> The article lacks references to many of its claims, and the remaining
>> > >> ones directly contradict its points. The Register article is even
>> > >> linked incorrectly. A superficial reader would not bother to try to
>> > >> follow the links or find the article. For me this is clearly
>> > >> malicious attention-seeking.
>> > >>
>> > >> Regarding the pdf posted earlier[1], almost all of it is factually
>> > >> incorrect. As an example, there are no drivers for modern nvidia or
>> > >> amd chips or bluetooth. Many of the "system calls" listed in the pdf
>> > >> are not system calls (proccreate) or simply don't exit (vlongtime),
>> > >> and so on. In addition, it is trivial to recreate the same content
>> > >> with a query like the following: `Generate a detailed book-style
>> > >> document called "Revitalizing Plan 9: integrating modern enhacements
>> > >> into 9legacy" detailing all improvements introduced in 9front compared
>> > >> to 9legacy'. See for yourself in an excerpt below my email.
>> > >>
>> > >> I don't understand what the goal here is. All this post and pdf
>> > >> accomplish is spreading misinformation, promoting cancel culture,
>> > >> fostering community division and discouraging collaboration with
>> > >> 9front and even 9legacy, directly contradicting both Vic's claims and
>> > >> that of those who have sided with him in the thread. At this point,
>> > >> use of chatgpt in this thread is blatant and harmful. Please stop.
>> > >>
>> > >> Thanks,
>> > >> qwx
>> > >>
>> > >> [1] 
>> > >> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
>> > >> ---
>> > >>
>> > >> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
>> > >> Introduction
>> > >> Plan 9 from Bell Labs has long been recognized for its innovative 
>> > >> approach to distributed computing. However, as hardware and software 
>> > >> technologies advanced, the need for a more modernized version of Plan 9 
>> > >> became apparent. This need led to the development of 9front, a fork of 
>> > >> Plan 9 that incorporates numerous enhancements and updates, surpassing 
>> > >> 9legacy in several key areas. This document details these improvements, 
>> > >> offering a comprehensive comparison of the advancements introduced in 
>> > >> 9front over 9legacy.
>> > >>
>> > >> Chapter 1: Graphics and Video Drivers
>> > >> Improved Graphics Hardware Support
>> > >> One of the most significant areas of enhancement in 9front is its 
>> > >> support for modern graphics hardware. This includes:
>> > >>
>> > >> Support for Newer GPUs: 9front integrates drivers for the latest GPU 
>> > >> models, ensuring compatibility with modern graphics cards from 
>> > >> manufacturers like NVIDIA and AMD.
>> > >> Enhanced Frame Buffer Device: The frame buffer device driver has been 
>> > >> optimized for better performance, providing smoother graphics rendering 
>> > >> and faster display updates.
>> > >> Broad Chipset Compatibility: 9front supports a wider range of graphics 
>> > >> chipsets, allowing it to run on diverse hardware configurations with 
>> > >> improved stability and performance.
>> > >> Advanced Video 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Kurt H Maier via 9fans]

On Fri, May 17, 2024 at 07:32:18AM -0400, pl...@room3420.net wrote:
> an other interesting reading :
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card

I love this article very much.  Unhelpful, bossy blowhards should
experience exactly these emotions.  My favorite part was the accusation
of "cancel culture," which I have learned is Boomer code for
"accountability."  They really hate that shit!

If 9front has constructed a culture where someone who calls themselves
"Innovator Harnessing the Power of Open Source: Transforming Businesses,
Empowering Solutions" does not feel welcome, then I am profoundly
satsified with that culture, and commend everyone involved in its
creation.

Anyway, just for the record, nobody in the 9front project has any ill
will toward 9legacy.  Technical concerns like p9sk1, yes, but everyone
agrees there should be *more* Plan 9 out there, not less.  We keep
suggesting that people fork 9front as well, and make 9front Suit And Tie
Edition, Empowering Harnessed Transformative Innovations, with all of
the technical goodies and none of the humor or fun, but nobody seems to
have the drive to make that happen.

If anyone wants help bootstrapping such a project, please let me know
and I'll help however I can.  The existence of something like that might
help deflect all the unfunded mandates people keep trying to demand of
the 9front project, and create a nice home for the sorts of people whose
primary qualifications are that they like to watch and they've been
watching for decades.

khm

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M4bc8405899fcc7a94bd431ef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vester . thacker]

Ok, I'm back. I stopped by because I heard about the ruckus. I am not wrong 
about my sentiments. I am not submitting disinformation. I'm expressing my 
viewpoint based on my experience and what I've witnessed reading 9fans. Help do 
the right thing and help eliminate abusive behavior.  The article I wrote 
wasn't anything special.  9fans has years of evidence for additional claims. 
I'm grateful that the evidences exist online. If you want me to elaborate, I'll 
write about them. What I want to know is why abusive behavior permitted on the 
9fans mailing list? I do not mind exposing bad behavior to a much broader 
audience so that it can get the attention it deserves so that positive change 
can occur.  Quite honestly, the Plan 9 community would be better for it.

I'm hoping change will happen. It will be good for those that want to 
contribute. It is not about control but rather it is about helping others. 
Putting others down isn't helpful nor being friendly. For anyone that engages 
in abusive behavior, please consider getting professional help. Entitlement 
doesn't justify abuse.

I do not write to be spiteful. I write because I care, and I hope to promote 
positive change.

Sincerely,
Vic


On Fri, May 17, 2024, at 23:49, Jacob Moody wrote:
> Hit the enter key a bit early...
> This is directed at Vic, if that is not clear already.
> To everyone else who called me out for assuming malice on victor's part 
> because he was "just trying to help", does this not
> make my claim more obvious now? This likewise is including AI bullshit, 
> and I suspect my claims about his other mails
> being LLM trash are also correct too. There was no apology owed and 
> none should have been given. This is about the
> furthest thing from "helping" that there is.
>
> To be direct, I have found the misinformation about 9front on this list 
> to be at best highly incompetent and at
> worst actively malicious to spread misinformation. Is this really what 
> our resident "9front-haters" are going to rally behind?
> Like I respect that some people don't like us, that's fine. I get that 
> some people have some differences but AI generated misinformation
> is downright insulting. The demands that 9front do something or change 
> their behavior to match some noncontributor's opinion here is
> frankly also insulting our time. I've generally held respect for the 
> people here who have been around a lot longer, while I may disagree
> I will read and think about what is said here. However is this is the 
> type of behavior that is defended (and therefore encouraged) I am
> not interested at all.
>
> I'll be around on this list to argue against the misinformation 
> campaigns, it is clear that if we were to go away this type of 
> misinformation
> would run rampant. I really expected better.
>
> - Moody
>
> On 5/17/24 09:14, Jacob Moody wrote:
>> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/
>> 
>> This linked-in article is frankly disgusting, I suggest you take this 
>> incorrect garbage down.
>> 
>> 
>> On 5/17/24 07:43, Samuel Reader via 9fans wrote:
>>> It is only a first draft, and it is not a finished product. I'll correct 
>>> the mistakes found. 
>>>
>>> Thank you for the kind feedback.
>>>
>>>
>>>
>>>
>>> Sent with Proton Mail secure email.
>>>
>>> On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> wrote:
>>>
 On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote:

> an other interesting reading :
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card


 I'm appalled and frankly furious about this article. It's blatant
 slander which can affect me in my professional career. I'm a phD
 candidate and my work is based on Plan 9 and developed on 9front; I
 was going to present it at iwp9 but could not once the venue was
 changed as it rendered it incompatible with my time table.

 The article lacks references to many of its claims, and the remaining
 ones directly contradict its points. The Register article is even
 linked incorrectly. A superficial reader would not bother to try to
 follow the links or find the article. For me this is clearly
 malicious attention-seeking.

 Regarding the pdf posted earlier[1], almost all of it is factually
 incorrect. As an example, there are no drivers for modern nvidia or
 amd chips or bluetooth. Many of the "system calls" listed in the pdf
 are not system calls (proccreate) or simply don't exit (vlongtime),
 and so on. In addition, it is trivial to recreate the same content
 with a query like the following: `Generate a detailed book-style
 document called "Revitalizing Plan 9: integrating modern enhacements
 into 9legacy" detailing all improvements introduced in 9front compared
 to 9legacy'. See 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Kurt H Maier via 9fans]

On Fri, May 17, 2024 at 02:22:01PM +, Samuel Reader via 9fans wrote:
> The 2nd draft is out. I've made some corrections as mentioned by others, and 
> I have added those who have helped to the acknowledgements. This draft is 
> only for those that are interested in the content. If you are not interested 
> please disregard. I confirmed the model was trained on 9front resources, 
> including git history.
> 
> https://link.storjshare.io/s/juh72ktckqt2mpdaeebljo7mve2q/revitalizing-project/RevitalizingPlan9.pdf

This document is full of lies, and I don't think you trained a model at
all.  I'd wager you only applied an inference step, and from an
inexpensive model at that.  Your claim that you "confirmed the model was
trained" just tells me you know as little about large-language models as
you do about Plan 9:  you're the wrong person for this job.

This is not a meaningful contribution to the literature.  Nobody will be
helped by this.  

Samuel Reader was an American hero who fought with John Brown.  If you
share a name with such a famous writer, maybe you can take inspiration
from him and anctually try to write something.

khm

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M524e78627dc57f60f74081ab
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[plan6]

I guess that Vic Thacker and Samuel Reader are the very same person. And Ori, I 
was trying to be sarcastic when I called the linkedin paper "interesting". :)
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M29f298f8c9c2e6a54cc3e4a7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

We call it as we see them, it is very clear that Vic is using an LLM. Based on 
his responses to being called out for it
along with the way its been written. The article features AI art as well.
Take one walk down Vic's story postings on linkedin. All AI art, all written in 
the same AI tone.

Assume our accusations are wrong and this is actual human generated writing, 
the misinformation is still insulting and deserves to be called out.

On 5/17/24 09:46, Michael Kerpan wrote:
> Could people please stop accusing people of being fake just because they 
> write verbosly? That kind of behavior is part and parcel of the incredibly 
> rude and mean-spirited behavior mentioned in that LinkedIn thing.
> 
> Mike
> 
> On Fri, May 17, 2024, 10:21 AM hiro <23h...@gmail.com 
> > wrote:
> 
> or rename that linkedin garbage to "using AI to disincentivize open
> discussion communities"
> 
> On Fri, May 17, 2024 at 4:16 PM Jacob Moody  > wrote:
> >
> > 
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/
>  
> 
> >
> > This linked-in article is frankly disgusting, I suggest you take this 
> incorrect garbage down.
> >
> >
> > On 5/17/24 07:43, Samuel Reader via 9fans wrote:
> > > It is only a first draft, and it is not a finished product. I'll 
> correct the mistakes found.
> > >
> > > Thank you for the kind feedback.
> > >
> > >
> > >
> > >
> > > Sent with Proton Mail secure email.
> > >
> > > On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net 
> > wrote:
> > >
> > >> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net 
>  wrote:
> > >>
> > >>> an other interesting reading :
> > >>> 
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
>  
> 
> > >>
> > >>
> > >> I'm appalled and frankly furious about this article. It's blatant
> > >> slander which can affect me in my professional career. I'm a phD
> > >> candidate and my work is based on Plan 9 and developed on 9front; I
> > >> was going to present it at iwp9 but could not once the venue was
> > >> changed as it rendered it incompatible with my time table.
> > >>
> > >> The article lacks references to many of its claims, and the remaining
> > >> ones directly contradict its points. The Register article is even
> > >> linked incorrectly. A superficial reader would not bother to try to
> > >> follow the links or find the article. For me this is clearly
> > >> malicious attention-seeking.
> > >>
> > >> Regarding the pdf posted earlier[1], almost all of it is factually
> > >> incorrect. As an example, there are no drivers for modern nvidia or
> > >> amd chips or bluetooth. Many of the "system calls" listed in the pdf
> > >> are not system calls (proccreate) or simply don't exit (vlongtime),
> > >> and so on. In addition, it is trivial to recreate the same content
> > >> with a query like the following: `Generate a detailed book-style
> > >> document called "Revitalizing Plan 9: integrating modern enhacements
> > >> into 9legacy" detailing all improvements introduced in 9front 
> compared
> > >> to 9legacy'. See for yourself in an excerpt below my email.
> > >>
> > >> I don't understand what the goal here is. All this post and pdf
> > >> accomplish is spreading misinformation, promoting cancel culture,
> > >> fostering community division and discouraging collaboration with
> > >> 9front and even 9legacy, directly contradicting both Vic's claims and
> > >> that of those who have sided with him in the thread. At this point,
> > >> use of chatgpt in this thread is blatant and harmful. Please stop.
> > >>
> > >> Thanks,
> > >> qwx
> > >>
> > >> [1] 
> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
>  
> 
> > >> ---
> > >>
> > >> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
> > >> Introduction
> > >> Plan 9 from Bell Labs has long been recognized for its innovative 
> approach to distributed computing. However, as hardware and software 
> technologies advanced, the need for a more modernized version of Plan 9 
> became apparent. This need led to the development of 9front, a fork of Plan 9 
> that incorporates 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Dave Eckhardt]

> I confirmed the model was trained on 9front resources, including
> git history.

I looked quickly at the document but didn't see a statement that
it was machine-generated text or what the inputs were.  Though
"LLM ethics" are far from settled, I think at this stage it would
be good to state clearly and prominently, up front, that this is
machine-generated text, and to somewhere include information about
which LLM was used, trained on what, and with what sort of prompt.

As a separate matter, though I am not presently a 9front user, as
I quickly skimmed the document it didn't seem clearly accurate.
Is accuracy a goal?  If so, how will it be determined whether or
not that goal has been achieved?

Dave Eckhardt

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me5cc575537394d7a0803f2c0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

Hit the enter key a bit early...
This is directed at Vic, if that is not clear already.
To everyone else who called me out for assuming malice on victor's part because 
he was "just trying to help", does this not
make my claim more obvious now? This likewise is including AI bullshit, and I 
suspect my claims about his other mails
being LLM trash are also correct too. There was no apology owed and none should 
have been given. This is about the
furthest thing from "helping" that there is.

To be direct, I have found the misinformation about 9front on this list to be 
at best highly incompetent and at
worst actively malicious to spread misinformation. Is this really what our 
resident "9front-haters" are going to rally behind?
Like I respect that some people don't like us, that's fine. I get that some 
people have some differences but AI generated misinformation
is downright insulting. The demands that 9front do something or change their 
behavior to match some noncontributor's opinion here is
frankly also insulting our time. I've generally held respect for the people 
here who have been around a lot longer, while I may disagree
I will read and think about what is said here. However is this is the type of 
behavior that is defended (and therefore encouraged) I am
not interested at all.

I'll be around on this list to argue against the misinformation campaigns, it 
is clear that if we were to go away this type of misinformation
would run rampant. I really expected better.

- Moody

On 5/17/24 09:14, Jacob Moody wrote:
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/
> 
> This linked-in article is frankly disgusting, I suggest you take this 
> incorrect garbage down.
> 
> 
> On 5/17/24 07:43, Samuel Reader via 9fans wrote:
>> It is only a first draft, and it is not a finished product. I'll correct the 
>> mistakes found. 
>>
>> Thank you for the kind feedback.
>>
>>
>>
>>
>> Sent with Proton Mail secure email.
>>
>> On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> wrote:
>>
>>> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote:
>>>
 an other interesting reading :
 https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
>>>
>>>
>>> I'm appalled and frankly furious about this article. It's blatant
>>> slander which can affect me in my professional career. I'm a phD
>>> candidate and my work is based on Plan 9 and developed on 9front; I
>>> was going to present it at iwp9 but could not once the venue was
>>> changed as it rendered it incompatible with my time table.
>>>
>>> The article lacks references to many of its claims, and the remaining
>>> ones directly contradict its points. The Register article is even
>>> linked incorrectly. A superficial reader would not bother to try to
>>> follow the links or find the article. For me this is clearly
>>> malicious attention-seeking.
>>>
>>> Regarding the pdf posted earlier[1], almost all of it is factually
>>> incorrect. As an example, there are no drivers for modern nvidia or
>>> amd chips or bluetooth. Many of the "system calls" listed in the pdf
>>> are not system calls (proccreate) or simply don't exit (vlongtime),
>>> and so on. In addition, it is trivial to recreate the same content
>>> with a query like the following: `Generate a detailed book-style
>>> document called "Revitalizing Plan 9: integrating modern enhacements
>>> into 9legacy" detailing all improvements introduced in 9front compared
>>> to 9legacy'. See for yourself in an excerpt below my email.
>>>
>>> I don't understand what the goal here is. All this post and pdf
>>> accomplish is spreading misinformation, promoting cancel culture,
>>> fostering community division and discouraging collaboration with
>>> 9front and even 9legacy, directly contradicting both Vic's claims and
>>> that of those who have sided with him in the thread. At this point,
>>> use of chatgpt in this thread is blatant and harmful. Please stop.
>>>
>>> Thanks,
>>> qwx
>>>
>>> [1] 
>>> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
>>> ---
>>>
>>> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
>>> Introduction
>>> Plan 9 from Bell Labs has long been recognized for its innovative approach 
>>> to distributed computing. However, as hardware and software technologies 
>>> advanced, the need for a more modernized version of Plan 9 became apparent. 
>>> This need led to the development of 9front, a fork of Plan 9 that 
>>> incorporates numerous enhancements and updates, surpassing 9legacy in 
>>> several key areas. This document details these improvements, offering a 
>>> comprehensive comparison of the advancements introduced in 9front over 
>>> 9legacy.
>>>
>>> Chapter 1: Graphics and Video Drivers
>>> Improved Graphics Hardware Support
>>> One of the most significant 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Michael Kerpan]

Could people please stop accusing people of being fake just because they
write verbosly? That kind of behavior is part and parcel of the incredibly
rude and mean-spirited behavior mentioned in that LinkedIn thing.

Mike

On Fri, May 17, 2024, 10:21 AM hiro <23h...@gmail.com> wrote:

> or rename that linkedin garbage to "using AI to disincentivize open
> discussion communities"
>
> On Fri, May 17, 2024 at 4:16 PM Jacob Moody  wrote:
> >
> >
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/
> >
> > This linked-in article is frankly disgusting, I suggest you take this
> incorrect garbage down.
> >
> >
> > On 5/17/24 07:43, Samuel Reader via 9fans wrote:
> > > It is only a first draft, and it is not a finished product. I'll
> correct the mistakes found.
> > >
> > > Thank you for the kind feedback.
> > >
> > >
> > >
> > >
> > > Sent with Proton Mail secure email.
> > >
> > > On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net>
> wrote:
> > >> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote:
> > >>
> > >>> an other interesting reading :
> > >>>
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
> > >>
> > >>
> > >> I'm appalled and frankly furious about this article. It's blatant
> > >> slander which can affect me in my professional career. I'm a phD
> > >> candidate and my work is based on Plan 9 and developed on 9front; I
> > >> was going to present it at iwp9 but could not once the venue was
> > >> changed as it rendered it incompatible with my time table.
> > >>
> > >> The article lacks references to many of its claims, and the remaining
> > >> ones directly contradict its points. The Register article is even
> > >> linked incorrectly. A superficial reader would not bother to try to
> > >> follow the links or find the article. For me this is clearly
> > >> malicious attention-seeking.
> > >>
> > >> Regarding the pdf posted earlier[1], almost all of it is factually
> > >> incorrect. As an example, there are no drivers for modern nvidia or
> > >> amd chips or bluetooth. Many of the "system calls" listed in the pdf
> > >> are not system calls (proccreate) or simply don't exit (vlongtime),
> > >> and so on. In addition, it is trivial to recreate the same content
> > >> with a query like the following: `Generate a detailed book-style
> > >> document called "Revitalizing Plan 9: integrating modern enhacements
> > >> into 9legacy" detailing all improvements introduced in 9front compared
> > >> to 9legacy'. See for yourself in an excerpt below my email.
> > >>
> > >> I don't understand what the goal here is. All this post and pdf
> > >> accomplish is spreading misinformation, promoting cancel culture,
> > >> fostering community division and discouraging collaboration with
> > >> 9front and even 9legacy, directly contradicting both Vic's claims and
> > >> that of those who have sided with him in the thread. At this point,
> > >> use of chatgpt in this thread is blatant and harmful. Please stop.
> > >>
> > >> Thanks,
> > >> qwx
> > >>
> > >> [1]
> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
> > >> ---
> > >>
> > >> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
> > >> Introduction
> > >> Plan 9 from Bell Labs has long been recognized for its innovative
> approach to distributed computing. However, as hardware and software
> technologies advanced, the need for a more modernized version of Plan 9
> became apparent. This need led to the development of 9front, a fork of Plan
> 9 that incorporates numerous enhancements and updates, surpassing 9legacy
> in several key areas. This document details these improvements, offering a
> comprehensive comparison of the advancements introduced in 9front over
> 9legacy.
> > >>
> > >> Chapter 1: Graphics and Video Drivers
> > >> Improved Graphics Hardware Support
> > >> One of the most significant areas of enhancement in 9front is its
> support for modern graphics hardware. This includes:
> > >>
> > >> Support for Newer GPUs: 9front integrates drivers for the latest GPU
> models, ensuring compatibility with modern graphics cards from
> manufacturers like NVIDIA and AMD.
> > >> Enhanced Frame Buffer Device: The frame buffer device driver has been
> optimized for better performance, providing smoother graphics rendering and
> faster display updates.
> > >> Broad Chipset Compatibility: 9front supports a wider range of
> graphics chipsets, allowing it to run on diverse hardware configurations
> with improved stability and performance.
> > >> Advanced Video Handling
> > >> 9front has made considerable strides in handling video output,
> particularly with high-resolution and multi-monitor setups.
> > >>
> > >> High-Resolution Display Support: Enhanced support for high-resolution
> displays, including 4K monitors, ensures crisp 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

it's hard to help if we don't see the query. why don't you put the
query into the document, or better just make it some text files in a
git repo so people can help you by sending patches.

On Fri, May 17, 2024 at 4:23 PM Samuel Reader via 9fans <9fans@9fans.net> wrote:
>
> The 2nd draft is out. I've made some corrections as mentioned by others, and 
> I have added those who have helped to the acknowledgements. This draft is 
> only for those that are interested in the content. If you are not interested 
> please disregard. I confirmed the model was trained on 9front resources, 
> including git history.
>
> https://link.storjshare.io/s/juh72ktckqt2mpdaeebljo7mve2q/revitalizing-project/RevitalizingPlan9.pdf
>
> I will not continue to post the URL and comment. If you like to help with 
> corrections please do. I'll continue to work on the document until it is as 
> accurate as possible. I can be reached at samuel.rea...@proton.me.
>
> Thank you.
>
> Sent with Proton Mail secure email.
>
> On Friday, May 17th, 2024 at 10:50 PM, Clout Tolstoy  
> wrote:
>
> It's very clear at this point Vic Has never read the 9front FAQ or perhaps 
> any other documentation provided by 9front.
>
> Some of the things they ask from the community seem I'll informed because of 
> that and other reasons (like asking for GPU drivers from the community for 
> Nvidia or AMD is out of context of what an open source community can provide)
>
> Another won't fix issue is that it seems that they're unsure if they can port 
> some 9front code for 9legacy because it might not survive a closed source 
> audit for resale.
>
> It doesn't seem they want to bring value to the project and just take control.
>
> Am I missing something?
>
> On Fri, May 17, 2024, 6:33 AM hiro <23h...@gmail.com> wrote:
>> 
>> Great that you're building AI prompts instead of operating systems.
>> More trollfactories for "cyber" "warfare" will mean that all our
>> trolls will be out of a job soon. Vic, what you post on linkedin
>> sounds mainly like a big "fuck you" towards 9front, not a fair answer
>> given the technical contributions brought here by others.
>> 
>> Again, please send patches, not propaganda.
>
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mf6bf122dfe8d84ea2c901aee
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Samuel Reader via 9fans]

The 2nd draft is out. I've made some corrections as mentioned by others, and I 
have added those who have helped to the acknowledgements. This draft is only 
for those that are interested in the content. If you are not interested please 
disregard. I confirmed the model was trained on 9front resources, including git 
history.

https://link.storjshare.io/s/juh72ktckqt2mpdaeebljo7mve2q/revitalizing-project/RevitalizingPlan9.pdf

I will not continue to post the URL and comment. If you like to help with 
corrections please do. I'll continue to work on the document until it is as 
accurate as possible. I can be reached at samuel.rea...@proton.me.

Thank you.

Sent with [Proton Mail](https://proton.me/) secure email.

On Friday, May 17th, 2024 at 10:50 PM, Clout Tolstoy  
wrote:

> It's very clear at this point Vic Has never read the 9front FAQ or perhaps 
> any other documentation provided by 9front.
>
> Some of the things they ask from the community seem I'll informed because of 
> that and other reasons (like asking for GPU drivers from the community for 
> Nvidia or AMD is out of context of what an open source community can provide)
>
> Another won't fix issue is that it seems that they're unsure if they can port 
> some 9front code for 9legacy because it might not survive a closed source 
> audit for resale.
>
> It doesn't seem they want to bring value to the project and just take control.
>
> Am I missing something?
>
> On Fri, May 17, 2024, 6:33 AM hiro <23h...@gmail.com> wrote:
>
>> Great that you're building AI prompts instead of operating systems.
>> More trollfactories for "cyber" "warfare" will mean that all our
>> trolls will be out of a job soon. Vic, what you post on linkedin
>> sounds mainly like a big "fuck you" towards 9front, not a fair answer
>> given the technical contributions brought here by others.
>> 
>> Again, please send patches, not propaganda.
>
> [9fans](https://9fans.topicbox.com/latest) / 9fans / see 
> [discussions](https://9fans.topicbox.com/groups/9fans) + 
> [participants](https://9fans.topicbox.com/groups/9fans/members) + [delivery 
> options](https://9fans.topicbox.com/groups/9fans/subscription) 
> [Permalink](https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me91e0ebfcfac416764fad981)
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M6fc7012e78a90b1230049d6a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

or rename that linkedin garbage to "using AI to disincentivize open
discussion communities"

On Fri, May 17, 2024 at 4:16 PM Jacob Moody  wrote:
>
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/
>
> This linked-in article is frankly disgusting, I suggest you take this 
> incorrect garbage down.
>
>
> On 5/17/24 07:43, Samuel Reader via 9fans wrote:
> > It is only a first draft, and it is not a finished product. I'll correct 
> > the mistakes found.
> >
> > Thank you for the kind feedback.
> >
> >
> >
> >
> > Sent with Proton Mail secure email.
> >
> > On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> wrote:
> >
> >> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote:
> >>
> >>> an other interesting reading :
> >>> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
> >>
> >>
> >> I'm appalled and frankly furious about this article. It's blatant
> >> slander which can affect me in my professional career. I'm a phD
> >> candidate and my work is based on Plan 9 and developed on 9front; I
> >> was going to present it at iwp9 but could not once the venue was
> >> changed as it rendered it incompatible with my time table.
> >>
> >> The article lacks references to many of its claims, and the remaining
> >> ones directly contradict its points. The Register article is even
> >> linked incorrectly. A superficial reader would not bother to try to
> >> follow the links or find the article. For me this is clearly
> >> malicious attention-seeking.
> >>
> >> Regarding the pdf posted earlier[1], almost all of it is factually
> >> incorrect. As an example, there are no drivers for modern nvidia or
> >> amd chips or bluetooth. Many of the "system calls" listed in the pdf
> >> are not system calls (proccreate) or simply don't exit (vlongtime),
> >> and so on. In addition, it is trivial to recreate the same content
> >> with a query like the following: `Generate a detailed book-style
> >> document called "Revitalizing Plan 9: integrating modern enhacements
> >> into 9legacy" detailing all improvements introduced in 9front compared
> >> to 9legacy'. See for yourself in an excerpt below my email.
> >>
> >> I don't understand what the goal here is. All this post and pdf
> >> accomplish is spreading misinformation, promoting cancel culture,
> >> fostering community division and discouraging collaboration with
> >> 9front and even 9legacy, directly contradicting both Vic's claims and
> >> that of those who have sided with him in the thread. At this point,
> >> use of chatgpt in this thread is blatant and harmful. Please stop.
> >>
> >> Thanks,
> >> qwx
> >>
> >> [1] 
> >> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
> >> ---
> >>
> >> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
> >> Introduction
> >> Plan 9 from Bell Labs has long been recognized for its innovative approach 
> >> to distributed computing. However, as hardware and software technologies 
> >> advanced, the need for a more modernized version of Plan 9 became 
> >> apparent. This need led to the development of 9front, a fork of Plan 9 
> >> that incorporates numerous enhancements and updates, surpassing 9legacy in 
> >> several key areas. This document details these improvements, offering a 
> >> comprehensive comparison of the advancements introduced in 9front over 
> >> 9legacy.
> >>
> >> Chapter 1: Graphics and Video Drivers
> >> Improved Graphics Hardware Support
> >> One of the most significant areas of enhancement in 9front is its support 
> >> for modern graphics hardware. This includes:
> >>
> >> Support for Newer GPUs: 9front integrates drivers for the latest GPU 
> >> models, ensuring compatibility with modern graphics cards from 
> >> manufacturers like NVIDIA and AMD.
> >> Enhanced Frame Buffer Device: The frame buffer device driver has been 
> >> optimized for better performance, providing smoother graphics rendering 
> >> and faster display updates.
> >> Broad Chipset Compatibility: 9front supports a wider range of graphics 
> >> chipsets, allowing it to run on diverse hardware configurations with 
> >> improved stability and performance.
> >> Advanced Video Handling
> >> 9front has made considerable strides in handling video output, 
> >> particularly with high-resolution and multi-monitor setups.
> >>
> >> High-Resolution Display Support: Enhanced support for high-resolution 
> >> displays, including 4K monitors, ensures crisp and clear visuals.
> >> Multi-Monitor Configurations: Improved multi-monitor support allows users 
> >> to extend their desktop across multiple screens seamlessly, enhancing 
> >> productivity and usability.
> >>
> >> Chapter 2: Networking
> >> [...]

--
9fans: 9fans
Permalink: 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/

This linked-in article is frankly disgusting, I suggest you take this incorrect 
garbage down.


On 5/17/24 07:43, Samuel Reader via 9fans wrote:
> It is only a first draft, and it is not a finished product. I'll correct the 
> mistakes found. 
> 
> Thank you for the kind feedback.
> 
> 
> 
> 
> Sent with Proton Mail secure email.
> 
> On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> wrote:
> 
>> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote:
>>
>>> an other interesting reading :
>>> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
>>
>>
>> I'm appalled and frankly furious about this article. It's blatant
>> slander which can affect me in my professional career. I'm a phD
>> candidate and my work is based on Plan 9 and developed on 9front; I
>> was going to present it at iwp9 but could not once the venue was
>> changed as it rendered it incompatible with my time table.
>>
>> The article lacks references to many of its claims, and the remaining
>> ones directly contradict its points. The Register article is even
>> linked incorrectly. A superficial reader would not bother to try to
>> follow the links or find the article. For me this is clearly
>> malicious attention-seeking.
>>
>> Regarding the pdf posted earlier[1], almost all of it is factually
>> incorrect. As an example, there are no drivers for modern nvidia or
>> amd chips or bluetooth. Many of the "system calls" listed in the pdf
>> are not system calls (proccreate) or simply don't exit (vlongtime),
>> and so on. In addition, it is trivial to recreate the same content
>> with a query like the following: `Generate a detailed book-style
>> document called "Revitalizing Plan 9: integrating modern enhacements
>> into 9legacy" detailing all improvements introduced in 9front compared
>> to 9legacy'. See for yourself in an excerpt below my email.
>>
>> I don't understand what the goal here is. All this post and pdf
>> accomplish is spreading misinformation, promoting cancel culture,
>> fostering community division and discouraging collaboration with
>> 9front and even 9legacy, directly contradicting both Vic's claims and
>> that of those who have sided with him in the thread. At this point,
>> use of chatgpt in this thread is blatant and harmful. Please stop.
>>
>> Thanks,
>> qwx
>>
>> [1] 
>> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
>> ---
>>
>> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
>> Introduction
>> Plan 9 from Bell Labs has long been recognized for its innovative approach 
>> to distributed computing. However, as hardware and software technologies 
>> advanced, the need for a more modernized version of Plan 9 became apparent. 
>> This need led to the development of 9front, a fork of Plan 9 that 
>> incorporates numerous enhancements and updates, surpassing 9legacy in 
>> several key areas. This document details these improvements, offering a 
>> comprehensive comparison of the advancements introduced in 9front over 
>> 9legacy.
>>
>> Chapter 1: Graphics and Video Drivers
>> Improved Graphics Hardware Support
>> One of the most significant areas of enhancement in 9front is its support 
>> for modern graphics hardware. This includes:
>>
>> Support for Newer GPUs: 9front integrates drivers for the latest GPU models, 
>> ensuring compatibility with modern graphics cards from manufacturers like 
>> NVIDIA and AMD.
>> Enhanced Frame Buffer Device: The frame buffer device driver has been 
>> optimized for better performance, providing smoother graphics rendering and 
>> faster display updates.
>> Broad Chipset Compatibility: 9front supports a wider range of graphics 
>> chipsets, allowing it to run on diverse hardware configurations with 
>> improved stability and performance.
>> Advanced Video Handling
>> 9front has made considerable strides in handling video output, particularly 
>> with high-resolution and multi-monitor setups.
>>
>> High-Resolution Display Support: Enhanced support for high-resolution 
>> displays, including 4K monitors, ensures crisp and clear visuals.
>> Multi-Monitor Configurations: Improved multi-monitor support allows users to 
>> extend their desktop across multiple screens seamlessly, enhancing 
>> productivity and usability.
>>
>> Chapter 2: Networking
>> [...]

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M7948c8f2a925c198cfda2fb0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Clout Tolstoy]

It's very clear at this point Vic Has never read the 9front FAQ or perhaps
any other documentation provided by 9front.

Some of the things they ask from the community seem I'll informed because
of that and other reasons (like asking for GPU drivers from the community
for Nvidia or AMD is out of context of what an open source community can
provide)

Another won't fix issue is that it seems that they're unsure if they can
port some 9front code for 9legacy because it might not survive a closed
source audit for resale.

It doesn't seem they want to bring value to the project and just take
control.

Am I missing something?

On Fri, May 17, 2024, 6:33 AM hiro <23h...@gmail.com> wrote:

> Great that you're building AI prompts instead of operating systems.
> More trollfactories for "cyber" "warfare" will mean that all our
> trolls will be out of a job soon. Vic, what you post on linkedin
> sounds mainly like a big "fuck you" towards 9front, not a fair answer
> given the technical contributions brought here by others.
> 
> Again, please send patches, not propaganda.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me91e0ebfcfac416764fad981
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

still you have not disclaimed anywhere that this is machine generated.
i expect a warning, bec. otherwise this low quality garbage is going
to be interpreted by future humans and AI alike as possibly factual,
which it clearly is not.
but i give you bonuspoint for making it in quotation marks.

On Fri, May 17, 2024 at 2:26 PM samuel.reader via 9fans <9fans@9fans.net> wrote:
>
> I've included 9front git history. Here is the results.
>
> "I reviewed the 9front Git repository to confirm details about the 
> differences between 9front and 9legacy. Here are some key points:
>
> Syscall Changes: As mentioned, 9front did not add new syscalls beyond the 
> 'nsec' syscall, which 9legacy had already included. This syscall was needed 
> to run Go binaries, although it was deprecated upon import.
>
> Kernel and Driver Enhancements: 9front has made numerous improvements to the 
> kernel and drivers. For example, they have added support for new hardware, 
> such as the i219-LM Ethernet device, and improved existing drivers, like the 
> virtio drivers for disk and Ethernet.
>
> Library Updates: There have been updates to various libraries, such as lib9p, 
> libsec, and libtags. These updates include bug fixes, performance 
> enhancements, and new features like support for additional audio formats in 
> libtags.
>
> Program Improvements: Many user programs have seen enhancements and bug 
> fixes. Notable examples include the acme editor, which received improvements 
> from Plan9port, and the git suite, which has been updated to handle modern 
> workflows more effectively. I reviewed the 9front Git repository to confirm 
> details about the differences between 9front and 9legacy. Here are some key 
> points:
>
> Syscall Changes: As mentioned, 9front did not add new syscalls beyond the 
> 'nsec' syscall, which 9legacy had already included. This syscall was needed 
> to run Go binaries, although it was deprecated upon import.
>
> Kernel and Driver Enhancements: 9front has made numerous improvements to the 
> kernel and drivers. For example, they have added support for new hardware, 
> such as the i219-LM Ethernet device, and improved existing drivers, like the 
> virtio drivers for disk and Ethernet.
>
> Library Updates: There have been updates to various libraries, such as lib9p, 
> libsec, and libtags. These updates include bug fixes, performance 
> enhancements, and new features like support for additional audio formats in 
> libtags
>
> Program Improvements: Many user programs have seen enhancements and bug 
> fixes. Notable examples include the acme editor, which received improvements 
> from Plan9port, and the git suite, which has been updated to handle modern 
> workflows more effectively."
>
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M28114ecf09cdbaf0eeb79306
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Steve Simon]

i got very suspicious at the mention of a procinfo syscall - unlikely in plan9, 
and i couldn't imagine a use for such a thing given we have /proc already.

-Steve



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M506b4d09d5f1ea68f7f1a8cd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ori]

I'm not sure it is interesting.

Quoth pl...@room3420.net:
> an other interesting reading :
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M5a800d099a877c4c827be898
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Samuel Reader via 9fans]

It is only a first draft, and it is not a finished product. I'll correct the 
mistakes found. 

Thank you for the kind feedback.




Sent with Proton Mail secure email.

On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> wrote:

> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote:
> 
> > an other interesting reading :
> > https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
> 
> 
> I'm appalled and frankly furious about this article. It's blatant
> slander which can affect me in my professional career. I'm a phD
> candidate and my work is based on Plan 9 and developed on 9front; I
> was going to present it at iwp9 but could not once the venue was
> changed as it rendered it incompatible with my time table.
> 
> The article lacks references to many of its claims, and the remaining
> ones directly contradict its points. The Register article is even
> linked incorrectly. A superficial reader would not bother to try to
> follow the links or find the article. For me this is clearly
> malicious attention-seeking.
> 
> Regarding the pdf posted earlier[1], almost all of it is factually
> incorrect. As an example, there are no drivers for modern nvidia or
> amd chips or bluetooth. Many of the "system calls" listed in the pdf
> are not system calls (proccreate) or simply don't exit (vlongtime),
> and so on. In addition, it is trivial to recreate the same content
> with a query like the following: `Generate a detailed book-style
> document called "Revitalizing Plan 9: integrating modern enhacements
> into 9legacy" detailing all improvements introduced in 9front compared
> to 9legacy'. See for yourself in an excerpt below my email.
> 
> I don't understand what the goal here is. All this post and pdf
> accomplish is spreading misinformation, promoting cancel culture,
> fostering community division and discouraging collaboration with
> 9front and even 9legacy, directly contradicting both Vic's claims and
> that of those who have sided with him in the thread. At this point,
> use of chatgpt in this thread is blatant and harmful. Please stop.
> 
> Thanks,
> qwx
> 
> [1] 
> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
> ---
> 
> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
> Introduction
> Plan 9 from Bell Labs has long been recognized for its innovative approach to 
> distributed computing. However, as hardware and software technologies 
> advanced, the need for a more modernized version of Plan 9 became apparent. 
> This need led to the development of 9front, a fork of Plan 9 that 
> incorporates numerous enhancements and updates, surpassing 9legacy in several 
> key areas. This document details these improvements, offering a comprehensive 
> comparison of the advancements introduced in 9front over 9legacy.
> 
> Chapter 1: Graphics and Video Drivers
> Improved Graphics Hardware Support
> One of the most significant areas of enhancement in 9front is its support for 
> modern graphics hardware. This includes:
> 
> Support for Newer GPUs: 9front integrates drivers for the latest GPU models, 
> ensuring compatibility with modern graphics cards from manufacturers like 
> NVIDIA and AMD.
> Enhanced Frame Buffer Device: The frame buffer device driver has been 
> optimized for better performance, providing smoother graphics rendering and 
> faster display updates.
> Broad Chipset Compatibility: 9front supports a wider range of graphics 
> chipsets, allowing it to run on diverse hardware configurations with improved 
> stability and performance.
> Advanced Video Handling
> 9front has made considerable strides in handling video output, particularly 
> with high-resolution and multi-monitor setups.
> 
> High-Resolution Display Support: Enhanced support for high-resolution 
> displays, including 4K monitors, ensures crisp and clear visuals.
> Multi-Monitor Configurations: Improved multi-monitor support allows users to 
> extend their desktop across multiple screens seamlessly, enhancing 
> productivity and usability.
> 
> Chapter 2: Networking
> [...]

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mb2f857e131344e3b02d181db
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[qwx via 9fans]

On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote:
> an other interesting reading :
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card

I'm appalled and frankly furious about this article.  It's blatant
slander which can affect me in my professional career.  I'm a phD
candidate and my work is based on Plan 9 and developed on 9front; I
was going to present it at iwp9 but could not once the venue was
changed as it rendered it incompatible with my time table.

The article lacks references to many of its claims, and the remaining
ones directly contradict its points.  The Register article is even
linked incorrectly.  A superficial reader would not bother to try to
follow the links or find the article.  For me this is clearly
malicious attention-seeking.

Regarding the pdf posted earlier[1], almost all of it is factually
incorrect.  As an example, there are no drivers for modern nvidia or
amd chips or bluetooth.  Many of the "system calls" listed in the pdf
are not system calls (proccreate) or simply don't exit (vlongtime),
and so on.  In addition, it is trivial to recreate the same content
with a query like the following: `Generate a detailed book-style
document called "Revitalizing Plan 9: integrating modern enhacements
into 9legacy" detailing all improvements introduced in 9front compared
to 9legacy'.  See for yourself in an excerpt below my email.

I don't understand what the goal here is.  All this post and pdf
accomplish is spreading misinformation, promoting cancel culture,
fostering community division and discouraging collaboration with
9front and even 9legacy, directly contradicting both Vic's claims and
that of those who have sided with him in the thread.  At this point,
use of chatgpt in this thread is blatant and harmful.  Please stop.

Thanks,
qwx

[1] 
https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
---

Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
Introduction
Plan 9 from Bell Labs has long been recognized for its innovative approach to 
distributed computing. However, as hardware and software technologies advanced, 
the need for a more modernized version of Plan 9 became apparent. This need led 
to the development of 9front, a fork of Plan 9 that incorporates numerous 
enhancements and updates, surpassing 9legacy in several key areas. This 
document details these improvements, offering a comprehensive comparison of the 
advancements introduced in 9front over 9legacy.

Chapter 1: Graphics and Video Drivers
Improved Graphics Hardware Support
One of the most significant areas of enhancement in 9front is its support for 
modern graphics hardware. This includes:

Support for Newer GPUs: 9front integrates drivers for the latest GPU models, 
ensuring compatibility with modern graphics cards from manufacturers like 
NVIDIA and AMD.
Enhanced Frame Buffer Device: The frame buffer device driver has been optimized 
for better performance, providing smoother graphics rendering and faster 
display updates.
Broad Chipset Compatibility: 9front supports a wider range of graphics 
chipsets, allowing it to run on diverse hardware configurations with improved 
stability and performance.
Advanced Video Handling
9front has made considerable strides in handling video output, particularly 
with high-resolution and multi-monitor setups.

High-Resolution Display Support: Enhanced support for high-resolution displays, 
including 4K monitors, ensures crisp and clear visuals.
Multi-Monitor Configurations: Improved multi-monitor support allows users to 
extend their desktop across multiple screens seamlessly, enhancing productivity 
and usability.

Chapter 2: Networking
[...]

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M680864af80eddaf3fa87c1bf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[samuel.reader via 9fans]

I've included 9front git history. Here is the results. 

"I reviewed the 9front Git repository to confirm details about the differences 
between 9front and 9legacy. Here are some key points:
 1. *Syscall Changes*: As mentioned, 9front did not add new syscalls beyond the 
'nsec' syscall, which 9legacy had already included. This syscall was needed to 
run Go binaries, although it was deprecated upon import.


 2. *Kernel and Driver Enhancements*: 9front has made numerous improvements to 
the kernel and drivers. For example, they have added support for new hardware, 
such as the i219-LM Ethernet device, and improved existing drivers, like the 
virtio drivers for disk and Ethernet. 


 3. *Library Updates*: There have been updates to various libraries, such as 
lib9p, libsec, and libtags. These updates include bug fixes, performance 
enhancements, and new features like support for additional audio formats in 
libtags.


 4. *Program Improvements*: Many user programs have seen enhancements and bug 
fixes. Notable examples include the acme editor, which received improvements 
from Plan9port, and the git suite, which has been updated to handle modern 
workflows more effectively. I reviewed the 9front Git repository to confirm 
details about the differences between 9front and 9legacy. Here are some key 
points:


 5. *Syscall Changes*: As mentioned, 9front did not add new syscalls beyond the 
'nsec' syscall, which 9legacy had already included. This syscall was needed to 
run Go binaries, although it was deprecated upon import.


 6. *Kernel and Driver Enhancements*: 9front has made numerous improvements to 
the kernel and drivers. For example, they have added support for new hardware, 
such as the i219-LM Ethernet device, and improved existing drivers, like the 
virtio drivers for disk and Ethernet.


 7. *Library Updates*: There have been updates to various libraries, such as 
lib9p, libsec, and libtags. These updates include bug fixes, performance 
enhancements, and new features like support for additional audio formats in 
libtags


 8. *Program Improvements*: Many user programs have seen enhancements and bug 
fixes. Notable examples include the acme editor, which received improvements 
from Plan9port, and the git suite, which has been updated to handle modern 
workflows more effectively."



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Md2f5a6f7ba20e50e4320a235
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

Great that you're building AI prompts instead of operating systems.
More trollfactories for "cyber" "warfare" will mean that all our
trolls will be out of a job soon. Vic, what you post on linkedin
sounds mainly like a big "fuck you" towards 9front, not a fair answer
given the technical contributions brought here by others.

Again, please send patches, not propaganda.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mcd639c005b0a78ca539ecbd1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Matt Wilbur]

On Mon, May 13, 2024 at 3:20 PM adventures in9 
wrote:

> Suggesting ways to try out a Plan9 system is not a hypothetical for
> me.  I put myself out there doing videos demonstrating Plan9 systems,
> and so I get questions all the time.


FWIW I have found your channel *extremely* helpful in learning how to play
with 9front and am very grateful for it.

Matt





>
> Everyone has access to amd64 machines.  The used market is flooded
> with retired quad core amd64 Dell and Lenovo office desktops.  Most
> experienced Linux users who want to try a Plan9 system can also
> navigate qemu.  9Front covers all these use cases.  The typical
> problems that arise are lack of drivers, which 9Legacy is even worse
> with.
>
> Besides the hardware issue, the biggest benefit from 9Front is that it
> has an active community all working on the same fork.  The most eye
> opening thing about this whole long exchange is that the old Plan9
> people are largely working alone on private forks.
>
> On Mon, May 13, 2024 at 10:02 AM Ori Bernstein  wrote:
> >
> > On Mon, 13 May 2024 11:56:20 -0400
> > "ibrahim via 9fans" <9fans@9fans.net> wrote:
> >
> > > I'm wondering why you don't adjust it so that 9front can also be run
> there.
> >
> > Because 9vx is a hacky dead end; it fundamentally
> > only runs (and can only run) on 32-bit x86. It
> > works because of a quirk of 32-bit x86 addressing.
> >
> > Linux distros are wanting to drop support for
> > running 32 bit binaries (Ubuntu tried in 2019,
> > others have tried on and off).
> >
> > Macs no longer ship x86 processors, and even the
> > ones that have x86 cpus dropped support for 32-bit
> > binaries 5 years ago.
> >
> > I have no idea what windows is up to.
> >
> > Basically, qemu/drawterm works better in more or
> > less every way.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mada7642df61168a6a618ddef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[plan6]

an other interesting reading :
https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Ma5744d064b6bfdd1e63ac9dd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

now an AI generated book? and you're blaming 9front of having invented
new syscalls? what? oh come on!

On Fri, May 17, 2024 at 12:07 PM samuel.reader via 9fans
<9fans@9fans.net> wrote:
>
> Someone asked about the differences between 9front and 9legacy. This first 
> draft provides a brief overview.
> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me1d258cbcd36ec0d632438e2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ori]

Quoth samuel.reader via 9fans <9fans@9fans.net>:
> Someone asked about the differences between 9front and 9legacy. This first 
> draft provides a brief overview.
> https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf

Unfortunately, it doesn't provide a correct overview.

For example, 9front added no syscalls beyond picking
up the 'nsec' system call that 9legacy had added.
We deprecated it on import, but it was needed to run
go binaries.

The rest of this seems similarly accurate.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M777c67b2191bf9d3c5c7a35c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[samuel.reader via 9fans]

Someone asked about the differences between 9front and 9legacy. This first 
draft provides a brief overview.
https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me50dc0bbdf1af1428124189a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> has an active community all working on the same fork.  The most eye
> opening thing about this whole long exchange is that the old Plan9
> people are largely working alone on private forks.

apart from the ones who moved to plan9port on mac os.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mac4ea9b7e2d8cf96e33ca20d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

On Mon, May 13, 2024 at 5:56 PM ibrahim via 9fans <9fans@9fans.net> wrote:
>
>
> On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote:
>
> 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.
>
>
> You should read more carefully what I replied to the new user. It had nothing 
> to do with licenses at all.  I drew a path which spares him the frustrations 
> during the time where he gets used to the system. And using 9vx is one way to 
> set one step after the other. I'm wondering why you don't adjust it so that 
> 9front can also be run there. As far as I can tell from once experimenting 
> the reason why 9front doesn't run are your extensions to the kernel 
> interface. 9vx is by far a better more plan9-ish way to virtualize under 
> linux. But thats your decision. The path I suggested is the simplest one at 
> least I think so. It takes less than 30 min to have a running plan9 
> installation without any problems arising from file servers without the 
> problems of networking or data exchange. If you really believe that the path 
> I suggested was a bad one or isn't simpler than directly using on of the 
> plan9 distros I would really be  surprised. This new guy has to learn rc, 
> acme, rio, about plan9.ini about mouse shortcuts in acme. And do you really 
> believe doing this directly on 9legacy or 9front is simpler than by using 9vx 
> ?
>
> If this guy reaches the 4.step he will find his own path to whatever fork he 
> pleases. So where exactly was my reply mindless ?
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

no

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mfd2a21c2adc4b2b4c023bb8b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[adventures in9]

Suggesting ways to try out a Plan9 system is not a hypothetical for
me.  I put myself out there doing videos demonstrating Plan9 systems,
and so I get questions all the time.

Everyone has access to amd64 machines.  The used market is flooded
with retired quad core amd64 Dell and Lenovo office desktops.  Most
experienced Linux users who want to try a Plan9 system can also
navigate qemu.  9Front covers all these use cases.  The typical
problems that arise are lack of drivers, which 9Legacy is even worse
with.

Besides the hardware issue, the biggest benefit from 9Front is that it
has an active community all working on the same fork.  The most eye
opening thing about this whole long exchange is that the old Plan9
people are largely working alone on private forks.

On Mon, May 13, 2024 at 10:02 AM Ori Bernstein  wrote:
>
> On Mon, 13 May 2024 11:56:20 -0400
> "ibrahim via 9fans" <9fans@9fans.net> wrote:
>
> > I'm wondering why you don't adjust it so that 9front can also be run there.
> 
> Because 9vx is a hacky dead end; it fundamentally
> only runs (and can only run) on 32-bit x86. It
> works because of a quirk of 32-bit x86 addressing.
> 
> Linux distros are wanting to drop support for
> running 32 bit binaries (Ubuntu tried in 2019,
> others have tried on and off).
> 
> Macs no longer ship x86 processors, and even the
> ones that have x86 cpus dropped support for 32-bit
> binaries 5 years ago.
> 
> I have no idea what windows is up to.
> 
> Basically, qemu/drawterm works better in more or
> less every way.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M97b5cd86db3eb04bac7ae05a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Ori Bernstein]

On Mon, 13 May 2024 11:56:20 -0400
"ibrahim via 9fans" <9fans@9fans.net> wrote:

> I'm wondering why you don't adjust it so that 9front can also be run there.

Because 9vx is a hacky dead end; it fundamentally
only runs (and can only run) on 32-bit x86. It
works because of a quirk of 32-bit x86 addressing.

Linux distros are wanting to drop support for
running 32 bit binaries (Ubuntu tried in 2019,
others have tried on and off).

Macs no longer ship x86 processors, and even the
ones that have x86 cpus dropped support for 32-bit
binaries 5 years ago.

I have no idea what windows is up to.

Basically, qemu/drawterm works better in more or
less every way.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M5d593a074dd95a16887f6a83
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

On 5/13/24 10:56, ibrahim via 9fans wrote:
> 
> On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote:
>> 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.
> 
> You should read more carefully what I replied to the new user. It had nothing 
> to do with licenses at all.

In your original email, you only mention:

> After you have collected enough experience I would stay with 9legacy and 
> ignore 9front.

The reasoning for this is never given. By your immediate followup and 
complaining about licensing and "being REAL plan9" I figured this was your 
reason.


I drew a path which spares him the frustrations during the time where he gets 
used to the system. And using 9vx is one way to set one step after the other. 
I'm wondering why you don't adjust it so that 9front can also be run there. As 
far as I can tell from once experimenting the reason why 9front doesn't run are 
your extensions to the kernel interface. 9vx is by far a better more plan9-ish
> way to virtualize under linux. But thats your decision. The path I suggested 
> is the simplest one at least I think so. It takes less than 30 min to have a 
> running plan9 installation without any problems arising from file servers 
> without the problems of networking or data exchange. If you really believe 
> that the path I suggested was a bad one or isn't simpler than directly using 
> on of the plan9 distros I would really be  surprised. This new guy has to 
> learn rc, acme, rio, about plan9.ini about
> mouse shortcuts in acme. And do you really believe doing this directly on 
> 9legacy or 9front is simpler than by using 9vx ?

Because I don't know why I should care about 9vx when every computer has 
hardware accelerated virtual machines. What is less frustrating I wonder? 
Telling someone to use
some random unmaintained x86 userspace emulation shim or using any existing 
virtual machine programs that are actively maintained, packaged for their 
operating system, and
much much more documented? We have spent a decent chunk of time making sure our 
code works under these modern virtual machines (and with acceleration),
including writing things like virtio drivers. A virtual machine combined with a 
local instance of drawterm to access it is how I suggest most new users get 
started.

> 
> If this guy reaches the 4.step he will find his own path to whatever fork he 
> pleases. So where exactly was my reply mindless ?

I honestly thought that you were suggesting against using 9front for the 
reasons I stated, if you were indeed basing everything off
of 9vx compatibility due to your opinion of it being a better choice than 
something like qemu or HyperV then I apologize for assuming
incorrectly.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M339bd65f5ceeb02ce28eedf7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote:
> 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.

You should read more carefully what I replied to the new user. It had nothing 
to do with licenses at all.  I drew a path which spares him the frustrations 
during the time where he gets used to the system. And using 9vx is one way to 
set one step after the other. I'm wondering why you don't adjust it so that 
9front can also be run there. As far as I can tell from once experimenting the 
reason why 9front doesn't run are your extensions to the kernel interface. 9vx 
is by far a better more plan9-ish way to virtualize under linux. But thats your 
decision. The path I suggested is the simplest one at least I think so. It 
takes less than 30 min to have a running plan9 installation without any 
problems arising from file servers without the problems of networking or data 
exchange. If you really believe that the path I suggested was a bad one or 
isn't simpler than directly using on of the plan9 distros I would really be  
surprised. This new guy has to learn rc, acme, rio, about plan9.ini about mouse 
shortcuts in acme. And do you really believe doing this directly on 9legacy or 
9front is simpler than by using 9vx ?

If this guy reaches the 4.step he will find his own path to whatever fork he 
pleases. So where exactly was my reply mindless ?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M71a22bd1f90c60a96961d626
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> As others have pointed out I think an "official" classification is of little 
> pragmatic benefit, but it would be nice
> to not have this tired conversation every email thread. Of course I have 
> reason to believe that even if the p9f were
> to recognize 9front as being a "Plan 9" it still would not be good enough.

i don't really care that much how things are named, as long as 9front
is recognized at all, for the value that it brings to the whole
community.

this would align very well with the official stated goals of the p9f:
"promote and support continued research into lightweight distributed
systems based on the ideas presented in the Plan 9 operating system
and related technologies".

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M7fd2aebde93ca02686793fc8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote:
> 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.

Of course I am interested in contributing. As an example i patched aux/vga 
while testing my fork on different hardware 9legacy couldn't switch to vga mode 
and I got blank screens on six different thin client models. Sometimes caused 
by not recognizing PCI bridges but many times by the way mode selection happens 
in aux/vga. This is a problem thats not only affecting my fork but many forks. 
I wrote a patch which tries to find the next possible 32 bpp mode available in 
the bios. While preselecting a fixed mode in plan9.ini led to blank screens 
with this simple change you get a mode that is supported an lies next to your 
choice in the ini file. This works until now for all devices I tested. Only a 
small example. 


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M252ef88ca11ebfce7119ae06
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

On 5/13/24 04:22, ibrahim via 9fans wrote:
>> I would make a big difference between what plan 9 is and what the licenses 
>> are. Software doesn't care about licenses. People do (and they should!).
>>
>> So what is plan 9 even? Can we compare it to UNIX™ or unix or posix? Who 
>> knows...
>>
>> I guess I could say a lot more about that topic, but I guess that's enough 
>> and you can puzzle everything else yourself.
> 
> plan9 is simply the final release made by bell labs and now owned by p9f. 
> Thats not my interpretation this is a fact. Everything beyond that point is a 
> fork based on plan9. 
> 
> Everyone is allowed to derive his/her work from this provided version of 
> plan9.
> 
> 9front is a fork, 9legacy is a fork and there were other forks. I have my own 
> fork. If tomorrow another one decides to fork plan9 than thats okay.
> 
> 9front isn't plan9. 9front is a fork based on plan9. Why is it that you can't 
> accept this fact. You aren't the owners of plan9 and you don't  even own the 
> trademark plan9.

By this line of logic the only thing stopping 9front from "being Plan 9" is 
recognition from the p9f no?
That could theoretically change any day, the p9f still continues to hold 
meetings where such things could be decided.

As others have pointed out I think an "official" classification is of little 
pragmatic benefit, but it would be nice
to not have this tired conversation every email thread. Of course I have reason 
to believe that even if the p9f were
to recognize 9front as being a "Plan 9" it still would not be good enough.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Md28a80fc0abf285efca61e42
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 4:32 PM, ori wrote:
> it's a sad system that can't even host its own sources.

If you are running a network for your work there is nothing sad about placing 
services on different OS'es. I'm using fossil-scm for about one decade had 
never problems it has nearly zero administration needs, an integratec ticket 
system, wiki documentation if you want to a web interface. When I decided to 
substitute CVS I choose fossil-scm and never regreted this desision. It has a 
BSD license and I'm grateful for this software. 

And using Linux as its host system is something you don't recognize. 
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1e5bff53873c27fb388e6645
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ori]

Quoth Jacob Moody :
> 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

Actually -- to that point: if someone is looking for organizational
work to do, that work could be finding people with private forks of
Plan 9, and then convincing them to make it public.

Following that up with cataloguing the differences between the
various forks would also be useful work.

Harvey has actually done a decent amount of this, putting the forks
into branches in the repo:

https://github.com/Harvey-OS/harvey


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mc49aaeab71da21ea885cbe31
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

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/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

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ori]

Quoth ibrahim via 9fans <9fans@9fans.net>:
> On Monday, 13 May 2024, at 4:01 PM, hiro wrote:
> > did you ever hear of the git
> implementation that ori has implemented?
> 
> It was placed on the latest 9legacy CD and I'm not needing/using it. I'm 
> using fossil-scm which replaced cvs for me. Fossil is running on a linux 
> machine in my network and is remotly accessible from plan9. But the choice of 
> a scm is a question of taste. 
> 

it's a sad system that can't even host its own sources.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mf6f39b8373cc63a544f217ef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 4:01 PM, hiro wrote:
> did you ever hear of the git
implementation that ori has implemented?

It was placed on the latest 9legacy CD and I'm not needing/using it. I'm using 
fossil-scm which replaced cvs for me. Fossil is running on a linux machine in 
my network and is remotly accessible from plan9. But the choice of a scm is a 
question of taste. 



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mdaa67e50520b81d782e013be
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

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

adding more compatibility layers doesn't generally makes sharing of
contributions easier.
the more forks diverge the harder it will be, no matter how many
layers you add. unless you actually *want* this complexity and measure
your achieved progress in terms of how much complexity you
generated...

i prefer a more pragmatic approach, as much as 9front has diverged
it's very easy to apply patches using the well known git principles
based on a common initial commit. did you ever hear of the git
implementation that ori has implemented? and, to contradict my earlier
point maybe you could even call that "our compatibility layer".

> 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.

we even respect and worship the coding styles of bell-labs. so there
would be no break, with or without compatibility layer, as long as you
didn't break with that one either.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M4eb82cf98fb7d990a3b189f6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 3:35 PM, G B wrote:
> Then you are still driving a Benz Patent-Motorwagen built in 1885, which is 
> regarded as the first practical modern automobile instead of driving 
> something newer like a Mercedes Benz S-Class or Lexus or Acura since these 
> newer automobiles are not automobiles from your perspective?

Is this some kind of shift working from 9front defenders ? If so perhaps you 
could exchange state information before you change shifts. If you use 9front 
that's fine with me do as you please I prefer the final plan9 release and I 
don't have to justify my decision. And I don't want my arguments. 
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mc3b0cd4ec4f8c03885597e31
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[G B via 9fans]

 "I respect your fork 9front but I won't and can't use it. 9front isn't plan9 
from my perspective."
Then you are still driving a Benz Patent-Motorwagen built in 1885, which is 
regarded as the first practical modern automobile instead of driving something 
newer like a Mercedes Benz S-Class or Lexus or Acura since these newer 
automobiles are not automobiles from your perspective?


On Monday, May 13, 2024 at 07:09:38 AM CDT, ibrahim via 9fans 
<9fans@9fans.net> wrote:  
 
 On Monday, 13 May 2024, at 1:26 PM, hiro wrote:

at this point all you're doing is speculation at best, it's verboseand spammy, 
and full of untruths. I do not welcome it, please stopgenerating noise.


You don't have to read nor to reply to my posts. The amount of noise you create 
exceeds mine by far. If you prefer this kind of conversation I don't have a 
problem with that too. 

I don't use 9front so spare me your lecturing this is not 9front's message 
board but 9fans.


9fans / 9fans / seediscussions +participants +delivery optionsPermalink  
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M22db0e0190f0d9ca12a76a03
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 1:26 PM, hiro wrote:
> at this point all you're doing is speculation at best, it's verbose
and spammy, and full of untruths. I do not welcome it, please stop
generating noise.

You don't have to read nor to reply to my posts. The amount of noise you create 
exceeds mine by far. If you prefer this kind of conversation I don't have a 
problem with that too. 

I don't use 9front so spare me your lecturing this is not 9front's message 
board but 9fans.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Maeacb3484e14957786de7f7f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

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

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

ibrahim you're further inventing misleading terms and definitions that
contribute nothing useful to any reader.
the "means of porting" is something that you have to go and invest the
work into, that's it. it's time, sweat, work. technology cannot help
you much with this, renaming the forks also changes nothing about the
amount of work this will take.

write the code, merge the code, that's the process now. anybody who
cares just sends patches that anybody can import into their favourite
fork to the mailinglist here, or they publish here some links to a git
or hg repository so that others can check the latest updates there.
that's my experience so far.

at this point all you're doing is speculation at best, it's verbose
and spammy, and full of untruths. I do not welcome it, please stop
generating noise.

On Mon, May 13, 2024 at 1:02 PM ibrahim via 9fans <9fans@9fans.net> wrote:
>
> On Monday, 13 May 2024, at 12:40 PM, sirjofri wrote:
>
> For me, it's "all plan9 systems", which includes belllabs plan9, 9legacy, 
> 9front and so on. That's one of the reasons I name 9front "a plan9 system", 
> not "the plan9 system", because there are a few different distributions/forks.
>
>
> The reason why I'm distinguishing between the plan9 and systems based on is 
> quite simple. The moment we agree on such a fact we have a way to exchange 
> code bug fixes participate in discussions. By this definition everything that 
> can directly compiled and run on the final release of plan9 is usable by all 
> forks cause each fork will have means of porting from this "mothership" and 
> if people from different forks discuss than we discuss about things part of 
> this mothership. Its okay that each fork has different views for things 
> outside of this definition but this would end the never ending discussions.
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9dc00fdf72b76118da9b1e28
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> I personally prefer to call my fork based on plan9. I didn't write or invent 
> plan9. Nor is my version a replacement or a continuation of plan9 it is fork 
> based on plan9.

can you please share it with us? i couldn't find a plan9 distribution
named "based on plan9" in my google assistant.

> As I said before I view 9front as one fork of plan9 and one I'm respecting. 
> You do a good job and people who use your fork surely benefit from your work.

respect includes not spreading lies and FUD about it without
understanding what you're talking about.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M8fb04a2e74b6854d67d0988e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Ori Bernstein]

On Mon, 13 May 2024 06:52:37 -0400, "ibrahim via 9fans" <9fans@9fans.net> wrote:

> 
> This was an example and I didn't find the original licenses from freetype in 
> the folder or in the code. Perhaps they got lost while porting this code to 
> 9front.

Indeed, it would be strange to find them, given that
we don't ship freetype.


-- 
Ori Bernstein

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Me2f7348f05a060950815e38e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> Note that 9front never claimed to be a continuation, but a fork. The people 
> who desperately cry for a continuation of plan 9 either claim 9front as a 
> continuation, or explicitly not.

yeah, I did, but that's just me. for me 9front is the perfect
continuation of plan9, both in code and in spirit.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5034b3b390be1c4258d946cd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

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?

On Mon, May 13, 2024 at 11:45 AM ibrahim via 9fans <9fans@9fans.net> wrote:
>
> On Monday, 13 May 2024, at 11:39 AM, hiro wrote:
>
> are you contributing the team? and paying the team?
>
> If you asked me. I don't use 9front or any of your contributions why should I 
> pay for or contribute to your team ?
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mf321ac8aca2f14bae5943865
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 12:40 PM, sirjofri wrote:
> For me, it's "all plan9 systems", which includes belllabs plan9, 9legacy, 
> 9front and so on. That's one of the reasons I name 9front "a plan9 system", 
> not "the plan9 system", because there are a few different distributions/forks.

The reason why I'm distinguishing between the plan9 and systems based on is 
quite simple. The moment we agree on such a fact we have a way to exchange code 
bug fixes participate in discussions. By this definition everything that can 
directly compiled and run on the final release of plan9 is usable by all forks 
cause each fork will have means of porting from this "mothership" and if people 
from different forks discuss than we discuss about things part of this 
mothership. Its okay that each fork has different views for things outside of 
this definition but this would end the never ending discussions.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1595216f59332b3651b45df6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

> if you notice missing copyright messages: please send a patch. i have
no clue what is required, but if you represent freetype or truetype or
can imagine their legal requirements, please help us out there. it
will be highly appreciated. btw, i hear about this for the first time.

This was an example and I didn't find the original licenses from freetype in 
the folder or in the code. Perhaps they got lost while porting this code to 
9front. I don't represent freetype and never claimed to 

> huh? which files exactly do you have doubts about?

Any files where I don't know who and how wrote it. Was is ported is it just a 
reimplementation. I didn't sit by your side when you wrote your contributions 
or sources. and most when not all files in your distro have no hints about the 
author or the copyrights. Or did I miss any special folder where you provide 
the information regarding authorship of your sources ?

> to me plan9 is indeed a toy. i wish it was otherwise. though it's a
> toy that is to me personally much more useful than most "professional"
> software.

Nothing wrong about using an operating system in this way. As long as I'm using 
my fork for my personal needs I call it toy tool the moment I have to deliver 
something to others I can't view it anymore as a toy. So as always you 
misinterpreted this sentence : I didn't name 9front a toy that would be rude 
9front is used by users and the moment you distribute it its a serious work 
which everyone me included has to respect. I didn't call 9front a toy but the 
purpose of its use. You can of course use plan9 for any tasks you can imagine 
and not the system is a toy.

I would be really surprised if a programmer mistook this statement of mine.

> That is a lie. We never ignored the license that plan9 was placed
> under - and it was the lucent public license, which is extremely
> permissive.
> We completely ignored the work done later (by others) around
> dual-licensing the GPL bec. we don't consider that an acceptably
> permissive license and we disagree with that philosophy.

I already replied to this and said that I didn't know you used the LPL version 
instead of GPL. I didn't know that you made that clear Ron defended your 
actions too so that's something I made a false assumption. Sorry for that.

> Do not contribute to 9front if you are not ok with the MIT license. To
> me this is why 9front is useful, but everybody has different legal
> interpretations, so i'm only sorry that you can not see it's worth.
If I contribute to plan9 than this will be made with an MIT license and all 
necessary information so that others can use the code if they see fit and this 
is also valid for 9front you can but thats your decision.

On Monday, 13 May 2024, at 12:05 PM, hiro wrote:
> I don't think p9f has ever provided anything apart from that
misleading website and some kind of money transfers to people that i
don't know.
They are the ones chosen by Nokia and make plan9 available with an MIT license 
thats more than enough. To be honest with the fact that they until now decided 
to just distribute the final release instead of contributing enhancements to 
the system itself. I'm sure the outcome of such enhancements and contributions 
would have started never ending discussions arguments from 9front. They 
preserve plan9 as of the final release and forks can take this as a basement 
with clean licenses. I'm grateful to their acting for what they accomplished 
and respect the fact that they didn't change anything till now. 

On Monday, 13 May 2024, at 12:05 PM, hiro wrote:
> 9legacy has both 9front and 4th edition code, as you already said. and
many other people contributed stuff to both 9legacy and 9front, and
other forks.
For my personal taste 9legacy has should restrict itself to bugpatches for the 
final release. Anything beyond that should be part of /n/sources. But thats my 
opinion.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Me6f3d0b36f444b6ea666d4c1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> namespaces. A few of the commands have changed, like rimport and rcpu
> , instead of import and cpu.

and just in case some readers might not know, since this topic came up:
the reason why it's not called import and cpu is explicitly for
backwards(4th ed./legacy/other forks) comaptibility.
personally i wouldn't even bothered, but as you can see the people
practically in charge of 9front (not me) care about the whole
community, even if this comes with costs like namechanges,
duplication.


>
> In my case, 9Legacy was the gateway drug.  I started with Miller's Pi
> images on 3 rpi 3B's, so I could run a file server, cpu server, and

correct me if i'm wrong, but IIRC 9legacy and miller's distributions
were distinct?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcf81b6e9ab8c9838aca2deec
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[sirjofri]

13.05.2024 12:12:49 ibrahim via 9fans <9fans@9fans.net>:

> On Monday, 13 May 2024, at 11:57 AM, sirjofri wrote:
>> So, you could say, plan 9 from bell labs is the last released version, 4th 
>> edition. The others (9legacy, 9front, ...) are also plan 9, just not plan 9 
>> from bell labs.
>
> I personally prefer to call my fork based on plan9. I didn't write or invent 
> plan9. Nor is my version a replacement or a continuation of plan9 it is fork 
> based on plan9.

I guess that's the difference in nomenclature. For me, a plan9 system is a 
system in the spirit of plan 9 from bell labs, using the concepts described in 
the papers and implemented in the bellabs sources. Similar to unix, which 
includes all the unices.

For you, plan9 is explicitly plan 9 from bell labs.

I don't think any of those definitions is "wrong" because there's no official 
definition. But I believe that we have to talk about the different systems 
using words. If I think about grouping operating systems based on concepts, we 
have all the doses, all the windowses, all the unices, and then (based on your 
definition) "plan 9 and forks of plan 9".

For me, it's "all plan9 systems", which includes belllabs plan9, 9legacy, 
9front and so on. That's one of the reasons I name 9front "a plan9 system", not 
"the plan9 system", because there are a few different distributions/forks.

> On Monday, 13 May 2024, at 11:57 AM, sirjofri wrote:
>> And if people want just a continuation of the concepts (the concepts which 
>> are commonly understood as "plan 9"), 9front is also one of those 
>> continuations, same as 9legacy or any other fork that tries to live those 
>> concepts.
> As I said before I view 9front as one fork of plan9 and one I'm respecting. 
> You do a good job and people who use your fork surely benefit from your work.

I wish I contributed more. I once tried to get at least one mention per 9front 
release, but that didn't work out.

Again, I think it's just different wording we use for "plan9 (systems)".

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9096f4a332e1934a9993293d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

> I was trying to communicate that for the purposes of using hardware made this 
> millennia (as any "professional" would do), 9front clearly has better code 
> for doing so.
> I trust that the licensing in 9front has been handled correctly.

are you trying to imply 9front wouldn't have better code for using
hardware made in the last millenium? i wasted a lot of years consuming
bad linux advice about how to break my computer, that i could have
spent with higher quality plan 9 systems, if the 9front bootloader was
available back then. i like being able to boot from both master and
slave IDE ports for example.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mdffe5281f4566330f79d10e2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 11:57 AM, sirjofri wrote:
> So, you could say, plan 9 from bell labs is the last released version, 4th 
> edition. The others (9legacy, 9front, ...) are also plan 9, just not plan 9 
> from bell labs.

I personally prefer to call my fork based on plan9. I didn't write or invent 
plan9. Nor is my version a replacement or a continuation of plan9 it is fork 
based on plan9.

On Monday, 13 May 2024, at 11:57 AM, sirjofri wrote:
> And if people want just a continuation of the concepts (the concepts which 
> are commonly understood as "plan 9"), 9front is also one of those 
> continuations, same as 9legacy or any other fork that tries to live those 
> concepts.
As I said before I view 9front as one fork of plan9 and one I'm respecting. You 
do a good job and people who use your fork surely benefit from your work. 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9e9f2a281196eedb3a94429f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

On Mon, May 13, 2024 at 5:53 AM ibrahim via 9fans <9fans@9fans.net> wrote:

...

> The reasoning is simple : p9f owns the rights for the final release and Nokia 
> has made this release available under a MIT license. Every one who uses plan9 
> not only to toy around or his/her personal use but also as a system which 
> he/she distributes like I do can't afford risks with code integrated from 
> sources like 9front. There are some libraries taken from 9front derived from 
> other open source projects like freetype (truetype) where copyright notices 
> are absent and this isn't the only library where in code comments the sources 
> are named but the original copyright notices are absent.

if you notice missing copyright messages: please send a patch. i have
no clue what is required, but if you represent freetype or truetype or
can imagine their legal requirements, please help us out there. it
will be highly appreciated. btw, i hear about this for the first time.

> plan9 as represented by p9f has a clear license all parts which are not MIT 
> licensed are marked as such but code back ported from other forks like 9front 
> contain code where I have doubts if those are really under an MIT license

huh? which files exactly do you have doubts about?

> I respect your fork 9front but I won't and can't use it. 9front isn't plan9 
> from my perspective. Plan 9 is the final release with patches for the files 
> from sources I can be sure that those aren't taken from open source projects 
> by copy and paste. The moment I and others who use plan9 for distribution or 
> embed it on systems we have to be absolutely sure about the sources of the 
> code. I can trust Bell Labs, Nokia, p9f but I won't trust some guys who toy 
> around with their fork of plan9.

the department in bell labs/nokia that you like to trust here doesn't
exist any more. maybe you can contribute to 9front to make it more
trustable.

> The first thing I am doing after downloading an iso from 9 legacy is to 
> remove all files which were not part of the final plan9 release. The second 
> thing I have always to do is removing all patches from the iso which came 
> from sources I can't be sure if they really followed licensing rules. The 
> third thing I have to do before distributing my fork of plan9 is to remove 
> fonts ghostscript diff page and other parts of the system which would infect 
> the distribution media to make sure the created system is not depending on 
> viral licensed code.

I am glad that you have such important production systems running that
you have to consider even license legalities. i hope more companies
will make serious money (and be able to afford such other related
overheads as legal advice) using excellent software like plan9 in the
future.
to me plan9 is indeed a toy. i wish it was otherwise. though it's a
toy that is to me personally much more useful than most "professional"
software.

> My fork isn't the only one which gets distributed. I'm sure there exist 
> millions of devices with plan9 integrated without anyone noticing except for 
> those who look into the documentation where the MIT licensed copyright is 
> placed.

how is your fork called? where can i find it? where can i find hints
to what these millions of devices might be? i would love to have a
commercial plan9 device.

> If people from forks like 9front are talking about numbers of their users I 
> always have to laugh. My fork is right now used by about 500 people per 
> semester more users. And be assured this is an unimportant number.

This is great for the whole community. I hope we can find out more. I
don't see it as competition at all, and please relax yourself, too! :)
Thank you for making it possible for so many people to learn from Plan 9.

> Not a single developer who uses plan9 for distributed systems, commercial 
> products will dare to use a system like 9front as the sources. The reason is 
> quite simple :
>
> You ignore copyrights as you please and distributed 9front under an MIT 
> license long before Nokia as the owner of it decided to do so. You did that 
> at a time when plan9 was placed under GPL.

That is a lie. We never ignored the license that plan9 was placed
under - and it was the lucent public license, which is extremely
permissive.
We completely ignored the work done later (by others) around
dual-licensing the GPL bec. we don't consider that an acceptably
permissive license and we disagree with that philosophy.

> 9front is a fork your fork I respect your work. But all your commits and 
> enhancements are absolutly useless for people who intend or use plan9 not 
> only  to play around with this system but make professional use of it. The 
> first thing such people have to check is the way you handle licenses.

Do not contribute to 9front if you are not ok with the MIT license. To
me this is why 9front is useful, but everybody has different legal
interpretations, so i'm only sorry that you can not see it's worth.

> Therefore 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[sirjofri]

So, with that definition, the system described in the paper "Plan 9 from bell 
labs" is not plan9, because it describes any system that uses the same concepts?

So, plan9 is like UNIX™ and there's no such thing as a concept about plan 9?

Note that 9front never claimed to be a continuation, but a fork. The people who 
desperately cry for a continuation of plan 9 either claim 9front as a 
continuation, or explicitly not.

People who want a continuation of plan 9 missed the train a long time ago. 
There won't be an official continuation of plan 9, and that's a fact, because 
p9f won't do it.

It's not the devs who claim a continuation of plan9, it's the people asking for 
it.

And if people want just a continuation of the concepts (the concepts which are 
commonly understood as "plan 9"), 9front is also one of those continuations, 
same as 9legacy or any other fork that tries to live those concepts.

So, you could say, plan 9 from bell labs is the last released version, 4th 
edition. The others (9legacy, 9front, ...) are also plan 9, just not plan 9 
from bell labs.

Similar to how UNIX™ is a unix, as is any linux system, bsd and mac.

13.05.2024 11:23:16 ibrahim via 9fans <9fans@9fans.net>:

>> I would make a big difference between what plan 9 is and what the licenses 
>> are. Software doesn't care about licenses. People do (and they should!).
>> 
>> So what is plan 9 even? Can we compare it to UNIX™ or unix or posix? Who 
>> knows...
>> 
>> I guess I could say a lot more about that topic, but I guess that's enough 
>> and you can puzzle everything else yourself.
> 
> plan9 is simply the final release made by bell labs and now owned by p9f. 
> Thats not my interpretation this is a fact. Everything beyond that point is a 
> fork based on plan9. 
> 
> Everyone is allowed to derive his/her work from this provided version of 
> plan9.
> 
> 9front is a fork, 9legacy is a fork and there were other forks. I have my own 
> fork. If tomorrow another one decides to fork plan9 than thats okay.
> 
> 9front isn't plan9. 9front is a fork based on plan9. Why is it that you can't 
> accept this fact. You aren't the owners of plan9 and you don't  even own the 
> trademark plan9.
> 
> Your fork is called 9front and its absolutely okay to fork from code with a 
> license that allows this.
> 
> Your fork based on plan9 is extremely close to the original. But that doesn't 
> mean you are the continuation of plan9.
> 
> The only thing we can agree on as fork developers is what is officially 
> called plan9 as a basement for exchange of code ideas aso. Code that can be 
> compiled and executed on the official release is one that can be exchanged.
> 
> There is only one group on this messaging board which has a problem with this 
> definition of plan9 thats 9front. You insist on being seen as the 
> continuation of plan9 but you aren't. You could have become this by buying 
> plan9 from nokia and the trademark or nokia could have chosen you to hand it 
> over to you but they didn't. p9f owns plan9 and if they ever decide to hand 
> it over to you than you become officially the owner and continuation of plan9 
> but this won't change the fact that meanwhile others have forked from plan9 
> and call themselves fork xyz based on plan9 and you to respect this.
> 
> Why is it so difficult for folks of 9front to accept that they are providing 
> a fork based on plan9.
> 
>> [1] (I would be very careful with such bold words. I feel like 9front people 
>> have heard this phrase a lot and it's probably very thin ice for a few 
>> people.)
>> 
> 
> And so what ? Compared to the replies of some folks from 9front regarding 
> simple questions there is nothing bold about my statements. This is 9fans and 
> if you start the same discussions over and over again than you have to live 
> with answers like mine. Neither you nor I own plan9 while people outside 
> 9front have no problem with facts you have this problem. You can't just 
> accept the fact that 9front is a fork like many others. You may do a good job 
> for your users and many enjoy using 9front as stated many times here on this 
> board but but you do your job others do their job and you are in no position 
> to give directions to others. I respect your work continue with it but don't 
> act as if you are the ones who are in possession of plan9 or can dictate 
> directions you can't and I also can't. I'm fed up with the regularly disputes 
> you search with people who don't want to use your fork. I'm not using it and 
> nothing will change my mind.
> 
>> About another topic: you mentioned that plan 9 is in use for commercial 
>> products, and you explicitly mention german medical sensors. I've never 
>> heard about that and I'd like to learn more, as well as about other 
>> companies who actually use plan 9.
>> 
>> Everything I always hear in the industry is that plan 9 is outdated and 
>> nobody uses it and nobody wants to hear about it. I only know of a single 
>> company that uses 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vic . thacker]

On Mon, May 13, 2024, at 18:22, ibrahim wrote:
...
> plan9 is simply the final release made by bell labs and now owned by 
> p9f. Thats not my interpretation this is a fact. Everything beyond that 
> point is a fork based on plan9. 
>
> Everyone is allowed to derive his/her work from this provided version of 
> plan9.
>
> 9front is a fork, 9legacy is a fork and there were other forks. I have 
> my own fork. If tomorrow another one decides to fork plan9 than thats 
> okay. 

I think that is a constructive way to view it. 

...
> The only thing we can agree on as fork developers is what is officially 
> called plan9 as a basement for exchange of code ideas aso. Code that 
> can be compiled and executed on the official release is one that can be 
> exchanged. 

That is a good point.  However, the question becomes how can we 
contribute to the original source repository?  It would be nice to have the
baseline updated so that more forks can be created with fewer updates
needed to be relevant.

Vic

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M0bef10695cfd8b7a823b2ce4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 11:39 AM, hiro wrote:
> are you contributing the team? and paying the team?
If you asked me. I don't use 9front or any of your contributions why should I 
pay for or contribute to your team ? 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mfd203382b8fd745cca9f025b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[hiro]

are you contributing the team? and paying the team?

On Mon, May 13, 2024 at 2:22 AM  wrote:
>
> The complexity of communication in this medium often necessitates detailed 
> discussions.  You highlighted the need for additional personnel to manage the 
> workload (e.g. do the work).  From my perspective, this requires a 
> well-defined vision, clear objectives, and a prioritized list of deliverables 
> to align efforts effectively.  Currently, it seems the role of product 
> managers is collectively held, though it's unclear who exactly is 
> responsible.  Typically, a team of two or more individuals would focus on 
> these deliverables.  In past projects, I've seen the use of a project board 
> to keep everyone updated on tasks—an approach known as "information radiator" 
> in project management.  I'm open to other methods if you had something 
> different in mind that I may have overlooked.  If you are considering a 
> meritocracy, I would recommend caution.  Experience has shown that what we 
> truly need is increased collaboration and unity, rather than a system that 
> could potentially encourage competition and division.  I apologize if my 
> message is obtuse, I am trying to keep this message concise, I can expound 
> more for clarity.  I hope my explanation helps.
>
> Vic
>
>
> On Mon, May 13, 2024, at 03:36, o...@eigenstate.org wrote:
> > that's not what I said.
> >
> > Quoth vic.thac...@fastmail.fm:
> >> I agree that having a clear vision and charter is essential before forming 
> >> a team. Regarding building an inclusive Plan 9 community that encompasses 
> >> multiple groups, it's important to establish common goals and values that 
> >> resonate with all members. What are your thoughts on creating open 
> >> channels for dialogue and collaboration? How can we ensure that everyone 
> >> feels valued and heard? This approach could foster a more cooperative and 
> >> inclusive environment.
> >>
> >> Vic
> >>
> >>
> >> On Sun, May 12, 2024, at 16:19, pl...@room3420.net wrote:
> >> > "tl;dr: you need people doing the work before you can try
> >> > to organize them; the way to get people doing the work is
> >> >  to bootstrap it by doing work and showing value." [from Ori].
> >> >  or
> >> >  "Don't be the kid who can't play [whatever]ball but wants to teach
> >> > everybody and be the team coach, just because he read a book."

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1f94e4e212bbb9d19954d53a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

> I would make a big difference between what plan 9 is and what the licenses 
> are. Software doesn't care about licenses. People do (and they should!).
> 
> So what is plan 9 even? Can we compare it to UNIX™ or unix or posix? Who 
> knows...
> 
> I guess I could say a lot more about that topic, but I guess that's enough 
> and you can puzzle everything else yourself.

plan9 is simply the final release made by bell labs and now owned by p9f. Thats 
not my interpretation this is a fact. Everything beyond that point is a fork 
based on plan9. 

Everyone is allowed to derive his/her work from this provided version of plan9.

9front is a fork, 9legacy is a fork and there were other forks. I have my own 
fork. If tomorrow another one decides to fork plan9 than thats okay. 

9front isn't plan9. 9front is a fork based on plan9. Why is it that you can't 
accept this fact. You aren't the owners of plan9 and you don't  even own the 
trademark plan9. 

Your fork is called 9front and its absolutely okay to fork from code with a 
license that allows this. 

Your fork based on plan9 is extremely close to the original. But that doesn't 
mean you are the continuation of plan9. 

The only thing we can agree on as fork developers is what is officially called 
plan9 as a basement for exchange of code ideas aso. Code that can be compiled 
and executed on the official release is one that can be exchanged. 

There is only one group on this messaging board which has a problem with this 
definition of plan9 thats 9front. You insist on being seen as the continuation 
of plan9 but you aren't. You could have become this by buying plan9 from nokia 
and the trademark or nokia could have chosen you to hand it over to you but 
they didn't. p9f owns plan9 and if they ever decide to hand it over to you than 
you become officially the owner and continuation of plan9 but this won't change 
the fact that meanwhile others have forked from plan9 and call themselves fork 
xyz based on plan9 and you to respect this. 

Why is it so difficult for folks of 9front to accept that they are providing a 
fork based on plan9.

> [1] (I would be very careful with such bold words. I feel like 9front people 
> have heard this phrase a lot and it's probably very thin ice for a few 
> people.)
> 

And so what ? Compared to the replies of some folks from 9front regarding 
simple questions there is nothing bold about my statements. This is 9fans and 
if you start the same discussions over and over again than you have to live 
with answers like mine. Neither you nor I own plan9 while people outside 9front 
have no problem with facts you have this problem. You can't just accept the 
fact that 9front is a fork like many others. You may do a good job for your 
users and many enjoy using 9front as stated many times here on this board but 
but you do your job others do their job and you are in no position to give 
directions to others. I respect your work continue with it but don't act as if 
you are the ones who are in possession of plan9 or can dictate directions you 
can't and I also can't. I'm fed up with the regularly disputes you search with 
people who don't want to use your fork. I'm not using it and nothing will 
change my mind.

> About another topic: you mentioned that plan 9 is in use for commercial 
> products, and you explicitly mention german medical sensors. I've never heard 
> about that and I'd like to learn more, as well as about other companies who 
> actually use plan 9.
> 
> Everything I always hear in the industry is that plan 9 is outdated and 
> nobody uses it and nobody wants to hear about it. I only know of a single 
> company that uses it (coraid), plus a few little projects by taw that could 
> evolve into commercial products.

I am and have acted as an advisor for many of these projects. The license 
change made it attractive for such projects cause you can keep your code closed 
source. The only duty to fulfill is providing the terms of the MIT license. You 
don't have to make your technology open source like you would have to if you 
used Linux. 

Don't underestimate the potential. Another example for a tiny os which is wide 
spread is Xinu which no one would expect. Plan9 has advantages over other 
systems that makes it attractive. I can only talk about those projects I know 
but be assured there are millions of devices around which run plan9 without 
anyone noticing. 


Again for the x-th time : I don't have a problem with 9front. I don't use it 
but I respect your work. The only think I dislike is the never ending 
discussions about plan9 being dead and 9front being the only choice and the 
attitude in some replies to questions of people on this board in an harsh and 
aggressive way. The moment one asks about 9legacy or plan9 and one from 9front 
advices to use 9front without success many of 9front getting aggressive and 
thats not right.


--
9fans: 9fans
Permalink: 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[sirjofri]

Hey all,

Just about one topic mentioned by ibrahim:

You mentioned that 9front can't be plan 9 in your perspective because of this 
licensing and the "origin" of the licensing.

> 9front isn't plan9 from my perspective. Plan 9 is the final release with 
> patches for the files from sources I can be sure that those aren't taken from 
> open source projects by copy and paste.
[1]

I would make a big difference between what plan 9 is and what the licenses are. 
Software doesn't care about licenses. People do (and they should!).

So what is plan 9 even? Can we compare it to UNIX™ or unix or posix? Who 
knows...

I guess I could say a lot more about that topic, but I guess that's enough and 
you can puzzle everything else yourself.

[1] (I would be very careful with such bold words. I feel like 9front people 
have heard this phrase a lot and it's probably very thin ice for a few people.)

---

About another topic: you mentioned that plan 9 is in use for commercial 
products, and you explicitly mention german medical sensors. I've never heard 
about that and I'd like to learn more, as well as about other companies who 
actually use plan 9.

Everything I always hear in the industry is that plan 9 is outdated and nobody 
uses it and nobody wants to hear about it. I only know of a single company that 
uses it (coraid), plus a few little projects by taw that could evolve into 
commercial products.

I sometimes thought about building a list of companies that use plan 9 
technology, just so people can get involved with them, and now that I'm 
searching for a new job that's even more interesting for me personally. (Not 
sure if I want to do plan 9 as $dayjob, but I could see it as an option.) That 
topic should end up in a new thread however (or even a DM).

sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Md69516f3df7ddcfdffa75613
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

> I don't want to depend on anything. Your method is just adding other
> dependencies to ghostscript if you start with ps, and other
> dependencies, if not ghostscript, including C++ code that is inability
> to port on Plan9, if you use pdf.
> 

I don't have any dependences remaining you misinterpreted something.

In the first time I needed some way to handle pdf files I had to connect to a 
linux machine in my network where the conversion from pdf to ps was done by 
using command line tools. The result of this conversion were first jpeg files 
afterwards svg files for which I wrote a renderer in plan9. The second step was 
to write a converter pdftosvg which works for pdf files I had to handle. No C++ 
no postscript interpreter. If you have to handle pdf files with embedded 
postscript than I wish you good luck.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mb94a807ef23009e0c91d9042
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[adventures in9]

On Sun, May 12, 2024 at 7:17 PM clinton  wrote:
>
> If I were completely naive to actually  running plan9 but with many clues 
> about other operating systems and hardware, would it be better for me to 
> install 9legacy on some mildly obsolescent but still quite serviceable and 
> reliable hardware, or start with 9front on something more modern? Is the 
> learning curve the same for both varieties? Would it help getting to know 
> 9front if I spent a bit of time with her older sister 9legacy? Can 9legacy be 
> considered the gateway drug to 9front?
> I await the scorching flames for my great impudence of interjecting into a 
> vociferous discussion with such a pragmatic tangent!

Having done a variety of Plan9 and 9Front installs on various pieces
of hardware and VMs...

I would, and do, tell most people to just go with 9Front.  It does all
the same core Plan9 concepts.  It all speaks 9P and has per-process
namespaces. A few of the commands have changed, like rimport and rcpu
, instead of import and cpu.  It has a few new things, like auto
mounting usb thumb drives in /shr.  When you work your way up to
managing a grid, there are a lot of changes, but nothing that really
gets away from the core concepts.

I run 9Front on plenty of old hardware.  I boot it on mips based
router boards with only 64MB of ram.  I run it on very new but rather
meager and cheap hardware and have done videos demonstrating it.  I've
ran it on Virtualbox in Windows on a 10 year old laptop, and bhyve on
a FreeBSD file server with pci passthrough to the nic, both cases
running on a single core.

9Front does all the stuff classic Plan9 does as far as teaching one
the basic concepts of Plan9.  It also has the advantage of more
hardware drivers and an active community adding more drivers and
documentation.

I see a lot of arguments about 9Legacy having a more pristine license.
But nothing about it doing anything better than 9Front.  Or any
arguments that 9Front does anything in a very non-Plan9 way.

In my case, 9Legacy was the gateway drug.  I started with Miller's Pi
images on 3 rpi 3B's, so I could run a file server, cpu server, and
terminal.  But the difficulty moving from that to some retired Dell
office computers is why I jumped over to 9Front.  The 9Front usb
install image just works better on a wider variety of old and new
hardware.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M3a7329a3b7b10d8eefdd1453
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[tlaronde]

On Mon, May 13, 2024 at 03:27:16AM -0400, ibrahim via 9fans wrote:
> > For the ghostscript thing, and for the record (noting that, in this
> > area, I have put my code-money where my mouth is):
> > 
> > I too want to get rid of Ghostscript. The path adopted is the
> > TeX/METAFONT way with the following:
> > 
> > - A PostScript interpreter can be, functionnally, divided in two
> > parts: 1) a general purpose language allowing computation but aimed
> > for images and supposed, finally, to produce primitive graphics
> > directives (fixed results); 2) a rasterizer to produce a matricial
> > image;
> 
> Converting pdf and ps to svg and rendering svg is the simpler approach. 
> During the first time I used this method I just added a linux computer to my 
> network and made use of pdftocairo with svg export. The advantage of this 
> method is that the resulting container kept page information and also all 
> glyphs are embedded in the resulting svg file which than gets rendered by a 
> tiny svg renderer. 
> 
> Substituting ghostscript with a new interpreter wasn't worth the effort in my 
> case. By reading the pdf metadata you also can keep the outline and other 
> information. 

I don't want to depend on anything. Your method is just adding other
dependencies to ghostscript if you start with ps, and other
dependencies, if not ghostscript, including C++ code that is inability
to port on Plan9, if you use pdf.

There was a TeX engine called pdfTeX, that replaced DVI with PDF. The
end result was that they depended on an external PDF library that they
have to adapt and, soon, they simply drop the updates and froze the
version they used because they were unable to follow the
evolution of this external code they depended upon.

Furthermore, if you are very careful about licenses, the more you add
dependencies, the more you have to be careful. PDF doesn't protect for
some claim, some day, from a lawyers' gang, pretending that PDF files
contain the result of some infringement of some patent---it is
notorious that the crazy US system of patents have led some big
enterprises to have a huge patents portfolio, some patents being real
ones, and some being crap, but just in order to frighten opponents:
"don't try to play this game with me, or I will be able to demonstrate
that you are using a number of my patents, and I will sue you to
death."

Problem: what will become of these portfolios if the big enterprise is
declining and is bought by financial sharks?

Furthermore, having the obligation to add a Linux system to render a
man page is not exactly simplification. Is it? ;-)
-- 
Thierry Laronde 
 http://www.kergis.com/
http://kertex.kergis.com/
 http://nunc-et-hic.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M673079c862fdba46a4c15ae0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 7:33 AM, ron minnich wrote:
> So, Ibrahim,  I can not agree with your statement here. 
I missed that they combined LPL licensed code instead of combining GPL licensed 
one. Thanks for the insides and sorry for the late response. 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcd9e17b18ec5bfa7a0b4c527
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

> For the ghostscript thing, and for the record (noting that, in this
> area, I have put my code-money where my mouth is):
> 
> I too want to get rid of Ghostscript. The path adopted is the
> TeX/METAFONT way with the following:
> 
> - A PostScript interpreter can be, functionnally, divided in two
> parts: 1) a general purpose language allowing computation but aimed
> for images and supposed, finally, to produce primitive graphics
> directives (fixed results); 2) a rasterizer to produce a matricial
> image;

Converting pdf and ps to svg and rendering svg is the simpler approach. During 
the first time I used this method I just added a linux computer to my network 
and made use of pdftocairo with svg export. The advantage of this method is 
that the resulting container kept page information and also all glyphs are 
embedded in the resulting svg file which than gets rendered by a tiny svg 
renderer. 

Substituting ghostscript with a new interpreter wasn't worth the effort in my 
case. By reading the pdf metadata you also can keep the outline and other 
information. 


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Md9b6263712929d39588a677a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote:
> I was making fun of your bragging because you implicated more installs 
> equated to higher quality.
I never said that more installs equate higher quality and I never said that the 
quality of your code sucks or my code quality is better. 

On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote:
> I trust that the licensing in 9front has been handled correctly.
I have to make my decisions cause by distributing my fork I am the one who is 
liable. On Monday, 13 May 2024, at 

8:22 AM, Kurt H Maier wrote:
> Hope this helps,
Yes it does. As it seems you used code licensed with LPL and made changes while 
avoiding the use of GPL licensed code which would have caused problems.

On Monday, 13 May 2024, at 8:02 AM, Kurt H Maier wrote:
> One by one we're getting rid of the third-party software -- I
particularly look forward to the day we can finally ditch Ghostscript --
but in the meantime these accusations of license violations are
misinformed and have no basis in reality.

You don't have to ditch Ghostscript. You can provide this as a seperated 
download. The user of your system is free to download GPL'ed programs or code 
as he pleases. This won't infect other parts of the system which don't rely on 
the existence of such programs. 


On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote:
> I was trying to communicate that for the purposes of using hardware made this 
> millennia (as any "professional" would do), 9front clearly has better code 
> for doing so.
I trust that the licensing in 9front has been handled correctly.
I don't doubt that your fork runs on more systems out of the box compared to 
plan9 final edition. But with minor changes in the final edition of plan9 I 
also don't have problems to make my fork work on hardware made for this 
millennia. I tried your system on some thin clients and except for a few with 
bugs in the bios or in uefi and some issues with timer interrupts your system 
was also running. 

I respect your fork but I won't use it for distributed systems. 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mf4269410df19d9e1e7239526
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[tlaronde]

On Sun, May 12, 2024 at 11:01:59PM -0700, Kurt H Maier via 9fans wrote:
> [...] 
> One by one we're getting rid of the third-party software -- I
> particularly look forward to the day we can finally ditch Ghostscript --
> but in the meantime these accusations of license violations are
> misinformed and have no basis in reality.

For the ghostscript thing, and for the record (noting that, in this
area, I have put my code-money where my mouth is):

I too want to get rid of Ghostscript. The path adopted is the
TeX/METAFONT way with the following:

- A PostScript interpreter can be, functionnally, divided in two
parts: 1) a general purpose language allowing computation but aimed
for images and supposed, finally, to produce primitive graphics
directives (fixed results); 2) a rasterizer to produce a matricial
image;

- TeX is a general language, aimed at text formatting,
emitting primitive graphics directives. It's the 1) part of
PostScript;

- METAFONT is a graphical language and a black/white rasterizer;
meaning there is a already 2) with the rasterizing routines of
METAFONT.

John Hobby's MetaPost is the ability to have a graphical language,
much more easy to use than PostScript, but emiting basic PostScript
directives.

=> So there are already almost all the pieces there to obtain 1+2 at
least for obtaining the same result as *roff.

What has still to be done:

- TeX has been extended because LaTeX requires now primitives that are
not in vanilla TeX. The extended TeX engine has been written: it's
Prote, in kerTeX. Prote has to be extended to allow to use the newline
as a prevision macro character so that, indeed, roff can be, like
latex, simply a predigested set of macros with a TeX/Prote engine;

- DVI has to be extended to add a primitive, present in *roff and not
in it: spline;

- TeX/Prote has to be extended to accept UTF-8 (without, in the engine
proper, handling whatever local related thing: this has to be done at
the macro set level, or as font instructions) and to handle a font as a
directory of 256 glyphes chunks (this can be compatible with existing:
the font is searched first as a directory---extension---; if not
existing, as a file---present state, equivalent to the 0 chunk);

- A DVI interpreter has then to be written using the METAFONT
rasterizing routines to produce the end result.

One important part in the above, is that with this scheme, one has not
to take a position about roff vs. tex: underneath, there will be the
TeX/Prote engine, but interpreting whatever roff macros set is given.
One could perfectly continue to write troff-wise.

As for fonts, there are still the Hershey's digitalized ones, having
not only occidental glyphes, but oriental ones. Plus all the existing
METAFONT ones. One possible extension concerning fonts, in the DVI
rendering, would be an intermediate representation, \'a la Hershey: to
convert curved primitives to linestrings, without rasterization,
allowing a quite correct last time scaling with a very low resources
impact for final rendering.

All this, I plan to do some day. But I'm at the limit of thrashing at
the moment.
-- 
Thierry Laronde 
 http://www.kergis.com/
http://kertex.kergis.com/
 http://nunc-et-hic.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Ma1eb78088eb726ad7013891c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Kurt H Maier via 9fans]

On Mon, May 13, 2024 at 02:18:54AM -0400, ibrahim via 9fans wrote:
> You really should read the GPL. Your changes were included with GPL'ed code 
> even in the same file and not distributed as independent patches so the 
> modified work as a whole got infected by the GPL license.

This is explicitly allowed by the GPL as explained by the FSF.  [1] But
that's moot, since we never shipped a GPL upstream.  We went from LPL,
sat out the GPL, and switched to MIT directly.  See previous email for
revision history.

khm

1 - https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M791ca8b4f0060d0f07822405
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Kurt H Maier via 9fans]

On Mon, May 13, 2024 at 02:04:24AM -0400, ibrahim via 9fans wrote:
> 
> There are many companies who double license code. As the owners of such code 
> they are free to do this. Users can't relicense code as they please 
> especially not GPL licensed code.

At no point did we 'relicense' anything.  We have never been in control
of the license terms of Labs-provided code.  The code we write, we
licensed MIT.  We then released both as a mixture; this is explicitly
allowed under the GPL (the FSF calls MIT the "expat" license, see [1]
for their declaration that it is compatible) and also under Lucent
Public License Section 3 A.   We comply with LPL section 3 C by
providing complete revision history in a source control system; anyone
may inspect it to identify the originator of any of the code.

Hope this helps,
khm

1 - https://www.gnu.org/licenses/license-list.en.html#Expat

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M24a9625c1ca2e86426c517fa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

On 5/13/24 00:45, ibrahim via 9fans wrote:
> libttf was one example and because it made its way into 9legacy i inspected 
> it.
> 
>> Are you implying that a majority of users are using Plan9 in a commercial 
>> setting? That seems a bit absurd.
>> For personal use I think these license issues (if they do even exist) are of 
>> no concern. I think you are greatly
>> exaggerating the possible issue here for your average user.
>  
> I could tell you about more than two dozens of projects alone at german 
> universities where plan9 was used in medical sensor devices. Calling 
> something absurd which lies beyond your experience gives reason enough to not 
> name any of those projects.

You didn't read closely enough. I was calling your assumption that our new user 
was going to attempt to sell Plan 9 commercially absurd.
I didn't say anything about there not being any commercial appliances, just 
that your scenario is not common for the people here.

>> Again, I think in your situation of distributing hardware with plan 9 or 
>> whatever, then it makes sense to do whatever your lawyer says.
>> I think advising against using 9front for every user on these grounds though 
>> is misleading at best.
> 
> Its not the lawyer who is responsible to avoid copyright issues its the duty 
> of the developer. Not the lawyer gets sued but the one who distributes the 
> system.

A lawyer really should be the one who is legally interpreting the obligations 
of any licensing.

> 
> Everyone is free to use 9front. But I won't use 9front for a distributed 
> system because I don't have the legal certainty as with plan9. I know who 
> developed plan9 and I know that Nokia owned it before they relicensed it. But 
> I don't this trust in 9front code. And so I wouldn't advise others who make 
> use of plan9 in ways like I do to use 9front.
> 
>> Do you also remove the Lucida and printer fonts? These were released as part 
>> of the original source but have interesting claims as to the ability to 
>> redistribute them.
>> Do you also strip out the parts of ape that include ancient GNU utilities? 
>> Are you running your system without a diff and patch?
> 
> Of course I removed all fonts from the system. I have my own font library 
> with scaleable vector fonts based on caligraphy. As I stated before I removed 
> any GNU utilities ghostview postscript page and all tools which have clearly 
> GPL licenses are removed. Patch and diff are replaced with BSD licensed 
> versions taken from OpenBSD.
> 
> Those are the rules.
> 
>> And Java runs on a billion devices.
> 
> And I can't distribute Java, Linux, commercial operating systems because 
> those can't be distributed as you please their licenses don't allow 
> distribution as the MIT license does.

You missed the joke. I was making fun of your bragging because you implicated 
more installs equated to higher quality.

>> I'm quite curious as to your definition of "professional" in one where none 
>> of the work done by 9front would be seen as beneficial.
> 
> I can assure you I respect your fork and the state you reached. Professional 
> use as a distributed operating system needs legal certainty. If you include 
> code from sources and I use your fork than I am the one who is doomed not you 
> because you are no legal entity. I have to make sure that my distributions 
> has no legal issues. The way you answer to such licensing problems makes 
> clear you don't care about them and take the issue lightly.

I was trying to communicate that for the purposes of using hardware made this 
millennia (as any "professional" would do), 9front clearly has better code for 
doing so.
I trust that the licensing in 9front has been handled correctly.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M6f8de0e3da3e27ff3391a2ad
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

> You have apparently not read our licensing document at
> /lib/legal/NOTICE, which explicitly names the terms of the original Plan
> 9 code, and assigns the MIT license only to changes produced by 9front.
> 
> As the labs-provided code has been made available under different
> licenses, we have updated this to reflect the changes, from Lucent
> Public License, through the GPL relicense, and then the MIT license.
> At all times we've complied with the distribution requirements of all
> applicable licenses.
> 2. You may modify your copy or copies of the Program or any portion of it, 
> thus forming a work based on the Program, and copy and distribute such 
> modifications or work under the terms of Section 1 above, provided that you 
> also meet all of these conditions:
> 
>     a) You must cause the modified files to carry prominent notices stating 
> that you changed the files and the date of any change.
>     b) You must cause any work that you distribute or publish, that in whole 
> or in part contains or is derived from the Program or any part thereof, to be 
> licensed as a whole at no charge to all third parties under the terms of this 
> License.
>     c) If the modified program normally reads commands interactively when 
> run, you must cause it, when started running for such interactive use in the 
> most ordinary way, to print or display an announcement including an 
> appropriate copyright notice and a notice that there is no warranty (or else, 
> saying that you provide a warranty) and that users may redistribute the 
> program under these conditions, and telling the user how to view a copy of 
> this License. (Exception: if the Program itself is interactive but does not 
> normally print such an announcement, your work based on the Program is not 
> required to print an announcement.)
> 
> These requirements apply to the modified work as a whole. If identifiable 
> sections of that work are not derived from the Program, and can be reasonably 
> considered independent and separate works in themselves, then this License, 
> and its terms, do not apply to those sections when you distribute them as 
> separate works. But when you distribute the same sections as part of a whole 
> which is a work based on the Program, the distribution of the whole must be 
> on the terms of this License, whose permissions for other licensees extend to 
> the entire whole, and thus to each and every part regardless of who wrote it.

You really should read the GPL. Your changes were included with GPL'ed code 
even in the same file and not distributed as independent patches so the 
modified work as a whole got infected by the GPL license.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcbca2e6474097e0d12b334e9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Kurt H Maier via 9fans]

On Mon, May 13, 2024 at 01:54:27AM -0400, ibrahim via 9fans wrote:
> 
> Please correct me if I'm wrong.
> 


Happily.  Here's the original revision of /lib/legal/NOTICE: 
http://code.9front.org/hg/plan9front/file/944787349e93/lib/legal/NOTICE

> The Plan 9 software is provided under the terms of the
> Lucent Public License, Version 1.02, reproduced in the
> file /lib/legal/lpl, with the following notable exceptions:

a later revision, specifying the license for 9front-originated code, and
adding exceptions for Python and Mercurial:

http://code.9front.org/hg/plan9front/file/84ba3046886d/lib/legal/NOTICE
> Plan 9 from Bell Labs is provided under the terms of the Lucent Public 
> License,
> Version 1.02, reproduced in the file /lib/legal/lpl.
> 
> Any additions or changes (as recorded in Mercurial history) made by 9front 
> are provided
> under the terms of the MIT License, reproduced in the file /lib/legal/mit, 
> unless
> otherwise indicated.
>
> The following exceptions apply:

When the Labs released the code under GPL, it was still *also* available
under the Lucent Public License 1.02.  The software was, at that point,
dual-licensed under LPL and GPL.  We didn't see any benefit from
acknowledging this, since the previous license was still valid and
compatible with our needs.

Once the MIT-licensed release was made available, we rebased on that:

http://code.9front.org/hg/plan9front/file/87d8e72ffb5c/lib/legal/NOTICE
> Plan 9 from Bell Labs is provided under the terms of the MIT license,
> reproduced in the file /lib/legal/mit.
> 
> Any additions or changes (as recorded in Mercurial history) made by 9front
> are also provided under the same MIT License, unless otherwise
> indicated.

The only material change since then was moving from Mercurial to Git as
source control, at which time we deleted Python and Mercurial from the
tree, and removed the relevant clauses from /lib/legal/NOTICE.

Third-party software not mentioned in the NOTICE file, but covered by
non-MIT licenses, has always explicitly been identified as having their
special cases addressed in-tree:

> Other, less notable exceptions are marked in the file tree with
> COPYING, COPYRIGHT, or LICENSE files.

That practice predates 9front.

Hope this clears up the history.

khm

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mbdebd79c701e669045af7f62
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ron minnich]

On Sun, May 12, 2024 at 10:55 PM ibrahim via 9fans <9fans@9fans.net> wrote:

>
>
> Please correct me if I'm wrong.
> Permalink
> 
>

In my opinion? you are wrong. And that's as far as I will stay involved in
this discussion.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M918765fe95c422bafdedbbf1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

The last post had some paste copy issues :

There are many companies who double license code. As the owners of such code 
they are free to do this. Users can't relicense code as they please especially 
not GPL licensed code. 

If you download code that is GPL licensed you can't change the license to the 
MIT license. The only one who had the right to make a change of the license was 
Nokia they were the owners and they decided to do so after this bold action 
from 9front. If I'm wrong it would be nice if you tell me where exactly lies my 
mistake.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M08dd52c34338ab27c6590836
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Kurt H Maier via 9fans]

On Sun, May 12, 2024 at 11:52:29PM -0400, ibrahim via 9fans wrote:
> 
> You ignore copyrights as you please and distributed 9front under an MIT 
> license long before Nokia as the owner of it decided to do so. You did
> that at a time when plan9 was placed under GPL. 

You have apparently not read our licensing document at
/lib/legal/NOTICE, which explicitly names the terms of the original Plan
9 code, and assigns the MIT license only to changes produced by 9front.

As the labs-provided code has been made available under different
licenses, we have updated this to reflect the changes, from Lucent
Public License, through the GPL relicense, and then the MIT license.
At all times we've complied with the distribution requirements of all
applicable licenses.

> The first thing such people have to check is the way you handle licenses. 

Yes, and our handling of them has been impeccable, with a wonderful end
state where all of the Plan 9 code, both from the Labs and from 9front,
can live happily ever after under the same license thanks to a lot of
work from people who cared.

One by one we're getting rid of the third-party software -- I
particularly look forward to the day we can finally ditch Ghostscript --
but in the meantime these accusations of license violations are
misinformed and have no basis in reality.

khm

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M27e972c2ed30ae3748f1d0d4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 7:33 AM, ron minnich wrote:
> At no time in all this was there any evidence of incorrect behavior on the 
> part of 9front. None. Zip. Zero. Zed. They have always been careful to follow 
> the rules. 
> 
> Further, when people in 9front wrote new code, they released it under MIT, 
> and Cinap among others was very kind in letting Harvey use it.  
> 
> So, Ibrahim,  I can not agree with your statement here. 
> 0.2.4.4 - PRAISE FOR 9FRONT’S BOLD ACTION, RE: LICENSING
> 
> Any additions or changes (as recorded in git history) made by 9front are 
> provided under the terms of the MIT License, reproduced in the file 
> /lib/legal/mit, unless otherwise indicated.
> 
> Read: /lib/legal/NOTICE.
> 
> 0.2.4.5 - Everyone loves the Plan 9 license (circa 2021)
> 
> In 2021, the Plan 9 Foundation (aka P9F—no relation) convinced Nokia to 
> re-license all historical editions of the Plan9 source code under the MIT 
> Public License.
> 
> As a consequence, all of 9front is now provided under the MIT License unless 
> otherwise indicated.
> 
> Re-read: /lib/legal/mit

This is a citation of the current FQA and in older ones predating the 
relicensing by Nokia  the same paragraphs were present. If those statements 
from the 9front documentation are correct than your MIT relicensing predates 
the moment where the owner of plan9 Nokia made such a decission. This paragraph 
regarding the "bold action" of relicensing appeard before the owners of the 
code made it available under MIT license.

Please correct me if I'm wrong.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M87ce4c9f9e82fb2fa4b938f2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

libttf was one example and because it made its way into 9legacy i inspected it.

> Are you implying that a majority of users are using Plan9 in a commercial 
> setting? That seems a bit absurd.
> For personal use I think these license issues (if they do even exist) are of 
> no concern. I think you are greatly
> exaggerating the possible issue here for your average user.
 
I could tell you about more than two dozens of projects alone at german 
universities where plan9 was used in medical sensor devices. Calling something 
absurd which lies beyond your experience gives reason enough to not name any of 
those projects. 

> Again, I think in your situation of distributing hardware with plan 9 or 
> whatever, then it makes sense to do whatever your lawyer says.
> I think advising against using 9front for every user on these grounds though 
> is misleading at best.

Its not the lawyer who is responsible to avoid copyright issues its the duty of 
the developer. Not the lawyer gets sued but the one who distributes the system.

Everyone is free to use 9front. But I won't use 9front for a distributed system 
because I don't have the legal certainty as with plan9. I know who developed 
plan9 and I know that Nokia owned it before they relicensed it. But I don't 
this trust in 9front code. And so I wouldn't advise others who make use of 
plan9 in ways like I do to use 9front.

> Do you also remove the Lucida and printer fonts? These were released as part 
> of the original source but have interesting claims as to the ability to 
> redistribute them.
> Do you also strip out the parts of ape that include ancient GNU utilities? 
> Are you running your system without a diff and patch?

Of course I removed all fonts from the system. I have my own font library with 
scaleable vector fonts based on caligraphy. As I stated before I removed any 
GNU utilities ghostview postscript page and all tools which have clearly GPL 
licenses are removed. Patch and diff are replaced with BSD licensed versions 
taken from OpenBSD.

Those are the rules.

> And Java runs on a billion devices.

And I can't distribute Java, Linux, commercial operating systems because those 
can't be distributed as you please their licenses don't allow distribution as 
the MIT license does.

> I'm quite curious as to your definition of "professional" in one where none 
> of the work done by 9front would be seen as beneficial.

I can assure you I respect your fork and the state you reached. Professional 
use as a distributed operating system needs legal certainty. If you include 
code from sources and I use your fork than I am the one who is doomed not you 
because you are no legal entity. I have to make sure that my distributions has 
no legal issues. The way you answer to such licensing problems makes clear you 
don't care about them and take the issue lightly.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5c4cdcf81f1cd752663d81e5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ron minnich]

On Sun, May 12, 2024 at 8:53 PM ibrahim via 9fans <9fans@9fans.net> wrote:

> Not a single developer who uses plan9 for distributed systems, commercial
> products will dare to use a system like 9front as the sources. The reason
> is quite simple :
>
> You ignore copyrights as you please and distributed 9front under an MIT
> license long before Nokia as the owner of it decided to do so. You did that
> at a time when plan9 was placed under GPL
>

I do not agree with what you are saying here. I was involved in the license
discussions starting in 2003, and was involved in both the GPL release and
the more recent MIT license release. The choice of license, both times, was
made by the same person in Bell Labs, even as the Bell Labs corporate
parent changed. In fact, in 2013, we were *required* to use the GPL,
whereas in the later release, the GPL was specifically mentioned as a
license we could *not* use. I won't pretend to understand why.

At no time in all this was there any evidence of incorrect behavior on the
part of 9front. None. Zip. Zero. Zed. They have always been careful to
follow the rules.

Further, when people in 9front wrote new code, they released it under MIT,
and Cinap among others was very kind in letting Harvey use it.

So, Ibrahim,  I can not agree with your statement here.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M3d0b948ec892b2d0de94a895
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[clinton]

Some excellent advice so far I have to say. A reasonable assumption is that
I am at least a linux user (entirely accurate, I installed slackware from
floppies a long time ago when the world was new and 486es were still
moderately expensive). Would a BASIC interpreter count as an operating
system I wonder? Well no matter, I don't have to live with one these days.
Anyway, a nice pathway from linux to a plan9 of some description is quite
helpful and I am very thankful. I should be rather careful with that DES
implementation in 9legacy, is it the 1970s version or 3DES? Quite shocked
if it is the former. Some very good advice indeed, thanks to everyone!
I look forward to blundering around with 9front too I must say.

On Monday, May 13, 2024, Jacob Moody  wrote:

> On 5/12/24 22:52, ibrahim via 9fans wrote:
> > On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote:
> >> When people suggest tossing that all out for a minimally patched 4e, I
> think some people rightfully feel a bit annoyed. That's a lot of baby that
> goes out with that bathwater.
> >
> > It's Davids decission what he includes as patches for the 4th edition
> but I would toss everything out of 9legacy which isn't part of the 4th
> edition or contributed by the team members at Bell Labs from their archives
> as enhancements.
> >
> > The reasoning is simple : p9f owns the rights for the final release and
> Nokia has made this release available under a MIT license. Every one who
> uses plan9 not only to toy around or his/her personal use but also as a
> system which he/she distributes like I do can't afford risks with code
> integrated from sources like 9front. There are some libraries taken from
> 9front derived from other open source projects like freetype (truetype)
> where copyright notices are absent and this isn't the only library
> > where in code comments the sources are named but the original copyright
> notices are absent.
> >
> > plan9 as represented by p9f has a clear license all parts which are not
> MIT licensed are marked as such but code back ported from other forks like
> 9front contain code where I have doubts if those are really under an MIT
> license as you state in your documentation cause deriving from a different
> license or taking large amounts of code doesn't remove viral licenses like
> LGPL or GPL.
>
> If you have a list of libraries that you feel do not represent their
> license providence by /lib/legal/NOTICE in our 9front tree, let me know we
> should probably get that updated.
> Our libttf is not derived from freetype as I understand it.
>
> >
> > It would be in the interest of plan9 and all who professionally use it
> in embedded systems or as a distributed operating system to keep suspicious
> code out of the 9legacy CD. If really necessary to provide such
> contributions or back ports I wouldn't place them in the system folders but
> as it was in the past in contrib folders for additional download. The risks
> to infect a clearly licensed system gifted by Nokia to all of us to make
> best use of it for free commercial private embedded ...
> > solutions are to high and I would really prefer it when nothing from
> forks like 9front would take its way into the 9legacy CD ROM which is
> defined as :
> >
> >  Plan 9 archives, reference releases of Plan 9.
> >
> >  9legacy, Plan 9 with many useful patches applied. Download page
> has an
> >  installation CD image including 386, amd64, and arm kernels and
> binaries;
> >  a bootable USB image for 386; a bootable SD card image for
> Raspberry Pi;
> >  and virtual disk images for QEMU and GCE.
> >
> >  The 4th Edition distribution from Bell Labs:
> >  live CD/install CD/USB image, installation notes,
> >  browse the source, additional software
>
> Are you implying that a majority of users are using Plan9 in a commercial
> setting? That seems a bit absurd.
> For personal use I think these license issues (if they do even exist) are
> of no concern. I think you are greatly
> exaggerating the possible issue here for your average user.
>
> >
> > I respect your fork 9front but I won't and can't use it. 9front isn't
> plan9 from my perspective. Plan 9 is the final release with patches for the
> files from sources I can be sure that those aren't taken from open source
> projects by copy and paste. The moment I and others who use plan9 for
> distribution or embed it on systems we have to be absolutely sure about the
> sources of the code. I can trust Bell Labs, Nokia, p9f but I won't trust
> some guys who toy around with their fork of plan9. The moment
> > FSF or another organisation starts to suit me because they recognized
> that some guy at any forked system has copy pasted code from a viral
> licensed project I am the one who has to take the consequences.
>
> Again, I think in your situation of distributing hardware with plan 9 or
> whatever, then it makes sense to do whatever your lawyer says.
> I think advising 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

On 5/12/24 22:52, ibrahim via 9fans wrote:
> On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote:
>> When people suggest tossing that all out for a minimally patched 4e, I think 
>> some people rightfully feel a bit annoyed. That's a lot of baby that goes 
>> out with that bathwater.
> 
> It's Davids decission what he includes as patches for the 4th edition but I 
> would toss everything out of 9legacy which isn't part of the 4th edition or 
> contributed by the team members at Bell Labs from their archives as 
> enhancements.
> 
> The reasoning is simple : p9f owns the rights for the final release and Nokia 
> has made this release available under a MIT license. Every one who uses plan9 
> not only to toy around or his/her personal use but also as a system which 
> he/she distributes like I do can't afford risks with code integrated from 
> sources like 9front. There are some libraries taken from 9front derived from 
> other open source projects like freetype (truetype) where copyright notices 
> are absent and this isn't the only library
> where in code comments the sources are named but the original copyright 
> notices are absent.
> 
> plan9 as represented by p9f has a clear license all parts which are not MIT 
> licensed are marked as such but code back ported from other forks like 9front 
> contain code where I have doubts if those are really under an MIT license as 
> you state in your documentation cause deriving from a different license or 
> taking large amounts of code doesn't remove viral licenses like LGPL or GPL.

If you have a list of libraries that you feel do not represent their license 
providence by /lib/legal/NOTICE in our 9front tree, let me know we should 
probably get that updated.
Our libttf is not derived from freetype as I understand it.

> 
> It would be in the interest of plan9 and all who professionally use it in 
> embedded systems or as a distributed operating system to keep suspicious code 
> out of the 9legacy CD. If really necessary to provide such contributions or 
> back ports I wouldn't place them in the system folders but as it was in the 
> past in contrib folders for additional download. The risks to infect a 
> clearly licensed system gifted by Nokia to all of us to make best use of it 
> for free commercial private embedded ...
> solutions are to high and I would really prefer it when nothing from forks 
> like 9front would take its way into the 9legacy CD ROM which is defined as :
> 
>  Plan 9 archives, reference releases of Plan 9.
>    
>  9legacy, Plan 9 with many useful patches applied. Download page has 
> an
>  installation CD image including 386, amd64, and arm kernels and 
> binaries;
>  a bootable USB image for 386; a bootable SD card image for Raspberry 
> Pi;
>  and virtual disk images for QEMU and GCE.
>    
>  The 4th Edition distribution from Bell Labs:
>  live CD/install CD/USB image, installation notes,
>  browse the source, additional software

Are you implying that a majority of users are using Plan9 in a commercial 
setting? That seems a bit absurd.
For personal use I think these license issues (if they do even exist) are of no 
concern. I think you are greatly
exaggerating the possible issue here for your average user.

> 
> I respect your fork 9front but I won't and can't use it. 9front isn't plan9 
> from my perspective. Plan 9 is the final release with patches for the files 
> from sources I can be sure that those aren't taken from open source projects 
> by copy and paste. The moment I and others who use plan9 for distribution or 
> embed it on systems we have to be absolutely sure about the sources of the 
> code. I can trust Bell Labs, Nokia, p9f but I won't trust some guys who toy 
> around with their fork of plan9. The moment
> FSF or another organisation starts to suit me because they recognized that 
> some guy at any forked system has copy pasted code from a viral licensed 
> project I am the one who has to take the consequences.

Again, I think in your situation of distributing hardware with plan 9 or 
whatever, then it makes sense to do whatever your lawyer says.
I think advising against using 9front for every user on these grounds though is 
misleading at best.

> 
> The first thing I am doing after downloading an iso from 9 legacy is to 
> remove all files which were not part of the final plan9 release. The second 
> thing I have always to do is removing all patches from the iso which came 
> from sources I can't be sure if they really followed licensing rules. The 
> third thing I have to do before distributing my fork of plan9 is to remove 
> fonts ghostscript diff page and other parts of the system which would infect 
> the distribution media to make sure the created
> system is not depending on viral licensed code.

Do you also remove the Lucida and printer fonts? These were released as part of 
the original source but have interesting claims as to the 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vic . thacker]

Thank you, Ibrahim, for your comments.  I can see where my suggestions do not 
make sense.  It is too difficult a challenge for the communities to envisage.  
If no one can envisage it, then no one can do it.

Vic


On Mon, May 13, 2024, at 12:52, ibrahim wrote:
> On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote:
>> When people suggest tossing that all out for a minimally patched 4e, I think 
>> some people
> rightfully feel a bit annoyed. That's a lot of baby that goes out with
> that bathwater.
> 
> It's Davids decission what he includes as patches for the 4th edition
> but I would toss everything out of 9legacy which isn't part of the 4th
> edition or contributed by the team members at Bell Labs from their
> archives as enhancements.
> 
> The reasoning is simple : p9f owns the rights for the final release and
> Nokia has made this release available under a MIT license. Every one
> who uses plan9 not only to toy around or his/her personal use but also
> as a system which he/she distributes like I do can't afford risks with
> code integrated from sources like 9front. There are some libraries
> taken from 9front derived from other open source projects like freetype
> (truetype) where copyright notices are absent and this isn't the only
> library where in code comments the sources are named but the original
> copyright notices are absent.
> 
> plan9 as represented by p9f has a clear license all parts which are not
> MIT licensed are marked as such but code back ported from other forks
> like 9front contain code where I have doubts if those are really under
> an MIT license as you state in your documentation cause deriving from a
> different license or taking large amounts of code doesn't remove viral
> licenses like LGPL or GPL.
> 
> It would be in the interest of plan9 and all who professionally use it
> in embedded systems or as a distributed operating system to keep
> suspicious code out of the 9legacy CD. If really necessary to provide
> such contributions or back ports I wouldn't place them in the system
> folders but as it was in the past in contrib folders for additional
> download. The risks to infect a clearly licensed system gifted by Nokia
> to all of us to make best use of it for free commercial private
> embedded ... solutions are to high and I would really prefer it when
> nothing from forks like 9front would take its way into the 9legacy CD
> ROM which is defined as :
> 
>  Plan 9 archives, reference releases of Plan 9.
> 
>  9legacy, Plan 9 with many useful patches applied. Download
> page has an
>  installation CD image including 386, amd64, and arm kernels
> and binaries;
>  a bootable USB image for 386; a bootable SD card image for
> Raspberry Pi;
>  and virtual disk images for QEMU and GCE.
> 
>  The 4th Edition distribution from Bell Labs:
>  live CD/install CD/USB image, installation notes,
>  browse the source, additional software
> 
> I respect your fork 9front but I won't and can't use it. 9front isn't
> plan9 from my perspective. Plan 9 is the final release with patches for
> the files from sources I can be sure that those aren't taken from open
> source projects by copy and paste. The moment I and others who use
> plan9 for distribution or embed it on systems we have to be absolutely
> sure about the sources of the code. I can trust Bell Labs, Nokia, p9f
> but I won't trust some guys who toy around with their fork of plan9.
> The moment FSF or another organisation starts to suit me because they
> recognized that some guy at any forked system has copy pasted code from
> a viral licensed project I am the one who has to take the consequences.
> 
> The first thing I am doing after downloading an iso from 9 legacy is to
> remove all files which were not part of the final plan9 release. The
> second thing I have always to do is removing all patches from the iso
> which came from sources I can't be sure if they really followed
> licensing rules. The third thing I have to do before distributing my
> fork of plan9 is to remove fonts ghostscript diff page and other parts
> of the system which would infect the distribution media to make sure
> the created system is not depending on viral licensed code.
> 
> My fork isn't the only one which gets distributed. I'm sure there exist
> millions of devices with plan9 integrated without anyone noticing
> except for those who look into the documentation where the MIT licensed
> copyright is placed.
> 
> If people from forks like 9front are talking about numbers of their
> users I always have to laugh. My fork is right now used by about 500
> people per semester more users. And be assured this is an unimportant
> number.
> 
> Not a single developer who uses plan9 for distributed systems,
> commercial products will dare to use a system like 9front as the
> sources. The reason is quite simple :
> 
> You ignore copyrights as you please and distributed 9front under an MIT
> license long 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[ibrahim via 9fans]

On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote:
> When people suggest tossing that all out for a minimally patched 4e, I think 
> some people
rightfully feel a bit annoyed. That's a lot of baby that goes out with that 
bathwater.

It's Davids decission what he includes as patches for the 4th edition but I 
would toss everything out of 9legacy which isn't part of the 4th edition or 
contributed by the team members at Bell Labs from their archives as 
enhancements. 

The reasoning is simple : p9f owns the rights for the final release and Nokia 
has made this release available under a MIT license. Every one who uses plan9 
not only to toy around or his/her personal use but also as a system which 
he/she distributes like I do can't afford risks with code integrated from 
sources like 9front. There are some libraries taken from 9front derived from 
other open source projects like freetype (truetype) where copyright notices are 
absent and this isn't the only library where in code comments the sources are 
named but the original copyright notices are absent. 

plan9 as represented by p9f has a clear license all parts which are not MIT 
licensed are marked as such but code back ported from other forks like 9front 
contain code where I have doubts if those are really under an MIT license as 
you state in your documentation cause deriving from a different license or 
taking large amounts of code doesn't remove viral licenses like LGPL or GPL.

It would be in the interest of plan9 and all who professionally use it in 
embedded systems or as a distributed operating system to keep suspicious code 
out of the 9legacy CD. If really necessary to provide such contributions or 
back ports I wouldn't place them in the system folders but as it was in the 
past in contrib folders for additional download. The risks to infect a clearly 
licensed system gifted by Nokia to all of us to make best use of it for free 
commercial private embedded ... solutions are to high and I would really prefer 
it when nothing from forks like 9front would take its way into the 9legacy CD 
ROM which is defined as :

 Plan 9 archives, reference releases of Plan 9.
   
 9legacy, Plan 9 with many useful patches applied. Download page has an
 installation CD image including 386, amd64, and arm kernels and 
binaries;
 a bootable USB image for 386; a bootable SD card image for Raspberry 
Pi;
 and virtual disk images for QEMU and GCE.
   
 The 4th Edition distribution from Bell Labs:
 live CD/install CD/USB image, installation notes,
 browse the source, additional software

I respect your fork 9front but I won't and can't use it. 9front isn't plan9 
from my perspective. Plan 9 is the final release with patches for the files 
from sources I can be sure that those aren't taken from open source projects by 
copy and paste. The moment I and others who use plan9 for distribution or embed 
it on systems we have to be absolutely sure about the sources of the code. I 
can trust Bell Labs, Nokia, p9f but I won't trust some guys who toy around with 
their fork of plan9. The moment FSF or another organisation starts to suit me 
because they recognized that some guy at any forked system has copy pasted code 
from a viral licensed project I am the one who has to take the consequences. 

The first thing I am doing after downloading an iso from 9 legacy is to remove 
all files which were not part of the final plan9 release. The second thing I 
have always to do is removing all patches from the iso which came from sources 
I can't be sure if they really followed licensing rules. The third thing I have 
to do before distributing my fork of plan9 is to remove fonts ghostscript diff 
page and other parts of the system which would infect the distribution media to 
make sure the created system is not depending on viral licensed code. 

My fork isn't the only one which gets distributed. I'm sure there exist 
millions of devices with plan9 integrated without anyone noticing except for 
those who look into the documentation where the MIT licensed copyright is 
placed. 

If people from forks like 9front are talking about numbers of their users I 
always have to laugh. My fork is right now used by about 500 people per 
semester more users. And be assured this is an unimportant number.

Not a single developer who uses plan9 for distributed systems, commercial 
products will dare to use a system like 9front as the sources. The reason is 
quite simple :

You ignore copyrights as you please and distributed 9front under an MIT license 
long before Nokia as the owner of it decided to do so. You did that at a time 
when plan9 was placed under GPL. 

9front is a fork your fork I respect your work. But all your commits and 
enhancements are absolutly useless for people who intend or use plan9 not only  
to play around with this system but make professional use of it. The first 
thing such people have to check 

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vic . thacker]

The approach is effective in open source projects when there are leaders who 
excel in communication, provide a clear vision, and prioritize objectives. Its 
effectiveness diminishes in the absence of strong communication and planning. 
Clear expectations generally facilitate easier collaboration and sustained 
engagement. However, I am not referring to the 2% of individuals who engage 
only if it aligns with their own ideas. Prima donnas will act independently 
regardless, but for the majority who seek a constructive environment, like 
myself, establishing a structured system or model is beneficial.

Competence levels vary within the community, and any system necessitates 
knowledge transfer. This can be achieved through mentorship or onboarding 
sponsorship programs. The onboarding process involves several stages:
1. Not knowing what you don't know, where clear direction is essential.
2. Knowing that you don't know, where coaching is necessary.
3. Knowing and performing tasks with conscious effort, where occasional 
correction may be required.
4. Performing tasks instinctively, where little to no correction is needed.

There seems to be an implicit expectation that contributors should be at stage 
four, but many in the 9fans community may not yet be at this level. While I'm 
not an expert, my initial experiences with Plan 9 were enriched by several 
mentors who were willing to guide me and others; but in today's environment 
that might be a big ask, so you might be right.

Vic


On Mon, May 13, 2024, at 10:32, o...@eigenstate.org wrote:
> I don't think this approach has ever worked in
> the open source world -- it always starts with
> someone building something useful. The vision
> and goal is defined by the work being done.
>
> After something useful is built, people start
> to join in and contribute.
>
> After enough people join in, it makes sense to
> have more organization.
>
> Quoth vester.thac...@fastmail.fm:
>> The complexity of communication in this medium often necessitates detailed 
>> discussions.  You highlighted the need for additional personnel to manage 
>> the workload (e.g. do the work).  From my perspective, this requires a 
>> well-defined vision, clear objectives, and a prioritized list of 
>> deliverables to align efforts effectively.  Currently, it seems the role of 
>> product managers is collectively held, though it's unclear who exactly is 
>> responsible.  Typically, a team of two or more individuals would focus on 
>> these deliverables.  In past projects, I've seen the use of a project board 
>> to keep everyone updated on tasks—an approach known as "information 
>> radiator" in project management.  I'm open to other methods if you had 
>> something different in mind that I may have overlooked.  If you are 
>> considering a meritocracy, I would recommend caution.  Experience has shown 
>> that what we truly need is increased collaboration and unity, rather than a 
>> system that could potentially encourage competition and division.  I 
>> apologize if my message is obtuse, I am trying to keep this message concise, 
>> I can expound more for clarity.  I hope my explanation helps. 
>> 
>> Vic
>> 
>> 
>> On Mon, May 13, 2024, at 03:36, o...@eigenstate.org wrote:
>> > that's not what I said.
>> >
>> > Quoth vic.thac...@fastmail.fm:
>> >> I agree that having a clear vision and charter is essential before 
>> >> forming a team. Regarding building an inclusive Plan 9 community that 
>> >> encompasses multiple groups, it's important to establish common goals and 
>> >> values that resonate with all members. What are your thoughts on creating 
>> >> open channels for dialogue and collaboration? How can we ensure that 
>> >> everyone feels valued and heard? This approach could foster a more 
>> >> cooperative and inclusive environment.
>> >> 
>> >> Vic
>> >> 
>> >> 
>> >> On Sun, May 12, 2024, at 16:19, pl...@room3420.net wrote:
>> >> > "tl;dr: you need people doing the work before you can try
>> >> > to organize them; the way to get people doing the work is
>> >> >  to bootstrap it by doing work and showing value." [from Ori].
>> >> >  or
>> >> >  "Don't be the kid who can't play [whatever]ball but wants to teach
>> >> > everybody and be the team coach, just because he read a book."

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mee6775a4b239f8cd0dc57264
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Jacob Moody]

On 5/12/24 20:46, Dan Cross wrote:
> On Sun, May 12, 2024 at 9:33 PM  wrote:
>> I don't think this approach has ever worked in
>> the open source world -- it always starts with
>> someone building something useful. The vision
>> and goal is defined by the work being done.
>>
>> After something useful is built, people start
>> to join in and contribute.
>>
>> After enough people join in, it makes sense to
>> have more organization.
> 
> I remain mystified by the desired end state here.  For all intents and
> purposes, as far as the wider world is concerned, 9front is plan 9.
> I'm not sure I'd want that burden, to be honest, but that's just me.
> That aside, realistically, 9front is the only thing in the plan 9
> world that has energy behind it.

This doesn't seem about any "end result" here. I read it as more a direct 
response
to whatever bureaucratic/project management/deliverables/hard core team Vic is 
imagining.
This is pointing out that everything around organization falls out from people 
doing work
and others choosing to work with them, which I agree with.

However your question about the end state is interesting.
As it has been discussed ad nauseam here, there is fairly high discontent at
there being anything even close to acknowledgement about 9front being Plan 9.
So much so that things like the p9f go out of their way to avoid talking about 
us.
You seem to think as I do that this has had litle practical impact. However it
is what I would call unfortunate. I don't bring this up to rehash this issue,
just to explain part of what I feel the current situation is.

We often find ourselves in these situations because of bogus claims made
at 9front's expense. We're here in this thread because of such claims that
9front and 9legacy were wildly incompatible.

> 
> On the other hand, there's 9legacy, which pulls together some useful
> patches and attempts to carry on in a manner imagined to be closer to
> what Bell Labs did. That's fine; it's low activity, but people are
> busy, have lives to live, all that stuff. Regardless, some people seem
> to be genuinely offended by its existence, and I can't really
> understand why.

I can really only speak for myself but I think some frustration comes
at the direct comparisons between the two. 9front has seen a lot of work.
As qwx mentioned we have 10,555 commits on top of our initial import from 2011
and we continue to receive bug fixes and improvements at regular intervals.
Just talking about raw hours invested I think these projects are in different 
ballparks.
When people suggest tossing that all out for a minimally patched 4e, I think 
some people
rightfully feel a bit annoyed. That's a lot of baby that goes out with that 
bathwater.

> 
> Meanwhile, the people actually doing any work are in communication
> with one another, regardless of what label is applied to the software
> running on their individual computers, which is as it should be.

I think it's worth mentioning that I feel like this has improved since
iwp9 was continued. I've learned so much by interacting more with the
"old guard" and there has been much more discussions and code being
passed around. I encourage more folks to join us in working on things.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M75f50b19e10239ae6e23e2e5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription