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 
> <mailto: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  <mailto:mo...@posixcafe.org>> wrote:
> >
> > 
> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/
>  
> <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 
> <mailto:9fans@9fans.net>> wrote:
> > >
> > >> On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net 
> <mailto: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
>  
> <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.
> > >>
> 

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

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] List of companies that use Plan 9.

[Jacob Moody]

On 5/15/24 11:20, Don Bailey wrote:
> 
> I have zero emotional attachment to Fossil. What I am asking for, not even 
> demanding, is a fact-based assessment of the asserted issue. Pointing at the 
> code is not an emotional attachment. It's literally the opposite. It's asking 
> to demonstrate and document the issues, instead of asserting that something 
> is awful because /you/ have had an emotional reaction to it failing. How did 
> it fail? Can you reproduce it? What code is bad? Why is the code bad? If you 
> can't answer these questions, maybe you
> shouldn't have removed it. 

The emotional accusation I understand, it really seems like it's just fossil 
that evokes this
reaction out of people. Just fossil that makes people want us to prove without 
any reason of doubt that the
code should have been removed. I also just don't understand why people are so 
attached to fossil.
Is it because people feel like there is a high burden of evidence for touching 
the holy code
as ordained by bell labs? We didn't want it so it went. If you think this is 
actually a
mistake and there is a world of possibility to be had thanks to fossil in Plan 
9 I encourage
you to maintain fossil yourself and prove to us that we were wrong in thinking 
it was dead weight.

I want to specifically compare the discussion that happened on this thread 
between p9sk1
and fossil. We think that no one should be using p9sk1, and so we spent the 
time to explain
to others the very real, concrete and specific issues with the code and 
implementation.

We are not telling any other user of Plan 9 to not use fossil if they'd like, 
we simply don't want to
deal with it in 9front. I think the burden of proof you are putting on us to 
make this
decision would only make sense if we were advocating for other distributions 
and current
users of fossil to no longer use it. It's fine, we're just not interested in 
it, sorry.

As I, and others, have pointed out now a couple of times. Adding fossil back to 
9front
is trivial. Perhaps you haven't had the experience of having to sit in irc and 
help
new users get going with the system who really don't have opinions about 
anything and
then dealing with the outcomes when things blow up. As you said fossil is not 
exactly
easy to deal with, it needs a lot of special consideration. So why then are you 
complaining
that 9front made the decision to remove that option for the uninformed user? 
Does it not
make more sense to direct users towards a filesystem that is more resilient and 
requires
less watering?

All of this is entirely moot with gefs right around the corner. I can't imagine 
someone
willingly want to use fossil with gefs as a (soon to be) alternative.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M0565bff8d967be11771601b6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] List of companies that use Plan 9.

[Jacob Moody]

Thank you, I look forward to seeing your work then.

On 5/15/24 11:21, Don Bailey wrote:
> Sounds good.
> 
> D
> 
> 
> On Wed, May 15, 2024 at 12:19 PM Jacob Moody  <mailto:mo...@posixcafe.org>> wrote:
> 
> On 5/15/24 10:56, Don Bailey wrote:
> > Yeah but that's the thing... "explained in this list" works while the 
> discussion is being had. But searching for that and attempting to grok the 
> discussion and the context of discussion at a later date? Not so much. Some 
> centralized documentation should be used to make these decisions clear. In 
> the commit messages is not sufficient, either. One still must search through 
> the commit messages and identify the branch/context/etc. Plus, you have to 
> /know/ about what you are looking for, if
> something
> > was removed. A separate document that outlines these 
> removed/altered/added items, and the rationale/context, would solve that. 
> Does that help illuminate the problem I'm discussing? 
> 
> Who exactly is the audience here? If the audience is developers then the 
> commit message is fine, if someone wants to know why code was changed that is 
> where you put the reasoning.
> People here like to work on code, less so on writing up whatever 
> justification you personally feel is sufficient to warrant whatever we're 
> doing. I already stated that I think
> these days more rationale and notice would be given to people for a 
> change that big, things are trending towards what I think you want.
> 
> If however you (or someone else) wanted to do what you are asking us to 
> do, which is spend the significant time it takes to demonstrably prove that 
> fossil is _not_ busted
> as we think it is and present it to us that would make for a compelling 
> argument for inclusion. Perhaps what you do could become the standard for how 
> these large changes
> are documented going forward.
> 
> Or if you'd like to start with a fork and/or raise your own community 
> with this high level of standard for code changes I would absolutely 
> encourage you to do so, if
> that is truly a better way of doing open source then it will be evident. 
> But right now I can't help but read this as asking us (people writing code 
> for 9front) to do
> more work to appease you when you are not interested in helping get that 
> work done.
> 
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-Me6bf30814627cb2d023dac80
>  
> <https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-Me6bf30814627cb2d023dac80>
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> <https://9fans.topicbox.com/groups/9fans/subscription>
> 
> *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/Tad3dc0c93039a7d2-Ma45e0253b479829aece635bc>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-Ma98136cdefad2d3331c8a061
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] List of companies that use Plan 9.

[Jacob Moody]

On 5/15/24 10:57, hiro wrote:
>> I don't understand the difference between code being included in the 
>> distribution and being "back in 9front". These are the same thing. If we 
>> ship code we maintain it.
> 
> there are some exceptions :)

I would like to see a list, that could should either be fixed or removed in my 
opinion.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M49756ac9191c4d1b95dd0c2c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] List of companies that use Plan 9.

[Jacob Moody]

On 5/15/24 10:56, Don Bailey wrote:
> Yeah but that's the thing... "explained in this list" works while the 
> discussion is being had. But searching for that and attempting to grok the 
> discussion and the context of discussion at a later date? Not so much. Some 
> centralized documentation should be used to make these decisions clear. In 
> the commit messages is not sufficient, either. One still must search through 
> the commit messages and identify the branch/context/etc. Plus, you have to 
> /know/ about what you are looking for, if something
> was removed. A separate document that outlines these removed/altered/added 
> items, and the rationale/context, would solve that. Does that help illuminate 
> the problem I'm discussing? 

Who exactly is the audience here? If the audience is developers then the commit 
message is fine, if someone wants to know why code was changed that is where 
you put the reasoning.
People here like to work on code, less so on writing up whatever justification 
you personally feel is sufficient to warrant whatever we're doing. I already 
stated that I think
these days more rationale and notice would be given to people for a change that 
big, things are trending towards what I think you want.

If however you (or someone else) wanted to do what you are asking us to do, 
which is spend the significant time it takes to demonstrably prove that fossil 
is _not_ busted
as we think it is and present it to us that would make for a compelling 
argument for inclusion. Perhaps what you do could become the standard for how 
these large changes
are documented going forward.

Or if you'd like to start with a fork and/or raise your own community with this 
high level of standard for code changes I would absolutely encourage you to do 
so, if
that is truly a better way of doing open source then it will be evident. But 
right now I can't help but read this as asking us (people writing code for 
9front) to do
more work to appease you when you are not interested in helping get that work 
done.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-Me6bf30814627cb2d023dac80
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] List of companies that use Plan 9.

[Jacob Moody]

On 5/15/24 10:20, Don Bailey wrote:
> This is part of the issue I've had with 9front. If there are valid reasons 
> for things to disappear or not be used, that's OK. But please document them 
> and provide rationale/evidence for their removal. That way, even if another 
> group chooses not to remove those items, they can learn from other teams' 
> decision making. This is especially imperative for file system stability, for 
> those that have not had trouble with Fossil, but need to understand that it 
> is problematic enough to be pulled from
> 9front. How was the lack-of-stability tested? To what degree was it tested? 
> etc. 
> 

I think many of the reasons and rational has been explained in this list. 
Really we don't entirely rip out programs often.
It's fairly rare. This change was made fairly early on in 9front's history, I 
think things would have gone over different
these days. A technical write-up would be nice, sure I don't disagree but I 
think people just wanted to stop dealing with
the crash reports and lost data and get back to spending time on code they 
enjoyed to work on.

For what it is worth I think our commit messages these days are quite 
descriptive of the problem being addressed, the details
put in commonly directly include the crash repro or failure state or technical 
description as to why things were done.
Also a huge portion of things are discussed on irc, nearly everything that gets 
put in to the system is discussed with
at least 1 additional person and usually more depending on the weight of the 
patch. There is a lot of thought that
goes in to what changes these days.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M18079e3e58e96c530d8a56c5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] List of companies that use Plan 9.

[Jacob Moody]

On 5/15/24 10:18, Lucio De Re wrote:
> What makes you think I want Fossil back in 9front? I suggested that the 
> sources could be included in the distribution, so they would not fork-rot as 
> they are doing presently.

I don't understand the difference between code being included in the 
distribution and being "back in 9front". These are the same thing. If we ship 
code we maintain it.


 It's always been the case that the Plan 9 distribution included "broken" 
sources that could not be compiled without external support, but were 
interesting enough to be published. That changed some when Alef was dropped and 
in fact I saved the Alef development stuff and ported it to 3ed and 4ed because 
I disagreed with the
> decision. Note that I made a sweeping generalisation, for simplicity, much 
> was discarded between 2ed and 4ed, and I find all that quite regrettable.

That's not how things are maintained in 9front, if things are shipped with the 
system they should build and be useful.
Nowadays we have tests that run every night to ensure that things continue to 
build and work as advertised.

> 
> I am certain that Cinap had good reasons for removing Fossil, but I'm not 
> sure you have painted the entire picture for this audience. No matter, of 
> course, 9front will be what 9front will be.

What is missing from my description?

> 
> I'm not going to argue with the semantic subtleties of "bad" as you interpret 
> it, but I will privately consider your judgement and interpret your postings 
> with a bias parallel to the one you have displayed toward me so far.

I like 9front, that's not any secret. I don't have anything against you.




--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M0cee12bd7f19ee6d277b72f2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Clarifying Lucio's Additional Requests [Was: Re: [9fans] List of companies that use Plan 9. ]

[Jacob Moody]

On 5/15/24 09:18, Don Bailey wrote:
> This thread is perhaps one of the best examples of the bizarre ecosystem that 
> Plan 9 has evolved (devolved?) into. While I have not always understood Vic's 
> choices, I was, in the past, aware of his /position/ at certain entities... 
> and provided him with security information I hoped was relevant to that 
> position at that time. He has been on the Plan 9 mailing list as long (or 
> longer?) than I have (pre-2002?) and has always written his emails in the 
> fashion he writes them currently. 

I'm not quite sure what his position has to do with anything honestly. I am 
sorry I lack some historical context.

