Re: [9fans] Throwing in the Towel

[hiro]

> Finally,. SSDs just die over time.

i can confirm.

> Keep backups.

i just hope i will be able to restore them, too. i'm too lazy to check
every year if stuff is still readable, and i fear it will wear out the
heads anyways ;)

most recent interesting read:
https://www.lto.org/wp-content/uploads/2024/05/LTOUltrium_2023_MediaShipmentReport.pdf

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2ca67486c7a13a77-Mae84dcb8843a0e9be3537403
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

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

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

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

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

[hiro]

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

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

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

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

[hiro]

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

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

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

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

[hiro]

he already admitted he's using grammarly.

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

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

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

[hiro]

no.

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

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

[hiro]

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

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

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

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

[hiro]

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

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

--
9fans: 9fans
Permalink: 

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

[hiro]

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

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

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

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

[hiro]

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

Again, please send patches, not propaganda.

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

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

[hiro]

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

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

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

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

[hiro]

I  believe you Steve, but I also believe noam. He's apparently the
biggest lover of fossil around out here.

On Thu, May 16, 2024 at 12:39 AM Steve Simon  wrote:
>
>
> i read the paper.
>
> i can believe there are still bugs, truth be told there are bugs in most 
> software. all i can say is in my experience i have not hit any since the 
> ephemeral snapshot fix. Honestly fosdil has been solid for me; i hope i have 
> not just jinx’ed it :-)
>
> -Steve
>
>
> > On 15 May 2024, at 11:18 pm, hiro <23h...@gmail.com> wrote:
> >
> > noam said there's also some well-known issues with locks that still
> > keeps happening in fossil. did you watch the outcome of last iwp9? he
> > has the best description of the state of venti and fossil to date.
> >
> >> On Thu, May 16, 2024 at 12:08 AM Steve Simon  wrote:
> >>
> >>
> >> Just a little first hand experience - I have run a fossil and venti server 
> >> for twenty years now.
> >>
> >> Fossil suffered three problems in my opinion:
> >>
> >> Firstly it was not well publicised that fossil was never designed to cope 
> >> with overflow; the sad truth is it fails catastrophically, as whitenessed 
> >> by Brucee. it should cope better really, but when used as a write buffer 
> >> for venti this is unlikely, it has never happened to me.
> >>
> >> Secondly it had a race condition in the ephemeral snapshot code. the only 
> >> way to make fossil reliable was to turn these off. This bug was fixed by 
> >> Charles (i think, though perhaps it was Richard) about 10 years ago and 
> >> with the fix my server has been taking ephemeral snapshots ever since.
> >>
> >> Thirdly venti and fossil are slow.
> >>
> >> I think its sad (an emotion, sorry) that fossil sources where deleted from 
> >> 9front but i do understand the principal of not distributing things the 
> >> community does not wish to support.
> >>
> >> -Steve
> >>

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

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

[hiro]

noam said there's also some well-known issues with locks that still
keeps happening in fossil. did you watch the outcome of last iwp9? he
has the best description of the state of venti and fossil to date.

On Thu, May 16, 2024 at 12:08 AM Steve Simon  wrote:
> 
> 
> Just a little first hand experience - I have run a fossil and venti server 
> for twenty years now.
> 
> Fossil suffered three problems in my opinion:
> 
> Firstly it was not well publicised that fossil was never designed to cope 
> with overflow; the sad truth is it fails catastrophically, as whitenessed by 
> Brucee. it should cope better really, but when used as a write buffer for 
> venti this is unlikely, it has never happened to me.
> 
> Secondly it had a race condition in the ephemeral snapshot code. the only way 
> to make fossil reliable was to turn these off. This bug was fixed by Charles 
> (i think, though perhaps it was Richard) about 10 years ago and with the fix 
> my server has been taking ephemeral snapshots ever since.
> 
> Thirdly venti and fossil are slow.
> 
> I think its sad (an emotion, sorry) that fossil sources where deleted from 
> 9front but i do understand the principal of not distributing things the 
> community does not wish to support.
> 
> -Steve
> 

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

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

[hiro]

about venti: probably nobody got around to removing it.
send a patch.

more seriously: i have no clue what might be wrong with venti, cause i
haven't used it for decades.
the papers for venti and fossil are nice btw, i have nothing against
the concept, rather i'm all for it, in theory.

On Wed, May 15, 2024 at 7:33 PM Lucio De Re  wrote:
>
> Factually, Fossil is no big deal. Its design shortcomings have been raised in 
> the past from the Bell Labs side and the documentation (for Venti, I think, 
> but it's not very important) suggests that Fossil was knocked together as a 
> minimal Venti cache so the benefits of Venti could be utilised and the old 
> file system could be abandoned.
>
> I somehow missed that discussion at the time and never went back to find out 
> how it panned out. But it sure feels with hindsight that Fossil became the 
> trigger for the 9front schism and that would explain the sensitivity on 
> either side. It's a shame, because the Venti potential remains unrealised as 
> there isn't the Fossil bridge (where development is continuing, in 9front) to 
> a better, full functionality file system that includes Venti backing storage.
>
> Which brings me to the question I have been meaning to ask: what scope does 
> Venti serve in the absence of Fossil? I appreciate that VAC is a handy form 
> of archiving, but does it justify the complexity of configuring and 
> maintaining a Venti archive? I know that vacfs has some failings I haven't 
> had the opportunity or the inclination to investigate, but exhibit themselves 
> only in P9P - in my experience. So is Venti only a trophy application, or are 
> there serious uses for it among the 9front community?
>
> Lucio.
>
> On Wed, May 15, 2024 at 7:04 PM Jacob Moody  wrote:
>>
>> 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.
>> 
>
>
>
> --
> Lucio De Re
> 2 Piet Retief St
> Kestell (Eastern Free State)
> 9860 South Africa
>
> Ph.: +27 58 653 1433
> Cell: +27 83 251 5824
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 

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

[hiro]

> The presumption you're making is based on the fact that it is easy /for you/.

That is correct.

> A valid reason is, for those that don't know what Fossil is, and what to 
> understand the history of 9fans decision making, there is no way to know that 
> decision was made, or why.

A valid reason for what?

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

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

[hiro]

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

This separate document exists these days, that's what we call the
release, you can sometimes even get it in print-form IIRC as sl
compiles it into various digital and analog formats.

Regardless of us seemingly being in agreement about this, finding a
commit that removes fossil in the git log is *easy*, and knowing what
you want to be looking for is definitely a prerequisite for looking
for it, so I cannot draw the conclusion for the reason you stated.

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

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

[hiro]

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

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

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

[hiro]

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

and i agree that we should hold everybody to this standard. Preferably
a big change like this should be mentioned in a verbose commit
message, and maybe in the release notes.

the problem is that this removal was kind of the joke that started
9front, and back then these kinds of jokes were not documented well
yet and a good release process had not been established yet. when it
turned out that the joke that was 9front was better than all the
serious bizznezz competition, over time, (maybe accidentally?)
professionalism set in.

i would presume that nowadays there would be better notice in this
regard to explain to all the many users in detail (back then there
were just few) what awaits them in each release.

yes, 9front was trolling, to some extent, but the troll has turned
into something extremely useful.

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

agreed. i'm confident that most of the releases are taking this kind
of approach nowadays.

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

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

[hiro]

> I suggested that the sources could be included in the distribution, so they 
> would not fork-rot as they are doing presently. 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.

this is a good point, and this is exactly the kind of arguments that i
would like to see more of on 9fans.

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

Interesting, thanks for sharing some of that history.

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

I agree with you that maybe "removing Fossil" was a little bit overly
dramatic, and maybe the goal was indeed to send a strong message with
this act.
otoh, i can understand the anger, after countless people lost their
data, trusting that fossil is certified by bell-labs and "totally
safe".

> 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 hope you can reconsider for the sake of technical professionalism.

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

[hiro]

> That said, I have been excited by the developments in the 9front and 9legacy, 
> etc, groups, even if I don't fully agree with all the decision making. It at 
> least means people are still interested in building, and that's a good 
> start...

to agree with the decision making it helps to be part of it, and to be
part of it it helps to understand the decision making and to
understand it it helps to read the code. i think this is the major
reason why some people are appalled these days. there's just so much
volume of code it's hard to keep track.
but that might be a good thing...

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T9bf40e9448c878ab-Mc8b31b1fd14ff5c50feafad8
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. ]

[hiro]

it's not much of a degree if they don't require you to read Strunk & White

On Wed, May 15, 2024 at 11:18 AM  wrote:
>
> On Wed, May 15, 2024, at 16:39, pl...@room3420.net wrote:
> > It doesn't. I don't know if you're a troll or just not clever enough to
> > understand that you make everybody uncomfortable.
> > Hope this helps.
> 
> Well, I am disappointed that you feel that way. I am definitely not a troll 
> nor am I that clever. However, I can respond in kind if provoked. I'm human 
> after all. I'll be frank and set boundaries if things get too far out of 
> hand. Overall, I much prefer fostering friendly interactions in 9fans. I do 
> not see the need for conflict and ill-will. I'm not attempting to create 
> problems nor make anyone feel uncomfortable. However, I'll gladly respond in 
> kind. If you want to call me a troll for responding in kind that is fine. 
> However, please be fair minded and consider my perspective as well.
> 
> Not everyone here is uncomfortable, but like you, I'm disappointed in how 
> interactions have turned out, so we have that in common. I respond to 
> empirical evidence, so I mentioned the concern about submitting feature and 
> bug requests because it seemed that it would benefit Lucio and others. There 
> is nothing wrong with helping others and setting expectations. I don't 
> understand why that would be a problem. Clarity is better than 
> misunderstanding.
> 
> Regarding my writing style, it is shaped by years of government service and 
> an M.A. degree. I understand that my style may be unusual. Before posting, I 
> make an effort to revise my responses for clarity, which can result in longer 
> messages. We can blame grammarly.com for some word choices as well.
> 
> Kind regards,
> 
> Vic

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

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

[hiro]

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

there's only one division, not in my control, between the people that
actually run plan 9 (that includes 9front), and the people who run
plan9port (not 9front).

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

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

[hiro]

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

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

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

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

[hiro]

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

no

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

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

[hiro]

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

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

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

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

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