> 
> Frankly, I don't even understand the point in attacking whether he is or is 
> not "an LLM". He's actually trying to be helpful. Perhaps spending less time 
> trolling everyone you don't understand (and inaccurately presume to be a 
> troll), and instead trying to understand how they purport to add value, is a 
> useful path forward. 

I thought he was using a LLM because I had mentioned such in previous emails in 
this thread and was not corrected. Some posts have this improper summation
of what the previous mail said in the same way I've seen LLMs do. A lot of the 
discussions earlier were about adding bureaucratic process and what not
that it was hard for me to take seriously. I understand now that these were 
honest attempts at helping things, just not ones that I would
tend to agree with. Vic, I am sorry for attributing malice to what you were 
doing to help.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9bf40e9448c878ab-Md8f2dacc717ea65eae27b99e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] List of companies that use Plan 9.

[Jacob Moody]

On 5/15/24 04:02, Lucio De Re wrote:
> I have asked precisely NOTHING and have only pointed out the consequences of 
> omitting sources from the 9front distribution because it leads to undesirable 
> divisions.

I'm just trying to correct the misinformation you stated.
When you call the decision to drop fossil "bad", your email reads as a 
persuasive argument for why things should change.
I was in turn explaining why this is not happening, and if someone wanted that 
to change what would need to happen.

> 
> I do find it tiresome that you keep ascribing intentions to me that may well 
> reflect precisely how YOU would feel and react in my position. I assure I am 
> nothing like that and I'm sure my history on 9fans for the past 20+ years 
> would reflect that. But then again, people have abandoned 9fans in the past 
> for reasons not dissimilar from these; I can read the undercurrent ("because 
> you are asking for other people to maintain your software for you for free"), 
> I am not impolite enough to respond in kind.

Are your intentions not to persuade someone in the 9front world that fossil is 
worth adding back to the system?



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M487e5306116b96ed7c5b7052
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Clarifying Lucio's Additional Requests [Was: Re: [9fans] List of companies that use Plan 9. ]

[Jacob Moody]

At this point I can't really tell if you're using some LLM to be ironic or if 
you actually think this junk
is of any substance. I am not sure how you don't see this copy pasta garbage as 
anything else than a waste
of everyone else's inbox and time.

On 5/15/24 00:55, vic.thac...@fastmail.fm wrote:
> Firstly, congratulations to Lucio on the progress with getting Fossil running 
> under 9front. A heartfelt thank you to everyone who offered their support and 
> assistance to make this possible!  I only say this as a person who wants to 
> celebrate successes.
> 
> FWIW, I’d like to help clarify the additional requests that Lucio has made to 
> address each point effectively on a separate thread.  Here are Lucio’s 
> requests, organized by topic:

I find it very funny that your LLM summarized Lucio's mail as a list of demands.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9bf40e9448c878ab-Me40aca14846539176500a8cd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] List of companies that use Plan 9.

[Jacob Moody]

On 5/14/24 23:46, Lucio De Re wrote:
> If this comes across as a troll, keep in mind that it is your interpretation 
> that makes it so, a lesson we South Africans are still busy learning, at our 
> country's expense.
> 
> I've got Fossil running under 9front; thanks to all those who prodded me (and 
> others). I would be happier knowing that there is a "canonical" version 
> rather than at least two varieties as appears to be the case from the above 
> discussion, but I'd rather not spoil the moment.
> 
> My point all along was that if the source (Fossil or other) is not included 
> in the (9front) distribution, a (bad) decision is being made by arbitrary 
> (non)contributors for all the silent participants who may not even know about 
> it. Why would anyone want to play God? Isn't Google bad enough?
The decision was not made by an arbitrary contributor on a whim, it was decided 
after people maintaining 9front got sick
and tired of dealing with people's data getting minced. Effort was put in to 
the two (and soon to be three) other
file systems that have had a much better reliability track record. The intent 
was to nudge people away from
using what was deemed buggy software. If you want this to change then either 
you or someone else needs to step up and maintain
the software. You are asking for 9front to take on the burden of maintaining an 
additional old buggy filesystem
because it makes your life a tiny bit easier?

A bit hard to tell from your wording but either you are saying the contributor 
became a "noncontributor" by deleting
fossil or are you accusing the person who deleted fossil as being generally a 
"noncontributor"?
If you had spent even 10 seconds looking at the git history you would have seen 
that the one to pull the plug and
delete fossil was cinap and not some random passerby.

Do you not see the irony here? You, a most certain "noncontributor", are 
demanding that we do what you want without any intent of doing any of the work 
yourself.
Why can you not just tar up your files and put them on a supported filesystem? 
Why are we still having this discussion?

> 
> I concede that I didn't know myself what I was looking for (I think what "I" 
> need is for 9legacy to boot, install and possibly run, from a USB stick on 
> any PC hardware, and support both IDE and SATA where present) and my rather 
> vague question was intended to make the details less sketchy. Instead, I got 
> a tirade about what I was or was not ready, willing or able to contribute. 
> Fortunately, that tends to have the desired effect with me, so right now I 
> haven't yet recovered my decades of pretty
> pointless effort, but I know I can do it, with sufficient application, it is 
> no longer lost or teetering on edge of the abyss.

Yes because you are asking for other people to maintain your software for you 
for free. 9front maintainers do not want to do
this, so the reaction is going to be to do it yourself. I don't know why this 
is seen as a surprising outcome.

On 5/14/24 18:19, michaelian ennis wrote:
>
>
>
> The flurries of traffic on this list often seem to have a negative tone to 
> me.  It means a lot to me when the conversations are supportive.

I agree, I would like to have positive interactions towards working on 
solutions to current problems. I would much prefer if conversations
trended towards these type of topics. We seem to have no issue keeping things 
like this at IWP9 (for the most part).


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-Me7dff9ba3eef0718fabede05
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)

[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)

[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] one weird trick to break p9sk1 ?

[Jacob Moody]

On 5/13/24 05:18, Richard Miller wrote:
> Jacob and Ori, thank you for filling in some more details. Without
> the specifics I had been making some wrong assumptions about where
> the exact threat was.
> 
> I think I now have a clearer picture:
> 
> It's not particularly p9sk1 which is vulnerable, but the protocol
> for ticket request / response, which leaks enough information to
> allow offline exploration of user keys. The contribution of p9sk1
> is that its handshake protocol helpfully reveals a valid user name -
> ie the authid - which can be used by an attacker to make a legitimate
> ticket request, without any need for eavesdropping or guessing at
> user names.

Yes that is how I understand it.

> 
> So, if you have an authentication service exposed to the ipv4
> internet (or to the ipv6 internet with a findable address), and
> your authid or a known or guessable userid has a weak enough
> password to succumb to a dictionary search, it's probably right
> to say that a random attacker could make a cpu connection or
> mount your file service with an afternoon's work on consumer
> hardware.
> 
> Nobody needs to have weak passwords, though. Using the !hex attribute
> instead of !password with factotum, and/or using secstore(1), makes it
> easy to have a randomly generated DES key with the full 56 bits of
> entropy. This makes the attacker do more work ...  but not all that
> much more. I hadn't kept up with how powerful commodity GPUs have
> become. (My most recent experience with High Performance Computing
> involved transputer arrays and Cray T3Ds.  Nowadays I specialise in
> low performance computing.) It appears that investment of a few
> thousand dollars and a few days compute time (maybe less if using
> cloud services) is enough for a full brute-force exploration of the
> single-DES keyspace.

I'm very glad we were able to communicate this and thank you for taking
the time to talk about this here in this thread.


Thank you,
Jacob Moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Me0355c116b61ac991520ac58
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)

[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 distributi

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

Re: [9fans] one weird trick to break p9sk1 ?

[Jacob Moody]

On 5/12/24 08:16, Richard Miller wrote:
> I'm using a new subject [was: Interoperating between 9legacy and 9front]
> in the hope of continuing discussion of the vulnerability of p9sk1 without
> too many other distractions.
> 
> mo...@posixcafe.org said:
>> If we agree that:
>>
>> 1) p9sk1 allows the shared secret to be brute-forced offline.
>> 2) The average consumer machine is fast enough to make a large amount of 
>> attempts in a short time,
>>in other words triple DES is not computationally hard to brute force 
>> these days.
>>
>> I don't know how you don't see how this is trivial to do.
> 
> I agree that 1) is true, but I don't think it's serious. The shared secret is
> only valid for the current session, so by the time it's brute forced, it may
> be too late to use. I think the bad vulnerability is that the ticket request
> and response can be used offline to brute force the (more permanent) DES keys
> of the client and server. Provided, of course, that the random teenager 
> somehow
> is able to listen in on the conversation between my p9sk1 clients and servers.

You do not need to listen between clients in order to get the DES key to begin
brute forcing of the password. A malicious client can initiate an authentication
attempt without any current information about the user and leave with the 
encrypted
DES key to perform the known plaintext attack.

> 
> On the other hand, it's hard to know whether to agree or disagree with 2),
> without knowing exactly what is meant by "large amount", "short time",
> "computationally hard", and "trivial".
> 
> When Jacob told me at IWP9 in Waterloo that p9sk1 had been broken, not
> just theoretically but in practice, I was looking forward to seeing 
> publication
> of the details. Ori's recent claim in 9fans seemed more specific:

There are unfortunately some issues with the original paper done by my
friends that have prevented me from posting it publicly.
I think it would still be good to document this issue in a more concrete
fashion, I am sorry this has turned in to such a mess.

>> From: o...@eigenstate.org
>> ...
>> keep in mind that it can literally be brute forced in an
>> afternoon by a teenager; even a gpu isn't needed to do
>> this in a reasonable amount of time.
> 
> I was hoping for a citation to the experimental result Ori's claim was
> based on. If the "it" which can be brute forced refers to p9sk1, it
> would be very interesting to learn if there are flaws in the algorithm
> which will allow it to be broken without breaking DES. My assumption
> was that "it" was referring simply to brute forcing DES keys with a
> known-plaintext attack. In that case, a back of the envelope calculation
> can help us to judge whether the "in an afternoon" claim is plausible.
> 
> In an afternoon from noon to 6pm, there are 6*60*60 seconds. To crack
> a single DES key by brute force, we'd expect to have to search on average
> half the 56-bit key space, performing about 2^55 DES encryptions. So how
> fast would the teenager's computer have to be?
> 
> cpu% hoc
> 2^55/(6*60*60)
> 1667999861989
> 1/_
> 5.995204332976e-13
> 
> 1667 billion DES encryptions per second, or less than a picosecond
> per encryption. I think just enumerating the keys at that speed would
> be quite a challenge for "the average consumer machine" (even with a GPU).
> 
> A bit of googling for actual results on DES brute force brings up
> https://www.sciencedirect.com/science/article/abs/pii/S138376212266
> from March 2022, which says:
>  "Our best optimizations provided 3.87 billion key searches per second for 
> Des/3des
>  ... on an RTX 3070 GPU."
> 
> So even with a GPU, the expected time to crack a random 56-bit key would be
> something like:
> 
> cpu% hoc
> 2^55/3.87e9
> 9309766.671567
> _/(60*60*24)
> 107.7519290691
> 
> More than three months. The same paper mentions someone else's purpose-built
> machine called RIVYERA which "uses 128 Xilinx Spartan-6 LX150 FPGAs ... 
> can try 691 billion Des keys in a second ... costs around 100,000 Euros".
> Still not quite fast enough to break a key in an afternoon.

>From what I found online a GTX 4090 has a single DES hash rate of 146.6 GH/s

cpu% hoc
2^55/146.6e9
245762.599038
_/(60*60*24)
2.8444745259

So Dan's guess of a couple of days is more accurate then Ori's hyperbole, but 
not by much.

> 
> When Jacob says "triple DES is not computationally hard to brute force these 
> days",
> I assume this is just a slip of the keyboard, since p9sk1 uses only single 
> DES.
> But if we are worried about the shaky foundations of p9sk1 being based on
> single DES, Occam's Razor indicates that we should look for the minimal and 
> simplest
> possible extension to p9sk1 to mitigate the brute force threat. The manual 
> entry for
> des(2) suggests that the Plan 9 authors were already thinking along these 
> lines:
> 
>  BUGS
>   Single DES can be realistically 

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

[Jacob Moody]

I've gone ahead and made a repository[0] for an up to
date fossil* for 9front. I didn't have to do more then
clone the 4e repository, apply the 9legacy patches and
type mk. Took all of 10 minutes. Testing is left as
an exercise for the reader.

* No warranty given or implied.
[0] http://only9fans.com/moody/fossil/HEAD/info.html

On 5/11/24 19:43, o...@eigenstate.org wrote:
> As far as I can tell, 9front doesn't have a problem
> on this side; we just imported the Power64 compilers,
> have working versions of risc64, etc, all pulled in
> from the 9legacy world.
> 
> The work to port usually ranges between negligible
> and trivial.
> 
> As far as I can tell, the only thing preventing 9front
> changes from making their way back to 9legacy is a lack
> of hands to do the work.
> 
> And while I'm happy to lend a hand, help debug, and even
> make trivial changes to enhance portability, I personally
> don't care to spend time porting software to a system I
> don't intend to use.
> 
> 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.
> 
> Quoth vic.thac...@fastmail.fm:
>> Perhaps adopting this mindset could be beneficial. When developing a 
>> feature, it's worth considering its potential for portability and usefulness 
>> to other communities.
>>
>> Vic
>>
>> On Sun, May 12, 2024, at 07:27, hiro wrote:
>>> just send the code then
>>>
>>> On Sun, May 12, 2024 at 12:22 AM  wrote:

 Let me explain my intent and elaborate on my point of view.  I started a 
 new thread to enhance the signal-to-noise ratio. It's easy for a thread to 
 become cluttered with multiple issues, so I believe creating separate 
 threads for distinct concerns helps streamline communication and keeps 
 discussions focused.

 As a hobbyist, I see we all share a passion for Plan 9 and its 
 development.  Enhancing collaboration between communities would benefit 
 everyone involved, and potentially enhance decorum on 9fans.  I am curious 
 to gauge whether there is any interest in activities that could facilitate 
 positive teamwork, foster stronger connections, and break down barriers 
 between communities.

 Fostering discord among communities seems to only perpetuate more discord. 
  In my mind, seeking to improve collaboration between communities seemed, 
 and still seems, worthwhile.

 As a hobbyist, I find myself pondering: What motivates individuals to 
 participate in 9fans if not for a genuine interest in supporting the Plan 
 9 community?

 Vic


 On Sun, May 12, 2024, at 01:26, hiro wrote:
> congrats for teaching the bot to create more email threads with new
> subjects. just what we need as a community.
>
> On Fri, May 10, 2024 at 4:55 PM Lucio De Re  wrote:
>>
>> I guess we're on the same page, right up and including the fist 
>> fight(s). But I think we are all entitled to be treated more courteously 
>> in a public forum such as this, including not ascribing malice unless it 
>> is explicit. Being touchy has plagued this forum just about forever, it 
>> would be nicer if instead of calling out bad behaviour, it got the 
>> benefit of the doubt. I accept that I was as guilty of that presumption 
>> as much as anyone who posted after me.
>>
>> Lucio.
>>
>> On Fri, May 10, 2024 at 3:39 PM  wrote:

 What I notice - correct me if I am mistaken - is that any comparison 
 between 9front and 9legacy seems to needle a few members (very few, 
 there are many names from that community that have not participated, 
 specifically the ones I know hand have long respectes, ask them) of 
 the 9front community that seem to take offence unless 9front is 
 painted in a better light. I guess that's permissible, but please mind 
 your manners if you choose to go that route, this is 9fans and 9front 
 I believe has its own discussion groups.

>>>
>>> I offer you the perspective that this happens by rule when obviously 
>>> wrong
>>> or ridicolous claims or demands about / of 9front are made.
>>> This is seen to further degrade the already quite degraded perspective
>>> it has within parts of the 9fans community.
>>>
>>> I don't think it is unreasonable for people who have invested a lot of 
>>> effort
>>> into 9front and believe it to be something worthwhile to feel the 
>>> urgency to
>>> defend it, or at the very least talk about it.
>>>
>>> I do think a bit more courtesy or less bad faith assumptions could
>>> be prescribed to certain individuals, and not only on the 9front side.
>>>
>>> Anyway, I propose such issues are best solved by a fist fight, therefore
>>> acknowledging the legacy of dispute resolution methods of our 

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

[Jacob Moody]

On 5/11/24 14:59, Dan Cross wrote:
> On Sat, May 11, 2024 at 3:36 PM hiro <23h...@gmail.com> wrote:
>>> explanation of dp9ik, which while useful, only
>>> addresses what (I believe) Richard was referring to in passing, simply
>>> noting the small key size of DES and how the shared secret is
>>> vulnerable to dictionary attacks.
>>
>> i don't remember what richard was mentioning, but the small key size
>> wasn't the only issue, the second issue is that this can be done
>> completely offline. why do you say "only", what do you think is
>> missing that should have been documented in addition to that?
> 
> Probably how a random teenager could break it in an afternoon. :-)

If we agree that:

1) p9sk1 allows the shared secret to be brute-forced offline.
2) The average consumer machine is fast enough to make a large amount of 
attempts in a short time,
   in other words triple DES is not computationally hard to brute force these 
days.

I don't know how you don't see how this is trivial to do.
A teenager can learn to download hashcat, all that is missing from this right 
now is some python
script to get the encrypted shared secret from a running p9sk1 server. All the 
code for doing
this is already written in C as part of the distribution, you just have to only 
do half the
negotiation and break out. I think you vastly underestimate the resourcefulness 
of teenagers.

I had previously stated I would publish the PoC that friends of mine in 
university built
as part of their class, I have been asked to not do that so I will not.

- moody


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

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

[Jacob Moody]

For the sake of time I am going to just reply here after
reading all of the existing thread

On 5/10/24 03:17, Lucio De Re wrote:
>> why don't you just let 9legacy die?
> 
> You are not paying attention: I have a multi-gigabyte commitment to Fossil. I 
> am not convinced *I* could "just port" Fossil to 9front (if it was all that 
> easy, why was it discarded entirely?) and I don't have the hardware to 
> migrate the data to a different disk representation. In fact, I can't even 
> justify attempting to migrate my setup to P9P under Linux (or NetBSD, which 
> is my preferred POSIX flavour) where Fossil may be better supported than 
> under 9front. And if the question "why don't you
> just let 9legacy die?" has any validity, then Windows or Linux could be said 
> to justify the analogous "why don't you just let 9front die?"
> 
> Hiro, if there was no conflict, in the sense of an hostile attitude, then 
> Moodly would not have accused me of being lazy in a public forum. Nor would 
> you consider it good manners in the same forum to demand that people should 
> follow some "true way" as you suggest. That's where Vic's attitude is so much 
> less antagonistic than your own. And I have believed since I first met Cinap 
> in Greece in 2008 that neither he nor his development colleagues share your 
> attitude. You may br factually right, but
> that is really not enough.
> 

My intention was to not call you lazy, I was trying to communicate that if the 
system is not doing what you want and you would like someone else to fix
that for you there are better ways of doing so then being snide about the 
interoperability between 9front and 9legacy. Had the conversation been
"I need help doing this with 9front" without the finger pointing I would have 
been happy to sit down and point you in the right direction without retorting.

Fossil was removed long before my time in 9front, it was removed because it 
kept eating people's data and the maintainers at the time did not want to deal
with it when we have perfectly good alternatives. So what Charles says is right 
on the money. I agree that for your specific usecase (and anyone else
migrating from 9legacy) this is less than ideal. As kvik and qwx both mentioned 
there are places where you can find find a "ready to go" fossil for
use with 9front, please try that and come back to us with specific questions. 
However I am telling you now that your request for fossil to be included
again just because it helps you out personally is not going to convince anyone. 
The system (and us as part of its maintainers) do not exist
to service you individually, sorry. We've pointed you in the right direction 
and your response of "that's over my head so I wont even try" is frustrating.
If you have specific questions of how to get started with things, or issues we 
can likely advise.

I will add that 9front does still support p9sk1, that code was not removed from 
the system.
If you are using 9front as the auth server you need to pass an additional flag 
to authsrv(6) to allow
it to respond to p9sk1 queries. I don't know why your setup is not working as 
is, but I don't have any
interest in standing up a similar environment in attempts to reproduce the 
issue.

Good luck


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

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

[Jacob Moody]

On 5/10/24 05:58, Richard Miller wrote:
>> From: o...@eigenstate.org
>> ...
>> keep in mind that it can literally be brute forced in an
>> afternoon by a teenager; even a gpu isn't needed to do
>> this in a reasonable amount of time.
> 
> [citation needed]
> 

Two people have independently broken the encryption, there has been a lack of 
publication
about it out of a matter of respect, but if it that is what it takes I will be 
putting the
proof of concept online later today.




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

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

[Jacob Moody]