[hiro]

> My point was only about the advantage of p9sk3 over p9sk1, not to
> compare it with anything else. The intent was to counter the implication
> that p9sk1 is terrible and completely broken, by suggesting that the

One error in our naming is that it might imply dp9ik completely replaced p9sk1.
quickly googling for the terms reveals others have amplified this
misunderstanding.
Instead, dp9ik *extends* the p9sk1 by an additional authentication
procedure. Forgive the confusion everybody.

> (with no change to the protocol on-the-wire).  Of course it doesn't mitigate
> the problem of users negligently choosing weak passwords.  dp9ik has the
> extra advantage of doing that too, by removing the opportunity for offline
> dictionary attacks.

Thank you for finding a better way to phrase that one also. This was
indeed one of cinap's design goals.
It is pretty near to the minimal amount of changes needed in the
system that would achieve secure continued use of passwords with the
same user experience as before.

I have not seen another implementation that does quite the same either
in the real world. Remember, everybody else just gave up on passwords,
while here, passwords are now secure by design: Secure your
authservers well, and you will have a very very modern and extremely
unique security system, unalike anything else out there.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M5da7bb9c49b6387cc74e0a3b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

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

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

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

> I don't have a problem respecting any fork of plan9. I will give back to 
> other forks as much as I take from them. And if I contribute code to plan9 
> than I will make sure that it doesn't make use of enhancements I am using 
> within my fork respect the coding styles of such a compatibility layer if one 
> is ever defined. The whole discussion is about interoperability between forks.

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

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

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

[hiro]

citation needed

On Mon, May 13, 2024 at 1:58 PM  wrote:
>
> On Mon, May 13, 2024, at 18:38, hiro wrote:
> > how did you find out about this company, i never saw it mentioned
> > anywhere before?
> 
> I don't spend my time trolling 9fans. ;-)
> 
> Vic

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

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

[hiro]

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

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

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

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

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

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

[hiro]

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

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

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

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

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

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

[hiro]

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

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

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

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

[hiro]

i mean contributing to the plan9 team. i don't share in your
discrimination of 9front vs. non9front code.
i bet if all of us can be gainfully employed to work on "real plan9"
we can all stop contributing to 9front. please enlighten me who my
future coworkers might be. who else is going to join the team?

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

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

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

[hiro]

> Have a look at authsrv(6) in the manual. The authenticator sends a
> pair of tickets to the client, one encrypted with the client's own
> key and one encrypted with the server's key. That's what allows
> both the client and server to authenticate each other.

i stand corrected. also i confused cpuserver and authserver. and i
still don't have the details paged in, so thank you for contributing
another good summary :)

> Yes, I think you're probably right. I was thinking in terms of minimum
> lines of code to change, but other factors are also important.

i generally use the same tactic in regards to minimal changes, and i
certainly see it isn't used often enough in the field.
i think the rule also doesn't conflict with what happened: replacement
of outdated systems without good incremental path for future
improvements, with useful high-quality software developed from
scratch. it can happen, despite the late hype around
"enshittification".
lastly, rules are meant to be broken. the details just happen to
matter more than the rule of thumb here.

and again, anybody who knows crypthographers, since the approach is
rather modern, please help share cinap's paper, maybe even the code,
have a look, the more eyes the more better ;)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M925311bc2b8c990e6ba917ed
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

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

not only will they be able to make the connection, but they will be
authenticated as a user that is probably more permissive than the
'none' user.
for all the newbies reading this thread, this is the second reminder
to read the auth paper. it is truly excellent ;)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Md3a8fecbefcca9c49ceeb87e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

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

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


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

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

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

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

[hiro]

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

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

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

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

[hiro]

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

...

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

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

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

huh? which files exactly do you have doubts about?

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

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

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

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

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

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

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

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

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

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

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

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

> Therefore 

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

[hiro]

are you contributing the team? and paying the team?

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

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

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

[hiro]

how did you find out about this company, i never saw it mentioned
anywhere before?

On Mon, May 13, 2024 at 10:43 AM  wrote:
>
> Thank you, Sirjofri, nice idea.
>
> There are two private U.S. companies that are investing, developing, and 
> using a closed source Plan 9 distribution called ᴁOS (aka ᴁ9).  The companies 
> have been in existence since 2020.
>
> Nantahala Holdings, LLC
> Nantahala Operations, LLC (dba Nantahala Systems)
>
> Vic
>
>
> On Mon, May 13, 2024, at 17:10, sirjofri wrote:
> > Hey all,
> >
> > Just about one topic mentioned by ibrahim:
> >
> > You mentioned that 9front can't be plan 9 in your perspective because
> > of this licensing and the "origin" of the licensing.
> >
> >> 9front isn't plan9 from my perspective. Plan 9 is the final release with 
> >> patches for the files from sources I can be sure that those aren't taken 
> >> from open source projects by copy and paste.
> > [1]
> >
> > I would make a big difference between what plan 9 is and what the
> > licenses are. Software doesn't care about licenses. People do (and they
> > should!).
> >
> > So what is plan 9 even? Can we compare it to UNIX™ or unix or posix?
> > Who knows...
> >
> > I guess I could say a lot more about that topic, but I guess that's
> > enough and you can puzzle everything else yourself.
> >
> > [1] (I would be very careful with such bold words. I feel like 9front
> > people have heard this phrase a lot and it's probably very thin ice for
> > a few people.)
> >
> > ---
> >
> > About another topic: you mentioned that plan 9 is in use for commercial
> > products, and you explicitly mention german medical sensors. I've never
> > heard about that and I'd like to learn more, as well as about other
> > companies who actually use plan 9.
> >
> > Everything I always hear in the industry is that plan 9 is outdated and
> > nobody uses it and nobody wants to hear about it. I only know of a
> > single company that uses it (coraid), plus a few little projects by taw
> > that could evolve into commercial products.
> >
> > I sometimes thought about building a list of companies that use plan 9
> > technology, just so people can get involved with them, and now that I'm
> > searching for a new job that's even more interesting for me personally.
> > (Not sure if I want to do plan 9 as $dayjob, but I could see it as an
> > option.) That topic should end up in a new thread however (or even a
> > DM).
> >
> > sirjofri

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

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

[hiro]

to answer my own question:

> Who is Eric Grosse?
>

  author =   "Russ Cox and Eric Grosse and Rob Pike and Dave
 Presotto and Sean Quinlan",
  title ="Security in {Plan 9}",

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

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

[hiro]

> I thought of 3DES in the first instance because of this desire to be
> minimally disruptive.  Support for DES is already there and tested.
> 3DES only needs extra keys in /mnt/keys, and because 3DES encryption
> with all three keys the same becomes single DES, there's a graceful
> fallback when users have access only via an older client with
> unmodified p9sk1. Obviously the server ticket would always be protected
> by 3DES.

it is not obvious to me. but then, you know more about 3des than me. ;)