On 5/8/24 11:06, Lucio De Re wrote:
> There is much I would like to explain, but the problem I am attempting to 
> solve ought to have an obvious answer that I am clearly missing.
> 
> I can't seem to get a 9front workstation to mount a networked 9legacy fossil 
> service. The FS is a fairly pristine 9legacy installation, on a somewhat old 
> 386 platform. I did need to tweak various parameters on both side, but 
> eventually I got to the point where both hosts declare that the connection 
> has been established; now on the 9front workstation I get the message
>     "srv net!192.96.33.148!9fs: mount failed: fossil authCheck: auth protocol 
> not finished"
> I suspect the culprit is the lack of the newer "dp9ik" security on 9legacy, 
> in which case it would be helpful to know how to work around that.

Probably. Why not just temporarily disable auth checks for the fossil 9legacy 
machine?
Or perhaps just take a disk/mkfs backup and tar that. You really have chosen 
the most painful way of accomplishing this (which you seem to acknowledge).
Or just exportfs the root? There are so many ways of just getting the files.

> 
> Why am I mixing my platforms like this? Because the hardware on which I am 
> attempting to recover a rather large historical file system is split between 
> IDE and SATA and I have no hardware that can handle both disk modes and I 
> need to move information between the two media types. I am not describing all 
> the dead ends I tried, incidentally, that would take too long and really 
> expose my limited understanding.
> 
> It took almost a day to copy the Fossil cache (or lose a lot of the most 
> recent changes) and now I need (or at least want) to update the default boot 
> ("arenas") Venti configuration on a SATA drive which I can only access on 
> hardware I can't install 9legacy on. It's complicated and I'm sure there are 
> people here who would not find this so daunting, but that's where I am at. To 
> be precise, I need to change the Fossil default configuration (in the 
> "fossil" cache) so it points to the correct Venti
> arenas. I'll deal with the analogous Venti situation when I get past the 
> total absence of Fossil tools on 9front.
> 
> I guess I can port fossil/conf to 9front, but I'm not sure I have the stomach 
> to try that. Maybe now that I have raised the possibility...

It sound like you're trying to make this someone else's problem.
Being stuck in a hardware pickle when there are ample existing software 
solutions is not
a good reason to ask someone else to go out of their way to write software.

Fossil can be pulled in largely without modifications as I understand it,
I don't run fossil but some people in the 9front community do and it does
not appear to me that they've had issues with continuing to have it work
(other then fossil bugs itself).

> 
> I managed to share the Fossil cache through a NetBSD server providing u9fs 
> services, but that host does not have the capacity to store the Venti arenas, 
> nor can I really justify spending the amount of time it would take to pass it 
> between the 9legacy and 9front devices via NetBSD, no matter how I try to 
> arrange that. It does baffle me, though, that a NetBSD intermediary is more 
> competent than the two "native" platforms.

Are you blaming us for moving on from AES 53 bit keys that can be brute forced 
in an afternoon?
I have tried to open a dialogue for getting dp9ik on 9legacy a couple times 
now, when I had brought it
up I am told to write the patch. Something about being asked to spend the work 
to write a patch for 9legacy given
the historical context of why 9front exists does not sit right with me. So it 
wont be me, sorry.
Sure it sucks that things have drifted, but all our code is there, neatly 
organized out in to commits, if someone
wants to import our work it is readily available. However something tells me 
most people are just going to use 9front as is.


Good luck,
moody


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

Re: [9fans] drawterm factotum interference in 9front

[Jacob Moody]

On 4/30/24 13:57, wb.kl...@gmail.com wrote:
> BTW. I would like to see a way to build a drawterm without gui, as installing 
> X11 libs for nothing else than compiling a drawterm on a remote server is 
> annoying. My main application of  drawterm -g is exporting factotum from a 
> 9front system, as plan9port factotum does not support dp9ik.

This is in part why I wrote tlsclient: https://github.com/majiru/tlsclient


Thanks,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T132487c88905c339-M9167f6811d24c3bc885b2942
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Jacob Moody]

On 4/18/24 16:48, Shawn Rutledge wrote:
> Interesting that it's Rust.  Just another reason to eventually have Rust on 
> Plan 9…
Has anyone done any work on this? I know someone technically got stuff running 
using a
webasm intermediate, but I am curious if anyone has scoped out what it would 
look like
to do a proper port.

Cross compiling from some linux to a plan 9 a.out and bootstrapping that way 
seems to be the most likely.


Thanks,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M91204b3fe12de0a3f6c04660
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Jacob Moody]

On 4/18/24 10:54, certanan via 9fans wrote:
> Hi,
> 
> is there any more "organic/natural" way to do source control on today's Plan9 
> (9front specifically), other than Ori's Git?
> 
> In other words, how (if at all) did people at Bell Labs and the community 
> alike originally manage their contributions in a way that would allow them to 
> create patches without much hassle?
> 
> Was it as simple as backing a source tree up, making some changes, and then 
> comparing the two? Venti? Replica?

Perhaps worth mentioning that before git 9front used mecurial for VCS, but I 
don't think that answers your question.
>From what I understand folks used to make diffs against the last release. 
>There was also some use of replica as you eluded to.


Thanks,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M9dd2ab1b9959fd2af34615b8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Hello, RPi fixes and bind -b trouble

[Jacob Moody]

Responses in-line.

On 2/23/24 06:12, Alyssa M via 9fans wrote:
> (Lucio posted while I've been thinking/composing/trying things...)
> 
> Thanks for putting up with me!

No, thank you for your thoughts and helping test.

> 
> I confess I've been thinking about this a bit more, as something about this 
> doesn't feel right:
> 
> As I understand it, the kernel is getting an error string from some file 
> server, and is decorating it with a filename/pathname for the benefit of the 
> user, then returning it to userspace through errstr(2).
> exportfs(4) is then sending the decorated error string out to whatever mounts 
> it.
> 
> But, another machine that mounts that exported file system will then decorate 
> it a second time... If that composite file system is exported to a third 
> computer, then that system will mount it and its kernel will decorate it a 
> third time...
> 
> This being plan 9, you can do this all on the same machine, so I tried it.
> In each  window I typed/snarfed/pasted something like:
> term% srv tcp!themachine!9123 step1
> term% mount /srv/step1 /power
> term% aux/listen1 -t tcp!*!9124 /bin/service/tcp5564
> 
> (/power is just a handy unused directory to mount on. ;))
> 
> /bin/service/tcp5564 above is:
> #!/bin/rc
> exec /bin/exportfs -r /
> 
> I created 3 windows, each mounting a composite file system exported from the 
> previous one (by advancing the port numbers and srv names I used above). And 
> sure enough, the error message strings get longer and longer!
> 
> Eventually I got:
> term% echo >/lib
> /fd/0:10: > can't create: lib: is a directory: './power/lib': 
> './power/power/lib': './power/power/power/lib': 'lib'

Oh dear yes that does seem to be a bit of an issue.

> 
> I had to generate an 'is a directory' error to see this, rather than a 'file 
> not found' error, as the latter seems to get treated a bit differently, and 
> doesn't show this concatenative effect.

I am curious as to why this was treated differently, can't recall off the top 
of my head.

> 
> This seems a bit daft.
> I was thinking that maybe exportfs should be stripping off the filename 
> decoration after all: I'm not sure I can think of a scenario where sending it 
> through Rerror is helpful.
> 
> but this still doesn't feel right.
> 
> exportfs is having to remove a decoration on an error string that the kernel 
> added for the benefit of the user. I think the kernel should probably not be 
> doing this. The outcome is nice, but maybe it would be better if it were done 
> in libc, perhaps in the implementation of %r. Maybe the system call functions 
> in user space could record the pathname in a global buffer when an error 
> occurs, and %r could use that.
> Exportfs could then forward the error string without the kernel decorating 
> it, and we could leave Linux v9fs alone.
> Would that be better?

Maybe? It's hard to tell without looking at a patch that does this. It seems 
like the end result would be the same. Exportfs is chucking the resulting
errstr across the network. So whether set by libc or the kernel doesn't make 
much of a difference. I am also not entirely sure that having an extra
"opt-in" step is the correct thing to do here.  If there were to be a way 
around these problems then perhaps it would be worth pursuing.
> 
> 
> Although English is my first language, I live among people for whom it mostly 
> isn't, so I see these issues every day. There's definitely a tension between 
> the obvious practicality of using English as a "Lingua Franca" and not 
> wanting to lose other languages, which is important to some people. The whole 
> internationalisation thing is complicated and political, and thus hopefully 
> something we can ignore here most of the time! I probably shouldn't have 
> mentioned it.  :D

Yes that is a tough question. I have spent a lot of time thinking about 
language support on 9front. What I would like first before "localization" of
things like error messages is just to be able to input and display the 
multitude of languages that people use. Right now we are not so great about 
this.
Some of the work I've done for 9front has helped improve this, we have more 
aware unicode routines with respect to word breaks, line breaks, and grapheme
breaks. Ktrans has been included and expanded to cover some chinese input 
methods. However the system still has issues dealing with decomposed unicode,
both in display and input. There are lots of tricky things to get right there 
w.r.t. mouse selection, display and so on that this current code was just
not built for. Part of that problem is the bitmap fonts are just not built for 
this world really either. I find these to be much more pressing and interesting
challenges.


Thanks,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M2affd026483c5a273ee22a92
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Hello, RPi fixes and bind -b trouble

[Jacob Moody]

I apologize I had recalled incorrectly in my previous email on this topic.
We had intentions of fixing this issue with v9fs but only half of the work
was done. 9front changed that specific error in the kernel to suffix the
filename instead of prefix the filename to

A) be more consistent with userspace
B) allow use of strncmp() with the error

The intention was to submit a patch to Linux to change their memcmp()
to use strncmp() to allow this to be recognized. If I recall mcf had
intended to submit said patch but I am unaware of where that went.

In the meantime a hack around in exportfs is probably the best option.

In regards to hjfs, I agree it should probably be brought in line with
this if this is the convention we would like v9fs to use. I will purpose
a patch to change it on the 9front list.


Apologies and thank you,
moody