there are some fundamental features in dp9ik that are still missing
even when you increase the "quality" of the DES key by giving it
arbitrarily longer lengths. also, the server and client keys are the
same in p9sk1 as far as i understood. i would welcome public/private
key system though (is that what you were thinking of when separating
"server key" and "client key". that would add yet another set of
features that are currently missing.

> This is only the first scratching of an idea, not implemented yet.

i can offer strictly less than that even. but it seems to me that
concentrating on 3DES just for the sake of similarity to DES is taking
ocam's razor slightly too far.

though i do find it generally happens that security mechanisms are
claimed to be "outdated", resulting in less scientific processes and
more popularity contests than anything else, so putting extra scrutiny
is highly welcome.

on my part i'm simply trusting cinap on his intent and research as i
have no hope to ever understand any details. but the dp9ik approach
has some novelties which should make it worthwhile for security
researchers to study.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M3d84204e405a926acc80c609
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

this is mostly wild speculation. further, the numbers are not
representative at all.
since the import of the (possibly redundent) 9k amd64 work from "labs"
(which in this case might mean geoff+charles?) 2 years ago there were
zero active developers contributing to 9legacy.

please note, that stuff has been developed in the dark and without any
kind of open community process, also not in 9legacy but in some other
fork (that is unknown to me). it was pulled in by 9legacy but i have
no clue from where and why.
there was near zero communication about that other fork, and what it's
plan was, or who might want to use 9k nowadays, and for what purposes.
since this was not developed in the open and not discussed with 9front
people we are at this point largely ignorant of what 9k can do. i
would appreciate a more in-depth comparison if possible, though i fear
9k is about as dead as plan9 4th edition (and 9legacy for that matter)
at this point. sorry for my doubts.

On Sun, May 12, 2024 at 5:13 PM  wrote:
>
> My understanding is that the initial request came from a 9legacy member to 
> the 9front community, and the responses were quite intriguing. It has led me 
> to ponder how we might bridge the gap between these communities. There seems 
> to be conflict on both sides, and for some reason, I hold 9front to higher 
> standards—perhaps because of our more idealistic roots. The core mission of 
> 9front was always to advance the Plan 9 tradition, but not at the cost of 
> alienating others.
>
> From what I observe, there seem to be only a handful of active developers 
> remaining in each group. Initially, I believed we had around 30 active 
> developers in 9front and about 7 in 9legacy, but I now think I may have 
> overestimated these numbers. It appears that many are staying on the 
> sidelines, possibly due to past grievances, which could explain the responses 
> I've seen. The developers who are active might be overextended, while those 
> who are less active might feel marginalized.
>
> Vic
>
>
> On Sun, May 12, 2024, at 22:23, q...@nopenopenope.net wrote:
> > On Sun May 12 14:43:17 +0200 2024, vester.thac...@fastmail.fm wrote:
> >> I don't mind the ad hominem attacks.  I just hope things improve. I do 
> >> find it ironic that I'm addressing the 9front community about 
> >> collaboration and inclusiveness when I recall those as being two reasons 
> >> for the inception of 9front.
> >>
> >> Vic
> >
> > You hit the nail on the head there.  Why *are* you addressing just the
> > 9front community or assuming there is no willingness to collaborate on
> > its part?  9legacy users so far have expressed interest in someone
> > else porting dp9ik (David for instance) or demanded explanations about
> > DES cracking (Richard) or asked for others to port or fix fossil on
> > 9front (Lucio), but who explicitely said that they would like to put
> > in some work themselves and collaborate with 9front people?  Maybe I'm
> > beginning to misremember the rest of the thread, am I missing
> > anything?  Could you point to *specific examples*?
> >
> > 9front users demand code because they've already put in a lot of work
> > and it has been often ignored or dismissed, and because it would be up
> > to them to backport it to 9legacy -- why would they do double duty for
> > a system they don't use and a community which is generally not
> > receptive to their work?  Also, do you realize that 9front right now
> > has upwards of 10500 changes in the repository, after 13 years?
> > Bringing 9legacy up to date as you've proposed would require a
> > colossal amount of work, all just to obtain...  9front.  Do you
> > believe it has diverged to the point where backporting hardware
> > support, fixing bugs and broken or incomplete implementations and so
> > on will result in anything other than what 9front already is?
> >
> > You yourself demand everyone, especially the 9front community, to make
> > suggestions, start projects, etc.  What about you?  What do you
> > suggest to do and which projects would you take part in?  That's what
> > "just send the code" implies.  Promises don't fix bugs or help
> > implement programs, nor help fix this one-sided conversation.
> >
> > I'm asking these questions yet I fear that they will meet radio
> > silence or more empty walls of text, as it happens too often here
> > when asking "why" or how it came to this.  I hope I'm wrong.
> >
> > Thanks,
> > qwx
> >
> > PS: I was about to hit send when I received Richard's mail.
> > Richard, thank you for the constructive and detailed response.
> > I hope this marks a turn of the tide.

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

Re: [9fans] best place to be sent a patch

[hiro]

best is here on the mailinglist as you can attach the patches easily,
and even if david doesn't have time to respond, others here might help
you on the path, others might appreciate taking part in your adventure
and others might learn from it, too. i guess you can cc david if
getting into 9legacy is your goal.

On Sun, May 12, 2024 at 4:31 PM Kyohei Kadota via 9fans <9fans@9fans.net> wrote:
> 
> I have a question: where is the *best* place to be sent a patch for
> 9legacy? replica? GitHub? or here?
> 
> I'm motivated, but I don't like to get no feedback as before.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T57377acea9350f32-M962c9a20d2e9f6001e37325f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

sorry for ignoring your ideas about a p9sk3, but is your mentioning of
ocam's razor implying that dp9ik is too complicated?
is there any other reason to stick with DES instead of AES in
particular? i'm not a cryptographer by any means, but just curious.

On Sun, May 12, 2024 at 3:17 PM Richard Miller <9f...@hamnavoe.com> 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.
>
> 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:
>
> > 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.
> 
> 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 broken by brute-force; its
>  56-bit key is just too short.  It should not be used in new
>  code, which should probably use aes(2) instead, or at least
>  triple DES.
> 
> Let's postulate a p9sk3 which is identical to p9sk1 except that it encrypts 
> the
> ticket responses using 3DES instead of DES. The effective keyspace of 3DES is
> considered to be 112 bits because of the theoretical meet-in-the-middle 
> attack.
> So brute forcing a 3DES key with commodity hardware (including GPU) would be
> expected to take something like:
> 
> cpu% hoc
> 2^111/3.87e9
> 

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

[hiro]

why step back. step forward and put your money where your mouth is.

On Sun, May 12, 2024 at 2:42 PM  wrote:
>
> Thank you for sharing your thoughts. I want to clarify that my intention is 
> not to exert control or disrupt, but to foster better collaboration between 
> communities.  I understand that there may be concerns about redundancy and 
> approaches, which is why I believe a dialogue about our common goals and how 
> best to achieve them is crucial.  I do not see much collaboration between 
> 9legacy and 9front.  From what I gather from this thread, it seems that one 
> community wants to lord over another and not be helpful.  At least this is 
> how it appears to a hobbyist like me.  It would be nice if things were more 
> cordial and helpful.
>
> I am assuming everyone here is a hobbyist, so I speak as a hobbyist. It’s 
> important to recognize that our shared interest in advancing the Plan 9 
> community is at the heart of these discussions. I am here not for personal 
> gain but to contribute positively. I think we all bring valuable perspectives 
> that, when combined, can lead to innovative solutions that benefit everyone 
> involved.
>
> Let’s focus on how we can work together more effectively. I am open to 
> suggestions and willing to step back where needed to allow for a more 
> collective approach. I believe that through constructive dialogue and a 
> shared commitment to our community’s goals, we can overcome misunderstandings 
> and move forward together.
>
> I don't mind the ad hominem attacks.  I just hope things improve. I do find 
> it ironic that I'm addressing the 9front community about collaboration and 
> inclusiveness when I recall those as being two reasons for the inception of 
> 9front.
>
> Vic
>
>
> On Sun, May 12, 2024, at 21:18, pl...@room3420.net wrote:
> > The collaboration is already here. You try to create tools that already
> > exist. I'd like to pinpoint why you have this unbelievable need for
> > control and wonder if you're not just working for Microsoft, Google or
> > the guy who stole Freenode and just try to disrupt the plan9 community.

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

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

[hiro]

what fears? i welcome you making this collaboration greater by helping
out the people that already are busy collaborating. thank you.

On Sun, May 12, 2024 at 1:58 PM  wrote:
>
> Why the fear about collaborating?  Wouldn't greater 9legacy and 9front 
> collaboration be something good for the Plan 9 community?
>
> Vic
>
>
> On Sun, May 12, 2024, at 20:53, hiro wrote:
> >> How can we ensure that everyone feels valued and heard?
> >
> > easy. stop spamming LLM garbage and start contributing concise code
> > and documentation, not this blabber.

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

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

[hiro]

> How can we ensure that everyone feels valued and heard?

easy. stop spamming LLM garbage and start contributing concise code
and documentation, not this blabber.

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

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

[hiro]

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 ancestors 
> >>> and
> >>> fostering a more resilient and vibrant community that thrives on both 
> >>> change
> >>> and tradition.
> >>
> >>
> >>
> >> --
> >> Lucio De Re
> >> 2 Piet Retief St
> >> Kestell (Eastern Free State)
> >> 9860 South Africa
> >>
> >> Ph.: +27 58 653 1433
> >> Cell: +27 83 251 5824
> >> 9fans / 9fans / see discussions + participants + delivery options Permalink

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

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

[hiro]

i do mind. please do not. but thanks for this medium-to-low-quality
trolling attempt.

On Sat, May 11, 2024 at 11:00 PM Skip Tavakkolian
 wrote:
>
> Hiro, I hope you don't mind if I use your correspondence on 9fans to train a 
> very annoying LLM.
>
> On Sat, May 11, 2024, 1:30 PM hiro <23h...@gmail.com> wrote:
>> > Hey! It's a nice day out. A bit chilly with some wind, but sunny. I
>> > don't know about you, but I'm going fishing.
>> 
>> oh, i guess you are not Fish? i confused you. why are you speaking for
>> Fish though, it's his decision to put it into 9legacy, no?
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

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

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

[hiro]

> Hey! It's a nice day out. A bit chilly with some wind, but sunny. I
> don't know about you, but I'm going fishing.

oh, i guess you are not Fish? i confused you. why are you speaking for
Fish though, it's his decision to put it into 9legacy, no?

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

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

[hiro]

are you discontinuing 9legacy?

On Sat, May 11, 2024 at 10:01 PM Dan Cross  wrote:
>
> On Sat, May 11, 2024 at 3:52 PM hiro <23h...@gmail.com> wrote:
> > it's YOUR fork, why aren't you doing it?
>
> For a simple reason: time.
>
> The work to integrate it in isn't technically that difficult, but
> requires time, which is always in short supply.
>
> - Dan C.
>
> > On Sat, May 11, 2024 at 11:47 AM David du Colombier <0in...@gmail.com> 
> > wrote:
> > >
> > > I'd be very pleased if someone could port the
> > > dp9ik authentication protocol to 9legacy.
> > >
> > > --
> > > David du Colombier

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

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

[hiro]

it's YOUR fork, why aren't you doing it?

On Sat, May 11, 2024 at 11:47 AM David du Colombier <0in...@gmail.com> wrote:
> 
> I'd be very pleased if someone could port the
> dp9ik authentication protocol to 9legacy.
> 
> --
> David du Colombier

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

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

[hiro]

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

significant effort has been spent not only to come up with dp9ik and
verify it but also to document it openly and suggest it's use
repeatedly to the whole plan9 community (even non-9front-users).

it's beyond me why more 9fans people are not taking this contribution
at face value.

> I should note that a couple of years ago I talked to Eric Grosse about
> dp9ik and p9sk1.

Who is Eric Grosse?

> I do
> wish the name were different: c'mon guys, not _everything_ needs to be
> snarky. ?;-)

I do wish there wasn't ever any reasons to ever be snarky to anybody
in the whole plan9 community.

But sometimes it's easier to make some jokes than to solve all
perceived interpersonal issues of all involved people in the
community.

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

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

[hiro]

On Fri, May 10, 2024 at 12:59 PM Richard Miller <9f...@hamnavoe.com> wrote:
> > From: o...@eigenstate.org
> > ...
> > keep in mind that it can literally be brute forced in an
> > afternoon by a teenager[1][2]; even a gpu isn't needed to do
> > this in a reasonable amount of time.[1]
>
> [citation needed][1]
>

there you are[1].
[1] http://felloff.net/usr/cinap_lenrek/newticket.txt

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

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

[hiro]

> I suspect no-one wanted to maintain it (in 9front)

I think you meant: I suspect no-one wanted to maintain it.

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

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

[hiro]

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 ancestors and
>> fostering a more resilient and vibrant community that thrives on both change
>> and tradition.
>
>
>
> --
> Lucio De Re
> 2 Piet Retief St
> Kestell (Eastern Free State)
> 9860 South Africa
>
> Ph.: +27 58 653 1433
> Cell: +27 83 251 5824
> 9fans / 9fans / see discussions + participants + delivery options Permalink

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

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

[hiro]

no clue which conflict you're seeing, vic.

there's been some trolling back and forth since forever, there's been
complaints and contributions, and more complaints about the
contributions and the lack of contributions. as it should be. we can
have one united community if you like but then i hope we still have
those complaints. if no issues come up it just means that nobody used
the system.

personally i think non-dp9ik protocols should be removed completely or
at the very least only allowed with very big fat warning messages. if
9legacy still doesn't have dp9ik, then why don't you just let 9legacy
die? is there a single 9legacy-only improvement that's worth having in
the first place? why does this discussion here even exist? if you want
interoperability between things just upgrade everything to 9front.
there's no more straightforward way, or?

i know from linuxland where some garbage firmware or closed-source
kernel driver prevents the use of newer linux releases, but i don't
see similar problems in the 9front world at all. 9front provides a
very steady and stable upgrade path i see no reason to keep an older
plan9 4th edition system alive at all. what hardware does anybody have
where 9front doesn't work but plan9 4th edition does?!

On Wed, May 8, 2024 at 11:53 PM  wrote:
>
> Hi Hiro et al,
>
> This mailing list is focused on Plan 9 discussions.  Noticing conflicts 
> between the 9legacy and 9front communities indicates that adopting 
> collaborative strategies could be advantageous.  In my detailed post, I aimed 
> to provide a comprehensive overview to fully encapsulate the topic.  Having 
> observed conflicts evolve over more than two decades, I am motivated to 
> suggest improvements rather than seeing history repeat itself.  I contributed 
> my comments in hopes of fostering meaningful positive change.  I value both 
> 9front and 9legacy but choose to remain neutral and refrain from taking 
> sides.  In my view, there's no advantage in picking sides, particularly among 
> us 9fans.  The need for collaboration seems great, I'm astonished that more 
> collaboration hasn't happened over the years.
>
> Kind regards,
> Vester
>
> On Thu, May 9, 2024, at 05:10, hiro wrote:
> > vester, why do you recommend all these things so overly
> > methodologically that are all already a reality in the 9front
> > community? are you a bot?
> >
> > On Wed, May 8, 2024 at 9:18 PM  wrote:
> >>
> >> Dear Members of the 9legacy and 9front Communities,
> >>
> >> This message is intended to share thoughts on potential improvements to 
> >> collaborative processes between systems. The aim is to foster an 
> >> environment that encourages ongoing enhancement and mutual support.
> >>
> >> Community Efforts
> >> Appreciation is extended to all community members for their dedication in 
> >> updating and maintaining these systems. Their efforts are vital to 
> >> collective progress.
> >>
> >> Community Dialogue
> >> An open forum for all members to share insights, discuss challenges, and 
> >> propose solutions related to system updates and integration efforts could 
> >> prove beneficial. Such dialogue can help better understand different 
> >> perspectives and formulate effective strategies collaboratively.
> >>
> >> Collaborative Working Group
> >> The creation of a working group to address specific technical challenges, 
> >> such as integrating the dp9ik security protocol, could facilitate smoother 
> >> and more efficient integration. Interested members might consider 
> >> participating in such a group.
> >>
> >> Transparency in Decision-Making
> >> Improving the transparency of decision-making processes is a goal. Sharing 
> >> regular informational updates could keep everyone informed about the 
> >> progress and decisions that affect both communities.
> >>
> >> Inclusive Decision-Making Processes
> >> Exploring ways to ensure that decision-making processes reflect the 
> >> community's needs and inputs is under consideration. Contributions on how 
> >> to achieve this are highly valued.
> >>
> >> Recognition Program
> >> Recognizing the hard work and achievements of community members is 
> >> important. Plans to introduce a recognition program that highlights 
> >> significant contributions and successes are being explored.
> >>
> >> Addressing Historical Concerns
> >> Dedicating time to openly discuss historical concerns is crucial for 
> >> moving forward. This could help reconcile and strengthen community ties.
> >>
> >> Feedba

Re: [9fans] Re: Raspberry pi with a largish screen?

[hiro]

4k@59hz works here.
but only if i disable bluetooth.

On Wed, May 8, 2024 at 9:56 PM  wrote:
>
> Thanks, that’s promising. What’s your monitor?
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcb982002ae12827e-M80dcfdccde1b1faf52f7e8a8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

vester, why do you recommend all these things so overly
methodologically that are all already a reality in the 9front
community? are you a bot?

On Wed, May 8, 2024 at 9:18 PM  wrote:
>
> Dear Members of the 9legacy and 9front Communities,
>
> This message is intended to share thoughts on potential improvements to 
> collaborative processes between systems. The aim is to foster an environment 
> that encourages ongoing enhancement and mutual support.
>
> Community Efforts
> Appreciation is extended to all community members for their dedication in 
> updating and maintaining these systems. Their efforts are vital to collective 
> progress.
>
> Community Dialogue
> An open forum for all members to share insights, discuss challenges, and 
> propose solutions related to system updates and integration efforts could 
> prove beneficial. Such dialogue can help better understand different 
> perspectives and formulate effective strategies collaboratively.
>
> Collaborative Working Group
> The creation of a working group to address specific technical challenges, 
> such as integrating the dp9ik security protocol, could facilitate smoother 
> and more efficient integration. Interested members might consider 
> participating in such a group.
>
> Transparency in Decision-Making
> Improving the transparency of decision-making processes is a goal. Sharing 
> regular informational updates could keep everyone informed about the progress 
> and decisions that affect both communities.
>
> Inclusive Decision-Making Processes
> Exploring ways to ensure that decision-making processes reflect the 
> community's needs and inputs is under consideration. Contributions on how to 
> achieve this are highly valued.
>
> Recognition Program
> Recognizing the hard work and achievements of community members is important. 
> Plans to introduce a recognition program that highlights significant 
> contributions and successes are being explored.
>
> Addressing Historical Concerns
> Dedicating time to openly discuss historical concerns is crucial for moving 
> forward. This could help reconcile and strengthen community ties.
>
> Feedback on these suggestions and potential interest in participating in 
> these initiatives is invited. Contributions from community members are 
> invaluable and will help shape the direction of collaborative efforts.
>
> Thank you for your engagement and commitment to the community.
>
> Best regards,
> Vester
>
>
> On Thu, May 9, 2024, at 01:29, Jacob Moody wrote:
> > 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 

Re: [9fans] VMX Cores

[hiro]

> i dont see vmx causing kernel crashes for me.
> however, i think the author meant to express is lack
> of confidence in the air-tightiness of vmx giving
> the zillions of architectual registers you have to
> setup to contain a guest. it is easy to forget
> to set some bit and everything works until someone
> manages to exploit that.

and not like any competitor has any great solution to that either. the
hardware just never was built for such strong isolation to
meaningfully prevent that kind of exploit. and if it did, there would
still always be other side-channels. just less obvious ones (from
today's pov).
in terms of stability, my slowlaris hypervisor (their own vmx plus
qemu) has finally reached some limit, which destroyed the guest
kernel's interpretation of time, which created some centuries of
timeshifting, waits don't fire any more, and suddenly i have 1000s
days of uptime bec. it's like a hundred years later now. forced me to
destroy this virtual computer and thus reboot the guest. :D stuff
breaks. everywhere. vmx is small, so actually it might break less in
some edge-cases. but yes, virtualization is one more layer, and the
interfaces, drivers, aren't as minimal as they could be, so
virtualization still sucks. even with all these hw optimizations now.
still a neat hack, i guess if you want to implement multi-core vmx, a
lot of firefox on vmx on plan9 users will be happy. otherwise, what do
we need that needs multiple cores in a vm?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc08115552282a0a2-M62c7b76e5e8a766d7ecc601d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[hiro]

all this makes sense. thank you.
i might be dense, but what's the problem with inetd exactly?

On 3/5/24, a...@9srv.net  wrote:
> I wonder what percentage of people who reply are going to be running a
> finger server they wrote. :-) My tcp79 comes from my implementation,
> here: http://txtpunk.com/finger/index.html
> 
> I think we've got enough interoperable unicode-aware implementations we can
> start working on the update to the RFC now.
> 
> I have a service which allows some unix hosts I run to submit vac scores
> after they perform a backup to my venti; a slightly outdated version is
> here: https://9p.io/sources/contrib/anothy/bin/rc/tcp17038
> 
> tcp411 calls pqsrv, I think the same version as on the "extra"
> page: http://9p.io/sources/extra/
> 
> I usually have at least one "poor man's nat traversal" thing running with
> aux/trampoline.
> 
> I love how easy aux/listen makes sticking trivial little services up on the
> net. I used to have one that provided a menu of MUDs to connect to. Another
> gave the weather, as the telnet service at Weather Underground started to go
> unmaintained (of course, mine used darksky, which is now also defunct). I
> made a little text-based zine server (inspired by Cara
> Esten's https://github.com/caraesten/dial_a_zine, which powered the things
> at anewsession.com); that's up, although very lightly
> used: http://txtpunk.com/zine/ 
> 
> Before life got away from me last year, I was trying to get a VoIP bridge
> working so I could plug a POTS line into my modem and get telcodata working
> again. I think 'cp tcp2323 telcodata' should be enough to make that zine
> server dialable. (Sadly, I've only gotten the bridge to *place* calls over
> my crummy DSL line.)
> 
> As a young unix sysadmin back in the 1900s, aux/listen was one of the first
> things that caught my eye about Plan 9, in comparison to inetd and the
> direction everyone else was headed from there. Certainly the growth (in
> multiple senses) of systemd has only tightened my grip on that particular
> tool.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-M32b1f1b0e1eeedd875aee9d9
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]

[hiro via 9fans]

the few remaining "original Labs' Plan 9" people anyways all went to
concentrate on golang. so if you wanna hang out with them, they have a
very big and active community, too.
it keeps a lot of the core spirit behind plan9 alive, just that it
abstracts away the operating system layer. i might not like the
latter, but i can relate to people who want to engage with this, just
go for it. they are not coming back for 9front, maybe they are even
happy anybody sees more value in their old produce than they
themselves... though they never quite say so. :P

On Sat, Jan 27, 2024 at 2:25 AM Vester "Vic" Thacker
 wrote:
>
> I would like to extend my gratitude to everyone who took the time to provide 
> their valuable feedback. I fully acknowledge that there appears to be limited 
> interest in the proposal. Your time and assistance are greatly appreciated.
>
> --vic
> 9fans / 9fans / see discussions + participants + delivery options Permalink

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