On 2/22/24 13:45, Alyssa M via 9fans wrote:
> Well, my daughter has kindly given me a couple of her spare raspberry pis - a 
> pi4 and a pi5.
> I've put 9front on the pi4, and have been having a look at it. I had to use 
> the Raspberry Pi Imager program this time. windd didn't work (she thinks this 
> might be a feature of the later Pis). There are 5 computers on my desk now! 
> :) I'm running out of room for my teacup. I have a 2-port kvm, and I could be 
> using drawterm for the Plan 9 installations, but if I do that I won't be 
> motivated to finish implementing a drawterm for my own system...
> 
> I tried mounting a 9front exportfs on Linux, but encountered the same problem 
> I mentioned earlier: the error strings don't match what v9fs on Linux is 
> expecting, with effect that I can't create files from Linux on a file system 
> exported from 9front either. I think the problem is that v9fs tries to open a 
> file before creating it: if it doesn't get an error that it can recognise as 
> corresponding to ENOENT it won't attempt the subsequent create message.
> v9fs currently does an exact match on the error string returned in Rerror and 
> will recognise any of the following strings:
> 
> "No such file or directory"
> "directory entry not found"
> "file does not exist"
> "file not found"
> "illegal path element"
> "directory entry is not allocated"
> 
> as being different ways of saying ENOENT (which has the numeric value of 2). 
> It looks like the 4th Edition kernel prefixes these with the filename in 
> quotes, e.g.:
> 
> "'foo' file does not exist"
> 
> I spoke earlier about my patch to exportfs(4) to get around this.
> On 9front, though, I'm seeing:
> 
> "not found: 'foo'"
> 
> or
> 
> "file does not exist: 'foo'"
> 
> depending on which file system is involved. Even if I apply my exportfs patch 
> to 9front, it looks like hjfs(1) has introduced "not found" as a  new way to 
> say "file does not exist", and v9fs is not going to understand that either... 
> I suppose I could add a special case in exportfs to translate that into "file 
> not found".
> 
> I see several problems:
> The first and most obvious one is that v9fs doesn't cope well with the 
> variety of ways ENOENT gets encoded over 9p. The second is that there seems 
> to be an assumption that:
> a) errors are only ever immediately reported to the user, and
> b) the user speaks English...
> 
> For me, I have a very analogous problem with the 9p client file system 
> adapter on my own OS:
> I'm thinking at this point that I'm going to have to extract the currently 
> fixed strings it recognises into a file (which I can edit to keep up with the 
> times) and also use regular expressions so that the entries in that file can 
> actually pattern-match any embedded quoted filename, allowing for future 
> creativity in the ways it can get inserted into the error string returned via 
> Rerror...
> I'm not sure I quite believe I'm seriously contemplating doing this.
> 
> Perhaps I'm missing something obvious.
> 
> *9fans * / 9fans / see discussions 
>  + participants 
>  + delivery options 
>  Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-Mee427615742065db50311a27
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Jacob Moody]

On 1/25/24 17:38, Don A. Bailey wrote:
> It’s telling that you see a difference of opinion as a temper tantrum. A 
> major problem with people’s perspective of 9front and the current plan 9 
> community, honestly. 

I didn't see it as a tempter tantrum until you stopped replying in good faith 
and started name calling.
I think referring to Noam as "Jung Noam" was perhaps where I mentally drew the 
line, or the
fact that you refused to answer any of my questions and instead responded with 
"Cool Rant"
to our previous thread of discussion.

I _want_ to listen to your difference of opinion, I have, at almost every step 
of the way, asked what your
complaints are. You repeatedly have chosen to avoid my questions and respond in 
bad faith. How
else am I supposed to interpret this?

My email is still open if you want to send me a list of actual complaints with 
9front's code.

- moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M01ecc67d4de8ce02c661089d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Jacob Moody]

On 1/25/24 16:03, Don A. Bailey wrote:
> I’m aware you’re a member of the foundation.
> 
> What I want I think I’ve made clear. I do not want to see a formal release of 
> Plan 9 that includes anything from the 9front project. I do not want 9front 
> merged with what I tongue-in-cheek term “mainline” (9legacy / 9pio updated 
> patch sets). I’d rather 9front stay its own thing. I’m certain there are a 
> lot of relevant contributions within 9front but I think its place is as its 
> own niche system.
> 

Who is going to do the work? Do you want to do the work? Do you think this 
temper tantrum you've been throwing on
this list all day is somehow going to convince anyone else to work with/for you?
It's rich that you feel like you can dictate rules (no 9front code) but have no 
interest in making any effort
yourself to make that a reality.

I await your "better" plan 9.

- moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M76f4757e0b08c42ccd659390
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Jacob Moody]

It doesn't matter if one is "mainline" or not, you've completely missed the 
point of my mail.
One is usable and the other is not. One has a community, the other does not. 
One has people
who share source, there other does not. Put your time where your mouth is and 
do something
about the sorry state of "mainline". Where is the work? Where is the code? 
Again all I see
are snarky comments and bullshit.

Or perhaps you're more interested in hoarding code so you can sit around 
stroking your
ego about ideological purity. Doesn't make any difference to me. Honestly hope 
you do
walk away from Plan 9 because its clear that your attitude sucks.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M095a1f330d5f64d018cbb086
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Jacob Moody]

Do you have specific issues with our code? All I've seen is vague finger 
pointing.
We don't need some authority to point at 9front and say its "mainline", people
see where the effort is going, endorsement or not.

On 1/25/24 10:44, Don Bailey wrote:
> I'm not sure what all this was, so I didn't read most of it. 
> 
> If 9front becomes the "mainline" 9, I will stop using 9 altogether. Both as a 
> user and a developer. 
> 
> I trust the sources that come from 9legacy/9pio but I don't have any interest 
> in the mess of whatever 9front is supposed to be. 
> 
> D
> 
> On Thu, Jan 25, 2024 at 11:40 AM hiro via 9fans <9fans@9fans.net 
> > wrote:
> 
> > I am not a fan of the weird 9front split from the standard repo. I’d 
> prefer the sources to be managed by the foundation and would like to only 
> receive patches through them.
> 
> Are you speaking as part of the foundation? As a developer? Or as a User?
> 
> Me, as a user, I would also appreciate if the foundation (or the real
> bell-labs unix room heritage, before the foundation existed) would
> "manage" something. for example  development and continuous hosting of
> the sources server. This doesn't seem to be the case.
> 
> I also would appreciate the making available of patches by the
> foundation. I have no clue where their codebase is moving in the last
> few years as there was no single commit (or even simple patch via
> email) received from them.
> 
> I think the reason the 9front repo is continuing to stay split "off"
> is because the bell-labs servers have all been shut down. As a result
> the community has stepped in to donate their own time, money, server
> resources, sweat and blood, etc. to keep a usable plan 9 version and
> community (that is willing to stay patches) alive.
> 
> It is extremely unfortunate, but the pressure behind the freely
> contributed code ended up being stronger than the ability to negotiate
> with the empty halls of bell-labs. So as a result lots of community
> members are able to contribute quite effectively.
> 
> To me the legend of what must have been the unix room will always stay
> alive, and I will continue to use it as a benchmark to measure my own
> team's success against. But if I cannot be part of the group of cool
> kids that came out of this, I can at least have my own bell-labs, with
> blackjack and hookers. In my head.
> 
> Don, I wish you great technical collaborations. At least this is what
> I have came here for, and have tried to take what caused awe in me and
> keep them alive and infect others with all that. Maybe you can submit
> another patch to sources some day soon.
> 
> hiro
> 
> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-Md70d852f764bf07113bf0b48
>  
> 
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> 
> 
> *9fans * / 9fans / see discussions 
>  + participants 
>  + delivery options 
>  Permalink 
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M3474b3710be83f926df8fe13
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Jacob Moody]

On 1/25/24 09:35, Don Bailey wrote:
> Direction comes from people writing code... but you write code for 9front, 
> yes? What does that have to do with mainline Plan 9? And what does that have 
> to do with the direction set forth by the people that actually designed it? 

There is no "path for patches" in 9legacy, if I wanted to write code for 
"mainline Plan 9" who do
I send to code to? Who is going to help review and bug test my code. You 
mentioned earlier that
you had ported Plan 9 to other systems, is that code available anywhere, was 
that upstreamed into
"mainline Plan 9". 9front happened, as Ori stated, because there was no path 
forward with "mainline
Plan 9".

When I looked in to Plan 9 some 5ish years ago and looking at both camps of 
folks it was clear to me
that one group was going to look at my patches, work on my hardware, and had an 
active community.

If y'all wanted to set up a pipeline for patches, encourage folks to send in 
their patches and make
some repo for folks to work on then yeah sure. But right now there really isn't 
a comparison between
what "mainline plan 9" is and 9front, one is a museum and the other is a living 
distribution. There is
of course Miller's branch, which I respect as being active and actually usable, 
but I have a feeling you
don't consider that "mainline plan 9" either.

Look man, be the change you want to see in the world, setup the repo, review 
patches, merge new code, et
all. Getting mad at us for writing the code and keeping stuff working is a bit 
silly, especially if your
only reason is that we aren't the "blessed few". Those folks as far as I can 
tell are not interested in
this anymore, we're on our own here. There are clearly some folks interested 
here in continuing "mainline
plan 9" why not work together and get something that is easier for folks to 
use? 9front will continue to
be over here with a ten year plus head start.

- moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-Mac83e1bc119b1da9aafec69e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Jacob Moody]

On 1/24/24 19:53, Don A. Bailey wrote:
> Tbf I took it as genuine. 
> 
> One reason I responded with no is that Rob noted that further 9 releases 
> should not be a release at all, but should be fluid updates through the 
> network. I think if 9 lives on it should be that was, as intended. 

I have a hard time following what "fluid updates through the network" is 
supposed to mean.
If you mean that patches should be made by the community then that is exactly 
what 9front is.

> 
> I am not a fan of the weird 9front split from the standard repo. I’d prefer 
> the sources to be managed by the foundation and would like to only receive 
> patches through them. 

Why do you dislike 9front? 9front works with the foundation, we have a regular 
committer who is directly
in the foundation.

>> On Jan 24, 2024, at 8:50 PM, vic.thac...@fastmail.fm wrote:
>>
>> To clarify, my message represented a genuine exploration of the idea of 
>> envisioning a new release.
>>
>> --vic

9front is exactly what you're envisioning, we keep the system up to date to 
keep it working in the
modern world. Modern hardware support, modern compatibility with software as 
required, all this stuff.

I don't know where you folks think the code is going to come from, there really 
isn't that much activity
outside of 9front. If you want to personally take up the lead and fix 
everything bug-for-bug starting
again from 4e or 9legacy be my guest. But all I see here is asking for others 
to do the work.

- moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M6cbc90c73e5f1ff9ed6c5258
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Supported Notebooks

[Jacob Moody]

On 1/24/24 14:28, Michael Grunditz wrote:
> I have looked at the reform code and I like how it is done. I think that it 
> would be easy to use for porting 9legacy or in fact any system. But it is 
> more work than a recompile.
> 
> Michael 

It is certainly not drag and drop. Getting the arm64 compiler and linker 
working on
9legacy is already not what I would consider trivial due to drift in 
/sys/src/cmd/cc.
So yes if you have enough understanding on how to work with and debug the 
compiler, the linker, and
the kernel then perhaps you could call it "easy". I'll believe it when I see it.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T724dd319036f59d3-M495d507e61f64a8d7f97b074
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Supported Notebooks