Re: [9fans] Formation of a Plan 9 Core Team

[hiro]

> People use 9front, which is not plan 9. Many good things
> started as forks, and that's ok.

mostly i agreed. but to me plan9 is just an old 9front version without
the bootloader.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T8d272411830cebfc-Me49ce2009cac0e3bcb51a185
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]

[hiro]

> This was a simple comment on why I strongly disagreed with VT’s request for

it didn't get displayed as just a simple comment here. maybe you
should fix your email program.

> a 5th Release. I explained myself. I did not get emotional, nor am I
> emotional now.

How is this relevant to the technical issue at hand. You should
explain what has been asked and not yourself.

> What I did receive is a lot of strange emotional responses

If emotion is strange to you, please try to stay more technical. lots
of nerds here - no problem. or give it some time, maybe you can open
up when you cease reacting so fast and negatively to everything that
seems new to you.

> for which I have neither time nor interest. And frankly, neither should
> anyone here.

I'm sure you can make very long lists of things you're uninterested
in. But can you try to limit your talking points to things that
wouldn't be on such list?

> Who cares if I like 9front? I’m not against it, nor the developers. I’m
> simply against *joining* 9front with 9legacy/etc as a formal release. I
> personally believe that’s a bad move.

No worries, it is your reasoning, not your motivation that is at question here.
It might give an unjustified bad impression based solely on your error
of judgement.

9legacy already includes lots of 9front patches, and 9front includes
patches that have appeared before on mailinglists or 9legacy. Patches
are shared regularly, even though activity on 9front is much higher in
general.

The projects are all joined by a common history, and anybody who
doesn't like change is free to never pull from any of the forks,
mailinglists, or patch repositories.

> Don’t agree? Ok, so what? I’m one dude. And yet the gaggle of you people

I don't see how you being a dude is relevant on the internet.

> have tried to drag me down some psychoanalytical rabbit hole, and waste my
> entire day. And because I won’t let you drag me into it, and because I
> respond with short unemotional statements,

A play on rabbit hole -> glenda lair?
Also, these are the kind of promises that you should be making to
yourself, not to us.

> you somehow think *I’m* the bad
> guy because I won’t devolve into your world.

This is not some beauty contest.

> Geez guys seriously… go touch grass and have a life. Know what I did today
> instead of engaging with your bullshit? I did my job. I played with my son.
> I cooked us an amazing dinner. We built a fort. We looked at deer outside.
> We listened to music.

I'm extremely glad for you having such non-computer hobbies, and I
will always endorse people to seek out for that in their lives.

> All that because I didn’t waste my time with long bullshit responses that
> wouldn’t satisfy you, anyway, because I disagree with 9front being merged.

Why disagree with something that has never been suggested or implied
or thought of or done?

> Who cares?

Are you implying you don't? Then why ask?

> Live your life, man.

So far I believe we are in compliance.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M87fba6633c3911eb2034f856
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]

[hiro]

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

Nobody asked for your trust. Can you please elaborate which part of
9front you consider "messy" ?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M3d3fb12a535a7136b105cda2
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]

[hiro via 9fans]

> [...] then it is not surprising that people
> misunderstand your intentions.

and otherwise, too. you'll just have to adapt your predictions (or
expectations?) a little if you're so frequently surprised.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T42f11e0265bcfa18-M78c9e38af01976d49ea1ccf8
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]

[hiro via 9fans]

> 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

Re: [9fans] I would like to get off the mailing list

[hiro]

no.
remove yourself yourself.

On 11/9/23, yourlitlen1g@national.shitposting.agency
 wrote:
> Hello, I never participate in the mailing list, please remove me from
> the mailing list, thank you.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T82e0e631b89070c9-M3e52f5a480353d3b6efd016b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] fd and /srv filesystem

[hiro]

btw it's very common on unix to share FDs in multi-threaded programs.
and all the pain resulting from un-synchronised FD access is available
as expected :)

On 10/4/23, hiro <23h...@gmail.com> wrote:
> file descriptors describe to the kernel which of the files you
> previously open()'ed (a syscall) you want to operator on.
>
> it's not about security: if you want to operate on a file that another
> process might have opened before, you have to be careful that the
> other process isn't writing to the same location in the file at the
> same time. the kernel also keeps offsets for you.
>
> if you share FDs between multiple processes you might want some
> synchronisation like locking.
>
> On 10/4/23, Chris McGee  wrote:
>> Hi All,
>> 
>> I was thinking about file descriptors in the context of Plan 9. On Unix
>> an
>> fd is generally only usable by the current process, and child ones
>> through
>> a fork with some special incantation if one wants to communicate one over
>> a
>> domain socket. This is possibly for security reasons, avoiding other
>> users'
>> processes from trying to guess the fd of a critical file.
>> 
>> It's common practice in Plan 9 to post an fd (sometimes via a pipe) from
>> one process to the /srv filesystem so that others can discover it and
>> open
>> a comms channel. Does the kernel transform the fd into something when
>> posted to /srv so that it can be consumed by any other process in the
>> system?
>> 
>> Thanks,
>> Chris

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfaa2554a9b74c479-Mcf0b3c1629feb1b852c3224d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] fd and /srv filesystem

[hiro]

file descriptors describe to the kernel which of the files you
previously open()'ed (a syscall) you want to operator on.

it's not about security: if you want to operate on a file that another
process might have opened before, you have to be careful that the
other process isn't writing to the same location in the file at the
same time. the kernel also keeps offsets for you.

if you share FDs between multiple processes you might want some
synchronisation like locking.

On 10/4/23, Chris McGee  wrote:
> Hi All,
> 
> I was thinking about file descriptors in the context of Plan 9. On Unix an
> fd is generally only usable by the current process, and child ones through
> a fork with some special incantation if one wants to communicate one over a
> domain socket. This is possibly for security reasons, avoiding other users'
> processes from trying to guess the fd of a critical file.
> 
> It's common practice in Plan 9 to post an fd (sometimes via a pipe) from
> one process to the /srv filesystem so that others can discover it and open
> a comms channel. Does the kernel transform the fd into something when
> posted to /srv so that it can be consumed by any other process in the
> system?
> 
> Thanks,
> Chris

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tfaa2554a9b74c479-Md097c18fd19852d1e89a068c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] RPi in QEMU

[hiro]

> I didn't realize 9legacy actually had a distribution for some reason I
> thought it was only a patch set applied against the old main line. Glad I
> don't have to pick apart the patch set that (works)...

yes. i was expecting this confusion will arise some day. officially
it's a spoon, nor a fork.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M1db836357d101fab323e306d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] RPi in QEMU

[hiro]

ah no i was wrong. first google result "KVM support is available only
for 64-bit ARM architecture (AArch64"
oh well

On Sat, Aug 26, 2023 at 1:45 PM mkf  wrote:
>
> I believe KVM on aarch64 would help aarch64 guests.
> i could be wrong.
>
> On Sat, 26 Aug 2023 13:39:01 +0200
> hiro <23h...@gmail.com> wrote:
>
> > why do you assume kvm helps with emulating a raspberry?
> > kvm helps virtualize amd64 on amd64, and shouldn't be usable for much else.
> 
> -
> mkf

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M4a05d05887502397c942d91e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] RPi in QEMU

[hiro]

why do you assume kvm helps with emulating a raspberry?
kvm helps virtualize amd64 on amd64, and shouldn't be usable for much else.

On Sat, Aug 26, 2023 at 11:25 AM Philip Silva via 9fans <9fans@9fans.net> wrote:
> 
> Hi,
> 
> I've only tried qemu with 9front and this got me to a console (the files in 
> dos/ are from the image):
> 
> EXTRA_ARGS='user=glenda nobootprompt=local!/dev/sdM0/fs virtio nousbrc='
> qemu-system-aarch64 -M raspi3b -dtb dos/bcm2711-rpi-4-b.dtb  -kernel dos/9PI3 
> -append "console='1 b9600' core_freq=250 arm_64bit=1 gpu_mem=16 enable_uart=1 
> boot_delay=1 $EXTRA_ARGS"  -drive file=9front.img,if=sd,format=raw -serial 
> mon:stdio
> 
> It's awfully slow though but maybe it's possible to run fast with KVM.
> 
> Also I had been trying https://github.com/0xMirasio/qemu-patch-raspberry4.git 
> but I think it also works with an unpatched qemu.
> 
> Philip
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T5da5467097e4eab2-M9e2752b8f55ee0d3c306b0df
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Using 9front as a server

[hiro]

why don’t you follow the fqa
these port forwarding sound tedious

On 8/23/23, Sebastian Higgins  wrote:
> i'm assuming you're using QEMU + drawterm. if you're using QEMU you might
> need to add command line arguments for port forwarding. here's mine after
> tons of trial and error:
>
>> qemu-system-x86_64 -m 2048 -net nic,model=virtio,macaddr=00:20:91:37:33:77
>> -net
>> user,hostfwd=tcp:127.0.0.1:17564-:564,hostfwd=tcp:127.0.0.1:17010-:17010,hostfwd=tcp:127.0.0.1:17019-:17019,hostfwd=tcp:127.0.0.1:17020-:17020
>> -device virtio-scsi-pci,id=scsi -drive
>> if=none,id=vd0,file=9front.qcow2.img -device scsi-hd,drive=vd0
> 
> your mileage might vary.
> 
> 
> From: dusan3...@gmail.com 
> Sent: Tuesday, August 22, 2023 18:07
> To: 9fans
> Subject: [9fans] Using 9front as a server
> 
> I want to use my 9front booted from QEMU as a server, so i can transfer
> files from linux to 9front, but it wont open any ports. Help
> 9fans / 9fans / see
> discussions +
> participants + delivery
> options
> Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T1eb6489031b3e452-M7f1be698af6d80f48a8f4d22
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: How do I run plan9 in virtualbox?

[hiro]

oh, sorry for overlooking this mail before. so quite lucky for you
that this thread has clawed itself back out of it's grave.

the problem with vbox is the people who maintain it and allow bugs to
slip in on every other release. there is zero quality control.
normally, it's not a host/cpu issue and it's not a 9front issue. it's
a little babies like to rattle the box issue.

yay, and the 1001th support request about vbox has been answered. my pleasure.
please rate us with 5 stars for our continued engagement on this topic..
thank you.

On Thu, Aug 17, 2023 at 4:18 AM Don Bailey  wrote:
>
> forgot to respond to this but fwiw, running plan9 on virtualbox seems to work 
> peachy. Hiro what was the bug(s) you were running into before? I've never ran 
> into an issue with it, but I've only used vbox on Linux; maybe it's a 
> host/CPU issue?
>
> D
>
>
> On Wed, Aug 2, 2023 at 4:50 PM Robert W. Baskette  
> wrote:
>>
>>
>> If you feel like targeting ppc, you could host 9front in z/VM your z/Series.
>>
>> Here's some docs to get you started: 
>> https://www.ibm.com/docs/en/cic/1.1.4?topic=tutorials-getting-started-zvm
>>
>> On Wed, Aug 2, 2023 at 3:25 PM Don A. Bailey  wrote:
>>>
>>> If you’re not running plan9 on a Simics Alpha DEC hosted on a PA-RISC B 
>>> class workstation, are you even running plan9?
>>>
>>> On Aug 2, 2023, at 3:14 PM, redhatuser 
>>>  wrote:
>>>
>>> 
>>> So according to you, which one do you use?
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tce33a832621fe5a5-M31f436b5e339a1dfde758f89
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: How do I run plan9 in virtualbox?

[hiro]

I suppose hyper-v works on windows.

On Thu, Aug 17, 2023 at 9:09 AM Peter Hull  wrote:
>
> On Thu, 17 Aug 2023 at 03:18, Don Bailey  wrote:
> >
> > forgot to respond to this but fwiw, running plan9 on virtualbox seems to 
> > work peachy. Hiro what was the bug(s) you were running into before? I've 
> > never ran into an issue with it, but I've only used vbox on Linux; maybe 
> > it's a host/CPU issue?
> 
> My experience is that I ran 9front mostly successfully for a long
> time, but sometimes versions of either 9front or VB would conflict.
> Recently it stopped working for me:
> https://forums.virtualbox.org/viewtopic.php?t=109347
> I think the issue is that, due to the way it works (it's
> virtualisation, not an emulator), some aspects of the host CPU 'leak
> through' and that isn't always handled correctly. I had another issue
> with valgrind and Fedora linux which was down to the same thing.
> Someone once told me that QEMU always works, but last time I tried,
> QEMU is not very nice to use on Windows.
> Pete

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tce33a832621fe5a5-M6d274f0c9ffe52449e369f53
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: How do I run plan9 in virtualbox?

[hiro]

oh you don't want to know, but i'm telling you anyway: smartos.

On 8/2/23, redhatuser  wrote:
> So according to you, which one do you use?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tce33a832621fe5a5-M59f2dfce9b5d4cbe73769c32
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] How do I run plan9 in virtualbox?

[hiro]

not knowing how to use a VM is unusual. hard to beleive tbh. good
shitpost. will buy again.
virtualbox otoh is a usual error. avoid that solution.

On 8/2/23, yourlitlen1g@national.shitposting.agency
 wrote:
> I want to use plan9 in a virtual machine but I don't know how to install it

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tce33a832621fe5a5-M027cd01707ead07c3d2b3121
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9vx

[hiro]

in case somebody else is wondering what Stuart is talking about, he's
referencing a specific text passage using one of these google chrome
specific features:

https://web.dev/text-fragments/

On 6/26/23, Stuart Morrow  wrote:
>> Another interesting project would be seeing if it could be
>> modified to work as a 64-bit binary but still running a 32-bit
>> environment
>> on the inside...
> 
> 
> https://pdos.csail.mit.edu/papers/vx32:usenix08/#:~:text=The%20recent%2064,bit%20host%20application.
> 
> This needs to happen. I'd use it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T13921a25ae477a65-M88a880c0f59a83705d10b847
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] [PATCH] fossil: fix a deadlock in the caching logic

[hiro]

fixing another couple deadlocks makes you finally consider ditching fossil?
zfs storage isn't always permanent either, for example if you use
encryption or deduplication.

On 4/6/23, Lucio De Re  wrote:
> On 4/6/23, n...@pixelhero.dev  wrote:
>> Quoth Charles Forsyth :
>>> fussing about certain things for hard drives that probably don't matter
>>> for
>>> SSD let alone nvme
>>
>> I am once again asking you to be more specific, please :)
>>
>> I have Plans for improving venti for myself, it'd be great to actually
>> have a specific list of issues that others have noticed!
>>
> I presume that fossil doesn't apply special treatment to SSD and NVME
> which to my limited understand could be a serious downside. I guess
> I'm asking whether one should seriously consider ditching the
> fossil/venti combination and consider centralising permanent storage
> on something like ZFS instead?
> 
> Lucio.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T354fe702e1e9d5e9-Md68125af550af6687f52fa58
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

it's not that bad IMO, but you will have to live with having to redo
everything and lose all the data.

i have installed to usb flash drives before for some short temporary
tests. no big deal, if you don't need to keep anything of it...

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

Re: [9fans] Acme: support spaces in file|dir names

[hiro]

> Sorry hiro, I mean that I imported the acme version of 9front to
> my system (based on 9legacy) because it has been updated along the
> plan9port repo.

h, sorry for missing the other direction :D

> One thing I can't understand is why the text window
> is always redrawn completely when the tag line is edited.

yeah, i heard about that one, it's a bit surprising that's still not fixed.
but many people use just sam on 9front and never notice such things.
my memory of acme is fading :)

> Anyway, I remember seeing a version of plan9port with the apps from
> 9front somewhere, I'm surprised you didn't know about it.

yeah in fact i wanted to make sure you don't use that one, bec. really
it never got much care and 9fans/p9p was always it's upstream.

otherwise, i guess there's also the inferno version of acme (i am a
former acme-sac user).

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc1d9d9ca3a94e285-M40d76eccd7f7ae74ec0ac0b0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Acme: support spaces in file|dir names

[hiro]

9front has a p9p version? i was not aware... can you link to it?