[Jacob Moody]

On 1/24/24 09:47, alex...@posteo.de wrote:
> Hello everyone,
> 
> I would like to know which hardware (apart from the hardware listed here: 
> https://plan9.io/wiki/plan9/Supported_PC_hardware/index.html 
> ) is supported 
> by Plan 9. Is there any experience, especially with regard to other Thinkpad 
> models?
> 
> 9front even runs on the MNT Reform, would the corresponding code be easily 
> transferable to 9legacy?

It is likely transferable but it will certainly not be easy, the code has 
drifted quite a bit at this point.
I would suggest giving 9front a try first, but it sounds like you have already 
ruled that out.


Thanks,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T724dd319036f59d3-M66908ce5c382ef598ed46645
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] programs from UNI*x

[Jacob Moody]

On 6/28/23 10:09, arn...@skeeve.com wrote:
> I'd love to know if gawk can be made to work on Plan 9.
> Latest release is at https://ftp.gnu.org/gnu/gawk/
> 
> Or you can clone the git repo.
> 
> Thanks,
> 
> Arnold

whats the issue with the awk we already have?



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T3e60a159b1280462-M3474ba713e0fae065eb3ea5e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] How do I build from source on linux?

[Jacob Moody]

On 6/15/23 12:46, dusan3...@gmail.com wrote:
> Research

Research of what exactly? You've already seemingly written off the interface.

To quote utah2000:

"New employees in our lab now bring their world with them, or expect it to be 
there when they arrive. That's reasonable, but there was a time when joining a 
new lab was a chance to explore new ways of working.
Narrowness of experience leads to narrowness of imagination."


- moody

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5b2523de4ef223e9-Mc02ff751815320976b40c4ee
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] access files from 9front to Linux on the same laptop (2 harddrives).

[Jacob Moody]

On 6/12/23 09:29, pl...@room3420.net wrote:
> 
> Hello :)
> 
> Let's say I have 2 computers.
> I can "sshfs" from 9front to mount the distant (Linux) folders to /n/ssh.
> 
> Let's say now that I have 2 SSD on my laptop.
> One with 9front, that boots automatically and one with
> Linux, that I can occasionally select at boot with GRUB.
> 
> Is there a way to mount the Linux partitions from 9front, to transfer files ?
> 
> On 9front, 9front is labeled as /dev/sdE0 and Linux is /dev/sdE2.
> 
> As I'm only testing, the Linux is not currently encrypted.
> 
> Hope that's not a moronic question and thank you for any feedback.
> *9fans * / 9fans / see discussions 
>  + participants 
>  + delivery options 
>  Permalink 
> 

If your linux just uses ext[2-4], you can maybe use sigrid's 
https://git.sr.ht/~ft/ext4srv
If you are doing anything more (like encryption or lvm) you're likely on your 
own.

-
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T094e3f9c85c36a40-Mcd92c235ef478754862d949e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Wifi Firmware "does not exist", but it does.

[Jacob Moody]

On 4/10/23 08:07, Ravi Raj wrote:
> Hi
> 
> I believe the mentioned step in your reply is for systems with a local disk.
> 
> I am using live USB with hjfs.

Explain to me then how your usb install boots a kernel without a 9fat.
You likely have an incorrect assumption here. But I don't know, you
may have some boutique setup now.

Again I don't know why you are making things hard for yourself. If you
want to stray off the beaten path that's totally fine, but don't make
it everyone else's problem. I warned you about this.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9b33abcfc0b8784b-Ma0a0dec510f1bc89a8b73fa3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Wifi Firmware "does not exist", but it does.

[Jacob Moody]

On 4/3/23 10:56, Ravi Raj wrote:
> Hi
> 
> Is recompiling kernel same as installing new kernel ?
> 
> What is the command to recompile the kernel?

https://fqa.9front.org/fqa5.html#5.2.2
https://fqa.9front.org/fqa7.html#7.2.5


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9b33abcfc0b8784b-M6bac788beafbbebbbfb5902c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Wifi Firmware "does not exist", but it does.

[Jacob Moody]

On 3/24/23 08:01, Ravi Raj wrote:
> Hi
> 
> Many thanks for your suggestion. For now, i plan to use live usb!
> 
> Is it possible to create persistence on live USB? Web search reveals nothing. 
> 
> If it's possible, can someone please point me to the relevant procedures.
> 

I will not give instructions because I do not want to endorse or support a 
setup like this.
If you are choosing to not listen to my advice then you are on your own.

Good Luck!
Jacob Moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9b33abcfc0b8784b-M555dc8030e16769d17e27a84
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Wifi Firmware "does not exist", but it does.

[Jacob Moody]

On 3/23/23 10:15, Ravi Raj wrote:
> Hi
> 
> Do not have additional hardware (spare workstation).
> 
> Can i create a persistence to store the settings(which remains in live USB 
> between reboots)?
> 
> Thanks
> rraj

Using a USB stick as a root filesystem is not something I would recommend.
If you're adamant on doing so it can be done, but I would advise figuring
out another solution. There are plenty of ways to go about fitting multiple
operating systems on the same disk or machine.

If you are stuck with a single machine perhaps using the system within
a virtual machine paired with drawterm would be less of hassle given
your constraints? If your goal is just to do some exploration this
would be a fine way to just get going and not worry about this magical
chair situation.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9b33abcfc0b8784b-M25e74a4053bd5e1f77b7bde2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] temp of remote machine with stats

[Jacob Moody]

On 3/22/23 22:15, jimeric...@gmail.com wrote:
> i spoke to soon. it works perfectly on my amd64 machines but not on my 
> raspberry pi 4. what could i be doing wrong? or is the pi missing something?

A quick grep seems to indicate that devarch was never implemented for the bcm64 
kernel.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td46dc64ab1f12bcf-M9010b51a00d30f0ecd40005c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] temp of remote machine with stats

[Jacob Moody]

On 3/22/23 18:39, jimeric...@gmail.com wrote:
> i am using stats to monitor a remote machine i have. i can get all the stats 
> except temp. i have 'bind -a '#P' /dev' in lib/profile on both machines. how 
> can i get the temp of the remote machine? thank you for your time.
> *9fans * / 9fans / see discussions 
>  + participants 
>  + delivery options 
>  Permalink 
> 

Stats(1) uses rimport to access files from the remote machine.
rimport does not run your lib/profile, so when it goes to
read the remote cputemp file it is not there.

This is a case for the /cfg/$sysname/namespace file I believe.
Create this file on your machines with the

bind -a #P /dev

line in them. Make sure to have the file end in a newline.
This /cfg/$sysname/namespace is sourced by /lib/namespace, which
is used to, among other things, construct the namespace that rimport will see.
See namespace(6) for more of a description of the namespace file format.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td46dc64ab1f12bcf-M6090e16b7c5cdbe7a2b8ba63
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Wifi Firmware "does not exist", but it does.

[Jacob Moody]

On 3/22/23 11:14, Ravi Raj wrote:
> Hi
> Facing a similar issue with intel wireless firmware 7265, on Thinkpad E450. 
> Plan to use 9front as live usb to learn.
> Found firmware @ 
> https://github.com/OpenIntelWireless/itlwm/blob/master/itlwm/firmware/iwm-7265-17
>  
> .
> Unable to copy file in /lib/firmware as usb is categorized as read-only!
> 
> What to do?


I would recommend installing the system first.
You can do this by running 'inst/start' from a rc window within the live usb.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9b33abcfc0b8784b-M4fb15bd5f73d79b1aaef25df
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Wifi Firmware "does not exist", but it does.

[Jacob Moody]

On 3/21/23 05:24, Yury Chumak wrote:
> Same situation with the same wifi-card.
> % pci -v

I don't believe the situation is the same.
You are unable to associate with the access point,
which was not the same issue as our other friend here.

> ...
> 3.0.0: net  02.80.00 8086/08b1 4 0:a314 8192
> Intel Corporation Wireless 7260
> 
> Firmware added and kernel rebuilded. Command:
> % aux/wpa -p2 -s vega3 /net/ether1
> 
> asking password, returns '!' and exits. But next command ip/ipconfig returns:
> 
> ipconfig: no success with DHCP
> 
> DHCP is ok. It works good with other devices. DHCP-logs on server side
> have not requests with wifi-card mac-address.
> Trying to connect to mobile phone configured as hotspot takes the same
> result - no success with DHCP.
> Manual configuring:
> % ip/ipconfig -g 192.168.7.1 ether /net/ether1 192.168.7.23 255.255.255.0
> 
> also not solve the situaton - ip/ping says about  lost packets..
> % cat /net/ether1/ifstats
> essid: vega3
> bssid: 045ea4e8e2ac
> status: unassociated
> channel: 06
> brsne: .
> .
> ..big list of available wifi-networks
> 
> Tried also configure hotspot as open network, without authorization -
> same result, doesn't connect.
> 
> What could be the problem??
> 


The issue is stated in the ifstats output:
> status: unassociated

This is the failure mode I would expect if your wpa password was incorrect.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9b33abcfc0b8784b-M927cd981bb1b69915cc58f34
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Wifi Firmware "does not exist", but it does.

[Jacob Moody]

On 3/21/23 00:08, zxcdew...@gmail.com wrote:
> Ok...I recompiled the kernel...and I am getting this message...
> 
>> #l1: firmware:  iwm-7260-17, rev 11, build 3216344376, size [3] 14000+2c000 
>> + [3] 14000+2c000 + 0
>> iwl: no calibration results
> 
> I then try the following...but get no result.
>> term%  bind -a '#l1' /net
>> term%  aux/wpa -2 -s MYHOMEWIFI -p /net/ether1

Just one more step.

% ip/ipconfig ether /net/ether1

will do dhcp on the interface.
aux/wpa only associates with the access point.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9b33abcfc0b8784b-Ma33907f15ed59eb26bf8972b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB drive boot hangs

[Jacob Moody]

On 3/20/23 12:04, Ravi Raj wrote:
> Hi Jacob
> 
> Looks like 9front is subset of plan9?
> 

It is a fork.


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te9a4a2ad5a90ee13-M1a54d5b70c0e626b8a078ed5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB drive boot hangs

[Jacob Moody]

On 3/20/23 09:37, Ravi Raj wrote:
> Hi
> 
> Any clues?
> 
> Thanks
> rraj

If you want hardware compatibility, 9front may be a better choice for what 
you're trying to do.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te9a4a2ad5a90ee13-Mcab58e0c7ff846f7c24485d2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Wifi Firmware "does not exist", but it does.