On 2/20/23, adr  wrote:
> Hi,
> 
> this patch adds code from p9p to support spaces in file or dir
> names. I use the 9front version because it has been mantained, but
> there are more fixes in p9p to be imported.
> 
> adr
> diff -Nur /n/9front/sys/src/cmd/acme/fns.h /sys/src/cmd/acme/fns.h
> --- /n/9front/sys/src/cmd/acme/fns.hMon Jul 11 20:01:08 2022
> +++ /sys/src/cmd/acme/fns.h Mon Feb 20 15:23:42 2023
> @@ -90,6 +90,7 @@
>   void  flushwarnings(void);
>   long  nlcount(Text*, long, long, long*);
>   long  nlcounttopos(Text*, long, long, long);
> +Rune*  parsetag(Window*, int, int*);
> 
> #define   runemalloc(a)   (Rune*)emalloc((a)*sizeof(Rune))
> #define   runerealloc(a, b)   (Rune*)erealloc((a),
> (b)*sizeof(Rune))
> diff -Nur /n/9front/sys/src/cmd/acme/look.c /sys/src/cmd/acme/look.c
> --- /n/9front/sys/src/cmd/acme/look.c   Mon Jul 11 20:01:08 2022
> +++ /sys/src/cmd/acme/look.cMon Feb 20 15:47:24 2023
> @@ -397,9 +397,9 @@
> Runestr
> dirname(Text *t, Rune *r, int n)
> {
> -   Rune *b, c;
> -   uint m, nt;
> -   int slash;
> +   Rune *b;
> +   uint nt;
> +   int slash, i;
>   Runestr tmp;
> 
> b = nil;
> @@ -410,15 +410,13 @@
> goto Rescue;
> if(n>=1 && r[0]=='/')
> goto Rescue;
> -   b = runemalloc(nt+n+1);
> -   bufread(t->w->tag.file, 0, b, nt);
> +   b = parsetag(t->w, n, );
> slash = -1;
> -   for(m=0; m -   c = b[m];
> -   if(c == '/')
> -   slash = m;
> -   if(c==' ' || c=='\t')
> +   for(i--; i >= 0; i--){
> +   if(b[i] == '/'){
> +   slash = i;
> break;
> +   }
> }
> if(slash < 0)
> goto Rescue;
> @@ -502,7 +500,7 @@
> if(nname == -1)
> nname = n;
> for(i=0; i -   if(!isfilec(r[i]))
> +   if(!isfilec(r[i]) && r[i] != ' ')
> goto Isntfile;
> /*
>  * See if it's a file name in <>, and turn that into an include
> diff -Nur /n/9front/sys/src/cmd/acme/wind.c /sys/src/cmd/acme/wind.c
> --- /n/9front/sys/src/cmd/acme/wind.c   Mon Jul 11 20:01:08 2022
> +++ /sys/src/cmd/acme/wind.cMon Feb 20 15:20:37 2023
> @@ -109,14 +109,26 @@
> return rr - r;
> }
> 
> +int
> +delrunepos(Window *w)
> +{
> +   Rune *r;
> +   int i;
> +
> +   r = parsetag(w, 0, );
> +   free(r);
> +   i += 2;
> +   if(i >= w->tag.file->nc)
> +   return -1;
> +   return i;
> +}
> +
>   void
>   movetodel(Window *w)
>   {
> int n;
> -
> -   n = tagrunepos(w, delcmd);
> -   free(delcmd);
> -   delcmd = nil;
> +
> +   n = delrunepos(w);
> if(n < 0)
> return;
> moveto(mousectl, addpt(frptofchar(>tag, n), Pt(4,
> w->tag.font->height-4)));
> @@ -141,7 +153,7 @@
> 
> if(!w->tagexpand) {
> /* use just as many lines as needed to show the Del */
> -   n = tagrunepos(w, delcmd);
> +   n = delrunepos(w);
> if(n < 0)
> return 1;
> p = subpt(frptofchar(>tag, n), w->tag.r.min);
> @@ -412,11 +424,7 @@
> 
> /* w must be committed */
> n = w->tag.file->nc;
> -   r = runemalloc(n);
> -   bufread(w->tag.file, 0, r, n);
> -   for(i=0; i -   if(r[i]==' ' || r[i]=='\t')
> -   break;
> +   r = parsetag(w, 0, );
> for(; i if(r[i] == '|')
> break;
> @@ -433,6 +441,38 @@
> textsetselect(>tag, w->tag.q0, w->tag.q1);
> }
> 
> +Rune*
> +parsetag(Window *w, int extra, int *len)
> +{
> +   static Rune Ldelsnarf[] = { ' ', 'D', 'e', 'l', ' ', 'S', 'n', 'a',
> 'r', 'f', 0 };
> +   static Rune Lspacepipe[] = { ' ', '|', 0 };
> +   static Rune Ltabpipe[] = { '\t', '|', 0 };
> +   int i;
> +   Rune *r, *p, *pipe;
> +
> +   r = runemalloc(w->tag.file->nc+extra+1);
> +   bufread(w->tag.file, 0, r, w->tag.file->nc);
> +   r[w->tag.file->nc] = '\0';
> +
> +   /*
> +* " |" or "\t|" ends left half of tag
> +* If we find " Del Snarf" in the left half of the tag
> +* (before the pipe), that ends the file name.
> +*/
> +   pipe = runestrstr(r, Lspacepipe);
> +   if((p = runestrstr(r, Ltabpipe)) != nil && (pipe == nil || p <
> pipe))
> +   pipe = p;
> +   if((p = runestrstr(r, Ldelsnarf)) != nil && (pipe == nil || p <
> pipe))
> +   i = p - r;
> +   else {
> +   for(i=0; itag.file->nc; i++)
> +   if(r[i]==' ' || r[i]=='\t')
> +   break;
> +   }
> +   *len = i;
> +   return r;
> +}
> +
>   void
>   winsettag1(Window *w)
>   {
> @@ -445,12 +485,7 @@
> /* there are races that get us here with stuff in the tag cache, so
> we take extra care to sync it */
> if(w->tag.ncache!=0 || w->tag.file->mod)
> 

Re: [9fans] different users for different system roles

[hiro]

agreed. compartmentalization might be used to have less
users/passwords than servers. if two cpu servers are used
interchangably for the same usecase by the same end-users, why not
give them the same credentials.

next time please try to quote correctly, lyndon.

On 2/14/23, Lyndon Nerenberg (VE7TFX/VE6BBM)  wrote:
> hiro writes:
>> > should each system role get his own user?
>> > Like one user for file servers, one for auth, one for venti, and one for
>> cpu
>> > servers.
>
> My was has always been to have a file system user and an auth server
> user that are used ONLY for those roles.
>
> As for CPU servers, it really depends on how you use them.  The
> main reason you might want to have different CPU server owners is
> to control access to physical hardware.  E.g. I have machines that
> are used to control my radios via their serial and USB interfaces.
> For those, I don't want the "general pupulation" to have access to
> that hardware, so I run those servers under a userid that is distinct
> from the "general purpose" CPU server owner.
>
> Oh, the Pi I use for bluetooth dev work has its own host owner,
> for similar reasons.
>
> I'm sure there are other cases, but that's the only one where I've
> personally had a need for multiple host owners.
>
> --lyndon
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T690e4304847a34e4-M17036caa82debd1aa65af977
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] different users for different system roles

[hiro]

> should each system role get his own user?
> Like one user for file servers, one for auth, one for venti, and one for cpu
> servers.
> Is there any point in doing that

Yes, if you share one authserver, then you'd have to use different
users in order to be allowed to use different passwords. If you're
fine with somebody finding out one password being able to access all
your services, then it doesn't matter.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T690e4304847a34e4-M9d955c794ba5a3d22eca17b4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] the practicality of plan 9

[hiro]

why not get a used apu2 instead.
it comes with 3 real ethernet ports

On 11/10/22, fig  wrote:
> i did think of this, but i was unsure of its compatibility with 9front. the
> FQA only
> lists two usb to ethernet adapters which did not look popular or generic
> when i looked them up. i will buy the most popular one and hope it works.
>
> On Wed, Nov 9, 2022 at 7:55 PM  wrote:
>
>> You can use a usb to ethernet adapter to add more ethernet to a pi.  The
>> ethernet on a raspberry 3 is actually just a usb to ethernet soldered
>> right
>> onto the board.
>> *9fans * / 9fans / see discussions
>>  + participants
>>  + delivery options
>>  Permalink
>> 
>>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td6c4be6d8502dbd0-M3923a7a1d4aadfd9c0de7ffc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Plan 9 not selected for GSoC

[hiro]

> course, but maybe FreeBSD needs a 9p client or you want to get ffmpeg
> building on Plan 9 again. :-)

https://sr.ht/~ft/treason/

i know it's not the same, but i thought linking it here might help
somebody in the future

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tc5948a70f3fe536f-Ma28e6a6280c90afcb8cb13a5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] USB3 1Gb ethernet card working on 9legacy (rpi 4)

[hiro]

"Esta página no existe :("

On 7/31/22, a...@sdf.org  wrote:
> https://es.aliexpress.com/item/1005003167747779.html
> 
> First time using usb/ether, so let me share my experience for other users.
> 
> This is on the last 9pi image at 9legacy.
> 
> First, I added a line with did=0x8153 to /sys/src/cmd/usb/usbd/usbdb.
> Browsing the list's archives I thought that ether1=type=usb should be
> added to the configuration file (cmdline.txt on the pi), but etherusb
> wasn't in the link section of the pi4 kernel configuration file, so #l1
> wasn't created. I added, compiled the kernel and then a dummy #l1 was
> created, impossible to configure. I could use manually usb/ether and
> configure the device mounted in /net, but usbd didn't detect the usb
> card. Then I removed the ether parameters in cmdline.txt and etherusb
> from pi4 to be sure, now usbd recognize the card and creates the
> device /dev/etherU0. Other programs expect the devices mounted in
> /net. I'm binding the device inside a directory in /tmp and then
> binding this directory to /net. I would appreciate if someone shares
> the correct way of doing this.
> 
> In summary, the sequence was:
> ether1=type=usb in plan9.ini (cmdline.txt)
> etherusb in kernel config
> #l1 is created but useless
> usbd doesn't work because etherusb
> usb/ether works and the device appears on /net/
> remove ether1=type=usb and etherusb from the kernel
> now usbd works but the device doesn't appear on /net but on /dev
> 
> I finally made it work, but this is a mess, really.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T668643d11149fab4-M41f3c473944e9028dfd35bfa
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

On 6/1/22, Steve Simon  wrote:
> for performance testing why not copy from ramfs on one machine to ramfs on
> another?

ramfs is single-process and thus quite slow.

> the suggestion from a 9con passim was to have fossil/cwfs/hjfs etc add a Qid
> type flag to files indicating they are from backing store (QTSTABLE ?)and
> thus may be copied in parallel. devices and synthetic would not normally
> have this flag forcing the read or write be sequential.

yeah, that's what my comment about readahead is based on. this work
has been already done at least for cwfs.

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

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

[hiro]

In case this is not immediately clear: theoretically preventable 1rtt
minimum delays are much less bad than the practically unbounded
maximum delays in congested networks.

Put in another way: making some few things fast is much more easy than
making sure that everything else doesn't get infinitely slow as a
result to this.

Right now huge streams don't get huge unfair advantages unless the rtt
is very small or the parallelism very high

On 6/1/22, hiro <23h...@gmail.com> wrote:
> I don't think the reason nobody is doing this is that it's difficult per
> se.
>
> Fcp also achieves parallelism without any changes to 9p.
>
> And posix fs also share some of our statefulness.
>
> A file system can have offsets, readahead can help.
>
> Other synthetic FS need different tricks, but we can exchange some
> guarantees that are only needed in seekable files for an optimization
> that shall only be done on pipes and streaming access.
>
> There's some trivial heuristic solutions for this but they are not
> generic naturally.
>
> If one were to do this right, after a few increments one will see that
> bandwidth limits are hit, which is a new problem that is much harder
> to solve and impossible without even more heuristics classifications
> possibly applied by a distributed 9p scheduler (dynamic multi hop
> network congestion awareness anybody?)
>
> On 6/1/22, ron minnich  wrote:
>> On Tue, May 31, 2022 at 11:29 AM hiro <23h...@gmail.com> wrote:
>>>
>>> so virtiofs is not using 9p any more?
>>>
>>> and with 10 million parallel requests, why shouldn't 9p be able to
>>> deliver 10GB/s ?!
>> 
>> Everyone always says this. I used to say it too.
>> 
>> 9p requires a certain degree of ordering -- as Andrey once pointed
>> out, it's not productive to close a file, then write it. So there is a
>> tricky ordering requirement you need to get right, due to Plan 9 being
>> stateful.
>> 
>> The way we use 9p in Plan 9, as a general purpose protocol for
>> everything, like devices, requires that each Tread or Twrite occur in
>> order, but also requires that each T be retired before the next T is
>> issued. devmnt does  this. If you don't do this, hardware can get
>> confused (e.g. ordering of Twrite followed by Tread followed by Twrite
>> needs to be maintained. E.g. you don't want to issue the Tread before
>> you know the Twrite happened.  E.g. pre-posting 100 Treads to
>> /dev/mouse is not a good idea if you suddenly want to do a Twrite in
>> the middle of it).
>> 
>> This is why 9p starts to perform poorly in networks with high
>> bandwidth*delay products -- if you watch the net traffic, you see each
>> T op  on fid blocked by the previous Reply (by devmnt).
>> 
>> I never figured out a way to fix this without fixing devmnt -- by
>> removing its general nature.
>> 
>> But, more to the point, whether or not 9p should be able to do all
>> these parallel requests and get high performance, nobody has yet done
>> it. The only numbers ever reported for making high bandhwidth*delay
>> networks better were in Floren's thesis, when he added Tstream.
>> 
>> After 20+ years of this discussion, I start to wondering whether it's
>> harder than it looks.
>> 
>> ron

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

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

[hiro]

I don't think the reason nobody is doing this is that it's difficult per se.

Fcp also achieves parallelism without any changes to 9p.

And posix fs also share some of our statefulness.

A file system can have offsets, readahead can help.

Other synthetic FS need different tricks, but we can exchange some
guarantees that are only needed in seekable files for an optimization
that shall only be done on pipes and streaming access.

There's some trivial heuristic solutions for this but they are not
generic naturally.

If one were to do this right, after a few increments one will see that
bandwidth limits are hit, which is a new problem that is much harder
to solve and impossible without even more heuristics classifications
possibly applied by a distributed 9p scheduler (dynamic multi hop
network congestion awareness anybody?)

On 6/1/22, ron minnich  wrote:
> On Tue, May 31, 2022 at 11:29 AM hiro <23h...@gmail.com> wrote:
>>
>> so virtiofs is not using 9p any more?
>>
>> and with 10 million parallel requests, why shouldn't 9p be able to
>> deliver 10GB/s ?!
> 
> Everyone always says this. I used to say it too.
> 
> 9p requires a certain degree of ordering -- as Andrey once pointed
> out, it's not productive to close a file, then write it. So there is a
> tricky ordering requirement you need to get right, due to Plan 9 being
> stateful.
> 
> The way we use 9p in Plan 9, as a general purpose protocol for
> everything, like devices, requires that each Tread or Twrite occur in
> order, but also requires that each T be retired before the next T is
> issued. devmnt does  this. If you don't do this, hardware can get
> confused (e.g. ordering of Twrite followed by Tread followed by Twrite
> needs to be maintained. E.g. you don't want to issue the Tread before
> you know the Twrite happened.  E.g. pre-posting 100 Treads to
> /dev/mouse is not a good idea if you suddenly want to do a Twrite in
> the middle of it).
> 
> This is why 9p starts to perform poorly in networks with high
> bandwidth*delay products -- if you watch the net traffic, you see each
> T op  on fid blocked by the previous Reply (by devmnt).
> 
> I never figured out a way to fix this without fixing devmnt -- by
> removing its general nature.
> 
> But, more to the point, whether or not 9p should be able to do all
> these parallel requests and get high performance, nobody has yet done
> it. The only numbers ever reported for making high bandhwidth*delay
> networks better were in Floren's thesis, when he added Tstream.
> 
> After 20+ years of this discussion, I start to wondering whether it's
> harder than it looks.
> 
> ron

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

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

[hiro]

And fcp?

On 6/1/22, Bakul Shah  wrote:
> On May 31, 2022, at 9:14 AM, ron minnich  wrote:
>>
>> On Mon, May 30, 2022 at 12:21 AM Bakul Shah  wrote:
>>> 9p itself is low performance but that is a separate issue.
>>
>> Bakul, what are the units? It might be helpful to quantify this
>> statement. Are you possibly conflating Plan 9 file systems being slow
>> and 9p being slow?
>
> I did a quick test:
>
> From a 9front VM to another machine I get about 11.7 MBps
> caching. The first time around it was close to 7.3 MBps).
>
> From an Ubuntu VM to another machine I get about 111 MBps
> (cached. The first time around it was close to 62 MBps).
>
> Both VMs run on the same host. Test copies to the same target
> machine. I used 9p read for 9front, scp for Linux, copy to
> /dev/null. The target machine is freebsd. The VMs talk to
> the target over a 1Gbps ethernet (so 111 MBps is the wirespeed
> limit).
>
> 9front uses hjfs. Ubuntu uses ext4. On the host I give a file
> as the guest "disk", using 'nvme' type device on bhyve to each
> VM. Both 9front and ubuntu are 64 bit kernels.
>
> This is a very rough measurement as there are many differences
> between the systems. The filesystem overhead is clearly an issue
> but 10 times worse?
> -
> Looking at the protocol:
>
> For read/write 9p uses 4 byte for size so in theory you can send
> very large packets but then you have to buffer up a lot of data.
> Ideally you want streaming (some sort of sliding window). May be
> you can use the tag field to do something more intelligent. Not
> sure any implementations do so. You also have head of line blocking
> if you can have only one TCP connection to a server.
>
>> As Rob pointed out in 2013, "If go install is slow on Plan 9, it's
>> because Plan 9's file system is
>> slow (which it is and always has been)", so slowness in Plan 9 file
>> systems is to be expected.
>>
>> 9p itself does have its limits, which is why Bell Labs Antwerp started
>> an effort in 2011 to replace it, but the new work never went very far.
>>
>> I also know of a number of efforts in the virtualization world where
>> 9p was discarded for performance reasons. It's hard to argue with the
>> 100x performance improvement that comes with virtiofs, for example.
>
>
> Why is virtiofs 100x faster? Just lot of hardwork and tuning?
> May be that is good place to look to learn what needs to change
> (in case someone wants to replace 9p with something else)?
>
>> Gvisor is replacing 9p: https://github.com/google/gvisor/milestone/6.
>> Although, in the latter case, I would argue the problem is more with
>> Linux limitations than 9p limitations -- linux can't seem to walk more
>> than one pathname component at a time, for example, since it has the
>> old school namei loop.
>>
>> But I'm wondering if you have a measurement with numbers.
>>
>> For rough order of magnitude, HPC file systems can deliver 10 Gbytes/
>> second for file reads nowadays, but getting there took 20 years of
>> work. When we ran Plan 9 on Blue Gene, with the 6 Gbyte/second
>> toroidal mesh connect for each node, we never came remotely close to
>> that figure.
> 
> Given that experience, why do you need "numbers"? :-)
> 
> Running 10Gbps links even @ home is quite doable now. With TCP you
> can achieve decent performance if not quite wirespeed. NVMe "disks"
> are pretty damn fast - you can easily get 2-4 GBps. But I think at
> remote filesystem protocol level you'd have to optimize multiple
> things in order to get close to wirespeed performance. Minimize
> copying, increase concurrency, reduce overhead in frequently used
> common path code, reduce user/kernel crossings etc. I think rdma and
> mmap will probably get used a lot too (obviously on non-plan9 OSes!).
> May be if you pushed 9p knowledge down to a smart NIC, it can map a
> tag value to compute location where the data needs to go.
> 
> But all this is just handwaving. Without a real project and funding
> it is hard to get sufficiently motivated to do more.
> 

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

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