[Jacob Moody]

On 3/20/23 09:21, zxcdew...@gmail.com wrote:
> Hi, Plan9 newbie here. 
> 
> I downloaded the iwm firmware from OpenBSD and put it in /lib/firmware.
> The /dev/kmesg shows...
> #l1: '/lib/firmware/iwm-7260-17' does not exist
> 
> But it does.  What am I doing wrong?
> 
> Thanks!

After placing the file there, you need to rebuild and reinstall the kernel.
This puts the firmware in the paqfs, allowing the kernel to see it before
a root filesystem is mounted.



--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9b33abcfc0b8784b-M5883b3788e15004f85e880ee
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] plan 9 and lisp

[Jacob Moody]

On 1/19/23 11:26, Csepp wrote:
> 
> o...@eigenstate.org writes:
> 
>> Quoth Lassi Kortela :
 i’m wondering what 9fans think about lisp, specifically scheme.
>>>
>>> Chibi-Scheme has run on Plan 9.
>>>
>>
>> And more recently, Janet:
>>
>> https://git.sr.ht/~pixelherodev/janet
>>
> 
> In that vein, you can also use one of the Lua packages/ports with Fennel.
> 

Might also be worth mentioning here as well, but I did some work to get
a variant of clojure written in go running under 9front. As far as I know
it should still work.

https://github.com/candid82/joker


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7b0afbefb53189b6-M11a31c36f061c0d668f9f4be
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Trouble compiling "Hello, world"

[Jacob Moody]

On 8/1/22 15:18, Jag Talon wrote:
> Ah thanks for the tip. I ran `echo $objtype` and it says amd64. I believe 6c 
> is the compiler that I need but it seems to say another error: `??none??: 
> cannot open file: /amd64/lib/libc.a`

It's telling you exactly what is wrong, you are missing an amd64 libc archive.
I am not sure how you wound up with running an amd64 kernel with an incomplete
amd64 install. For building libc again:

cd /sys/src/libc/ && mk install && mk clean

However, you may be missing more then just libc, in that case may just be best 
to rebuild
the whole system as a second resort.

cd /sys/src/ && mk install && mk clean


How did you install this system? Did you bootstrap yourself
up from 386?


--
moody

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te178b97d94173ff8-Mb5347e194b8afbd0967d8a38
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Trouble compiling "Hello, world"

[Jacob Moody]

You would get that if you are using the wrong compilers for your architecture.
Check the output of $objtype, unless it's 386 you're using the wrong compilers.
2c(1) should have the full list of compilers.


--
moody

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Te178b97d94173ff8-Mef3f8baf231dacf25ad52ba9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: ctrans - Chinese language input for Plan9

[Jacob Moody]

On 7/22/22 12:06, Sebastian Higgins wrote:
> A few things:
> 
> 1.  Cangjie is still widely used in places that uses traditional Chinese 
> characters. You would still be required to be good at it if you apply for 
> text-heavy office jobs in these places.
> 2.  Radical-based/shape-based methods were extremely popular when the 
> prediction technology wasn't as good (which means Pinyin was significantly 
> slower). It wasn't until late 2000s to early 2010s before this situation has 
> changed.
> 3.  Pinyin without prediction is slow because of what we called the 重码 (lit. 
> "overlap of encoding") problem. For Pinyin the encoding overlaps because many 
> characters may have the same Pinyin; the purpose of all shape-based method is 
> to reduce the overlap problem and thus increase the input speed.
> 4.  ctrans uses cangjie because (1) implementing shape-based methods was 
> much, much more simpler than phonetic-based methods because most (if not all) 
> of the job is table lookup; (2) if we were to use the same UI (or lack 
> thereof) as ktrans the overlap-of-encoding problem of Pinyin would very 
> probably drive you nuts when using it; (3) it is the input method the author 
> uses, however I do admit using Cangjie for simplified Chinese input is kinda 
> peculiar.
> 
> Source: me who is a native Chinese speaker and have learned Wubi (a 
> shape-based method for simplified Chinese) in primary school.

I had taken a naive attempt at trying getting ktrans to support a form
of Chinese input. Admitably, my interest was mostly in stress testing
my rewrite of the hashmap used in ktrans, throwing a ~100k character
dictionary at it seemed like a fun way to test it. The dictionary I
imported was one that used Wubi based mapping for charters, posted
by jxy to the 9front mailing list a week or so ago.

If anyone is curious the dictionary itself can be found here:
https://raw.githubusercontent.com/fcitx/fcitx-table-data/master/wbx.txt

This has been super interesting to me from a learning perspective.

Thanks for the insight!
Jacob Moody

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tba6835d445e07919-Mcf3888dbfc4013192d8c471e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[Jacob Moody]

On 6/18/22 23:54, adr wrote:
> On Sat, 18 Jun 2022, Jacob Moody wrote:
>> I've attempted to reproduce it, trying to remove the libthread/notify
>> factors. I've come up with this:
>>
>> #include 
>> #include 
>>
>> static void
>> proc_udp(void*)
>> {
>>char resp[512];
>>char req[] = "request";
>>int fd;
>>int n;
>>int pid;
>>
>>fd = dial("udp!185.157.221.201!5678", nil, nil, nil);
>>if(fd < 0)
>>exits("can't dial");
>>
>>if(write(fd, req, strlen(req)) != strlen(req))
>>exits("can't write");
>>
>>pid = getpid();
>>fprint(1, "start %d\n", pid);
>>n = read(fd, resp, sizeof(resp)-1);
>>fprint(1, "end %d %d\n", pid, n);
>>exits(nil);
>> }
>>
>> void
>> main(int, char**)
>> {
>>int i;
>>Waitmsg *wm;
>>
>>for(i = 0; i < 10; i++){
>>switch(fork()){
>>case -1:
>>sysfatal("fork %r");
>>case 0:
>>proc_udp(nil);
>>sysfatal("ret");
>>default:
>>break;
>>}
>>}
>>for(i = 0; i < 10; i++){
>>wm = wait();
>>print("proc %d died with message %s\n", wm->pid, wm->msg);
>>}
>>exits(nil);
>> }
>>
>> This code makes it pretty obvious that we are losing some children;
>> on my machine this program never exits. I see some portion of the
>> readers correctly returning -1, and the parent is able to get their
>> Waitmsg but not all of them.
> 
> Moody I think this old thread will interest you:
> 
> https://marc.info/?t=11273092041=1=2
> 
> Russ Cox explained there:
>   It appears that your program, at its core, it is doing this:
> 
>   void
>   readproc(void *v)
>   {
>   int fd;
>   char buf[100];
>   fd = (int)v;
>   read(fd, buf, sizeof buf);
>   }
> 
>   void
>   threadmain(int argc, char **argv)
>   {
>   int p[2];
>   pipe(p);
>   proccreate(readproc, (void*)p[0], 8192);
>   proccreate(readproc, (void*)p[1], 8192);
>   close(p[0]);
>   /* and here you expect the first readproc to be done */
>   close(p[1]);
>   /* and here the second */
>   }
> 
>   Each read call is holding up a reference to its channel
>   inside the kernel, so that even though you've closed the fd
>   and removed the ref from the fd table, there is still a reference
>   to each side of the pipe in the form of the process blocked
>   on the read.
> 
>   I've never been sure whether the implicit ref held during
>   the system call is good behavior, but it's hard to change.
> 
>   In your case, writing 0 (or anything) makes the read
>   finish, releasing the last ref to the underlying pipe when
>   the system call finishes, and then everything cleans up
>   as expected.  So you've found your workaround, and now
>   we understand why it works.
> 

I was just making the wrong observation here.
I thought I had observed the child procs getting
murdered mid read, and the parent never getting
the Waitmsg. Testing again I see as Andrej had observed,
they are just blocking. I thought I was seeing a bug
related to just udp, nothing to do with notes/threads.

I apologize for the confusion, interesting thread
you linked regardless.

> --
> 9fans: 9fans
> Permalink: 
> https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M6e48031f9e8673387c0b47b8
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Md81beb48e514ad6a776fa41d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[Jacob Moody]

On 6/18/22 03:22, adr wrote:
> On Sat, 18 Jun 2022, adr wrote:
> 
>> On Sat, 18 Jun 2022, andrey100100...@gmail.com wrote:
>>
>>> -
>>>
>>> cpu% 6.out | grep end | wc -l
>>> 33
>>>
>>>
>>> Problem in unregistered handlers.
>>
>> But unregistered handlers shouldn't be a problem. The process is
>> been killed when alarm sends the note. That's why the code worked
>> removing the read statement, the alarm is set off and the note is
>> not sent before the process ends. I just don't see why the process
>> is been killed. The documentation describes another behavior. To
>> me it smells like bug barbecue (corrupted onnote?). Maybe I got
>> something wrong, bear with me.
>>
 Note that you could register the handler in threadmain and avoid
 completely this issue, but as I said before, something seems wrong
 to me here.
>>>
>>> I'm don't understand how handler in threadmain would solve the problem.
>>> I need in 'alarm' on per process basis.
>>
>> You need alarm() in every process, but you don't need to register the
>> same handler 80 times!
>>
>> adr.
> 
> I think there is some confussion here, so I'll explain myself a
> little more.
> 
> Lets change your last example to not use libthread:
> 
> #include 
> #include 
> 
> int
> handler_alarm(void *, char *msg)
> {
>  if(strstr(msg, "alarm")){
>  return 1;
>  }
> 
>  return 0;
> }
> 
> int
> test(void)
> {
>  if(atnotify(handler_alarm, 1) == 0){
>  fprint(1, "handler not registered\n");
>  }
> 
>  alarm(10);
>  fprint(1, "start\n");
>  sleep(40);
>  fprint(1, "end\n");
>  alarm(0);
> 
>  return 0;
> }
> 
> void
> main()
> {
>  for(int i = 0; i < 80; i++){
>  test();
>  }
> 
>  exits(nil);
> }
> 
> You see, after the NFNth iteration of test(), onnot[NFN] in atnotify
> will be full, the handlers wont be registered but the code will
> work without any problem. It doesn't matter, the first handler in
> onnot[] will be executed. I fact you only need one handler there, not
> 80, you should move atnotify to main.
> 
> The same should be happening with libthread. I'm really the only
> one smelling a bug here?

No, you've got me convinced something much more wrong is going on.
Because you're right, our read children shouldn't just be gone,
we should return from read with an error and then print the "end" line.
I've attempted to reproduce it, trying to remove the libthread/notify
factors. I've come up with this:

#include 
#include 

static void
proc_udp(void*)
{
char resp[512];
char req[] = "request";
int fd;
int n;
int pid;

fd = dial("udp!185.157.221.201!5678", nil, nil, nil);
if(fd < 0)
exits("can't dial");

if(write(fd, req, strlen(req)) != strlen(req))
exits("can't write");

pid = getpid();
fprint(1, "start %d\n", pid);
n = read(fd, resp, sizeof(resp)-1);
fprint(1, "end %d %d\n", pid, n);
exits(nil);
}

void
main(int, char**)
{
int i;
Waitmsg *wm;

for(i = 0; i < 10; i++){
switch(fork()){
case -1:
sysfatal("fork %r");
case 0:
proc_udp(nil);
sysfatal("ret");
default:
break;
}
}
for(i = 0; i < 10; i++){
wm = wait();
print("proc %d died with message %s\n", wm->pid, wm->msg);
}
exits(nil);
}

This code makes it pretty obvious that we are losing some children;
on my machine this program never exits. I see some portion of the
readers correctly returning -1, and the parent is able to get their
Waitmsg but not all of them.


Thanks,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Ma4f311286087163ef1e2565e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[Jacob Moody]

On 6/17/22 12:48, andrey100100...@gmail.com wrote:
> В Пт, 17/06/2022 в 10:11 -0600, Jacob Moody пишет:
>> On 6/17/22 09:06, andrey100100...@gmail.com wrote:
>>> В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
>>>> On 6/17/22 07:46, Thaddeus Woskowiak wrote:
>>>>> I believe threadnotify() should be called from threadmain() to
>>>>> properly register the handler in the rendez group
>>>>
>>>> This is incorrect, according to thread(2):
>>>>
>>>> "The thread library depends on all procs
>>>> being in the same rendezvous group"
>>>
>>>
>>> From sleep(2):
>>>
>>>     Alarm causes an alarm note (see notify(2)) to be sent to the
>>>     invoking process after the number of milliseconds given by
>>>     the argument.
>>>
>>> Mean to be sent only to the invoking process, NOT to the process
>>> group.
>>
>> Yes this is correct, If I implied otherwise I apologize. My point
>> with
>> pointing out that excerpt is that groups likely had nothing to do
>> with this.
>>
>>>>
>>>> The issue here is that your note handler has to call noted,
>>>> you are returning from the handler without actually resuming the
>>>> program.
>>>> You either need to call noted(NCONT) to resume execution or
>>>> noted(NDFLT)
>>>> to stop execution.
>>>>
>>>> An excerpt from notify(2):
>>>>
>>>> "A notification handler must finish either by exiting the
>>>> program or by calling noted; if the handler returns the
>>>> behavior is undefined and probably erroneous."
>>>>
>>>> So you are indeed observing undefined behavior.
>>>>
>>>
>>> With:
>>>
>>> 
>>> static int
>>> handler_alarm(void *, char *msg)
>>> {
>>>     if(strstr(msg, "alarm")){
>>>     noted(NCONT);
>>>     return 1;
>>>     }
>>>
>>>     return 0;
>>> }
>>> 
>>> result the same:
>>>
>>> cpu% 6.out | grep end | wc -l
>>>  33
>>>
>>>
>>> And noted(NCONT) may be needed, when process recieved many (2 and
>>> more)
>>> notes at once.
>>>
>>> May be something wrong  with interrupted an incomplete  system
>>> call?
>>
>> You _always_ should call either noted(NCONT) or noted(NDFLT).
> 
> But from atnotify(2) (section 'Atnotify'):
> 
>   When the system
>   posts a note to the process, each handler registered with
>   atnotify is called with arguments as described above until
>   one of the handlers returns non-zero.  Then noted is called
>   with argument NCONT.  If no registered function returns
>   non-zero, atnotify calls noted with argument NDFLT.
> 
> from /sys/src/libc/port/atnotify.c :
> 
> 
> static
> void
> notifier(void *v, char *s)
> {
> int i;
> 
> for(i=0; i if(onnot[i] && ((*onnot[i])(v, s))){
> noted(NCONT);
> return;
> }
> noted(NDFLT);
> }
> 
> 
> Seems like noted() call not needed in user code.
> 

Oh look at that, my apologies. That's the whole difference
between just notify() and atnotify(), how did I miss that.

>> But you are correct in that this wasn't the exact issue. I poked
>> around with the code a bit. I rewrote it to just use
>> fork(), and I got all 80 "end" messages. 
> 
> Yes, with fork() is working:
> 
> --
> #include 
> #include 
> 
> static int
> handler_alarm(void *, char *msg)
> {
> if(strstr(msg, "alarm"))
> return 1;
> 
> return 0;
> }
> 
> static void
> proc_udp(void *)
> {
> char resp[512];
> char req[] = "request";
> int fd;
> 
> atnotify(handler_alarm, 1);
> 
> if((fd = dial("udp!185.157.221.201!5678", nil, nil, nil)) >=
> 0){
> if(write(fd, req, strlen(req)) == strlen(req)){
> fprint(1, "start\n");
> alarm(2000);
>  

Re: [9fans] syscall silently kill processes

[Jacob Moody]

On 6/17/22 09:06, andrey100100...@gmail.com wrote:
> В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
>> On 6/17/22 07:46, Thaddeus Woskowiak wrote:
>>> I believe threadnotify() should be called from threadmain() to
>>> properly register the handler in the rendez group
>>
>> This is incorrect, according to thread(2):
>>
>> "The thread library depends on all procs
>> being in the same rendezvous group"
> 
> 
> From sleep(2):
> 
> Alarm causes an alarm note (see notify(2)) to be sent to the
> invoking process after the number of milliseconds given by
> the argument.
> 
> Mean to be sent only to the invoking process, NOT to the process group.

Yes this is correct, If I implied otherwise I apologize. My point with
pointing out that excerpt is that groups likely had nothing to do with this.

>>
>> The issue here is that your note handler has to call noted,
>> you are returning from the handler without actually resuming the
>> program.
>> You either need to call noted(NCONT) to resume execution or
>> noted(NDFLT)
>> to stop execution.
>>
>> An excerpt from notify(2):
>>
>> "A notification handler must finish either by exiting the
>> program or by calling noted; if the handler returns the
>> behavior is undefined and probably erroneous."
>>
>> So you are indeed observing undefined behavior.
>>
> 
> With:
> 
> 
> static int
> handler_alarm(void *, char *msg)
> {
> if(strstr(msg, "alarm")){
> noted(NCONT);
> return 1;
> }
> 
> return 0;
> }
> 
> result the same:
> 
> cpu% 6.out | grep end | wc -l
>  33
> 
> 
> And noted(NCONT) may be needed, when process recieved many (2 and more)
> notes at once.
> 
> May be something wrong  with interrupted an incomplete  system call?

You _always_ should call either noted(NCONT) or noted(NDFLT).
But you are correct in that this wasn't the exact issue. I poked
around with the code a bit. I rewrote it to just use
fork(), and I got all 80 "end" messages. So I suspected
libthread had some arbitrary limit:

#define NFN 33
#define ERRLEN  48
typedef struct Note Note;
struct Note
{
Lockinuse;
Proc*proc;  /* recipient */
chars[ERRMAX];  /* arg2 */
};

static Note notes[128];
static Note *enotes = notes+nelem(notes);
static int  (*onnote[NFN])(void*, char*);
static int  onnotepid[NFN];
static Lock onnotelock;

int
threadnotify(int (*f)(void*, char*), int in)
{
int i, topid;
int (*from)(void*, char*), (*to)(void*, char*);

if(in){
from = nil;
to = f;
topid = _threadgetproc()->pid;
}else{
from = f;
to = nil;
topid = 0;
}
lock();
for(i=0; ihttps://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M687ef3adb4df6c21a188e7e1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] syscall silently kill processes

[Jacob Moody]

On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> I believe threadnotify() should be called from threadmain() to
> properly register the handler in the rendez group

This is incorrect, according to thread(2):

"The thread library depends on all procs
being in the same rendezvous group"

The issue here is that your note handler has to call noted,
you are returning from the handler without actually resuming the program.
You either need to call noted(NCONT) to resume execution or noted(NDFLT)
to stop execution.

An excerpt from notify(2):

"A notification handler must finish either by exiting the
program or by calling noted; if the handler returns the
behavior is undefined and probably erroneous."

So you are indeed observing undefined behavior.


Hope this helps,
moody

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Mfced9ffce2a92c38458048ad
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9p server to multiply 9p messages?

[Jacob Moody]

hjfs is not exactly known for it's speed[0]. Running a cwfs
without a worm[1] is likely a more interesting comparison.

I also would recommend using kvik's clone[2] for copying
in parallel.

Would be curious how that stacks up.


Thanks,
moody

[0] http://fqa.9front.org/fqa4.html#4.3.6
[1] http://fqa.9front.org/fqa4.html#4.3.6.1
[2] https://git.sr.ht/~kvik/clone

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M0f93091b620bfd87f9d0f56a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Help with a sam cleanup script

[Jacob Moody]

On 7/27/21 7:39 AM, k...@a-b.xyz wrote:
>> Just pushed it to https://github.com/iru-/sam9f-unix. It might be
>> outdated, but I still use it daily.
> 
> It seems that you imported two months before '^' and '_' got added
> (in 758496ecaa42b5f6c17c0bd1e0f43189e50e0745).
> 
> There have been a few other changes very useful for scripting, like
> the $% and $%dot variables exported to forked procs giving a current
> file name and selection.
> 

I have done some work in porting 9front sam changes to a fork of the go sam 
port.
You can find the work here:
https://github.com/majiru/go/tree/frontsam

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T10b1d559ae7d981e-M23c2702dda25e6393ba969fb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Acme resize bug

[Jacob Moody]

Hello 9fans,

I've noticed that sometimes when resizing acme columns there is a
strip left at the bottom that doesn't get redrawn.
It's a bit hard to notice with the default colours, but changing it up
makes it more obvious.
I was able to fix it with this the following patch but am not sure if
this is the best way to go about fixing it.

diff -u /dist/clean/plan9front/sys/src/cmd/acme/cols.c /sys/src/cmd/acme/cols.c
--- /dist/clean/plan9front/sys/src/cmd/acme/cols.c Thu Nov  1 15:02:44 2018
+++ /sys/src/cmd/acme/cols.c Thu Nov  1 15:38:53 2018
@@ -204,6 +204,7 @@
  draw(screen, r2, display->black, nil, ZP);
  r1.min.y = r2.max.y;
  r1.min.y = winresize(w, r1, FALSE);
+ draw(screen, r1, textcols[BACK], nil, ZP);
  }
  c->r = r;
 }

Happy New Year,
Moody