[hiro]

so virtiofs is not using 9p any more?

and with 10 million parallel requests, why shouldn't 9p be able to
deliver 10GB/s ?!

On 5/31/22, ron minnich  wrote:
> On Mon, May 30, 2022 at 12:21 AM Bakul Shah  wrote:
>> 9p itself is low performance but that is a separate issue.
> 
> Bakul, what are the units? It might be helpful to quantify this
> statement. Are you possibly conflating Plan 9 file systems being slow
> and 9p being slow?
> 
> As Rob pointed out in 2013, "If go install is slow on Plan 9, it's
> because Plan 9's file system is
> slow (which it is and always has been)", so slowness in Plan 9 file
> systems is to be expected.
> 
> 9p itself does have its limits, which is why Bell Labs Antwerp started
> an effort in 2011 to replace it, but the new work never went very far.
> 
> I also know of a number of efforts in the virtualization world where
> 9p was discarded for performance reasons. It's hard to argue with the
> 100x performance improvement that comes with virtiofs, for example.
> 
> Gvisor is replacing 9p: https://github.com/google/gvisor/milestone/6.
> Although, in the latter case, I would argue the problem is more with
> Linux limitations than 9p limitations -- linux can't seem to walk more
> than one pathname component at a time, for example, since it has the
> old school namei loop.
> 
> But I'm wondering if you have a measurement with numbers.
> 
> For rough order of magnitude, HPC file systems can deliver 10 Gbytes/
> second for file reads nowadays, but getting there took 20 years of
> work. When we ran Plan 9 on Blue Gene, with the 6 Gbyte/second
> toroidal mesh connect for each node, we never came remotely close to
> that figure.

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

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

[hiro]

> 9p itself is low performance but that is a separate issue.

wrong

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

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

[hiro]

> the challenge is that 9p is stateful, so all servers must
> replay the same messages in the same order

no, not all servers.
9p state could be faked, that's not the main problem here.
the main problem is the higher layer application logic per server.
this is both good and bad.
e.g. some very few servers are stateless in this sense.
a lot of servers are stateful in a way that it becomes near-impossible
to recreate the state somewhere else.
there's also the "most stateful" of servers, the fileserver, which we
*can* reconnect to trivially in some edge-cases, because disk files
always support seeking, if we sync the open/seeked files and
positions.

by ignoring those layers of abstraction on top of 9p it looks like 9p
can provide for some kind of easy magic solutions. but that's just
because 9p is simple and doesn't do much at all, not much magic
either. impossible.

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

Re: [9fans] Aarch64 on labs|9legacy?

[hiro]

> Thaddeus, you can go and plumb yourself

hahahaha

i see you stopped using these bad words.

> Trolling and bullshit, as always.

oh maybe i was wrong.

another generalization, as always.
i'm so done in those pants!

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td5407cac4afa27f1-M7dbfd78bd408526bc10bb832
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[hiro]

> Good troll skills, but you are not dealing with a young hipster,
> I'm a middle-aged man who never have bought an overpriced piece of
> fashion-tech-crap like that in my life. And before you try another
> piece from your popular repertoire, I don't use twitter, facebook,
> instagram, 

did somebody propose to you yet? (the rest off-list)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td5407cac4afa27f1-Mba509d213c840015a740c4ca
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[hiro]

ah, so reverse-marketing. also appreciated :D

i'm just trying to make sure we're all having fun here.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td5407cac4afa27f1-Md14ba5c12d2a1d9c73926ba5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[hiro]

> Great.

indeed. thank charles and cinap for it.

> Because with this 4 magical words I was supposed to find... what?
> Where? What are you talking about?

magical words? what *are* you talking about!

> Where is this work on Bell Labs'
> plan9

Bell Labs is not working on plan9 any more.

> What are you talking about?

yes.

> You haven't help me to find anything, you don't have to do it, of
> course, but then don't talk like you have done it.

it's just that you don't like what you found. he helped by making sure
there would be a compiler.

you don't like the compiler because it has the wrong brandname
attached to it, and the wrong people are playing with it, am i right?

> A simple question, a fucking simple question and here we go with
> the trolling and the bullshit, I'm done with this fucking list.

maybe go back to playing with your new macbook? there's good customer
support for that.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M65ef7c5b80d1d8532cd3a834
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Aarch64 on labs|9legacy?

[hiro]

oops, i forgot there was also 32bit :D

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M2f1b643ac87d6121ac4c8ef8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription