[9fans] Interoperating between 9legacy and 9front

[9fans] Interoperating between 9legacy and 9front

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 2870 bytes --]

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.

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

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

I must admit I got to know nits in these two distributions that I would
rather I didn't have to, but I've just about had enough.

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

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

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

[-- Attachment #2: Type: text/html, Size: 3745 bytes --]

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

[Jacob Moody]

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

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

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

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

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

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

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


Good luck,
moody


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

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

[vester.thacker]

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 sound like you're trying to make this someone else's problem.
> Being stuck in a hardware pickle when there are ample existing software 
> solutions is not
> a good reason to ask someone else to go out of their way to write 
> software.
>
> Fossil can be pulled in largely without modifications as I understand it,
> I don't run fossil but some people in the 9front community do and it does
> not appear to me that they've had issues with continuing to have it work
> (other then fossil bugs itself).
>
>> 
>> I managed to share the Fossil cache through a NetBSD server providing u9fs services, but that host does not have the capacity to store the Venti arenas, nor can I really justify spending the amount of time it would take to pass it between the 9legacy and 9front devices via NetBSD, no matter how I try to arrange that. It does baffle me, though, that a NetBSD intermediary is more competent than the two "native" platforms.
> 
> Are you blaming us for moving on from AES 53 bit keys that can be brute
> forced in an afternoon?
> I have tried to open a dialogue for getting dp9ik on 9legacy a couple
> times now, when I had brought it
> up I am told to write the patch. Something about being asked to spend
> the work to write a patch for 9legacy given
> the historical context of why 9front exists does not sit right with me.
> So it wont be me, sorry.
> Sure it sucks that things have drifted, but all our code is there,
> neatly organized out in to commits, if someone
> wants to import our work it is readily available. However something
> tells me most people are just going to use 9front as is.
> 
> Good luck,
> moody
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mcbddcaf6a50bb11880d9f095
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 <vester.thacker@fastmail.fm> 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 sound like you're trying to make this someone else's problem.
> > Being stuck in a hardware pickle when there are ample existing software
> > solutions is not
> > a good reason to ask someone else to go out of their way to write
> > software.
> >
> > Fossil can be pulled in largely without modifications as I understand it,
> > I don't run fossil but some people in the 9front community do and it does
> > not appear to me that they've had issues with continuing to have it work
> > (other then fossil bugs itself).
> >
> >>
> >> I managed to share the Fossil cache through a NetBSD server providing u9fs services, but that host does not have the capacity to store the Venti arenas, nor can I really justify spending the amount of time it would take to pass it between the 9legacy and 9front devices via NetBSD, no matter how I try to arrange that. It does baffle me, though, that a NetBSD intermediary is more competent than the two "native" platforms.
> >
> > Are you blaming us for moving on from AES 53 bit keys that can be brute
> > forced in an afternoon?
> > I have tried to open a dialogue for getting dp9ik on 9legacy a couple
> > times now, when I had brought it
> > up I am told to write the patch. Something about being asked to spend
> > the work to write a patch for 9legacy given
> > the historical context of why 9front exists does not sit right with me.
> > So it wont be me, sorry.
> > Sure it sucks that things have drifted, but all our code is there,
> > neatly organized out in to commits, if someone
> > wants to import our work it is readily available. However something
> > tells me most people are just going to use 9front as is.
> >
> > Good luck,
> > moody
> >

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

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

[vic.thacker]

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 <vester.thacker@fastmail.fm> 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 sound like you're trying to make this someone else's problem.
>> > Being stuck in a hardware pickle when there are ample existing software
>> > solutions is not
>> > a good reason to ask someone else to go out of their way to write
>> > software.
>> >
>> > Fossil can be pulled in largely without modifications as I understand it,
>> > I don't run fossil but some people in the 9front community do and it does
>> > not appear to me that they've had issues with continuing to have it work
>> > (other then fossil bugs itself).
>> >
>> >>
>> >> I managed to share the Fossil cache through a NetBSD server providing u9fs services, but that host does not have the capacity to store the Venti arenas, nor can I really justify spending the amount of time it would take to pass it between the 9legacy and 9front devices via NetBSD, no matter how I try to arrange that. It does baffle me, though, that a NetBSD intermediary is more competent than the two "native" platforms.
>> >
>> > Are you blaming us for moving on from AES 53 bit keys that can be brute
>> > forced in an afternoon?
>> > I have tried to open a dialogue for getting dp9ik on 9legacy a couple
>> > times now, when I had brought it
>> > up I am told to write the patch. Something about being asked to spend
>> > the work to write a patch for 9legacy given
>> > the historical context of why 9front exists does not sit right with me.
>> > So it wont be me, sorry.
>> > Sure it sucks that things have drifted, but all our code is there,
>> > neatly organized out in to commits, if someone
>> > wants to import our work it is readily available. However something
>> > tells me most people are just going to use 9front as is.
>> >
>> > Good luck,
>> > moody
>> >

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

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

[wb.kloke]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

I am using fossil on plan9port (which should be similar to 9legacy) from 9front. The only thing which I needed was to enable p9sk1 for the hostowner on 9front  (the auth server) and a factotum entry for this in the file server, IIRC.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M7ea4a9b3813f6d25dfac622b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 954 bytes --]

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

That seems simple enough, but "enable p9sk1 for the hostowner on 9front"
isn't something I'm familiar with. Is it an additional attribute in the
network database that I am not aware of?

I will check the manual pages, although I'm not sure what to look for. I
did note when creating a user or similar activity that a special case was
made to include p9sk1 somewhere and I did later wonder about it, which is
what my long question was all about, but I could not see where the details
were hiding.

Much appreciated, in any case, thank you.

And, yes, plan9port is based on what has now become 9legacy, but there are
significant 9front contributions. It would have been quite helpful if p9p
development had been farmed out to a team comprising developers (and
designers) from both camps.

Lucio.

On Thu, May 9, 2024 at 11:06 AM <wb.kloke@gmail.com> wrote:

> I am using fossil on plan9port (which should be similar to 9legacy) from
> 9front. The only thing which I needed was to enable p9sk1 for the hostowner
> on 9front  (the auth server) and a factotum entry for this in the file
> server, IIRC.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M7ea4a9b3813f6d25dfac622b>
>


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

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

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

[-- Attachment #2: Type: text/html, Size: 2491 bytes --]

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

[wb.kloke]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

Installing fossil on 9front is not really difficult. Fossil is just a userland server which probably can even be copied as a binary, as long as the cpu is the same.

Here are the hostowner factotum/ctl readout from the auth server:

key proto=p9sk1 user=bootes dom=fritz.box  !password?
key proto=dp9ik user=bootes dom=fritz.box  !password?

and from the plan9port fossil server (which doesn't know dp9ik):
key dom=fritz.box proto=p9sk1 user=bootes !password?

I installed the standard /lib/ndb/auth:

hostid=bootes
      uid=!sys uid=!adm uid=*

Though, Moody's advice to try disabling auth in the fossil server  using the fossilcons may be a far simpler solution.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M680f6580845ab41d3d8cb120
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2412 bytes --]

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

[kvik]

> Installing fossil on 9front is not really difficult.

Correct. You only need to grab the source of it from your favorite vendor,
place it into right places and build it like any other system program.

Here's a script I wrote some years ago to do exactly that:

  https://hg.sr.ht/~kvik/fossil-up/raw/mkfile?rev=tip

I've no idea if it still works as-is and you should probably just do the
steps manually anyway.

Integrating fossil back into 9front so that it can be installed from a live
CD and booted from in its many possible configurations is gonna take more
effort and be of dubious value.

You're all better off cheering for Ori for his progress on gefs, which might
finally let you to store some files on this cursed system and go to sleep.

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

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

[Lucas Francesco]

https://seh.dev/p9sk1/

On Thu, 9 May 2024 at 08:01, Lucio De Re <lucio.dere@gmail.com> wrote:
>
> That seems simple enough, but "enable p9sk1 for the hostowner on 9front" isn't something I'm familiar with. Is it an additional attribute in the network database that I am not aware of?
>
> I will check the manual pages, although I'm not sure what to look for. I did note when creating a user or similar activity that a special case was made to include p9sk1 somewhere and I did later wonder about it, which is what my long question was all about, but I could not see where the details were hiding.
>
> Much appreciated, in any case, thank you.
>
> And, yes, plan9port is based on what has now become 9legacy, but there are significant 9front contributions. It would have been quite helpful if p9p development had been farmed out to a team comprising developers (and designers) from both camps.
>
> Lucio.
>
> On Thu, May 9, 2024 at 11:06 AM <wb.kloke@gmail.com> wrote:
>>
>> I am using fossil on plan9port (which should be similar to 9legacy) from 9front. The only thing which I needed was to enable p9sk1 for the hostowner on 9front  (the auth server) and a factotum entry for this in the file server, IIRC.
>
>
>
> --
> 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/Tde2ca2adda383a3a-M5816d9f941744129e57c0c84
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[ori]

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.

Quoth Lucas Francesco <lucas.francesco93@gmail.com>:
> https://seh.dev/p9sk1/
> 
> On Thu, 9 May 2024 at 08:01, Lucio De Re <lucio.dere@gmail.com> wrote:
> >
> > That seems simple enough, but "enable p9sk1 for the hostowner on 9front" isn't something I'm familiar with. Is it an additional attribute in the network database that I am not aware of?
> >
> > I will check the manual pages, although I'm not sure what to look for. I did note when creating a user or similar activity that a special case was made to include p9sk1 somewhere and I did later wonder about it, which is what my long question was all about, but I could not see where the details were hiding.
> >
> > Much appreciated, in any case, thank you.
> >
> > And, yes, plan9port is based on what has now become 9legacy, but there are significant 9front contributions. It would have been quite helpful if p9p development had been farmed out to a team comprising developers (and designers) from both camps.
> >
> > Lucio.
> >
> > On Thu, May 9, 2024 at 11:06 AM <wb.kloke@gmail.com> wrote:
> >>
> >> I am using fossil on plan9port (which should be similar to 9legacy) from 9front. The only thing which I needed was to enable p9sk1 for the hostowner on 9front  (the auth server) and a factotum entry for this in the file server, IIRC.
> >
> >
> >
> > --
> > 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/Tde2ca2adda383a3a-M9ae912348a14965096f54bc2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Richard Miller]

> From: ori@eigenstate.org
> ...
> keep in mind that it can literally be brute forced in an
> afternoon by a teenager; even a gpu isn't needed to do
> this in a reasonable amount of time.

[citation needed]


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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1023 bytes --]

Out of curiosity regarding your problem at hand Lucio :

You could use 9vx on 9legacy to establish a connection directly. You said you have an optical drive on your old machine so why don't you just use the 9legacy CD ROM ? You could also put your drive in an external hd case and access it running 9legacy (qemu or bare metal) or 9vx.

Creating a recovery stick of 9legacy to boot from an USB stick is also possible with 9vx or 9legacy with some tweaks simply integrated in a pre mk script is also no big deal. 

Did you solve your problem or do you need further details if so could you perhaps decide for on solution strategy ? If you just need to connect to a working plan9 I don't get the reason why you don't use 9legacy or 9vx instead of 9front. Perhaps I missed some reasoning. 


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

[-- Attachment #2: Type: text/html, Size: 1649 bytes --]

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

[Jacob Moody]

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

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




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

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

[hiro]

On Fri, May 10, 2024 at 12:59 PM Richard Miller <9fans@hamnavoe.com> wrote:
> > From: ori@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

[Dan Cross]

On Sat, May 11, 2024 at 2:26 PM hiro <23hiro@gmail.com> wrote:
> On Fri, May 10, 2024 at 12:59 PM Richard Miller <9fans@hamnavoe.com> wrote:
> > > From: ori@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

I believe the citation that Richard was asking for was one
demonstrating that p9sk1 could be broken by a teenager in an afternoon
(which, to be fair to Ori, is likely just a bit of fun hyperbole meant
to provide some flourish to an otherwise dry subject). The citation
you provided is to an 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 should note that a couple of years ago I talked to Eric Grosse about
dp9ik and p9sk1. I'm sure he won't mind if I share that his (early)
impression was that dp9ik is a strict improvement over p9sk1, and that
p9sk1 should be phased out in favor of dp9ik. As a small quip, I do
wish the name were different: c'mon guys, not _everything_ needs to be
snarky. ?;-)

        - Dan C.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mcb61bde6ee99250df4da09fb
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

[Dan Cross]

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

Probably how a random teenager could break it in an afternoon. :-)

> 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 wonder if you read the rest of my email....

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

https://n2vi.com/bio.html

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

Huh.

        - Dan C.

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

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

[Jacob Moody]

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

If we agree that:

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

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

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

- moody


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

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

[Dan Cross]

On Sat, May 11, 2024 at 4:17 PM Jacob Moody <moody@posixcafe.org> wrote:
> On 5/11/24 14:59, Dan Cross wrote:
> > On Sat, May 11, 2024 at 3:36 PM hiro <23hiro@gmail.com> wrote:
> >>> explanation of dp9ik, which while useful, only
> >>> addresses what (I believe) Richard was referring to in passing, simply
> >>> noting the small key size of DES and how the shared secret is
> >>> vulnerable to dictionary attacks.
> >>
> >> i don't remember what richard was mentioning, but the small key size
> >> wasn't the only issue, the second issue is that this can be done
> >> completely offline. why do you say "only", what do you think is
> >> missing that should have been documented in addition to that?
> >
> > Probably how a random teenager could break it in an afternoon. :-)
>
> If we agree that:
>
> 1) p9sk1 allows the shared secret to be brute-forced offline.
> 2) The average consumer machine is fast enough to make a large amount of attempts in a short time,
>    in other words triple DES is not computationally hard to brute force these days.
>
> I don't know how you don't see how this is trivial to do.
> A teenager can learn to download hashcat, all that is missing from this right now is some python
> script to get the encrypted shared secret from a running p9sk1 server. All the code for doing
> this is already written in C as part of the distribution, you just have to only do half the
> negotiation and break out. I think you vastly underestimate the resourcefulness of teenagers.
>
> I had previously stated I would publish the PoC that friends of mine in university built
> as part of their class, I have been asked to not do that so I will not.

To be clear: _I'm_ not saying it can't be done. I don't know that it
can be done in an _afternoon_; maybe a day or two, but I honestly
don't know. I was just trying to clarify what (I think) Richard was
asking for.

        - Dan C.

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

[9fans] one weird trick to break p9sk1 ?

[Richard Miller]

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.

moody@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: ori@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/S1383762122000066
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
        6.708393874076e+23
        _/(60*60*24*365.25)
        2.125761741728e+16

That's quadrillions of years. Not what most people would call "trivial".
And that's generously assuming the implementation of meet-in-the-middle
is zero cost. Without meet-in-the-middle, we're looking at a 168-bit
keyspace and an even more preposterous number of years.

I was looking forward to the "proof of concept". Even if we can't see
the details, it would be intriguing to know if it was specifically about
breaking p9sk1 or just cracking DES keys, and what assumptions were made
about practical speed of operation.


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

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

[tlaronde]

On Sun, May 12, 2024 at 02:16:47PM +0100, Richard Miller wrote:
> I'm using a new subject [was: Interoperating between 9legacy and 9front]
> in the hope of continuing discussion of the vulnerability of p9sk1 without
> too many other distractions.
> 
> moody@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: ori@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/S1383762122000066
> 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
>         6.708393874076e+23
>         _/(60*60*24*365.25)
>         2.125761741728e+16
> 
> That's quadrillions of years. Not what most people would call "trivial".
> And that's generously assuming the implementation of meet-in-the-middle
> is zero cost. Without meet-in-the-middle, we're looking at a 168-bit
> keyspace and an even more preposterous number of years.
> 
> I was looking forward to the "proof of concept". Even if we can't see
> the details, it would be intriguing to know if it was specifically about
> breaking p9sk1 or just cracking DES keys, and what assumptions were made
> about practical speed of operation.

Let's see if Natural Unintelligence (mine) can beat Artifial
Intelligence:

- knowing that bubbles can "resolve" equations that we can't
(Plateau's problem);
- knowing that teenagers chew chewing-gums;

Isn't it possible that a teenager, making bubbles with chewing-gum,
was able to solve analogically a problem that is digitally very
difficult to challenge?

[I'm absolutely convinced that, if cryptography is allowed in the
digital world, this is because some entities have analogical means
to solve them...].

Yes: I'm like others. I love Internet because, when I'm tired of
working, this is a great way of very busily doing nothing ;-)
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                     http://nunc-et-hic.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M6dbaaf4ed5d4e0cfb97f4016
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 <9fans@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.
>
> moody@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: ori@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/S1383762122000066
> 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
> 6.708393874076e+23
> _/(60*60*24*365.25)
> 2.125761741728e+16
> 
> That's quadrillions of years. Not what most people would call "trivial".
> And that's generously assuming the implementation of meet-in-the-middle
> is zero cost. Without meet-in-the-middle, we're looking at a 168-bit
> keyspace and an even more preposterous number of years.
> 
> I was looking forward to the "proof of concept". Even if we can't see
> the details, it would be intriguing to know if it was specifically about
> breaking p9sk1 or just cracking DES keys, and what assumptions were made
> about practical speed of operation.
> 

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

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

[Richard Miller]

23hiro@gmail.com:
> 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.

My comments are about p9sk1; I'm not implying anything about other
algorithms.  When working with other people's software, whether
professionally or for my own purposes, I try to take a
minimum-intervention approach: because it's respectful, because of
Occam's Razor, because of Tony Hoare's observation that software can
be either so simple that it obviously has no bugs, or so complicated
that it has no obvious bugs.

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.

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

I've got nothing against AES. I'm not a cryptographer either, but I did once
have to build a javacard implementation for a proprietary smartcard which
involved a lot of crypto infrastructure, and had to pass EMV certification.
Naturally that needed AES, elliptic curves, and plenty of other esoterica
to fit in with the existing environment and specifications.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2003e6b5eb34ea3270a33bec
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] one weird trick to break p9sk1 ?

[Richard Miller]

23hiro@gmail.com:
> ... 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.

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.

23hiro@gmail.com:
> ... it seems to me that
> concentrating on 3DES just for the sake of similarity to DES is taking
> ocam's razor slightly too far.

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.


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

[Dan Cross]

On Sun, May 12, 2024 at 12:44 PM Richard Miller <9fans@hamnavoe.com> wrote:
> 23hiro@gmail.com:
> > 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.
>
> My comments are about p9sk1; I'm not implying anything about other
> algorithms.  When working with other people's software, whether
> professionally or for my own purposes, I try to take a
> minimum-intervention approach: because it's respectful, because of
> Occam's Razor, because of Tony Hoare's observation that software can
> be either so simple that it obviously has no bugs, or so complicated
> that it has no obvious bugs.

Forgive my saying it, Richard, but I think this is a somewhat overly
staid view of things.

Software, as a constructed object, is maybe unique in that it is
almost infinitely malleable, and the "minimum intervention" approach
is often not terribly useful. As for being respectful of other
people's software, who are these other people? The original authors of
plan 9 are no longer involved, and indeed, the intellectual property
has been transferred to the foundation, and by any reasonable standard
the "community" has been given responsibility for the evolution of the
code.

As for the proposed strawman `p9sk3`, I fail to see what advantage
that would have over dp9ik, except perhaps a less silly name. The
person who wrote the paper on plan 9 security sees it being superior
to what's there now, after all, and frankly he'd know better than
either Occam or Tony Hoare.

        - Dan C.

> 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.
> 
> This is only the first scratching of an idea, not implemented yet.
> 
> I've got nothing against AES. I'm not a cryptographer either, but I did once
> have to build a javacard implementation for a proprietary smartcard which
> involved a lot of crypto infrastructure, and had to pass EMV certification.
> Naturally that needed AES, elliptic curves, and plenty of other esoterica
> to fit in with the existing environment and specifications.
> 

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

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

[Richard Miller]

me:
>> I try to take a
>> minimum-intervention approach ...

crossd@gmail.com:
> Forgive my saying it, Richard, but I think this is a somewhat overly
> staid view of things.

You're welcome to say it. My minimalist attitude amounts to a religion,
and therefore I don't need to justify it ☺. I know I'm at one extreme
end of the scale. None of my machines are even running 9legacy,
it's all 4th edition with enough hand-picked patches to make it useable
for me. I wouldn't dream of pushing anyone else to follow my example.
But personally, my Plan 9 network is a refuge from 21st century complexity,
where I can in theory read and understand the infrastructure from top to
bottom.

(OK, I know that's delusional because I've installed go. But maybe
not for much longer, as google seems determined to introduce python3
as a dependency.)


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

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

[Richard Miller]

crossd@gmail.com:
> As for the proposed strawman `p9sk3`, I fail to see what advantage
> that would have over dp9ik

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
threat of brute-forcing the entire keyspace can be mitigated with a
small, local and very easy to understand variation to the ticket service
(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.


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

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

>
> (OK, I know that's delusional because I've installed go. But maybe
> not for much longer, as google seems determined to introduce python3
> as a dependency.)


wat!??

On Mon, 13 May 2024 at 13:48, Richard Miller <9fans@hamnavoe.com> wrote:

> crossd@gmail.com:
> > As for the proposed strawman `p9sk3`, I fail to see what advantage
> > that would have over dp9ik
> 
> 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
> threat of brute-forcing the entire keyspace can be mitigated with a
> small, local and very easy to understand variation to the ticket service
> (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.
> 

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

[-- Attachment #2: Type: text/html, Size: 2842 bytes --]

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

[David du Colombier]

>> (OK, I know that's delusional because I've installed go. But maybe
>> not for much longer, as google seems determined to introduce python3
>> as a dependency.)
>
> wat!??

The Go team is willing to replace the CI builders written in Go by the
Chromium builders, which are written in Python 3.
So the CI will depend on Python to build Go and run tests.

-- 
David du Colombier

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

[9fans] golang dependency on python3

[Richard Miller]

me:
>> (OK, I know that's delusional because I've installed go. But maybe
>> not for much longer, as google seems determined to introduce python3
>> as a dependency.)

Charles Forsyth:
> wat!??

citation:
https://github.com/golang/go/issues/62025


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf65bc1d5ccdc425e-M67a81834c7b5494c98da1cfe
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] one weird trick to break p9sk1 ?

[Jacob Moody]

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

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

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

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

>> From: ori@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/S1383762122000066
> from March 2022, which says:
>  "Our best optimizations provided 3.87 billion key searches per second for Des/3des
>  ... on an RTX 3070 GPU."
> 
> So even with a GPU, the expected time to crack a random 56-bit key would be
> something like:
> 
>         cpu% hoc
>         2^55/3.87e9
>         9309766.671567
>         _/(60*60*24)
>         107.7519290691
> 
> More than three months. The same paper mentions someone else's purpose-built
> machine called RIVYERA which "uses 128 Xilinx Spartan-6 LX150 FPGAs ... 
> can try 691 billion Des keys in a second ... costs around 100,000 Euros".
> Still not quite fast enough to break a key in an afternoon.

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

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

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

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

Yes that is a mistake my mistake, it is indeed single 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
>         6.708393874076e+23
>         _/(60*60*24*365.25)
>         2.125761741728e+16
> 
> That's quadrillions of years. Not what most people would call "trivial".
> And that's generously assuming the implementation of meet-in-the-middle
> is zero cost. Without meet-in-the-middle, we're looking at a 168-bit
> keyspace and an even more preposterous number of years.

Yes this would move it out of the reach of some random teenager, however
this is entirely discounting a dictionary attack. I guess you could do that if you
have confidence that your password is globally unique.

Also take a look at: https://crack.sh/
Seems single or triple DES, this website can do the job for you for quite cheap.

> 
> I was looking forward to the "proof of concept". Even if we can't see
> the details, it would be intriguing to know if it was specifically about
> breaking p9sk1 or just cracking DES keys, and what assumptions were made
> about practical speed of operation.
> 
The issue is both getting the "point and shoot" nature of getting the encrypted
DES key from a running p9sk1 server starting from zero knowledge, as well as the
current bruteforceble encryption is what makes it a problem.


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

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

[ori]

Quoth Richard Miller <9fans@hamnavoe.com>:
> 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.
> 
> moody@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:
> 

The intial exchange sends across the challenges:

        C→S: CHc
        S→C: AuthTreq, IDs, DN, CHs, -, -

Because the challenge and IDs are sent as plain text, if I
can decrypt the client message with a key and find my known
plain text, that key will work to authenticate the client.
For example, if I have a ticket, and a trace of the first
few packets of the key exchange, I have enough information
to do something like this:

        ticketpair = {
                Kc{AuthTc, CHs, IDc, IDr, Kn},
                Ks{AuthTs, CHs, IDc, IDr, Kn}
        }

        cmsg = ticketpair[0]
        for(k in keyspace){
                m = decrypt(k, cmsg)
                if(m.CHs == CHs && m.IDs == IDs)
                        probably_bingo()
        }

At that point, I need to guess the username, but this often
is relatively easy -- often, this is posted publicly; you
can probably guess that my user is 'ori' without trouble.

With those bits of information, you're able to complete a
new exchange as the client, and log in successfully.

The EFF was cracking DES keys in 22 hours back in 1998.
https://en.wikipedia.org/wiki/EFF_DES_cracker

Hardware, in particular GPUs, have gotten quite a bit
better since then.


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

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

[ori]

Quoth ori@eigenstate.org:
> Quoth Richard Miller <9fans@hamnavoe.com>:
> > 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.
> > 
> > moody@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:
> > 
> 
> The intial exchange sends across the challenges:
> 
>         C→S: CHc
>         S→C: AuthTreq, IDs, DN, CHs, -, -
> 

Oops -- wrong messages; these are the ones
you want to be breaking:

        C→A: AuthTreq, IDs, DN, CHs, IDc, IDr
        A→C: AuthOK, Kc{AuthTc, CHs, IDc, IDr, Kn}, Ks{AuthTs, CHs,
               IDc, IDr, Kn}

Thanks to cinap for pointing that out.


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

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

[Richard Miller]

Jacob and Ori, thank you for filling in some more details. Without
the specifics I had been making some wrong assumptions about where
the exact threat was.

I think I now have a clearer picture:

It's not particularly p9sk1 which is vulnerable, but the protocol
for ticket request / response, which leaks enough information to
allow offline exploration of user keys. The contribution of p9sk1
is that its handshake protocol helpfully reveals a valid user name -
ie the authid - which can be used by an attacker to make a legitimate
ticket request, without any need for eavesdropping or guessing at
user names.

So, if you have an authentication service exposed to the ipv4
internet (or to the ipv6 internet with a findable address), and
your authid or a known or guessable userid has a weak enough
password to succumb to a dictionary search, it's probably right
to say that a random attacker could make a cpu connection or
mount your file service with an afternoon's work on consumer
hardware.

Nobody needs to have weak passwords, though. Using the !hex attribute
instead of !password with factotum, and/or using secstore(1), makes it
easy to have a randomly generated DES key with the full 56 bits of
entropy. This makes the attacker do more work ...  but not all that
much more. I hadn't kept up with how powerful commodity GPUs have
become. (My most recent experience with High Performance Computing
involved transputer arrays and Cray T3Ds.  Nowadays I specialise in
low performance computing.) It appears that investment of a few
thousand dollars and a few days compute time (maybe less if using
cloud services) is enough for a full brute-force exploration of the
single-DES keyspace.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2867926d1deafb39060269df
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] one weird trick to break p9sk1 ?

[Jacob Moody]

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

Yes that is how I understand it.

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

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


Thank you,
Jacob Moody


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

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

[Richard Miller]

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

And thanks to you for pointing me to the GTX 4090 and https://crack.sh

Both real eye openers.


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

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

[Kurt H Maier via 9fans]

On Sun, May 12, 2024 at 02:16:47PM +0100, Richard Miller wrote:
> 
> That's quadrillions of years. Not what most people would call "trivial".
> And that's generously assuming the implementation of meet-in-the-middle
> is zero cost. Without meet-in-the-middle, we're looking at a 168-bit
> keyspace and an even more preposterous number of years.

Meanwhile, sweet32 exists, all this shit has already been prosecuted on
other venues, and NIST shitcanned 3DES entirely last year.  Not
deprecated.  Disallowed.  Why?  Because no matter how many numbers you
paste into an email, it costs thirty bucks to crack it on someone else's
ASIC farm.  Pretending that getting access to $100k hash-cracking arrays
is any more inconvenient than Uber Eats is straight-up disingenuous.

It is extremely gross to be defending 3DES in 2024.  You should know
better.  I don't particularly care if 9legacy adopts dp9ik, but there
are people who will come reading this list archive down the road, and
they'll be under the assumption that your arguments are in good faith.
I hope they are not, because this crap is at best irresponsible.
Occam's razor does not advocate ignoring the entire standardized best
practices of the industry because you have emotional attachments to
broken software and have used a pocket calculator to convince yourself
you know better than everyone else on Earth.

Advocating a switch to 3DES because it's backward-compatible with DES if
you use it wrong is magnificent trolling, or depressing malpractice,
depending on your intent.  I can't ever know that, so I'll just state
for posterity:  kids, don't do this.  It's a terrible plan.


Do better,
khm

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M6ef048148514ce58cf76ead5
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] Interoperating between 9legacy and 9front

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 13542 bytes --]

Thank you, Vic, for your efforts. My perceptions about the conflicts that
seem to be stirred by any posts that compares 9front with the original,
poorly defined, shall we say, "heritage" Plan 9 release are well reflected
in your original, detailed posting.
I was planning to address the issue, but you have done that more
proactively than I would manage.

I suspect that Jacob misinterpreted my intentions, so at this point I will
limit myself to a simple explanation and a possibly controversial request.

I have two large data objects: a fossil cache and a venti backing arena.
They are held on one SATA drive. Both seem intact, although I am limited to
only superficial inspection because of the size of the objects and the
limits in the hardware available to me. I have made various attempts at
booting the release Plan 9 legacy system on the available platform that
supports SATA drives - but not serial IDE - and have failed. The hardware
involved pre-dates UEFI so I am using the traditional boot procedure, to
the best of my ability. Booting the 9-legacy distribution from either a
SATA optical drive or a USB device has proved beyond my understanding.

I could however boot 9front (I have used 9front on a number of occasions, I
have no reservations doing so, but my comfort zone remains with the legacy
system which I have been using ever since 2nd Edition was released for sale
- I still have the original CD-ROM and two volume documentation) from a USB
stick and eventually installed it on the SATA-capable platform where the
BIOS allows me to select which device I choose to boot from, within limits.

What I have been unable to do so far has been to get the right combination
of master boot record, Plan 9 bootstrap loader (legacy's 9load in
preference to 9front's 9boot for various reasons, not all perfectly
water-tight), Fossil- and Venti-capable kernel and the right Fossil and
Venti embedded configurations to complete the Plan 9 bootstrap procedure.

As I'm presently stuck with /386/pbslba (announcing itself as PBS2)
reporting "Bad format or I/O error" my guess is that either the kernel
"bootfile" is being specified incorrectly or (a subset condition) I am
instructing the loader to look for the kernel on the wrong device.
Specifically, I was surprised to discover that 9front uses "sdC[01]" and
"sdD[01]" where 9legacy, in my experience uses "sd[EF][01]" as the drive
selector. I could be wrong, it has been hard to try all possible
permutations, maybe I have missed one or more.

Now, I didn't explicitly indicate where 9front comes into this: I
manipulated the disk drive holding my precious data using 9front. Once I
had the means to edit the configuration in the Fossil cache partition - and
remembered that the Venti tool (venti/conf) for that operation is included
in the 9front distribution, which in my confusion I had actually forgotten
- I was confident that I had the boot issue sewn up, but as I explained, I
am still stuck.

There are many sharp corners I bumped my shins against in this exercise;
mostly of my own making as I am somewhat lazy and not as sharp as I thought
I was when younger.

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

Jacob makes the point that porting Fossil to 9front is not a 9front
responsibility, analogously he also states that the dp9ik code is available
to be ported to 9legacy. I concur with Vic that a port of dp9ik to 9legacy
is extremely desirable, but I disagree with whomever has dropped the Fossil
source code entirely from the 9front release. Right or wrong, I think it
will require assistance from the 9front development community to get Fossil
working on 9front and plenty of diplomacy to arrive at a release of Fossil
on 9front where both participants are proud of the result. Without the
sources in the 9front release it is not only hard to contemplate the
option, but it is also quite likely that progress in that direction may
already have been made but not shared with those who may in turn also
contribute to this.

My request, therefore, is that anyone who has worked with the Fossil code
in the 9front context (and that includes my minor tweaks to fossil/conf, if
any) should find a way to publish what they have. That may stir the pot a
bit.

As far as dp9ik goes, I have personal reasons to enhance 9legacy's security
code, but it is a massive endeavour, at least as I see it and I am always
fearful of undertaking anything I don't think I can handle. But the
motivation is there, the question is whether the necessary cooperation will
also materialise.

My sincere thanks to Vic, once again, for dowsing the looming flames, we do
not need conflict, of the emotional brand, to escalate out of measure.

Lucio.

On Wed, May 8, 2024 at 11:53 PM <vic.thacker@fastmail.fm> 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 <vester.thacker@fastmail.fm> 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 sound like you're trying to make this someone else's problem.
> >> > Being stuck in a hardware pickle when there are ample existing
> software
> >> > solutions is not
> >> > a good reason to ask someone else to go out of their way to write
> >> > software.
> >> >
> >> > Fossil can be pulled in largely without modifications as I understand
> it,
> >> > I don't run fossil but some people in the 9front community do and it
> does
> >> > not appear to me that they've had issues with continuing to have it
> work
> >> > (other then fossil bugs itself).
> >> >
> >> >>
> >> >> I managed to share the Fossil cache through a NetBSD server
> providing u9fs services, but that host does not have the capacity to store
> the Venti arenas, nor can I really justify spending the amount of time it
> would take to pass it between the 9legacy and 9front devices via NetBSD, no
> matter how I try to arrange that. It does baffle me, though, that a NetBSD
> intermediary is more competent than the two "native" platforms.
> >> >
> >> > Are you blaming us for moving on from AES 53 bit keys that can be
> brute
> >> > forced in an afternoon?
> >> > I have tried to open a dialogue for getting dp9ik on 9legacy a couple
> >> > times now, when I had brought it
> >> > up I am told to write the patch. Something about being asked to spend
> >> > the work to write a patch for 9legacy given
> >> > the historical context of why 9front exists does not sit right with
> me.
> >> > So it wont be me, sorry.
> >> > Sure it sucks that things have drifted, but all our code is there,
> >> > neatly organized out in to commits, if someone
> >> > wants to import our work it is readily available. However something
> >> > tells me most people are just going to use 9front as is.
> >> >
> >> > Good luck,
> >> > moody
> >> >


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

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

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

[-- Attachment #2: Type: text/html, Size: 16459 bytes --]

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

[Noam Preil]

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

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

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

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

- Noam Preil


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

Re: [9fans] fossil

[Richard Miller]

Noam Preil:
> I have a
> branch at https://git.sr.ht/~pixelherodev/plan9 which has fossil
> integrated.

I took the liberty of having a look at the fossil source in that repo.
It seems to be missing the fossil-time-backward patch. That's on the
current 9legacy distribution ISO (built 14 April 2023), and probably
on several previous ones as it went into the 9legacy git in April 2022.

It's a two-line patch which fixes a bug where the periodic sync process
can stop working if the system clock goes backwards. The consequences
of that are failure to update on-disk file data, and exhaustion of the
in-memory cache buffers which results in deadlock. From memory, I think
it could also make the sync process go into a 100% cpu loop which might
look like deadlock.

If you apply that patch, I hope that you will find some of the problems
you've been observing will be cleared up.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbbcec90e3dd997e1-M2a3d10ef36b09cf392eda1c2
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 <vic.thacker@fastmail.fm> 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 <vester.thacker@fastmail.fm> 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 sound like you're trying to make this someone else's problem.
> >> > Being stuck in a hardware pickle when there are ample existing software
> >> > solutions is not
> >> > a good reason to ask someone else to go out of their way to write
> >> > software.
> >> >
> >> > Fossil can be pulled in largely without modifications as I understand it,
> >> > I don't run fossil but some people in the 9front community do and it does
> >> > not appear to me that they've had issues with continuing to have it work
> >> > (other then fossil bugs itself).
> >> >
> >> >>
> >> >> I managed to share the Fossil cache through a NetBSD server providing u9fs services, but that host does not have the capacity to store the Venti arenas, nor can I really justify spending the amount of time it would take to pass it between the 9legacy and 9front devices via NetBSD, no matter how I try to arrange that. It does baffle me, though, that a NetBSD intermediary is more competent than the two "native" platforms.
> >> >
> >> > Are you blaming us for moving on from AES 53 bit keys that can be brute
> >> > forced in an afternoon?
> >> > I have tried to open a dialogue for getting dp9ik on 9legacy a couple
> >> > times now, when I had brought it
> >> > up I am told to write the patch. Something about being asked to spend
> >> > the work to write a patch for 9legacy given
> >> > the historical context of why 9front exists does not sit right with me.
> >> > So it wont be me, sorry.
> >> > Sure it sucks that things have drifted, but all our code is there,
> >> > neatly organized out in to commits, if someone
> >> > wants to import our work it is readily available. However something
> >> > tells me most people are just going to use 9front as is.
> >> >
> >> > Good luck,
> >> > moody
> >> >

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

[vic.thacker]

Hi Hiro et al,

I view Plan 9 4th Edition as a version that remains largely unchanged, serving as a snapshot in time, while 9legacy represents an active, distinct distribution. Conversely, 9front is a fork that has evolved significantly from Plan 9 4th Edition, making considerable advancements in recent years.

I appreciate the push for modernization with 9front, but I also see value in maintaining support for older versions like Plan 9 4th Edition and 9legacy.  Living in Japan, I have access to inexpensive hardware—local computer resellers often offer older computers for as little as 2,000 yen each (e.g. $12.85 USD).  For about 8,000 yen, it is possible to set up a functional Plan 9 system.  This isn’t about leading the charge with the latest and greatest OS; it's about the joy of tinkering and making the most of accessible resources.  For hobbyists like myself, the ability to use and experiment with older systems is invaluable.  Maintaining some level of support or compatibility in the community can enhance the inclusiveness and experimental spirit that is fundamental to Plan 9’s ethos.

Maintaining updates and compatibility between Plan 9 4th Edition, 9legacy, and 9front can provide several benefits, especially in a diverse community like that of Plan 9.  Here are some of the key advantages:

(1) Broader Hardware Support:  By keeping Plan 9 4th Edition and 9legacy updated, users who rely on older or less common hardware configurations that may not be fully supported by 9front can still benefit from updates and improvements.  This is particularly useful in academic or hobbyist settings where newer hardware may not be readily available or economically feasible.

(2) Incremental Upgrades:  Some users may prefer an incremental approach to system upgrades rather than a complete switch to a newer version. Integrating changes from 9front into 9legacy and Plan 9 4th Edition allows these users to benefit from specific enhancements without the need to overhaul their entire system setup.

(3) Community Engagement:  Keeping these versions updated helps engage different segments of the Plan 9 community.  It acknowledges the needs and preferences of those who might prefer the familiarity of 9legacy or Plan 9 4th Edition, fostering a more inclusive and vibrant community.

(4) Preservation of Educational and Historical Value:  Plan 9 has significant educational and historical importance in the field of operating systems.  Maintaining and updating older versions ensures that this legacy is preserved, allowing new generations of students and enthusiasts to learn from and experiment with these systems.

(5) Security and Stability:  Regular updates can address security vulnerabilities and fix bugs across all versions, ensuring that even older deployments remain secure and stable.  This is crucial for maintaining the integrity and usability of the systems over time.

(6) Customization:  Some users or organizations might have customized their systems based on older versions of Plan 9.  Keeping these systems updated with changes from 9front can provide a path for these custom setups to receive new features and improvements while maintaining their unique configurations.

Overall, the integration of updates across different versions of Plan 9 can help keep the system modern, secure, and accessible to a wide range of users, enhancing both its utility and appeal.

In embracing both the new and preserving the old, we not only honor the rich legacy of Plan 9 but also ensure its relevance and accessibility for all users, regardless of their hardware or specific needs. By updating 9legacy and Plan 9 4th Edition alongside 9front, we foster a community that values progress and innovation while respecting and supporting the diverse ways in which people interact with our beloved operating system. Together, let's continue to build a welcoming and vibrant Plan 9 community that thrives on both change and tradition.

Kind regards,
Vester "Vic" Thacker


On Fri, May 10, 2024, at 04:50, hiro wrote:
> 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?!
>

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

[Lallero]

[-- Attachment #1: Type: text/plain, Size: 5866 bytes --]

Is it just me noticing this is chatgpt?

Il 10 maggio 2024 06:44:48 CEST, vic.thacker@fastmail.fm ha scritto:
>Hi Hiro et al,
>
>I view Plan 9 4th Edition as a version that remains largely unchanged, serving as a snapshot in time, while 9legacy represents an active, distinct distribution. Conversely, 9front is a fork that has evolved significantly from Plan 9 4th Edition, making considerable advancements in recent years.
>
>I appreciate the push for modernization with 9front, but I also see value in maintaining support for older versions like Plan 9 4th Edition and 9legacy.  Living in Japan, I have access to inexpensive hardware—local computer resellers often offer older computers for as little as 2,000 yen each (e.g. $12.85 USD).  For about 8,000 yen, it is possible to set up a functional Plan 9 system.  This isn’t about leading the charge with the latest and greatest OS; it's about the joy of tinkering and making the most of accessible resources.  For hobbyists like myself, the ability to use and experiment with older systems is invaluable.  Maintaining some level of support or compatibility in the community can enhance the inclusiveness and experimental spirit that is fundamental to Plan 9’s ethos.
>
>Maintaining updates and compatibility between Plan 9 4th Edition, 9legacy, and 9front can provide several benefits, especially in a diverse community like that of Plan 9.  Here are some of the key advantages:
>
>(1) Broader Hardware Support:  By keeping Plan 9 4th Edition and 9legacy updated, users who rely on older or less common hardware configurations that may not be fully supported by 9front can still benefit from updates and improvements.  This is particularly useful in academic or hobbyist settings where newer hardware may not be readily available or economically feasible.
>
>(2) Incremental Upgrades:  Some users may prefer an incremental approach to system upgrades rather than a complete switch to a newer version. Integrating changes from 9front into 9legacy and Plan 9 4th Edition allows these users to benefit from specific enhancements without the need to overhaul their entire system setup.
>
>(3) Community Engagement:  Keeping these versions updated helps engage different segments of the Plan 9 community.  It acknowledges the needs and preferences of those who might prefer the familiarity of 9legacy or Plan 9 4th Edition, fostering a more inclusive and vibrant community.
>
>(4) Preservation of Educational and Historical Value:  Plan 9 has significant educational and historical importance in the field of operating systems.  Maintaining and updating older versions ensures that this legacy is preserved, allowing new generations of students and enthusiasts to learn from and experiment with these systems.
>
>(5) Security and Stability:  Regular updates can address security vulnerabilities and fix bugs across all versions, ensuring that even older deployments remain secure and stable.  This is crucial for maintaining the integrity and usability of the systems over time.
>
>(6) Customization:  Some users or organizations might have customized their systems based on older versions of Plan 9.  Keeping these systems updated with changes from 9front can provide a path for these custom setups to receive new features and improvements while maintaining their unique configurations.
>
>Overall, the integration of updates across different versions of Plan 9 can help keep the system modern, secure, and accessible to a wide range of users, enhancing both its utility and appeal.
>
>In embracing both the new and preserving the old, we not only honor the rich legacy of Plan 9 but also ensure its relevance and accessibility for all users, regardless of their hardware or specific needs. By updating 9legacy and Plan 9 4th Edition alongside 9front, we foster a community that values progress and innovation while respecting and supporting the diverse ways in which people interact with our beloved operating system. Together, let's continue to build a welcoming and vibrant Plan 9 community that thrives on both change and tradition.
>
>Kind regards,
>Vester "Vic" Thacker
>
>
>On Fri, May 10, 2024, at 04:50, hiro wrote:
>> 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?!
>>

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Maeaf9691be6b9745cf419692
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 7417 bytes --]

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

[vic.thacker]

Thanks! I’ve been practicing my impersonation. Want to hear my human impression next?

The goal of writing is to articulate ideas in a clear and comprehensive manner.  If I were unclear, I apologize.  I realize that reading a lengthy post can be a bit demanding on your time.  Thank you for your patience.  I'll make an effort to keep my posts shorter and to the point. I could have written it in the following way, but it seemed less expressive.

"Plan 9 4th Edition serves as a stable snapshot in time, while 9legacy is an active distribution, and 9front has evolved significantly, bringing modern advancements.  Living in Japan, where older computers are affordable, I appreciate maintaining support for these versions.  Accessible older systems allow hobbyists like me to enjoy tinkering without the need for the latest technology.

Updating and maintaining compatibility among Plan 9 4th Edition, 9legacy, and 9front offers several benefits.  It broadens hardware support, allowing users with older setups to benefit from new improvements. Incremental upgrades help those preferring gradual changes to seamlessly integrate new features.  Such updates enhance community engagement, preserve the educational value, ensure system security and stability, and accommodate customization for unique setups.

By updating all versions, we honor Plan 9's legacy while keeping it relevant and accessible, fostering a community that values both innovation and tradition.  This approach supports diverse user needs and promotes a vibrant, inclusive community."

I'm exploring whether there's interest in more collaboration.  It would be beneficial to focus on critiquing ideas rather than individuals.

Kind regards,
Vester "Vic" Thacker



On Fri, May 10, 2024, at 16:33, Lallero wrote:
> Is it just me noticing this is chatgpt?
>
> Il 10 maggio 2024 06:44:48 CEST, vic.thacker@fastmail.fm ha scritto:
>>Hi Hiro et al,
>>
>>I view Plan 9 4th Edition as a version that remains largely unchanged, serving as a snapshot in time, while 9legacy represents an active, distinct distribution. Conversely, 9front is a fork that has evolved significantly from Plan 9 4th Edition, making considerable advancements in recent years.
>>
>>I appreciate the push for modernization with 9front, but I also see value in maintaining support for older versions like Plan 9 4th Edition and 9legacy.  Living in Japan, I have access to inexpensive hardware—local computer resellers often offer older computers for as little as 2,000 yen each (e.g. $12.85 USD).  For about 8,000 yen, it is possible to set up a functional Plan 9 system.  This isn’t about leading the charge with the latest and greatest OS; it's about the joy of tinkering and making the most of accessible resources.  For hobbyists like myself, the ability to use and experiment with older systems is invaluable.  Maintaining some level of support or compatibility in the community can enhance the inclusiveness and experimental spirit that is fundamental to Plan 9’s ethos.
>>
>>Maintaining updates and compatibility between Plan 9 4th Edition, 9legacy, and 9front can provide several benefits, especially in a diverse community like that of Plan 9.  Here are some of the key advantages:
>>
>>(1) Broader Hardware Support:  By keeping Plan 9 4th Edition and 9legacy updated, users who rely on older or less common hardware configurations that may not be fully supported by 9front can still benefit from updates and improvements.  This is particularly useful in academic or hobbyist settings where newer hardware may not be readily available or economically feasible.
>>
>>(2) Incremental Upgrades:  Some users may prefer an incremental approach to system upgrades rather than a complete switch to a newer version. Integrating changes from 9front into 9legacy and Plan 9 4th Edition allows these users to benefit from specific enhancements without the need to overhaul their entire system setup.
>>
>>(3) Community Engagement:  Keeping these versions updated helps engage different segments of the Plan 9 community.  It acknowledges the needs and preferences of those who might prefer the familiarity of 9legacy or Plan 9 4th Edition, fostering a more inclusive and vibrant community.
>>
>>(4) Preservation of Educational and Historical Value:  Plan 9 has significant educational and historical importance in the field of operating systems.  Maintaining and updating older versions ensures that this legacy is preserved, allowing new generations of students and enthusiasts to learn from and experiment with these systems.
>>
>>(5) Security and Stability:  Regular updates can address security vulnerabilities and fix bugs across all versions, ensuring that even older deployments remain secure and stable.  This is crucial for maintaining the integrity and usability of the systems over time.
>>
>>(6) Customization:  Some users or organizations might have customized their systems based on older versions of Plan 9.  Keeping these systems updated with changes from 9front can provide a path for these custom setups to receive new features and improvements while maintaining their unique configurations.
>>
>>Overall, the integration of updates across different versions of Plan 9 can help keep the system modern, secure, and accessible to a wide range of users, enhancing both its utility and appeal.
>>
>>In embracing both the new and preserving the old, we not only honor the rich legacy of Plan 9 but also ensure its relevance and accessibility for all users, regardless of their hardware or specific needs. By updating 9legacy and Plan 9 4th Edition alongside 9front, we foster a community that values progress and innovation while respecting and supporting the diverse ways in which people interact with our beloved operating system. Together, let's continue to build a welcoming and vibrant Plan 9 community that thrives on both change and tradition.
>>
>>Kind regards,
>>Vester "Vic" Thacker
>>
>>
>>On Fri, May 10, 2024, at 04:50, hiro wrote:
>>> 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?!
>>>
>
> -- 
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 9290 bytes --]

Vic,
> I'm exploring whether there's interest in more collaboration.  It would
be beneficial to focus on critiquing ideas rather than individuals.
The assertion of one's individuality and superiority is generational; what
the proponents of that attitude are missing is that it is also a
self-defeating approach. I think that you have pointed out the correct
weakness in your original post, there has been too little recognition of
the contributions made by the 9front developers to the legacy (with a lower
case "L") of Plan 9. It led to resentment (I know a lot about resentment in
post-Apartheid South Africa!) and the inevitable divisions. Even a
well-reasoned description of the situation elicits ad hominem criticism.

I'm finding it ironic, though, that the defenders of the true 9front faith
find it necessary to insult their "enemies" in a forum dedicated to the
very subject matter they are so disapproving of. Surely they realise that
9fans is a stupid place to do so?

Lucio.


On Fri, May 10, 2024 at 10:49 AM <vic.thacker@fastmail.fm> wrote:

> Thanks! I’ve been practicing my impersonation. Want to hear my human
> impression next?
>
> The goal of writing is to articulate ideas in a clear and comprehensive
> manner.  If I were unclear, I apologize.  I realize that reading a lengthy
> post can be a bit demanding on your time.  Thank you for your patience.
> I'll make an effort to keep my posts shorter and to the point. I could have
> written it in the following way, but it seemed less expressive.
>
> "Plan 9 4th Edition serves as a stable snapshot in time, while 9legacy is
> an active distribution, and 9front has evolved significantly, bringing
> modern advancements.  Living in Japan, where older computers are
> affordable, I appreciate maintaining support for these versions.
> Accessible older systems allow hobbyists like me to enjoy tinkering without
> the need for the latest technology.
>
> Updating and maintaining compatibility among Plan 9 4th Edition, 9legacy,
> and 9front offers several benefits.  It broadens hardware support, allowing
> users with older setups to benefit from new improvements. Incremental
> upgrades help those preferring gradual changes to seamlessly integrate new
> features.  Such updates enhance community engagement, preserve the
> educational value, ensure system security and stability, and accommodate
> customization for unique setups.
>
> By updating all versions, we honor Plan 9's legacy while keeping it
> relevant and accessible, fostering a community that values both innovation
> and tradition.  This approach supports diverse user needs and promotes a
> vibrant, inclusive community."
>
> I'm exploring whether there's interest in more collaboration.  It would be
> beneficial to focus on critiquing ideas rather than individuals.
>
> Kind regards,
> Vester "Vic" Thacker
>
>
>
> On Fri, May 10, 2024, at 16:33, Lallero wrote:
> > Is it just me noticing this is chatgpt?
> >
> > Il 10 maggio 2024 06:44:48 CEST, vic.thacker@fastmail.fm ha scritto:
> >>Hi Hiro et al,
> >>
> >>I view Plan 9 4th Edition as a version that remains largely unchanged,
> serving as a snapshot in time, while 9legacy represents an active, distinct
> distribution. Conversely, 9front is a fork that has evolved significantly
> from Plan 9 4th Edition, making considerable advancements in recent years.
> >>
> >>I appreciate the push for modernization with 9front, but I also see
> value in maintaining support for older versions like Plan 9 4th Edition and
> 9legacy.  Living in Japan, I have access to inexpensive hardware—local
> computer resellers often offer older computers for as little as 2,000 yen
> each (e.g. $12.85 USD).  For about 8,000 yen, it is possible to set up a
> functional Plan 9 system.  This isn’t about leading the charge with the
> latest and greatest OS; it's about the joy of tinkering and making the most
> of accessible resources.  For hobbyists like myself, the ability to use and
> experiment with older systems is invaluable.  Maintaining some level of
> support or compatibility in the community can enhance the inclusiveness and
> experimental spirit that is fundamental to Plan 9’s ethos.
> >>
> >>Maintaining updates and compatibility between Plan 9 4th Edition,
> 9legacy, and 9front can provide several benefits, especially in a diverse
> community like that of Plan 9.  Here are some of the key advantages:
> >>
> >>(1) Broader Hardware Support:  By keeping Plan 9 4th Edition and 9legacy
> updated, users who rely on older or less common hardware configurations
> that may not be fully supported by 9front can still benefit from updates
> and improvements.  This is particularly useful in academic or hobbyist
> settings where newer hardware may not be readily available or economically
> feasible.
> >>
> >>(2) Incremental Upgrades:  Some users may prefer an incremental approach
> to system upgrades rather than a complete switch to a newer version.
> Integrating changes from 9front into 9legacy and Plan 9 4th Edition allows
> these users to benefit from specific enhancements without the need to
> overhaul their entire system setup.
> >>
> >>(3) Community Engagement:  Keeping these versions updated helps engage
> different segments of the Plan 9 community.  It acknowledges the needs and
> preferences of those who might prefer the familiarity of 9legacy or Plan 9
> 4th Edition, fostering a more inclusive and vibrant community.
> >>
> >>(4) Preservation of Educational and Historical Value:  Plan 9 has
> significant educational and historical importance in the field of operating
> systems.  Maintaining and updating older versions ensures that this legacy
> is preserved, allowing new generations of students and enthusiasts to learn
> from and experiment with these systems.
> >>
> >>(5) Security and Stability:  Regular updates can address security
> vulnerabilities and fix bugs across all versions, ensuring that even older
> deployments remain secure and stable.  This is crucial for maintaining the
> integrity and usability of the systems over time.
> >>
> >>(6) Customization:  Some users or organizations might have customized
> their systems based on older versions of Plan 9.  Keeping these systems
> updated with changes from 9front can provide a path for these custom setups
> to receive new features and improvements while maintaining their unique
> configurations.
> >>
> >>Overall, the integration of updates across different versions of Plan 9
> can help keep the system modern, secure, and accessible to a wide range of
> users, enhancing both its utility and appeal.
> >>
> >>In embracing both the new and preserving the old, we not only honor the
> rich legacy of Plan 9 but also ensure its relevance and accessibility for
> all users, regardless of their hardware or specific needs. By updating
> 9legacy and Plan 9 4th Edition alongside 9front, we foster a community that
> values progress and innovation while respecting and supporting the diverse
> ways in which people interact with our beloved operating system. Together,
> let's continue to build a welcoming and vibrant Plan 9 community that
> thrives on both change and tradition.
> >>
> >>Kind regards,
> >>Vester "Vic" Thacker
> >>
> >>
> >>On Fri, May 10, 2024, at 04:50, hiro wrote:
> >>> 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?!
> >>>
> >
> > --
> > Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.


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

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

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

[-- Attachment #2: Type: text/html, Size: 11578 bytes --]

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

[qwx via 9fans]

On Fri May 10 11:09:32 +0200 2024, lucio.dere@gmail.com wrote:

> I'm finding it ironic, though, that the defenders of the true 9front faith
> find it necessary to insult their "enemies" in a forum dedicated to the
> very subject matter they are so disapproving of. Surely they realise that
> 9fans is a stupid place to do so?
> 
> Lucio.

Several people, including 9front users, have tried to help you and
provided you with ways to accomplish your task; they have been so far
ignored.  Even Moody himself gave you alternatives and arguably easier
ways to do it.  Here's another one: mycroftiv's ANTS was in sync with
9front for a while and fully supports fossil; it is now out of date
but the last ANTS release will probably work on your hardware.  iirc
noam had also tried to update it based on latest 9front some time
ago, but I'm not sure where that lives.

You have everything you need, courtesy of your "enemies", the
"defenders of the true 9front faith", whatever that is supposed to
mean.  What have you tried so far, did it work?

Thanks,
qwx

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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

I am not allowed to ignore some advice when Vic raises a much more
interesting subject matter and does it in a perfectly justified and well
formulated fashion - and gets accused of being an AI or at minimum playing
one on 9fans?

How do you know that I did not follow any of Moodley's advice, which
incidentally I acknowledged I may not be competent to follow? None of the
legacy people I have noted responding have been even remotely as offensive
as those who are determined to deify 9front in legacy's place - when there
is no effort on legacy's side to promote our particular preference, nor to
justify such preference as being superior in any manner.

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.

Lucio.

On Fri, May 10, 2024 at 12:22 PM qwx via 9fans <9fans@9fans.net> wrote:

> On Fri May 10 11:09:32 +0200 2024, lucio.dere@gmail.com wrote:
>
> > I'm finding it ironic, though, that the defenders of the true 9front
> faith
> > find it necessary to insult their "enemies" in a forum dedicated to the
> > very subject matter they are so disapproving of. Surely they realise that
> > 9fans is a stupid place to do so?
> >
> > Lucio.
> 
> Several people, including 9front users, have tried to help you and
> provided you with ways to accomplish your task; they have been so far
> ignored.  Even Moody himself gave you alternatives and arguably easier
> ways to do it.  Here's another one: mycroftiv's ANTS was in sync with
> 9front for a while and fully supports fossil; it is now out of date
> but the last ANTS release will probably work on your hardware.  iirc
> noam had also tried to update it based on latest 9front some time
> ago, but I'm not sure where that lives.
> 
> You have everything you need, courtesy of your "enemies", the
> "defenders of the true 9front faith", whatever that is supposed to
> mean.  What have you tried so far, did it work?
> 
> Thanks,
> qwx


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

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

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

[-- Attachment #2: Type: text/html, Size: 4409 bytes --]

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

[Lallero]

Just to be clear, I have nothing against getting aid from an AI in expanding ideas. I just recognised the verbose style. Got nothing to reply on the content


Il 10 maggio 2024 13:53:56 CEST, Lucio De Re <lucio.dere@gmail.com> ha scritto:
>formulated fashion - and gets accused of being an AI or at minimum playing

Lallero

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

[thedaemon via 9fans]

[-- Attachment #1: Type: text/plain, Size: 3321 bytes --]

His name is Moody, you keep spelling it differently in what I can only assume is a passive aggressive way to insult him?

— thedæmon

On Friday, May 10th, 2024 at 6:53 AM, Lucio De Re <lucio.dere@gmail.com> wrote:

> I am not allowed to ignore some advice when Vic raises a much more interesting subject matter and does it in a perfectly justified and well formulated fashion - and gets accused of being an AI or at minimum playing one on 9fans?
>
> How do you know that I did not follow any of Moodley's advice, which incidentally I acknowledged I may not be competent to follow? None of the legacy people I have noted responding have been even remotely as offensive as those who are determined to deify 9front in legacy's place - when there is no effort on legacy's side to promote our particular preference, nor to justify such preference as being superior in any manner.
>
> 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.
>
> Lucio.
>
> On Fri, May 10, 2024 at 12:22 PM qwx via 9fans <9fans@9fans.net> wrote:
>
>> On Fri May 10 11:09:32 +0200 2024, lucio.dere@gmail.com wrote:
>>
>>> I'm finding it ironic, though, that the defenders of the true 9front faith
>>> find it necessary to insult their "enemies" in a forum dedicated to the
>>> very subject matter they are so disapproving of. Surely they realise that
>>> 9fans is a stupid place to do so?
>>>
>>> Lucio.
>> 
>> Several people, including 9front users, have tried to help you and
>> provided you with ways to accomplish your task; they have been so far
>> ignored. Even Moody himself gave you alternatives and arguably easier
>> ways to do it. Here's another one: mycroftiv's ANTS was in sync with
>> 9front for a while and fully supports fossil; it is now out of date
>> but the last ANTS release will probably work on your hardware. iirc
>> noam had also tried to update it based on latest 9front some time
>> ago, but I'm not sure where that lives.
>> 
>> You have everything you need, courtesy of your "enemies", the
>> "defenders of the true 9front faith", whatever that is supposed to
>> mean. What have you tried so far, did it work?
>> 
>> Thanks,
>> qwx
>
> --
>
> 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](https://9fans.topicbox.com/latest) / 9fans / see [discussions](https://9fans.topicbox.com/groups/9fans) + [participants](https://9fans.topicbox.com/groups/9fans/members) + [delivery options](https://9fans.topicbox.com/groups/9fans/subscription) [Permalink](https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M8d97eaec0e9d4e395d19361b)
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcca3cba6e150de7a1db2fd9d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 5433 bytes --]

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 4113 bytes --]

Most certainly not. I called him Jacob in my first response, but that was
followed by someone using the surname and I thought I had originally got
the surname wrong, probably by reading it wrong in the incoming message. I
did consider being wrong, but I thought someone would correct me. Now you
did.

My apologies to Jacob, first, and second to anyone else who may have found
my behaviour offensive,

Lucio.

On Fri, May 10, 2024 at 2:39 PM thedaemon via 9fans <9fans@9fans.net> wrote:

> His name is Moody, you keep spelling it differently in what I can only
> assume is a passive aggressive way to insult him?
>
> — thedæmon
>
> On Friday, May 10th, 2024 at 6:53 AM, Lucio De Re <lucio.dere@gmail.com>
> wrote:
>
> I am not allowed to ignore some advice when Vic raises a much more
> interesting subject matter and does it in a perfectly justified and well
> formulated fashion - and gets accused of being an AI or at minimum playing
> one on 9fans?
>
> How do you know that I did not follow any of Moodley's advice, which
> incidentally I acknowledged I may not be competent to follow? None of the
> legacy people I have noted responding have been even remotely as offensive
> as those who are determined to deify 9front in legacy's place - when there
> is no effort on legacy's side to promote our particular preference, nor to
> justify such preference as being superior in any manner.
>
> 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.
>
> Lucio.
>
> On Fri, May 10, 2024 at 12:22 PM qwx via 9fans <9fans@9fans.net> wrote:
>
>> On Fri May 10 11:09:32 +0200 2024, lucio.dere@gmail.com wrote:
>>
>> > I'm finding it ironic, though, that the defenders of the true 9front
>> faith
>> > find it necessary to insult their "enemies" in a forum dedicated to the
>> > very subject matter they are so disapproving of. Surely they realise
>> that
>> > 9fans is a stupid place to do so?
>> >
>> > Lucio.
>> 
>> Several people, including 9front users, have tried to help you and
>> provided you with ways to accomplish your task; they have been so far
>> ignored.  Even Moody himself gave you alternatives and arguably easier
>> ways to do it.  Here's another one: mycroftiv's ANTS was in sync with
>> 9front for a while and fully supports fossil; it is now out of date
>> but the last ANTS release will probably work on your hardware.  iirc
>> noam had also tried to update it based on latest 9front some time
>> ago, but I'm not sure where that lives.
>> 
>> You have everything you need, courtesy of your "enemies", the
>> "defenders of the true 9front faith", whatever that is supposed to
>> mean.  What have you tried so far, did it work?
>> 
>> Thanks,
>> qwx
>
>
> --
> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcca3cba6e150de7a1db2fd9d>
>


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

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

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

[-- Attachment #2: Type: text/html, Size: 6376 bytes --]

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

[qwx via 9fans]

On Fri May 10 13:55:58 +0200 2024, lucio.dere@gmail.com wrote:

> I am not allowed to ignore some advice when Vic raises a much more
> interesting subject matter and does it in a perfectly justified and well
> formulated fashion - and gets accused of being an AI or at minimum playing
> one on 9fans?

So you're ignoring the answers and advice people are giving you,
including my own, because it's just not interesting enough?


> How do you know that I did not follow any of Moodley's advice, which
> incidentally I acknowledged I may not be competent to follow?

Then which of Moody's suggestions did you try, and what worked?


> None of the
> legacy people I have noted responding have been even remotely as offensive
> as those who are determined to deify 9front in legacy's place - when there
> is no effort on legacy's side to promote our particular preference, nor to
> justify such preference as being superior in any manner.
> 
> 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'm puzzled why you feel there's any kind of crusade against 9legacy
going on.  Moody was direct about problems he has had trying to
collaborate in the past, and hiro questioned some of Vic's statements,
essentially just asking "why".  I don't see where the pitchforks or
the deification is, I must be just stupid.  Can you point to specific
statements you feel are so abrasive or offensive?

Thanks,
qwx

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

[kvik]

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

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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]

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 <kvik@a-b.xyz> 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
Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Ma35bdb36e0ec374698abde17
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3789 bytes --]

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 <lucio.dere@gmail.com> 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 <kvik@a-b.xyz> 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] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vic.thacker]

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 <lucio.dere@gmail.com> 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 <kvik@a-b.xyz> 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-M526c8c293297541ee0ff6c0d
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 <vic.thacker@fastmail.fm> 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 <lucio.dere@gmail.com> 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 <kvik@a-b.xyz> 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] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vic.thacker]

Perhaps adopting this mindset could be beneficial. When developing a feature, it's worth considering its potential for portability and usefulness to other communities.

Vic

On Sun, May 12, 2024, at 07:27, hiro wrote:
> just send the code then
>
> On Sun, May 12, 2024 at 12:22 AM <vic.thacker@fastmail.fm> 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 <lucio.dere@gmail.com> 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 <kvik@a-b.xyz> 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-M85b60529f8d0c8789138465a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[ori]

As far as I can tell, 9front doesn't have a problem
on this side; we just imported the Power64 compilers,
have working versions of risc64, etc, all pulled in
from the 9legacy world.

The work to port usually ranges between negligible
and trivial.

As far as I can tell, the only thing preventing 9front
changes from making their way back to 9legacy is a lack
of hands to do the work.

And while I'm happy to lend a hand, help debug, and even
make trivial changes to enhance portability, I personally
don't care to spend time porting software to a system I
don't intend to use.

tl;dr: you need people doing the work before you can try
to organize them; the way to get people doing the work is
to bootstrap it by doing work and showing value.

Quoth vic.thacker@fastmail.fm:
> Perhaps adopting this mindset could be beneficial. When developing a feature, it's worth considering its potential for portability and usefulness to other communities.
> 
> Vic
> 
> On Sun, May 12, 2024, at 07:27, hiro wrote:
> > just send the code then
> >
> > On Sun, May 12, 2024 at 12:22 AM <vic.thacker@fastmail.fm> 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 <lucio.dere@gmail.com> 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 <kvik@a-b.xyz> 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-Mb17573a9b6cf014d60859905
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Jacob Moody]

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

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

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

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

[plan6]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

"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-M612a57d35367f2de904e3eb2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1113 bytes --]

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

[vic.thacker]

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, plan6@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-M9e2163e0d5b11f835cf9b2b2
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)

[vester.thacker]

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-Mc0fa30d5ea72f95df95970de
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[plan6]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

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-M527f1433bb6ae0ec70a6a99f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1012 bytes --]

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

[vester.thacker]

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, plan6@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-Mcbfa4fef559b42babac44bab
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 step back. step forward and put your money where your mouth is.

On Sun, May 12, 2024 at 2:42 PM <vester.thacker@fastmail.fm> 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, plan6@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)

[plan6]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

"what you really want"...
Fuck, now I have the Spice Girls song in mind : /
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M936ff37e60f8d604f9181726
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 823 bytes --]

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

[vic.thacker]

I'm stepping back to listen.  Perhaps you're not a software engineer.  It is good to discuss before starting.

Vic  


On Sun, May 12, 2024, at 22:11, hiro wrote:
> why step back. step forward and put your money where your mouth is.
>
> On Sun, May 12, 2024 at 2:42 PM <vester.thacker@fastmail.fm> 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, plan6@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-M3bd18cdbea206712408fc2e4
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[qwx via 9fans]

On Sun May 12 14:43:17 +0200 2024, vester.thacker@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-M6a6ba83828236109b9c23a90
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)

[vic.thacker]

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, qwx@nopenopenope.net wrote:
> On Sun May 12 14:43:17 +0200 2024, vester.thacker@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-M1a00fb7eb0c7bb27d1f4d4d9
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 <vic.thacker@fastmail.fm> 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, qwx@nopenopenope.net wrote:
> > On Sun May 12 14:43:17 +0200 2024, vester.thacker@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] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vester.thacker]

Thank you, Hiro, for your insights.

I apologize to everyone for my intense and fervent approach; I acknowledge that I often overlook subtleties. To add a bit of humor, even my son has saved my contact as "Rambo" in his mobile phone. :-)

Vic


On Mon, May 13, 2024, at 00:55, hiro wrote:
> 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 <vic.thacker@fastmail.fm> 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, qwx@nopenopenope.net wrote:
>> > On Sun May 12 14:43:17 +0200 2024, vester.thacker@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-M28d19e105429cec6856056a0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[plan6]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

There's no attack, just questions. Let's say we speak with someone who rely on LLMs to get his point but still have a "need" that doesn't seem to be fulfilled by the community.
I have real questions: What are your motivations? 
Why don't you simply ask for what you want personally and stop telling us that you speak for the community.
How don't you understand that the "chatGPT" style is kind of irritating and redundant and that it won't help you to get what you really want?
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M395ea311dbde03e1f785722d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1291 bytes --]

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 <vester.thacker@fastmail.fm> 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)

[ori]

that's not what I said.

Quoth vic.thacker@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, plan6@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-M29a8b8a91cbfeb7a6d3a88d3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[vester.thacker]

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, ori@eigenstate.org wrote:
> that's not what I said.
>
> Quoth vic.thacker@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, plan6@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-M0ee970051b70040b8daee3a5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[ori]

I don't think this approach has ever worked in
the open source world -- it always starts with
someone building something useful. The vision
and goal is defined by the work being done.

After something useful is built, people start
to join in and contribute.

After enough people join in, it makes sense to
have more organization.

Quoth vester.thacker@fastmail.fm:
> The complexity of communication in this medium often necessitates detailed discussions.  You highlighted the need for additional personnel to manage the workload (e.g. do the work).  From my perspective, this requires a well-defined vision, clear objectives, and a prioritized list of deliverables to align efforts effectively.  Currently, it seems the role of product managers is collectively held, though it's unclear who exactly is responsible.  Typically, a team of two or more individuals would focus on these deliverables.  In past projects, I've seen the use of a project board to keep everyone updated on tasks—an approach known as "information radiator" in project management.  I'm open to other methods if you had something different in mind that I may have overlooked.  If you are considering a meritocracy, I would recommend caution.  Experience has shown that what we truly need is increased collaboration and unity, rather than a system that could potentially encourage competition and division.  I apologize if my message is obtuse, I am trying to keep this message concise, I can expound more for clarity.  I hope my explanation helps. 
> 
> Vic
> 
> 
> On Mon, May 13, 2024, at 03:36, ori@eigenstate.org wrote:
> > that's not what I said.
> >
> > Quoth vic.thacker@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, plan6@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-M0a94c7102286e462a972a310
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)

[Dan Cross]

On Sun, May 12, 2024 at 9:33 PM <ori@eigenstate.org> wrote:
> I don't think this approach has ever worked in
> the open source world -- it always starts with
> someone building something useful. The vision
> and goal is defined by the work being done.
>
> After something useful is built, people start
> to join in and contribute.
>
> After enough people join in, it makes sense to
> have more organization.

I remain mystified by the desired end state here.  For all intents and
purposes, as far as the wider world is concerned, 9front is plan 9.
I'm not sure I'd want that burden, to be honest, but that's just me.
That aside, realistically, 9front is the only thing in the plan 9
world that has energy behind it.

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

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

So what is it, exactly, that people want?

        - Dan C.

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

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

[Kurt H Maier via 9fans]

On Sun, May 12, 2024 at 09:46:12PM -0400, Dan Cross wrote:
> 
> So what is it, exactly, that people want?

The only people who feel like there's some conflict to resolve are
people who do not use the software and have nothing to offer except for
social commentary. This "us vs them" shit is only of interest to people
who are unaware that the argument stopped happening years ago.  "What
people want" is in general to feel like they're helping, but these days
it's a rare 9fan whose head is inserted so deep that middle management 
seems like the helping hand we all need.

Everyone in the Plan 9 world has what they want, at this point, except
maybe unlimited free time to pursue the to-do list.

khm

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

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

[Jacob Moody]

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

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

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

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

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

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

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

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


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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 5633 bytes --]

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

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

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

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

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

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

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

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

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

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

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

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

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

Therefore 9front is a fork but p9f's provided final release is the real thing with a clear ownership and license. 9legacy would be the right choice as the current plan9 but it contains code from sources which bare the risk of infecting a MIT licensed plan9 if no measures are taken regarding these problems.


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

[-- Attachment #2: Type: text/html, Size: 7101 bytes --]

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

[vic.thacker]

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

Vic


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

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

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

[Jacob Moody]

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

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

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

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

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

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

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

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

> 
> My fork isn't the only one which gets distributed. I'm sure there exist millions of devices with plan9 integrated without anyone noticing except for those who look into the documentation where the MIT licensed copyright is placed.
> 
> If people from forks like 9front are talking about numbers of their users I always have to laugh. My fork is right now used by about 500 people per semester more users. And be assured this is an unimportant number.

And Java runs on a billion devices.

> 
> Not a single developer who uses plan9 for distributed systems, commercial products will dare to use a system like 9front as the sources. The reason is quite simple :
> 
> You ignore copyrights as you please and distributed 9front under an MIT license long before Nokia as the owner of it decided to do so. You did that at a time when plan9 was placed under GPL.
> 
> 9front is a fork your fork I respect your work. But all your commits and enhancements are absolutly useless for people who intend or use plan9 not only  to play around with this system but make professional use of it. The first thing such people have to check is the way you handle licenses.

I'm quite curious as to your definition of "professional" in one where none of the work done by 9front would be seen as beneficial.
I'm glad you expanded upon this, I think its important context to have for why you didn't suggest 9front to our new user here.

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

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

[clinton]

[-- Attachment #1: Type: text/plain, Size: 7824 bytes --]

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

On Monday, May 13, 2024, Jacob Moody <moody@posixcafe.org> wrote:

> On 5/12/24 22:52, ibrahim via 9fans wrote:
> > On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote:
> >> When people suggest tossing that all out for a minimally patched 4e, I
> think some people rightfully feel a bit annoyed. That's a lot of baby that
> goes out with that bathwater.
> >
> > It's Davids decission what he includes as patches for the 4th edition
> but I would toss everything out of 9legacy which isn't part of the 4th
> edition or contributed by the team members at Bell Labs from their archives
> as enhancements.
> >
> > The reasoning is simple : p9f owns the rights for the final release and
> Nokia has made this release available under a MIT license. Every one who
> uses plan9 not only to toy around or his/her personal use but also as a
> system which he/she distributes like I do can't afford risks with code
> integrated from sources like 9front. There are some libraries taken from
> 9front derived from other open source projects like freetype (truetype)
> where copyright notices are absent and this isn't the only library
> > where in code comments the sources are named but the original copyright
> notices are absent.
> >
> > plan9 as represented by p9f has a clear license all parts which are not
> MIT licensed are marked as such but code back ported from other forks like
> 9front contain code where I have doubts if those are really under an MIT
> license as you state in your documentation cause deriving from a different
> license or taking large amounts of code doesn't remove viral licenses like
> LGPL or GPL.
>
> If you have a list of libraries that you feel do not represent their
> license providence by /lib/legal/NOTICE in our 9front tree, let me know we
> should probably get that updated.
> Our libttf is not derived from freetype as I understand it.
>
> >
> > It would be in the interest of plan9 and all who professionally use it
> in embedded systems or as a distributed operating system to keep suspicious
> code out of the 9legacy CD. If really necessary to provide such
> contributions or back ports I wouldn't place them in the system folders but
> as it was in the past in contrib folders for additional download. The risks
> to infect a clearly licensed system gifted by Nokia to all of us to make
> best use of it for free commercial private embedded ...
> > solutions are to high and I would really prefer it when nothing from
> forks like 9front would take its way into the 9legacy CD ROM which is
> defined as :
> >
> >          Plan 9 archives, reference releases of Plan 9.
> >
> >          9legacy, Plan 9 with many useful patches applied. Download page
> has an
> >          installation CD image including 386, amd64, and arm kernels and
> binaries;
> >          a bootable USB image for 386; a bootable SD card image for
> Raspberry Pi;
> >          and virtual disk images for QEMU and GCE.
> >
> >          The 4th Edition distribution from Bell Labs:
> >          live CD/install CD/USB image, installation notes,
> >          browse the source, additional software
>
> Are you implying that a majority of users are using Plan9 in a commercial
> setting? That seems a bit absurd.
> For personal use I think these license issues (if they do even exist) are
> of no concern. I think you are greatly
> exaggerating the possible issue here for your average user.
>
> >
> > I respect your fork 9front but I won't and can't use it. 9front isn't
> plan9 from my perspective. Plan 9 is the final release with patches for the
> files from sources I can be sure that those aren't taken from open source
> projects by copy and paste. The moment I and others who use plan9 for
> distribution or embed it on systems we have to be absolutely sure about the
> sources of the code. I can trust Bell Labs, Nokia, p9f but I won't trust
> some guys who toy around with their fork of plan9. The moment
> > FSF or another organisation starts to suit me because they recognized
> that some guy at any forked system has copy pasted code from a viral
> licensed project I am the one who has to take the consequences.
>
> Again, I think in your situation of distributing hardware with plan 9 or
> whatever, then it makes sense to do whatever your lawyer says.
> I think advising against using 9front for every user on these grounds
> though is misleading at best.
>
> >
> > The first thing I am doing after downloading an iso from 9 legacy is to
> remove all files which were not part of the final plan9 release. The second
> thing I have always to do is removing all patches from the iso which came
> from sources I can't be sure if they really followed licensing rules. The
> third thing I have to do before distributing my fork of plan9 is to remove
> fonts ghostscript diff page and other parts of the system which would
> infect the distribution media to make sure the created
> > system is not depending on viral licensed code.
>
> Do you also remove the Lucida and printer fonts? These were released as
> part of the original source but have interesting claims as to the ability
> to redistribute them.
> Do you also strip out the parts of ape that include ancient GNU utilities?
> Are you running your system without a diff and patch?
>
> >
> > My fork isn't the only one which gets distributed. I'm sure there exist
> millions of devices with plan9 integrated without anyone noticing except
> for those who look into the documentation where the MIT licensed copyright
> is placed.
> >
> > If people from forks like 9front are talking about numbers of their
> users I always have to laugh. My fork is right now used by about 500 people
> per semester more users. And be assured this is an unimportant number.
>
> And Java runs on a billion devices.
>
> >
> > Not a single developer who uses plan9 for distributed systems,
> commercial products will dare to use a system like 9front as the sources.
> The reason is quite simple :
> >
> > You ignore copyrights as you please and distributed 9front under an MIT
> license long before Nokia as the owner of it decided to do so. You did that
> at a time when plan9 was placed under GPL.
> >
> > 9front is a fork your fork I respect your work. But all your commits and
> enhancements are absolutly useless for people who intend or use plan9 not
> only  to play around with this system but make professional use of it. The
> first thing such people have to check is the way you handle licenses.
> 
> I'm quite curious as to your definition of "professional" in one where
> none of the work done by 9front would be seen as beneficial.
> I'm glad you expanded upon this, I think its important context to have for
> why you didn't suggest 9front to our new user here.

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

[-- Attachment #2: Type: text/html, Size: 9591 bytes --]

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

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

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

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

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

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

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

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

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

[-- Attachment #2: Type: text/html, Size: 2459 bytes --]

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

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

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

Please correct me if I'm wrong.

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

[-- Attachment #2: Type: text/html, Size: 2788 bytes --]

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

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

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

>
>
> Please correct me if I'm wrong.
> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M87ce4c9f9e82fb2fa4b938f2>
>

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

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

[-- Attachment #2: Type: text/html, Size: 1313 bytes --]

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

[Kurt H Maier via 9fans]

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


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

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

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

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

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

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

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

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

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

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

That practice predates 9front.

Hope this clears up the history.

khm

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

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

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

[-- Attachment #2: Type: text/html, Size: 1134 bytes --]

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

[sirjofri]

Hey all,

Just about one topic mentioned by ibrahim:

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

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

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

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

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

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

---

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

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

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

sirjofri

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

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

[vic.thacker]

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-M3cce19283b50acc036e39c94
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 <vic.thacker@fastmail.fm> 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] List of companies that use Plan 9.

[vic.thacker]

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-M59ea1a26d206f6c427eaef2b
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 <vic.thacker@fastmail.fm> 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] List of companies that use Plan 9.

[G B via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

 Curiously, I searched for Nantalala Systems and found an https link to NANTAHALA SYSTEMS. *****BEWARE: SEEMS TO BE BOGUS***** 
Under "store" they list two workstations they sell, both listed as "sold out" that are 
   
   - OS: FreeBSD with ᴁBSD customizations

Under ᴁOS (aka ᴁ9) installation media for x86™ computers and ᴁOS (aka ᴁ9) installation media for Raspberry PI™ computers there are "Learn more" links that lead to "page not found."
At the bottom of the page:   
   - ᴁBSD (AMD64) is ᴁBSD customizations on FreeBSD 14.0-STABLE.
   - GhostBSD is based on FreeBSD 14.0-STABLE.
   - ᴁBSD (AARCH64) is ᴁBSD customizations on FreeBSD 15-CURRENT.
   - ᴁOS (aka ᴁ9) is based on Plan 9.

On the Support page, if you happened to somehow purchase one of those workstations and need assistance, you need to contact them the only way possible:      Email: hello@nantahala.systems

Netcraft shows the hosting country as Australia. The domain registrar is unknown. The SSL/TLS certificate issued by Let's Encrypt is for "From Mar 14 2024 to Jun 12 2024 (2 months, 4 weeks)" .



    On Monday, May 13, 2024 at 07:58:20 AM CDT, hiro <23hiro@gmail.com> wrote:  
 
 citation needed

On Mon, May 13, 2024 at 1:58 PM <vic.thacker@fastmail.fm> 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-Mf58cc718484d6a1fce4d858b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 7017 bytes --]

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

[vic.thacker]

Yes, that is curious.  

On Mon, May 13, 2024, at 22:59, G B wrote:
> Curiously, I searched for Nantalala Systems and found an https link to 
> NANTAHALA SYSTEMS. *****BEWARE: SEEMS TO BE BOGUS***** 
> Under "store" they list two workstations they sell, both listed as 
> "sold out" that are 
>   
>    - OS: FreeBSD with ᴁBSD customizations
>
> Under ᴁOS (aka ᴁ9) installation media for x86™ computers and ᴁOS (aka 
> ᴁ9) installation media for Raspberry PI™ computers there are "Learn 
> more" links that lead to "page not found."
> At the bottom of the page:   
>    - ᴁBSD (AMD64) is ᴁBSD customizations on FreeBSD 14.0-STABLE.
>    - GhostBSD is based on FreeBSD 14.0-STABLE.
>    - ᴁBSD (AARCH64) is ᴁBSD customizations on FreeBSD 15-CURRENT.
>    - ᴁOS (aka ᴁ9) is based on Plan 9.
>
> On the Support page, if you happened to somehow purchase one of those 
> workstations and need assistance, you need to contact them the only way 
> possible:      Email: hello@nantahala.systems
>
> Netcraft shows the hosting country as Australia. The domain registrar 
> is unknown. The SSL/TLS certificate issued by Let's Encrypt is for 
> "From Mar 14 2024 to Jun 12 2024 (2 months, 4 weeks)" .
>
>
>
>     On Monday, May 13, 2024 at 07:58:20 AM CDT, hiro <23hiro@gmail.com> wrote:  
> 
>  citation needed
>
> On Mon, May 13, 2024 at 1:58 PM <vic.thacker@fastmail.fm> 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-Mf58cc718484d6a1fce4d858b
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

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

[vic.thacker]

On Mon, May 13, 2024, at 21:56, hiro wrote:
> citation needed

https://sosenterprise.sd.gov/BusinessServices/Business/FictitiousDetail.aspx?CN=078243101203005056228191044241171252181195229085

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

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

[B. Atticus Grobe]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

Taking the time to go through that, it's literally just you; your LLC.
Interesting the you didn't feel the need for transparency and simply say
'this is my company.'

This certainly fails to inspire even the least bit of confidence in me.

On Mon, May 13, 2024, 16:19 <vic.thacker@fastmail.fm> wrote:

> On Mon, May 13, 2024, at 21:56, hiro wrote:
> > citation needed
> 
> 
> https://sosenterprise.sd.gov/BusinessServices/Business/FictitiousDetail.aspx?CN=078243101203005056228191044241171252181195229085

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

[-- Attachment #2: Type: text/html, Size: 2319 bytes --]

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

[vic.thacker]

On Tue, May 14, 2024, at 23:12, B. Atticus Grobe wrote:
> Taking the time to go through that, it's literally just you; your LLC.
> Interesting the you didn't feel the need for transparency and simply say
> 'this is my company.'

The intention of this thread was to highlight which companies are using Plan 9. I mentioned two companies as examples.

The use of Plan 9 should be celebrated. It's surprising to encounter complaints about its utilization.

Vic

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

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

[B. Atticus Grobe]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

Oh, I think it's great that people are using it. I simply find the
obfuscatory nature of your presentation to be suspicious. It is generally
considered to be good etiquette to disclose affiliations to a company
during discussions. Failure to do so is not necessarily damning, but is
certainly a 'red flag', at least for me.

As for companies that use 9, Coraid (Brantley Coile) was invested in 9 for
their network storage systems, although it's possible their newer products
don't utilize it. He is responsible for vblade(8) and I believe also for
the kernel AoE driver. (I haven't verified the origin of the kernel driver;
corrections welcome.)

On Tue, May 14, 2024, 11:04 <vic.thacker@fastmail.fm> wrote:

> On Tue, May 14, 2024, at 23:12, B. Atticus Grobe wrote:
> > Taking the time to go through that, it's literally just you; your LLC.
> > Interesting the you didn't feel the need for transparency and simply say
> > 'this is my company.'
> 
> The intention of this thread was to highlight which companies are using
> Plan 9. I mentioned two companies as examples.
> 
> The use of Plan 9 should be celebrated. It's surprising to encounter
> complaints about its utilization.
> 
> Vic

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

[-- Attachment #2: Type: text/html, Size: 2823 bytes --]

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

[arnold]

"B. Atticus Grobe" <grobe0ba@gmail.com> wrote:

> As for companies that use 9, Coraid (Brantley Coile) was invested in 9 for
> their network storage systems, although it's possible their newer products
> don't utilize it.

They still do. See his posts on LinkedIn.

Arnold

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

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

[Steve Simon]

[-- Attachment #1.1: Type: text/html, Size: 4887 bytes --]

[-- Attachment #1.2: Brantley-Coile.jpg --]
[-- Type: image/jpeg, Size: 39493 bytes --]

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

[vic.thacker]

On Wed, May 15, 2024, at 02:54, Steve Simon wrote:
> coraid has an interesting history.
>
> Brantley-Coile.jpg
> How Silicon Valley can kill your business, by a man scolded by the 
> machine 
> <https://www.information-age.com/silicon-valley-can-kill-business-man-scolded-machine-6832/>
> information-age.com 
> <https://www.information-age.com/silicon-valley-can-kill-business-man-scolded-machine-6832/>
>  
> <https://www.information-age.com/silicon-valley-can-kill-business-man-scolded-machine-6832/>
>
> Brantley now has the Coraid name back too and is using plan9 to this day.
>
> -Steve

Thank you, Steve, for sharing that. There are some valuable lessons in the article. The best lessons are often learned from experiences of others.  It’s wonderful to learn that Coraid is still thriving, and that is something worth celebrating.  

If Brantley Coile still reads 9fans, thank you sir for being an inspiration to me and many others.  

Vester "Vic" Thacker

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

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

[tlaronde]

On Tue, May 14, 2024 at 06:54:02PM +0100, Steve Simon wrote:
> [html edited]
>
> coraid has an interesting history.
> https://www.information-age.com/silicon-valley-can-kill-business-man-scolded-machine-6832/

This is another illustration of "The Mythical Man-Month".

I still think there is place for a small, understandable system,
providing too features that other systems try not to master, but to
add to a pile of things that is already too huge---look at the
problems and the amount of code appearing now on the kernel side for
Unices for KMSDRM (already more or less considered a dead end, because
the graphical terminal is almost anecdoctical for the GPU).

How could such OSes be a correct fundation for reliable data
storage?---and even for something else in fact.

I don't know what is the trend in U.S., but in France, as usual, "big"
companies get to "cloud" like sheeps, not for any technical reason
but because it was fashionable and this gained managers photos in
magazines for doing so.

And they had been selling their data centers, firing their staff and so
on and promising costs cuts and incredible efficiency.

Neither costs reduction, nor security or efficiency have been
achieved.

And they are now silently trying to restore data centers of their own,
trying to get back what they, in fact, paid to give.

Because of war everything will collapse and the current insane beasts:
the software dinosaurs, will not survive.

I don't know if black holes do exist but I'm convinced that there are
already, out there, software implementations of black holes: things
that will collapse under their own weight.

There is still a chance for Plan9 based/like systems.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                     http://nunc-et-hic.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

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

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

[Wes Kussmaul]

On 5/14/24 15:05, tlaronde@kergis.com wrote:
> 
>  
> I don't know if black holes do exist but I'm convinced that there are
> already, out there, software implementations of black holes: things
> that will collapse under their own weight.

The biggest black hole of them all: https://silibandia.com

-- 

*Wes Kussmaul*

*Reliable Identities, Inc.*
an Authenticity Enterprise
738 Main Street
Waltham, MA 02451 USA





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

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

[tlaronde]

On Tue, May 14, 2024 at 03:44:37PM -0400, Wes Kussmaul wrote:
> 
> 
> On 5/14/24 15:05, tlaronde@kergis.com wrote:
> > 
> > I don't know if black holes do exist but I'm convinced that there are
> > already, out there, software implementations of black holes: things
> > that will collapse under their own weight.
> 
> The biggest black hole of them all: https://silibandia.com
> 

https://www.theguardian.com/australia-news/article/2024/may/09/unisuper-google-cloud-issue-account-access

"Google Cloud accidentally deletes UniSuper's online account due to
`unprecedented misconfiguration'

Super fund boss and Google Cloud global CEO issue joint statement
apologising for `extremely frustrating and disappointing' outage"

Well, I work on GIS. A points cloud is something that one has to
interpret, looking at it from far, and that disappears once you zoom
for a special information. This is also an inorganized collection of
data (this is only the one who looks at it from far that organizes the
picture). For it to be useful, it has to be replaced by organized
information that you extract from it. This is not then a cloud anymore...

I guess this also explains why I had from the beginning absolute
distrust to the whole hyped thing---whatever the provider.
Distributed, load balancing, tightly coupled multiprocessing, fault
tolerant internal system: yes. My system "somewhere", administrated by
"someone", shared with "everyone": no.
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                     http://nunc-et-hic.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

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

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

[michaelian ennis]

> On May 14, 2024, at 12:07, tlaronde@kergis.com wrote:
> M
> This is another illustration of "The Mythical Man-Month".

There were many lessons from “The Mythical Man Month” that seem glaringly missing from management decisions during those days. It was shocking. There were other more perplexing oddities too in the decision making process.  

I have much to say about the topic but this is perhaps not the right place. Perhaps it is not my place at all.

The VC years have a cartoonish character to them that seemed to be filled with an unlimited supply of “Wait, we’re doing what?” moments. Yes I’m looking at you boombox.

What I think is relevant here is that even the plan9 engineers on different coasts seemed to get divided by details not unlike the recent discussions’ beginnings. This didn’t help win arguments about product direction.

Then there was me just always bitching about Fred Brooks, or ways in which the cli was inconsistent, full of “we should”s and “we shouldn’t”s and noticing when I was right in dissent more than when I was wrong. So there’s that.

In some possible universes _that_ Coraid thrived 
but they are not ones where where new voices weren’t heard or old ones were ignored.

The flurries of traffic on this list often seem to have a negative tone to me.  It means a lot to me when the conversations are supportive. 

I hope this recent activity continues on as more collaborative conversations.  Nobody joins this list who isn’t interested in participating somehow.  Let’s not shut them down.

Ian





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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 5829 bytes --]

If this comes across as a troll, keep in mind that it is your
interpretation that makes it so, a lesson we South Africans are still busy
learning, at our country's expense.

I've got Fossil running under 9front; thanks to all those who prodded me
(and others). I would be happier knowing that there is a "canonical"
version rather than at least two varieties as appears to be the case from
the above discussion, but I'd rather not spoil the moment.

My point all along was that if the source (Fossil or other) is not included
in the (9front) distribution, a (bad) decision is being made by arbitrary
(non)contributors for all the silent participants who may not even know
about it. Why would anyone want to play God? Isn't Google bad enough?

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

As for the cryptography angle, that was an eye opener for sure and for
many, apparently. On my part, I still don't have SSH2 working from my own
Plan 9 "legacy", I haven't been able to shoehorn the right combination of
9legacy patches into it. It is surprising that I haven't broken it entirely
and I know I came close to doing that on occasion. I had a working version
of ssh-agent working smoothly on my system, both for Plan 9 and P9P (both
Linux and NetBSD), but a hardware failure exposed my lack of discipline and
I haven't had the need or fortitude to recover the working "branch" from
Git, that version control is too complicated for me to feel comfortable
with it, I use it only under duress. Now, after suggestions on this forum
that support my impressions, I want to look at bringing "the other Fossil"
on board using PostgreSQL running under NetBSD instead of embedded SQLite.
Don't hold your breath, though.

One more point, but I may raise more later, seeing that there is a claimed
interest in how others use the generic Plan 9 platform: I long ago ported
the OpenLDAP tools to Plan 9 and I continually use them to access remote
directories with them from a scrappy rc shell script. I noted only recently
that the OpenLDAP distribution has an option to build only the tools and
library, which vindicates my approach which happened rather
serendipitously. I need to investigate that further, my version of the tool
I think goes back to 2.3 or thereabouts. Graphviz I have also been unable
to promote past a very early version, but it works quite nicely for my
occasional use of Dot.

Let me point out also that I have paid absolutely no attention to licencing
requirements; where I live the culture remains that of "sanction busting"
from the Apartheid era and IP prosecutions don't seem to occur very often.
I do think that P9F would be kept quite busy assisting those of us that may
need legal advice or assistance and in some respects I think that role
would be beneficial to all of us - including myself - and it seems a role
that P9F is already playing. Just my impression, of course, but earlier
discussion does bring that to mind.

In short: I totally agree with Ian, we are responsible for what and how
gets discussed here.

Lucio.

On Wed, May 15, 2024 at 1:20 AM michaelian ennis <michaelian.ennis@gmail.com>
wrote:

>
>
> > On May 14, 2024, at 12:07, tlaronde@kergis.com wrote:
> > M
> > This is another illustration of "The Mythical Man-Month".
> 
> There were many lessons from “The Mythical Man Month” that seem glaringly
> missing from management decisions during those days. It was shocking. There
> were other more perplexing oddities too in the decision making process.
> 
> I have much to say about the topic but this is perhaps not the right
> place. Perhaps it is not my place at all.
> 
> The VC years have a cartoonish character to them that seemed to be filled
> with an unlimited supply of “Wait, we’re doing what?” moments. Yes I’m
> looking at you boombox.
> 
> What I think is relevant here is that even the plan9 engineers on
> different coasts seemed to get divided by details not unlike the recent
> discussions’ beginnings. This didn’t help win arguments about product
> direction.
> 
> Then there was me just always bitching about Fred Brooks, or ways in which
> the cli was inconsistent, full of “we should”s and “we shouldn’t”s and
> noticing when I was right in dissent more than when I was wrong. So there’s
> that.
> 
> In some possible universes _that_ Coraid thrived
> but they are not ones where where new voices weren’t heard or old ones
> were ignored.
> 
> The flurries of traffic on this list often seem to have a negative tone to
> me.  It means a lot to me when the conversations are supportive.
> 
> I hope this recent activity continues on as more collaborative
> conversations.  Nobody joins this list who isn’t interested in
> participating somehow.  Let’s not shut them down.
> 
> Ian
> 


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

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

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

[-- Attachment #2: Type: text/html, Size: 7674 bytes --]

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

[vic.thacker]

Firstly, congratulations to Lucio on the progress with getting Fossil running under 9front. A heartfelt thank you to everyone who offered their support and assistance to make this possible!  I only say this as a person who wants to celebrate successes.

FWIW, I’d like to help clarify the additional requests that Lucio has made to address each point effectively on a separate thread.  Here are Lucio’s requests, organized by topic:

Canonical Version of Fossil

    Unified Version: There is a need for a single, "canonical" version of Fossil to avoid confusion and fragmentation. Multiple versions can complicate usage and development.

Inclusion of Sources in Distributions

    Key Source Inclusion: Including important sources like Fossil in the 9front distribution is crucial. Excluding these sources can lead to decisions made by a few contributors affecting all users, especially those unaware of the exclusions.

9legacy Boot and Installation

    USB Boot and Installation: For 9legacy, it’s essential to enable it to boot, install, and run from a USB stick on any PC hardware, with support for both IDE and SATA. This would enhance accessibility and user-friendliness.

SSH2 Implementation

    Plan 9 Legacy: Lucio is encountering challenges in getting SSH2 to work in his Plan 9 legacy setup. Finding the right combination of patches has been difficult. Guidance or collaboration to achieve a stable implementation would be greatly appreciated.

Cryptography and Security

    Secure Communication Tools: Discussions about cryptography have been enlightening, but implementing and maintaining secure communication tools like SSH and ssh-agent remains challenging. Support in this area would be beneficial.

Version Control with Fossil and PostgreSQL

    Integration: Lucio is considering integrating "the other Fossil" with PostgreSQL running under NetBSD instead of embedded SQLite. This is complex, and any advice or assistance from experienced members would be invaluable.

Porting and Updating Tools

    OpenLDAP Tools: Lucio has ported OpenLDAP tools to Plan 9 and uses them regularly, but they are based on an older version. Investigating the latest build options and updating these tools would be beneficial.
    Graphviz Update: Updating Graphviz past its early version to ensure better functionality and compatibility would help those relying on it.

Licensing and Legal Support

    Legal Advice: Given the local culture of "sanction busting" and the rarity of IP prosecutions where Lucio lives, he hasn’t paid much attention to licensing. P9F could play a crucial role in providing legal advice and support to ensure adherence to licensing requirements.

I hope you find this useful.

Vic


On Wed, May 15, 2024, at 13:46, Lucio De Re wrote:
> If this comes across as a troll, keep in mind that it is your
> interpretation that makes it so, a lesson we South Africans are still busy
> learning, at our country's expense.
>
> I've got Fossil running under 9front; thanks to all those who prodded me
> (and others). I would be happier knowing that there is a "canonical"
> version rather than at least two varieties as appears to be the case from
> the above discussion, but I'd rather not spoil the moment.
>
> My point all along was that if the source (Fossil or other) is not included
> in the (9front) distribution, a (bad) decision is being made by arbitrary
> (non)contributors for all the silent participants who may not even know
> about it. Why would anyone want to play God? Isn't Google bad enough?
>
> I concede that I didn't know myself what I was looking for (I think what
> "I" need is for 9legacy to boot, install and possibly run, from a USB stick
> on any PC hardware, and support both IDE and SATA where present) and my
> rather vague question was intended to make the details less sketchy.
> Instead, I got a tirade about what I was or was not ready, willing or able
> to contribute. Fortunately, that tends to have the desired effect with me,
> so right now I haven't yet recovered my decades of pretty pointless effort,
> but I know I can do it, with sufficient application, it is no longer lost
> or teetering on edge of the abyss.
>
> As for the cryptography angle, that was an eye opener for sure and for
> many, apparently. On my part, I still don't have SSH2 working from my own
> Plan 9 "legacy", I haven't been able to shoehorn the right combination of
> 9legacy patches into it. It is surprising that I haven't broken it entirely
> and I know I came close to doing that on occasion. I had a working version
> of ssh-agent working smoothly on my system, both for Plan 9 and P9P (both
> Linux and NetBSD), but a hardware failure exposed my lack of discipline and
> I haven't had the need or fortitude to recover the working "branch" from
> Git, that version control is too complicated for me to feel comfortable
> with it, I use it only under duress. Now, after suggestions on this forum
> that support my impressions, I want to look at bringing "the other Fossil"
> on board using PostgreSQL running under NetBSD instead of embedded SQLite.
> Don't hold your breath, though.
>
> One more point, but I may raise more later, seeing that there is a claimed
> interest in how others use the generic Plan 9 platform: I long ago ported
> the OpenLDAP tools to Plan 9 and I continually use them to access remote
> directories with them from a scrappy rc shell script. I noted only recently
> that the OpenLDAP distribution has an option to build only the tools and
> library, which vindicates my approach which happened rather
> serendipitously. I need to investigate that further, my version of the tool
> I think goes back to 2.3 or thereabouts. Graphviz I have also been unable
> to promote past a very early version, but it works quite nicely for my
> occasional use of Dot.
>
> Let me point out also that I have paid absolutely no attention to licencing
> requirements; where I live the culture remains that of "sanction busting"
> from the Apartheid era and IP prosecutions don't seem to occur very often.
> I do think that P9F would be kept quite busy assisting those of us that may
> need legal advice or assistance and in some respects I think that role
> would be beneficial to all of us - including myself - and it seems a role
> that P9F is already playing. Just my impression, of course, but earlier
> discussion does bring that to mind.
>
> In short: I totally agree with Ian, we are responsible for what and how
> gets discussed here.
>
> Lucio.
>
> On Wed, May 15, 2024 at 1:20 AM michaelian ennis <michaelian.ennis@gmail.com>
> wrote:
>
>>
>>
>> > On May 14, 2024, at 12:07, tlaronde@kergis.com wrote:
>> > M
>> > This is another illustration of "The Mythical Man-Month".
>> 
>> There were many lessons from “The Mythical Man Month” that seem glaringly
>> missing from management decisions during those days. It was shocking. There
>> were other more perplexing oddities too in the decision making process.
>> 
>> I have much to say about the topic but this is perhaps not the right
>> place. Perhaps it is not my place at all.
>> 
>> The VC years have a cartoonish character to them that seemed to be filled
>> with an unlimited supply of “Wait, we’re doing what?” moments. Yes I’m
>> looking at you boombox.
>> 
>> What I think is relevant here is that even the plan9 engineers on
>> different coasts seemed to get divided by details not unlike the recent
>> discussions’ beginnings. This didn’t help win arguments about product
>> direction.
>> 
>> Then there was me just always bitching about Fred Brooks, or ways in which
>> the cli was inconsistent, full of “we should”s and “we shouldn’t”s and
>> noticing when I was right in dissent more than when I was wrong. So there’s
>> that.
>> 
>> In some possible universes _that_ Coraid thrived
>> but they are not ones where where new voices weren’t heard or old ones
>> were ignored.
>> 
>> The flurries of traffic on this list often seem to have a negative tone to
>> me.  It means a lot to me when the conversations are supportive.
>> 
>> I hope this recent activity continues on as more collaborative
>> conversations.  Nobody joins this list who isn’t interested in
>> participating somehow.  Let’s not shut them down.
>> 
>> Ian
>> 
> 
> 
> --
> Lucio De Re
> 2 Piet Retief St
> Kestell (Eastern Free State)
> 9860 South Africa
> 
> Ph.: +27 58 653 1433
> Cell: +27 83 251 5824

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

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

[Jacob Moody]

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

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

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



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

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

[vic.thacker]

On Wed, May 15, 2024, at 15:11, Jacob Moody wrote:
> At this point I can't really tell if you're using some LLM to be ironic 
> or if you actually think this junk
> is of any substance. I am not sure how you don't see this copy pasta 
> garbage as anything else than a waste
> of everyone else's inbox and time.

No, I am not being ironic at all. I understand that you do not know me. I am a seriously minded 20-year public servant, and I once held Q access authorization, where everything is taken extremely seriously. Since retiring, I am still adapting to civilian life. Perhaps this explains why my son has me listed as Rambo on his mobile phone. I also have a very dry sense of humor.

A better solution might be to inform others on how to interface with each community. For example, providing clear instructions on how to submit feature and bug requests. This is something I haven’t seen mentioned recently. It would be beneficial for each community to explain what is acceptable in these interactions.

In lieu of that, I’ll simply post for clarity in the hope that it piques interest and fosters further conversations.

Hope this helps.

Vic

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

[plan6]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]

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.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9bf40e9448c878ab-Mcc1cdcca2cec06e6edd2ec2a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 888 bytes --]

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

[vic.thacker]

On Wed, May 15, 2024, at 16:39, plan6@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-Me8e9f5029e323348324f05fc
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. ]

[sirjofri]

15.05.2024 11:17:46 vic.thacker@fastmail.fm:
> 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.

In this specific case, I think it was a misunderstanding on your side. Lucio mentioned a problem and asked for solutions. You understood it as a bug report that was not obviously flagged as a bug report. Lucio clearly stated in the last mail that he didn't ask for anything. He was merely asking about some problem he had. In my opinion that's a big difference.

Read also this: https://fqa.9front.org/fqa2.html#2.4

> It is possible you simply don’t know what you’re doing. If you do not understand how something is done in 9front or how it works, and can’t figure out how to resolve the problem using the manual pages, [...]
> 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.

I understand that. That's also one of the reasons why my mails are usually so long. Keep in mind though that people here are reading mails because they want to, and they all try to understand them.

I'm reminded of a friend who's working for the German government. He was sending out a mail with a spreadsheet to some colleague with the wish to fill it out. That colleague asked back multiple times: first, if that mail was sent to her on purpose and if she's the correct recipient. Second, if she is supposed to fill out that spreadsheet. Third, if she should fill out that one specific column that is described as "please fill out this column". Those people aren't here on this mailing list, but I would totally understand extremely verbose (-vvvvv) mails like yours if you managed people like that for many years!

I'm glad I don't have a job like that...

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9bf40e9448c878ab-M16d34b8ead3f8f9c3e1e69b7
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 <vic.thacker@fastmail.fm> wrote:
>
> On Wed, May 15, 2024, at 16:39, plan6@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: Clarifying Lucio's Additional Requests [Was: Re: [9fans] List of companies that use Plan 9. ]

[vic.thacker]

On Wed, May 15, 2024, at 19:35, hiro wrote:
> it's not much of a degree if they don't require you to read Strunk & White

Sure, I'll show you an example.

It was one of the best scholarships available. You should have seen my writing before. ;-)

Uriel admired Strunk & White. Today, many colleges follow the Purdue Writing Lab's guidance. Students learn the seven styles described by Strunk & White.

Vic

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

[sirjofri]

Hey vic,

There are a few different issues I see with your mails:

First and most obvious, they sound like they're generated by some LLM (playing captain obvious here). People don't like to see this, it might be related to some language barrier. That impression is also supported by the content.

Which leads to the second point: the content of your mails make me feel like you feel the urge/need to help. While help is generally appreciated, it depends. If you can only help by organizing stuff then organizing "the one single plan 9 system" doesn't lead to anything because that doesn't exist. 9legacy and 9front are both organized by their contributors, who all work for free. No money, no demands, no big organization that tells them what to do. It would be better if you find another way to help, preferably one that doesn't incorporate mails so long that nobody wants to read them with content that nobody wants to know.

It is generally fine to share patches and also bug reports to the mailing lists (yes there's a separate 9front mailing list for 9front topics). For 9front, there's even a section in the fqa about bug reports. Note that all bug reports suck in some way, and people who work on the systems do it for free. Also, not all apparent bugs are bugs, so keep using plan 9 systems until you understand how it is supposed to work (or ask).

In general, the people on our mailing lists know how to work with each other. You'll occasionally see discussion about patches (especially on 9front), as well as about other topics. There are also other channels of communication (irc, mostly). Be assured that people communicate with each other, as far as they are willing to. I've never seen so much interaction between 9front and 9legacy as in the last few years.

Other than that, your mails often enough just state the obvious. People read between the lines to understand what the person means. This sometimes fails to work, but that's just part of human communication. Your ability to summarize a mailing list thread about three different topics into a list of 7 user story action points is not well perceived, which I can rotally understand: it doesn't help anyone.

My advice would be (not sure if it helps):

Write your mails. Write them, don't send them. Read them again carefully and think about the people reading it. They most likely understand as much as you, and they have all the track record of earlier discussions, so they very likely understand more than you. Things are as they are for a reason. Not always for a good reason, but for a reason. After thinking about your mail and the recipient, you may revise/rewrite your mail or just throw it away.

Last, we're not a company. People who do the work are the ones organizing. Those people don't like to see strangers organizing their stuff without any contribution. If you can write software, try to organize yourself and give something back to the community. Hunt for bugs and fix them, or write tools that helps people, or improve the documentation. This should help the community much more than top-level organization when there is no top-level.

I hope this mail finds you well, please read it with some smile. I don't want to hurt anyone, and text can be rude sometimes.

sirjofri

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

[Aleksandar Kuktin]

[-- Attachment #1.1: Type: text/plain, Size: 1161 bytes --]

>On Wed, 15 May 2024 10:38:53 +0200 (GMT+02:00)
>sirjofri <sirjofri+ml-9fans@sirjofri.de> wrote:
>
> Hey vic,
> 
> There are a few different issues I see with your mails:

> Last, we're not a company. People who do the work are the ones
> organizing. Those people don't like to see strangers organizing their
> stuff without any contribution. If you can write software, try to
> organize yourself and give something back to the community. Hunt for
> bugs and fix them, or write tools that helps people, or improve the
> documentation. This should help the community much more than
> top-level organization when there is no top-level.

As a long-time lurker, I'd like to offer the following URLs as
evidence the preceding paragraph should be taken as culturally
normative:
https://catb.org/~esr/faqs/hacker-howto.html
https://catb.org/~esr/faqs/loginataka.html

This is the way hackers work, together, on building a better world.

-- 
Svi moji e-mailovi su kriptografski potpisani. Proverite ih.
All of my e-mails are cryptographically signed. Verify them.
--
You don't need an AI for a robot uprising.
Humans will do just fine.
--

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]


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

[vic.thacker]

On Wed, May 15, 2024, at 17:38, sirjofri wrote:
> Hey vic,
...
> Write your mails. Write them, don't send them. Read them again 
> carefully and think about the people reading it. They most likely 
> understand as much as you, and they have all the track record of 
> earlier discussions, so they very likely understand more than you. 
> Things are as they are for a reason. Not always for a good reason, but 
> for a reason. After thinking about your mail and the recipient, you may 
> revise/rewrite your mail or just throw it away.
>
> Last, we're not a company. People who do the work are the ones 
> organizing. Those people don't like to see strangers organizing their 
> stuff without any contribution. If you can write software, try to 
> organize yourself and give something back to the community. Hunt for 
> bugs and fix them, or write tools that helps people, or improve the 
> documentation. This should help the community much more than top-level 
> organization when there is no top-level.

Thanks, Sirjofri, I really appreciate your message. 

I'll keep things more casual in this message. I didn't use Strunk & White, which would have really annoyed people, but I agree that my posts have been rushed and barely revised.

I wanted to classify the topics to see if anyone was already working on them as it wasn't apparent. Some developers can be very territorial, and I didn't want to step into a mess. My plan was to ask around next.  I see that the current team is very happy with the status quo.     

If the hacker culture rules are necessary, I'm definitely not a good fit. I should step aside to avoid being disruptive. I've been programming for a long time, and I work in a very different manner. I'd rather avoid the drama I've experienced the past few days. I can only imagine the hell it must be to contribute. I don't mean that in an offensive way, but I'm just looking back on the hazing that has been happening. **heavy sigh** 

I was told this is a flat model, yet I see there is a meritocracy and outdated rules as well as too much hazing occurring. Hazing alone is enough to off put someone. I surmise there is too much entitlement occurring which results in both hazing and a cancel culture.  I am not trying to persuade you or anyone on 9fans, but rather I just want to show you what I see.  I've worked on 160 million USD projects and have needed to fix personnel issues.  I know this is not a company, but anyone that cannot see there are issues here has their head in the sand. I hope you take my comments as constructive. The intention of my comments to make things better. 
 
You've helped me see that I'm not a good cultural fit, which is good to know early. 

Again, thank you very much for your advice.  Let me share a letter with you that I wrote to Bakul and then I'll leave 9fans. 
Thank you and goodbye. 

Hi Bakul,

Thanks for reaching out.  I trust you are well. 

I have my own personal Plan 9 distribution that I have been using 
for years, circa 2006.   9legacy and 9front are great, but I find it 
challenging to contribute.  However, the 9legacy community has 
been much more friendly and helpful as you can imagine.  I am 
grateful for past help.

Whenever I witness the challenges faced between 9legacy and 
9front communities, I can't help but feel responsible.

Looking back, I see that my youthful inexperience played a role 
in deepening the rift between Plan 9 and what would become 
9front. At the time, I failed to bridge the gap between influential 
opposition members, such as Uriel and 20h, and the foundational 
members of the community, like Russ Cox and others. Now, as I 
contemplate my legacy, my goal was to somehow mend the 
division and foster unity among the communities before my time 
ends.  I think I could have prevented the need for 9front years ago 
and the community would had been in a better state today.  That 
is my biggest regret that I have.  That is one reason why I isolate
myself.  I am just not a good mediator nor communicator.

Sadly, I don't have what it takes to bridge the gap. I think that my 
idea of mending the communities is too grand. Also, I'm saddened 
to see the more I try to help the worse the situation becomes. 

Kind regards,
Vic


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

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 5751 bytes --]

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

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

There are other companies using Plan 9 in commercial operations/offerings,
but I don't think they care to be a part of whatever this mailing list has
become.

D


On Wed, May 15, 2024 at 10:00 AM <vic.thacker@fastmail.fm> wrote:

> On Wed, May 15, 2024, at 17:38, sirjofri wrote:
> > Hey vic,
> ...
> > Write your mails. Write them, don't send them. Read them again
> > carefully and think about the people reading it. They most likely
> > understand as much as you, and they have all the track record of
> > earlier discussions, so they very likely understand more than you.
> > Things are as they are for a reason. Not always for a good reason, but
> > for a reason. After thinking about your mail and the recipient, you may
> > revise/rewrite your mail or just throw it away.
> >
> > Last, we're not a company. People who do the work are the ones
> > organizing. Those people don't like to see strangers organizing their
> > stuff without any contribution. If you can write software, try to
> > organize yourself and give something back to the community. Hunt for
> > bugs and fix them, or write tools that helps people, or improve the
> > documentation. This should help the community much more than top-level
> > organization when there is no top-level.
> 
> Thanks, Sirjofri, I really appreciate your message.
> 
> I'll keep things more casual in this message. I didn't use Strunk & White,
> which would have really annoyed people, but I agree that my posts have been
> rushed and barely revised.
> 
> I wanted to classify the topics to see if anyone was already working on
> them as it wasn't apparent. Some developers can be very territorial, and I
> didn't want to step into a mess. My plan was to ask around next.  I see
> that the current team is very happy with the status quo.
> 
> If the hacker culture rules are necessary, I'm definitely not a good fit.
> I should step aside to avoid being disruptive. I've been programming for a
> long time, and I work in a very different manner. I'd rather avoid the
> drama I've experienced the past few days. I can only imagine the hell it
> must be to contribute. I don't mean that in an offensive way, but I'm just
> looking back on the hazing that has been happening. **heavy sigh**
> 
> I was told this is a flat model, yet I see there is a meritocracy and
> outdated rules as well as too much hazing occurring. Hazing alone is enough
> to off put someone. I surmise there is too much entitlement occurring which
> results in both hazing and a cancel culture.  I am not trying to persuade
> you or anyone on 9fans, but rather I just want to show you what I see.
> I've worked on 160 million USD projects and have needed to fix personnel
> issues.  I know this is not a company, but anyone that cannot see there are
> issues here has their head in the sand. I hope you take my comments as
> constructive. The intention of my comments to make things better.
> 
> You've helped me see that I'm not a good cultural fit, which is good to
> know early.
> 
> Again, thank you very much for your advice.  Let me share a letter with
> you that I wrote to Bakul and then I'll leave 9fans.
> Thank you and goodbye.
> 
> Hi Bakul,
> 
> Thanks for reaching out.  I trust you are well.
> 
> I have my own personal Plan 9 distribution that I have been using
> for years, circa 2006.   9legacy and 9front are great, but I find it
> challenging to contribute.  However, the 9legacy community has
> been much more friendly and helpful as you can imagine.  I am
> grateful for past help.
> 
> Whenever I witness the challenges faced between 9legacy and
> 9front communities, I can't help but feel responsible.
> 
> Looking back, I see that my youthful inexperience played a role
> in deepening the rift between Plan 9 and what would become
> 9front. At the time, I failed to bridge the gap between influential
> opposition members, such as Uriel and 20h, and the foundational
> members of the community, like Russ Cox and others. Now, as I
> contemplate my legacy, my goal was to somehow mend the
> division and foster unity among the communities before my time
> ends.  I think I could have prevented the need for 9front years ago
> and the community would had been in a better state today.  That
> is my biggest regret that I have.  That is one reason why I isolate
> myself.  I am just not a good mediator nor communicator.
> 
> Sadly, I don't have what it takes to bridge the gap. I think that my
> idea of mending the communities is too grand. Also, I'm saddened
> to see the more I try to help the worse the situation becomes.
> 
> Kind regards,
> Vic
> 

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

[-- Attachment #2: Type: text/html, Size: 7501 bytes --]

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

[sirjofri]

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

I didn't know that he's been here for so long. It's sad that you both perceive the state of the mailing list community as it is.

I can also totally see that vic is trying to help. I just see that the help he's providing in the last few months wasn't very helpful, and it also wasn't well perceived by all readers.

However, I can also only judge from my perspective, and I'm only here for a few years now.

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

I personally consider it a valid move to ask a LLM for help writing mails. It's just weird to do that on a mailing list like this. I doubt that vic used an AI or anything (I mean, why would he lie).

I can also see one or the other trolling attempt here, and I see only a few different reasons for that:

(1) People are tired because they're always reading the same arguments and defending themselves for the 1000th time. It's understandable that somw develop a trolling tone.

(2) People have fun trolling other people. In my opinion this belongs into human communication to some extent, but it shouldn't be endorsed and it should only happen in some safe space. On this mailing list, this is sometimes too much.

(3) People are trolls. In this case we're out of luck.

> There are other companies using Plan 9 in commercial operations/offerings, but I don't think they care to be a part of whatever this mailing list has become. 

(Still interested in learning about them.)

Sorry, I can't really perceive "whatever this mailing list has become". I'm not here for too long, and I probably don't see it as critical as you. I should note however that 9fans threads often are either non-existent (the list is very silent), half-dead or total drama (as this giga-thread). Compared to the 9front mailing list, there's almost only constructive work, feedback, steps forward.

I also notice that there's barely any software development going on here (almost no patches, no discussion). Is this because the mailing list evolved like that and people don't want to contribute in that environment, or is it the reason why it evolved like that?

Funnily enough, the 9fans discord community is very nice, helpful, I can barely see any trolling attempt at all (at least I can't remember anything like that).

sirjofri

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

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 5015 bytes --]

Yeah that's the thing, the few of us that have been around for 20 years
enjoyed the discussion as much as the engineering. But the discussion was
always around what to/not to do and how to do it. I was probably the
biggest outsider, as my career prior to diving into Plan 9 was classical
violin. I brought an art mindset to an engineering ecosystem and used the
opportunity to learn as much as I could from the Plan 9 guys, who I
definitely considered my engineering heroes (and still do). I'll never
forget the side conversations with jmk about how to go about testing kernel
code and him bringing me "back down to Earth". One of many little
encounters that honestly have made me into a much more refined engineer
today. Albeit, with still quite a ways to grow :-)

I think it may just be harder for us "old heads" to understand how to fit
in with the modern communication style here. And I don't say this to be
fiery or disrespectful, but a lot of the discussions come off paranoid and
inflammatory while simultaneously accusing everyone *else* of being quite
the same. It's very strange and is a big reason a lot of people have left
or just choose to lurk.

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

D


On Wed, May 15, 2024 at 10:57 AM sirjofri <sirjofri+ml-9fans@sirjofri.de>
wrote:

> 15.05.2024 16:18:49 Don Bailey <don.bailey@gmail.com>:
> > This thread is perhaps one of the best examples of the bizarre ecosystem
> that Plan 9 has evolved (devolved?) into. While I have not always
> understood Vic's choices, I was, in the past, aware of his /position/ at
> certain entities... and provided him with security information I hoped was
> relevant to that position at that time. He has been on the Plan 9 mailing
> list as long (or longer?) than I have (pre-2002?) and has always written
> his emails in the fashion he writes them currently.
>
> I didn't know that he's been here for so long. It's sad that you both
> perceive the state of the mailing list community as it is.
>
> I can also totally see that vic is trying to help. I just see that the
> help he's providing in the last few months wasn't very helpful, and it also
> wasn't well perceived by all readers.
>
> However, I can also only judge from my perspective, and I'm only here for
> a few years now.
>
> > Frankly, I don't even understand the point in attacking whether he is or
> is not "an LLM". He's actually trying to be helpful. Perhaps spending less
> time trolling everyone you don't understand (and inaccurately presume to be
> a troll), and instead trying to understand how they purport to add value,
> is a useful path forward.
>
> I personally consider it a valid move to ask a LLM for help writing mails.
> It's just weird to do that on a mailing list like this. I doubt that vic
> used an AI or anything (I mean, why would he lie).
>
> I can also see one or the other trolling attempt here, and I see only a
> few different reasons for that:
>
> (1) People are tired because they're always reading the same arguments and
> defending themselves for the 1000th time. It's understandable that somw
> develop a trolling tone.
>
> (2) People have fun trolling other people. In my opinion this belongs into
> human communication to some extent, but it shouldn't be endorsed and it
> should only happen in some safe space. On this mailing list, this is
> sometimes too much.
>
> (3) People are trolls. In this case we're out of luck.
>
> > There are other companies using Plan 9 in commercial
> operations/offerings, but I don't think they care to be a part of whatever
> this mailing list has become.
> 
> (Still interested in learning about them.)
> 
> Sorry, I can't really perceive "whatever this mailing list has become".
> I'm not here for too long, and I probably don't see it as critical as you.
> I should note however that 9fans threads often are either non-existent (the
> list is very silent), half-dead or total drama (as this giga-thread).
> Compared to the 9front mailing list, there's almost only constructive work,
> feedback, steps forward.
> 
> I also notice that there's barely any software development going on here
> (almost no patches, no discussion). Is this because the mailing list
> evolved like that and people don't want to contribute in that environment,
> or is it the reason why it evolved like that?
> 
> Funnily enough, the 9fans discord community is very nice, helpful, I can
> barely see any trolling attempt at all (at least I can't remember anything
> like that).
> 
> sirjofri

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

[-- Attachment #2: Type: text/html, Size: 6564 bytes --]

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

[sirjofri]

15.05.2024 17:04:56 Don Bailey <don.bailey@gmail.com>:
> Yeah that's the thing, the few of us that have been around for 20 years enjoyed the discussion as much as the engineering. But the discussion was always around what to/not to do and how to do it. I was probably the biggest outsider, as my career prior to diving into Plan 9 was classical violin. I brought an art mindset to an engineering ecosystem and used the opportunity to learn as much as I could from the Plan 9 guys, who I definitely considered my engineering heroes (and still do). I'll never forget the side conversations with jmk about how to go about testing kernel code and him bringing me "back down to Earth". One of many little encounters that honestly have made me into a much more refined engineer today. Albeit, with still quite a ways to grow :-) 

I always enjoy when people work with the system, and not only "on" it. Having actual users make most sense to me. I mean, it's an operating system. Having users from non-dev side (like sl, who's a writer) is also great.

That discussion type you describe is something I can see on the 9front mailing list and the 9fans discord. I really hope 9fans can turn back to that state eventually.

> I think it may just be harder for us "old heads" to understand how to fit in with the modern communication style here. And I don't say this to be fiery or disrespectful, but a lot of the discussions come off paranoid and inflammatory while simultaneously accusing everyone *else* of being quite the same. It's very strange and is a big reason a lot of people have left or just choose to lurk.

That's why I like to end messages with the most neutral smiley I can find. And I also try to read messages that way. Text can be rude, and I often enough find myself reading a text message in a discussion thread like a shakespeare program: arguing, fighting. However, the writer almost never intended to mean that!

I also sometimes miss the fidonet messaging style. As far as I could experience it, it was always friendly and constructive.

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

Agreeing is not necessary. There are many topics where we don't have to agree to be a community. For example, I'd like to see libxml in 9front, but the decision makers decided against it. More recently, people wished for fossil to come back to 9front, but the decision makers decided against it. Both have their reasons, and we can always fork off another fork and begin our own distribution, or just have our own local version with our changes.

Another example in the opposite direction: many users use various rio versions with theming etc. I don't want that. It's not part of the distribution (with very few exceptions), and it's 100% optional.

We don't always have to agree, but as long as we can discuss things in peace and exchange information we can still be a community.

sirjofri

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

[Jens Staal]

On Wed, May 15, 2024 at 05:20:21PM GMT, sirjofri wrote:
> 
> Agreeing is not necessary. There are many topics where we don't have to agree to be a community. For example, I'd like to see libxml in 9front, but the decision makers decided against it. More recently, people wished for fossil to come back to 9front, but the decision makers decided against it. Both have their reasons, and we can always fork off another fork and begin our own distribution, or just have our own local version with our changes.

I can probably put libxml2 in APExp [1] if you want. I have not done it yet
since nothing else I build there at the moment has this dependency, but
I had an old port of it that probably can be updated.

[1] https://github.com/staalmannen/apexp
 

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

[Jacob Moody]

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

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

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

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


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

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

[ori]

Quoth vic.thacker@fastmail.fm:
> Sadly, I don't have what it takes to bridge the gap. I think that my 
> idea of mending the communities is too grand. Also, I'm saddened 
> to see the more I try to help the worse the situation becomes. 

The communities are mending more or less fine, at least
among the people who actually hack on things. Code is
shared and imported in both directions, and discussion
is happening.

What is making things worse for you is back seat driving.
Starting from a position of contributing work might go
over well. Trying to tell me how I should spend my time
will require you to pay me.

For example:

> I have my own personal Plan 9 distribution that I have been using 
> for years, circa 2006.

Why should I listen to you about how to heal fractured
communities, when you have a community so fractured, it
has one member, and was effectively a secret for 18 years?

A first step would be putting it out there. A second would
be listing the changes you've felt the need to make. Ideally
with some reasoning.

If that's out there, I'll happily look through, and if it
makes sense, I'll integrate parts into 9front. The 9legacy
folks may or may not, but at least they'll have the choice.

So:

> but I find it  challenging to contribute. 

If you want to change that, I think the first step is
starting with some humility. Instead of trying to make
other people into your unpaid interns, start by figuring
out how to contribute.

Find a bug. Write a patch. Send a fix. Work on a specific
problem. Realize that people will only pay attention after
work gets done.

But, I've said this before. I don't expect it will get
listened to this time either.


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

[ori]

Quoth vic.thacker@fastmail.fm:
> A better solution might be to inform others on how to interface with
> each community.  For example, providing clear instructions on how to
> submit feature and bug requests.  This is something I haven’t seen
> mentioned recently.  It would be beneficial for each community to
> explain what is acceptable in these interactions.

Section 2.4 and 2.5 of the FQA: https://fqa.9front.org/fqa2.html#2.4

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

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

[Jacob Moody]

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

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

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

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

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

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

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


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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 4736 bytes --]

I have asked precisely NOTHING and have only pointed out the consequences
of omitting sources from the 9front distribution because it leads to
undesirable divisions.

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

Lucio.

On Wed, May 15, 2024 at 8:05 AM Jacob Moody <moody@posixcafe.org> wrote:

> On 5/14/24 23:46, Lucio De Re wrote:
> > If this comes across as a troll, keep in mind that it is your
> interpretation that makes it so, a lesson we South Africans are still busy
> learning, at our country's expense.
> >
> > I've got Fossil running under 9front; thanks to all those who prodded me
> (and others). I would be happier knowing that there is a "canonical"
> version rather than at least two varieties as appears to be the case from
> the above discussion, but I'd rather not spoil the moment.
> >
> > My point all along was that if the source (Fossil or other) is not
> included in the (9front) distribution, a (bad) decision is being made by
> arbitrary (non)contributors for all the silent participants who may not
> even know about it. Why would anyone want to play God? Isn't Google bad
> enough?
> The decision was not made by an arbitrary contributor on a whim, it was
> decided after people maintaining 9front got sick
> and tired of dealing with people's data getting minced. Effort was put in
> to the two (and soon to be three) other
> file systems that have had a much better reliability track record. The
> intent was to nudge people away from
> using what was deemed buggy software. If you want this to change then
> either you or someone else needs to step up and maintain
> the software. You are asking for 9front to take on the burden of
> maintaining an additional old buggy filesystem
> because it makes your life a tiny bit easier?
>
> A bit hard to tell from your wording but either you are saying the
> contributor became a "noncontributor" by deleting
> fossil or are you accusing the person who deleted fossil as being
> generally a "noncontributor"?
> If you had spent even 10 seconds looking at the git history you would have
> seen that the one to pull the plug and
> delete fossil was cinap and not some random passerby.
>
> Do you not see the irony here? You, a most certain "noncontributor", are
> demanding that we do what you want without any intent of doing any of the
> work yourself.
> Why can you not just tar up your files and put them on a supported
> filesystem? Why are we still having this discussion?
>
> >
> > I concede that I didn't know myself what I was looking for (I think what
> "I" need is for 9legacy to boot, install and possibly run, from a USB stick
> on any PC hardware, and support both IDE and SATA where present) and my
> rather vague question was intended to make the details less sketchy.
> Instead, I got a tirade about what I was or was not ready, willing or able
> to contribute. Fortunately, that tends to have the desired effect with me,
> so right now I haven't yet recovered my decades of pretty
> > pointless effort, but I know I can do it, with sufficient application,
> it is no longer lost or teetering on edge of the abyss.
>
> Yes because you are asking for other people to maintain your software for
> you for free. 9front maintainers do not want to do
> this, so the reaction is going to be to do it yourself. I don't know why
> this is seen as a surprising outcome.
>
> On 5/14/24 18:19, michaelian ennis wrote:
> >
> >
> >
> > The flurries of traffic on this list often seem to have a negative tone
> to me.  It means a lot to me when the conversations are supportive.
> 
> I agree, I would like to have positive interactions towards working on
> solutions to current problems. I would much prefer if conversations
> trended towards these type of topics. We seem to have no issue keeping
> things like this at IWP9 (for the most part).
> 


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

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

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

[-- Attachment #2: Type: text/html, Size: 6322 bytes --]

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

[ori]

Quoth Lucio De Re <lucio.dere@gmail.com>:
> 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.

Yes, in theory it would have been nice if we had people who had
volunteered to maintain it.


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

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

[Jacob Moody]

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

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

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

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



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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]

What makes you think I want Fossil back in 9front? I suggested that the
sources could be included in the distribution, so they would not fork-rot
as they are doing presently. It's always been the case that the Plan 9
distribution included "broken" sources that could not be compiled without
external support, but were interesting enough to be published. That changed
some when Alef was dropped and in fact I saved the Alef development stuff
and ported it to 3ed and 4ed because I disagreed with the decision. Note
that I made a sweeping generalisation, for simplicity, much was discarded
between 2ed and 4ed, and I find all that quite regrettable.

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

And I will not go away. Not by choice.

Lucio.

On Wed, May 15, 2024 at 4:37 PM Jacob Moody <moody@posixcafe.org> wrote:

> On 5/15/24 04:02, Lucio De Re wrote:
> > I have asked precisely NOTHING and have only pointed out the
> consequences of omitting sources from the 9front distribution because it
> leads to undesirable divisions.
>
> I'm just trying to correct the misinformation you stated.
> When you call the decision to drop fossil "bad", your email reads as a
> persuasive argument for why things should change.
> I was in turn explaining why this is not happening, and if someone wanted
> that to change what would need to happen.
>
> >
> > I do find it tiresome that you keep ascribing intentions to me that may
> well reflect precisely how YOU would feel and react in my position. I
> assure I am nothing like that and I'm sure my history on 9fans for the past
> 20+ years would reflect that. But then again, people have abandoned 9fans
> in the past for reasons not dissimilar from these; I can read the
> undercurrent ("because you are asking for other people to maintain your
> software for you for free"), I am not impolite enough to respond in kind.
> 
> Are your intentions not to persuade someone in the 9front world that
> fossil is worth adding back to the system?
> 


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

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

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

[-- Attachment #2: Type: text/html, Size: 4302 bytes --]

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

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 3892 bytes --]

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

D


On Wed, May 15, 2024 at 11:14 AM Lucio De Re <lucio.dere@gmail.com> wrote:

> What makes you think I want Fossil back in 9front? I suggested that the
> sources could be included in the distribution, so they would not fork-rot
> as they are doing presently. It's always been the case that the Plan 9
> distribution included "broken" sources that could not be compiled without
> external support, but were interesting enough to be published. That changed
> some when Alef was dropped and in fact I saved the Alef development stuff
> and ported it to 3ed and 4ed because I disagreed with the decision. Note
> that I made a sweeping generalisation, for simplicity, much was discarded
> between 2ed and 4ed, and I find all that quite regrettable.
>
> 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'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.
>
> And I will not go away. Not by choice.
>
> Lucio.
>
> On Wed, May 15, 2024 at 4:37 PM Jacob Moody <moody@posixcafe.org> wrote:
>
>> On 5/15/24 04:02, Lucio De Re wrote:
>> > I have asked precisely NOTHING and have only pointed out the
>> consequences of omitting sources from the 9front distribution because it
>> leads to undesirable divisions.
>>
>> I'm just trying to correct the misinformation you stated.
>> When you call the decision to drop fossil "bad", your email reads as a
>> persuasive argument for why things should change.
>> I was in turn explaining why this is not happening, and if someone wanted
>> that to change what would need to happen.
>>
>> >
>> > I do find it tiresome that you keep ascribing intentions to me that may
>> well reflect precisely how YOU would feel and react in my position. I
>> assure I am nothing like that and I'm sure my history on 9fans for the past
>> 20+ years would reflect that. But then again, people have abandoned 9fans
>> in the past for reasons not dissimilar from these; I can read the
>> undercurrent ("because you are asking for other people to maintain your
>> software for you for free"), I am not impolite enough to respond in kind.
>> 
>> Are your intentions not to persuade someone in the 9front world that
>> fossil is worth adding back to the system?
>> 
>
>
> --
> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M2588816c321c02966ca52c27>
>

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

[-- Attachment #2: Type: text/html, Size: 5324 bytes --]

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

[Kurt H Maier via 9fans]

On Wed, May 15, 2024 at 11:20:48AM -0400, Don Bailey wrote:
> But please document them and provide rationale/evidence for their
removal. 
        
You've been on this list a while.  You should remember therefore that   
Fossil was a *constant* topic of debate here for *years*.
Specifically, people kept reporting that Fossil had beshit their data,  
and other people deemed that a skill issue and insisted Fossil was fine.
As bug fixes trickled out, Fossil continued to be fine, and people's    
data kept getting corrupted.  Maybe Fossil is fixed now!  Maybe it
isn't!  It's not worth finding out, and the situation was never helped  
by the "there is no war in Ba Sing Se" crowd refusing to take bug
reports -- and actively attacking bug reporters.
        
So, the backstory of Fossil on 9fans is what led to it getting deleted.
Asking for 'evidence' is just more of the same gaslighting that happened
on this very list.
        
> How was the lack-of-stability tested? To what degree was it tested?
etc.
          
Not how it works.  The burden of support is on the distributor.  Part of
forking software is, when it breaks, people come knocking on your 
door/mailing list/ircnet complaining that "your" software ate their     
computer.  We *knew* Fossil was unreliable, so continuing to ship it in
that state was idiotic.  Removing it was an act of self-defense and/or  
housekeeping, depending on how militant you like your metaphors.
           
Meanwhile, since the defossilization of 9front, Fossil itself continued
to receive attention.  It sounds like the sp9sss dropped the ball on    
coordinating some of that, but we are assured that Fossil is great now.
The problem is: we were assured Fossil was great then, too, especially  
when it wasn't.  Therefore it is the burden of the Chamber of Fossil    
Fraternity Et Exuberance to prove that it is stable, and test it to such
a degree that it's worth considering again.  The rest of us are tired of
driving in that circle.
           
You can even store it on our sources server, or put the code on our git9
repo host.   We don't hate Fossil users.  We just don't want to take   
responsibility for it.
           
khm

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

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

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 3561 bytes --]

It's not gaslighting to ask for evidence. I was here, I remember the
complains with Fossil. But to what degree was that /actually/ Fossil? What
degree was it the configurations, the hardware, the firmware, the
consistency of management/usage? What investigations have gone into those
bits, as well. Setting up and running Fossil requires some knowledge and
maintenance. It is not unlike a classic Volkswagen. They run great if you
constantly bother with them.

It isn't gaslighting to ask for those details. And if we are a code-centric
community, as we claim to be, point to the code that shows me it's
problematic and unstable. Have you found it? And I don't say that to be
coy... where can we demonstrably show that Fossil is volatile? What data
backs that up?

So this is, again, the problem I have with what has occurred on this list.
Anything certain parties here disagree with is brushed off as trolling or
"gaslighting" or any other such term that rationalizes dismissal. Let's be
prescriptive, instead.

D


On Wed, May 15, 2024 at 11:40 AM Kurt H Maier via 9fans <9fans@9fans.net>
wrote:

> On Wed, May 15, 2024 at 11:20:48AM -0400, Don Bailey wrote:
> > But please document them and provide rationale/evidence for their
> removal.
>
> You've been on this list a while.  You should remember therefore that
> Fossil was a *constant* topic of debate here for *years*.
> Specifically, people kept reporting that Fossil had beshit their data,
> and other people deemed that a skill issue and insisted Fossil was fine.
> As bug fixes trickled out, Fossil continued to be fine, and people's
> data kept getting corrupted.  Maybe Fossil is fixed now!  Maybe it
> isn't!  It's not worth finding out, and the situation was never helped
> by the "there is no war in Ba Sing Se" crowd refusing to take bug
> reports -- and actively attacking bug reporters.
>
> So, the backstory of Fossil on 9fans is what led to it getting deleted.
> Asking for 'evidence' is just more of the same gaslighting that happened
> on this very list.
>
> > How was the lack-of-stability tested? To what degree was it tested?
> etc.
> 
> Not how it works.  The burden of support is on the distributor.  Part of
> forking software is, when it breaks, people come knocking on your
> door/mailing list/ircnet complaining that "your" software ate their
> computer.  We *knew* Fossil was unreliable, so continuing to ship it in
> that state was idiotic.  Removing it was an act of self-defense and/or
> housekeeping, depending on how militant you like your metaphors.
> 
> Meanwhile, since the defossilization of 9front, Fossil itself continued
> to receive attention.  It sounds like the sp9sss dropped the ball on
> coordinating some of that, but we are assured that Fossil is great now.
> The problem is: we were assured Fossil was great then, too, especially
> when it wasn't.  Therefore it is the burden of the Chamber of Fossil
> Fraternity Et Exuberance to prove that it is stable, and test it to such
> a degree that it's worth considering again.  The rest of us are tired of
> driving in that circle.
> 
> You can even store it on our sources server, or put the code on our git9
> repo host.   We don't hate Fossil users.  We just don't want to take
> responsibility for it.
> 
> khm

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

[-- Attachment #2: Type: text/html, Size: 5290 bytes --]

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

[Kurt H Maier via 9fans]

On Wed, May 15, 2024 at 11:53:28AM -0400, Don Bailey wrote:
> It's not gaslighting to ask for evidence. I was here, I remember the
> complains with Fossil. But to what degree was that /actually/ Fossil? What
> degree was it the configurations, the hardware, the firmware, the
> consistency of management/usage? What investigations have gone into those
> bits, as well. Setting up and running Fossil requires some knowledge and
> maintenance. It is not unlike a classic Volkswagen. They run great if you
> constantly bother with them.

Believe me, it causes me great personal pain to say this, as a dude who
just sold an 85 Jetta and must physically restrain himself from filling
his yard with air-cooled Boxers, but "constantly bothering" and "running
great" are mutually exclusive.  

> It isn't gaslighting to ask for those details. And if we are a code-centric
> community, as we claim to be, point to the code that shows me it's
> problematic and unstable. Have you found it? And I don't say that to be
> coy... where can we demonstrably show that Fossil is volatile? What data
> backs that up?

It's great that you're willing to take bug reports seriously!  If that
had been the prevailing attitude on 9fans some years back, 9front
probably wouldn't exist, much less exist without an in-tree Fossil.  But
your "point to the code" demand is not a great look.  That *is* more
like the old-school response to Fossil bug reports.  In a way, deleting
Fossil was the grandest test of all -- since it's gone, Fossil has
stopped corrupting my data for sure.  So there's the code causing the
problem, at the granularity I consider worthwhile to pursue.  Nobody
owes you a scientific analysis.  

But if you (or anyone else) wants to put this stuff back in the 9front
tree, it needs to be clearly demonstrated that it won't be a massive
timesink and a distraction from the other, more fun filesystems we have.

> So this is, again, the problem I have with what has occurred on this list.
> Anything certain parties here disagree with is brushed off as trolling or
> "gaslighting" or any other such term that rationalizes dismissal. Let's be
> prescriptive, instead.

No, not "anything."  Specifically this Fossil nonsense.  I don't know
why so many people have deep emotional ties to Fossil, and I'm not
really interested in finding out, but the years of hostility torward
problem reports regarding Fossil, interspersed with "fixes" that
weren't, led me (as an outsider) to conclude that nobody actually
understands how the damn thing works, and if they do they're not
interested in helping maintain it... and that alone is a great reason to
delete the code.  

Anyway I don't understand why everyone is pissed about this.  Anyone who
wants Fossil can install it.  If you want a 'canonical' Fossil, upload
it somewhere and canonize it.  Problem solved.

As an aside, not directed at you, Don: this weird bootlicking where a 
commercial entity has to be involved to make something 'real' is pretty
gross.  We don't need bureaucracy to help one another, and I will never
give a shit if someone's use of the software is for-profit or not, and I
don't understand why it matters at all.

khm

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

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

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 4394 bytes --]

Again, this is a core example I'm talking about. In this email you've
called me gross, a bootlicker, etc, while ignoring my concerns and brushing
them off as "emotional".

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.

D


On Wed, May 15, 2024 at 12:12 PM Kurt H Maier via 9fans <9fans@9fans.net>
wrote:

> On Wed, May 15, 2024 at 11:53:28AM -0400, Don Bailey wrote:
> > It's not gaslighting to ask for evidence. I was here, I remember the
> > complains with Fossil. But to what degree was that /actually/ Fossil?
> What
> > degree was it the configurations, the hardware, the firmware, the
> > consistency of management/usage? What investigations have gone into those
> > bits, as well. Setting up and running Fossil requires some knowledge and
> > maintenance. It is not unlike a classic Volkswagen. They run great if you
> > constantly bother with them.
>
> Believe me, it causes me great personal pain to say this, as a dude who
> just sold an 85 Jetta and must physically restrain himself from filling
> his yard with air-cooled Boxers, but "constantly bothering" and "running
> great" are mutually exclusive.
>
> > It isn't gaslighting to ask for those details. And if we are a
> code-centric
> > community, as we claim to be, point to the code that shows me it's
> > problematic and unstable. Have you found it? And I don't say that to be
> > coy... where can we demonstrably show that Fossil is volatile? What data
> > backs that up?
>
> It's great that you're willing to take bug reports seriously!  If that
> had been the prevailing attitude on 9fans some years back, 9front
> probably wouldn't exist, much less exist without an in-tree Fossil.  But
> your "point to the code" demand is not a great look.  That *is* more
> like the old-school response to Fossil bug reports.  In a way, deleting
> Fossil was the grandest test of all -- since it's gone, Fossil has
> stopped corrupting my data for sure.  So there's the code causing the
> problem, at the granularity I consider worthwhile to pursue.  Nobody
> owes you a scientific analysis.
>
> But if you (or anyone else) wants to put this stuff back in the 9front
> tree, it needs to be clearly demonstrated that it won't be a massive
> timesink and a distraction from the other, more fun filesystems we have.
>
> > So this is, again, the problem I have with what has occurred on this
> list.
> > Anything certain parties here disagree with is brushed off as trolling or
> > "gaslighting" or any other such term that rationalizes dismissal. Let's
> be
> > prescriptive, instead.
> 
> No, not "anything."  Specifically this Fossil nonsense.  I don't know
> why so many people have deep emotional ties to Fossil, and I'm not
> really interested in finding out, but the years of hostility torward
> problem reports regarding Fossil, interspersed with "fixes" that
> weren't, led me (as an outsider) to conclude that nobody actually
> understands how the damn thing works, and if they do they're not
> interested in helping maintain it... and that alone is a great reason to
> delete the code.
> 
> Anyway I don't understand why everyone is pissed about this.  Anyone who
> wants Fossil can install it.  If you want a 'canonical' Fossil, upload
> it somewhere and canonize it.  Problem solved.
> 
> As an aside, not directed at you, Don: this weird bootlicking where a
> commercial entity has to be involved to make something 'real' is pretty
> gross.  We don't need bureaucracy to help one another, and I will never
> give a shit if someone's use of the software is for-profit or not, and I
> don't understand why it matters at all.
> 
> khm

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

[-- Attachment #2: Type: text/html, Size: 6188 bytes --]

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

[Kurt H Maier via 9fans]

On Wed, May 15, 2024 at 12:20:04PM -0400, Don Bailey wrote:
> Again, this is a core example I'm talking about. In this email you've
> called me gross, a bootlicker, etc, while ignoring my concerns and brushing
> them off as "emotional".

What part of "not directed at you, Don" did you fail to parse?

What other entire clauses in my email messages have you failed to parse?
This is a concerning development.

khm

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

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

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

You handwave insults off by pretending like they aren't directed at the
exact person you're responding to :-)

It's quite tiresome, and yet persistent.

D


On Wed, May 15, 2024 at 12:53 PM Kurt H Maier via 9fans <9fans@9fans.net>
wrote:

> On Wed, May 15, 2024 at 12:20:04PM -0400, Don Bailey wrote:
> > Again, this is a core example I'm talking about. In this email you've
> > called me gross, a bootlicker, etc, while ignoring my concerns and
> brushing
> > them off as "emotional".
> 
> What part of "not directed at you, Don" did you fail to parse?
> 
> What other entire clauses in my email messages have you failed to parse?
> This is a concerning development.
> 
> khm

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

[-- Attachment #2: Type: text/html, Size: 2284 bytes --]

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

[Kurt H Maier via 9fans]

On Wed, May 15, 2024 at 12:54:41PM -0400, Don Bailey wrote:
> You handwave insults off by pretending like they aren't directed at the
> exact person you're responding to :-)
> 
> It's quite tiresome, and yet persistent.

When else has it happened?  Do I always do it?  Are there firmware
differences? Have you collected logs on the matter?  I just don't think
you have the data to back up this persistence claim.

I'm generally pretty direct when I want to insult someone.  It's not
like there are meaningful consequences.  If you feel like you were
subject to the category of people I was describing, there's not much I
can do about that, I guess.

khm

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

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

[Jacob Moody]

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

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

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

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

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

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



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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 4631 bytes --]

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 <moody@posixcafe.org> 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
Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M306a6ee417e8e91c0c9e01a7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6189 bytes --]

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 <lucio.dere@gmail.com> 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 <moody@posixcafe.org> 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: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M1843e75ffc3bf40e13ae37d0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Steve Simon]

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-M2f9ed7280e579942145b6ad1
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 <steve@quintile.net> 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.

[Steve Simon]

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 <23hiro@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 <steve@quintile.net> 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-M0d5250f5084dfe501f2a0e2d
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 <steve@quintile.net> 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 <23hiro@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 <steve@quintile.net> 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.

[Noam Preil]

I have found multiple deadlocks over the last few years, and only
bothered fixing one of them. That patch is in 9legacy, as well, now.

During my IWP9 talk in which, among other things, I explained why I
intend to replace fossil despite curently using it, I demonstrated one
of the problems with fossil by (attempting to) install Go, which crashes
the file system _every single time_.

I personally fixed over a dozen issues in Venti, and continue to find
more. To the best of my knowledge, those patches are currently _only_
present in 9front. I was not aware 9legacy existed when I did that
work.

I've lost some data to fossil crashes, since if it e.g. loses power
during a sync, it will end up _erasing_ a file rather than preserving
the old version, which has _broken boot_ if the system crashed while I
was editing lib/profile.

I have a branch of 9front with fossil restored. I have discussed what
would be needed to add fossil upstream again, and there was acceptance
to the possibility if the issues get worked out _first_.

The hostility on this list is pervasive and comes from all sides. If
your goal is positive engagement, this is not the place to do it.



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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 3990 bytes --]

"I have a branch of 9front with fossil restored. I have discussed what
would be needed to add fossil upstream again, and there was acceptance
to the possibility if the issues get worked out _first_."

I took the Fossil sources from whatever was the most readily available
distribution and after locating a single duplicated constant (56 * 1024 on
one hand and 64 * (2<<10) on the other, I hacked one away), Fossil compiled
on 9front without a hitch. Good enough for me to feel I can use it to
rescue my "precious" data. My fear was that I would not be able to afford
such a rescue if it got much more complex than that. So let's put to bed
any delusion that I want Fossil included in 9front, I was quite satisfied
with protestations that something no worse than the 9legacy version was in
fact available with minimal effort.

On the other hand, I am disappointed that the door unlocked by Venti and
barely held ajar by Fossil may slam shut to 9front users and to that end I
am going to make a new request. Now this is not an "or else" request, nor a
promise, merely a wish based on comments in this forum to the effect that
failures have been identified in Fossil (and Venti, too).

If such a list already exists, that would be extremely welcome (to me, at
least). If not, perhaps a summary of the type of triggers that cause
failures would be helpful, at least as much as knowing who are the most
knowledgeable developers in connection with this aspect. If all that's
available is some hazy description, well, that's perfectly OK, if
disappointing. Maybe for someone like me that will turn out sufficient to
continue Fossil/Venti development. It's tempting to point out that trying
to compete with 9front developers would be a mug's game, so not including a
version of Fossil/Venti that can be successfully compiled and deployed is
not going to handicap any 9legacy development.

Again, none of the above is intended to cast aspersions on anyone. I
reserve my opinions on the emotional undercurrents in the discussions that
are still taking place here, but the value of the emotional baggage
involved, in my opinion, is precisely zero, even though I have had quite a
few occasions for muttering and even cursing into my beard (or is it under
my breath?).

Lucio.

On Fri, May 17, 2024 at 6:53 PM Noam Preil <noam@pixelhero.dev> wrote:

> I have found multiple deadlocks over the last few years, and only
> bothered fixing one of them. That patch is in 9legacy, as well, now.
> 
> During my IWP9 talk in which, among other things, I explained why I
> intend to replace fossil despite curently using it, I demonstrated one
> of the problems with fossil by (attempting to) install Go, which crashes
> the file system _every single time_.
> 
> I personally fixed over a dozen issues in Venti, and continue to find
> more. To the best of my knowledge, those patches are currently _only_
> present in 9front. I was not aware 9legacy existed when I did that
> work.
> 
> I've lost some data to fossil crashes, since if it e.g. loses power
> during a sync, it will end up _erasing_ a file rather than preserving
> the old version, which has _broken boot_ if the system crashed while I
> was editing lib/profile.
> 
> I have a branch of 9front with fossil restored. I have discussed what
> would be needed to add fossil upstream again, and there was acceptance
> to the possibility if the issues get worked out _first_.
> 
> The hostility on this list is pervasive and comes from all sides. If
> your goal is positive engagement, this is not the place to do it.
> 


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

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

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

[-- Attachment #2: Type: text/html, Size: 5598 bytes --]

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

[Noam Preil]

I would _love_ a complete list of known issues.

What I'm aware of:

- IIRC ORCLOSE doesn't work properly (visible as acme leaving temporary
files around after exiting)
- At least one deadlock remaining
- Syncs are not atomic, so a crash can render the system unbootable if
e.g. termrc was being written to disk. I've seen this repeatedly.
        - It's not just non-atomic; the resulting state is usually an empty
file. Conjecture: blocks are being allocated, the file points at the new
blocks, the old data has not been copied yet.
- Multiple bugs in the file system checker. Nothing that messes with
data integrity, thankfully! I have needed multiple passes though, as a
single run does not fully clean up the file system. (Noticed this one
when cleaning up after the go failures :P)
        - Also seen a deadlock while running `check fix` in the console while
loading the file system, I think, but I don't remember for sure.

I've almost certainly run into more than this. I run into fossil bugs
probably once every two or three months and usually haven't bothered
noting them down because I don't lose data when they happen and they're
rare enough I haven't bothered investigating most of them yet.



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

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

This is extremely helpful; thank you, Noam.

I'm not in a position to make any promises, but I will add my efforts to
get issues such as these at least not forgotten.

Lucio.

On Fri, May 17, 2024 at 8:47 PM Noam Preil <noam@pixelhero.dev> wrote:

> I would _love_ a complete list of known issues.
> 
> What I'm aware of:
> 
> - IIRC ORCLOSE doesn't work properly (visible as acme leaving temporary
> files around after exiting)
> - At least one deadlock remaining
> - Syncs are not atomic, so a crash can render the system unbootable if
> e.g. termrc was being written to disk. I've seen this repeatedly.
>         - It's not just non-atomic; the resulting state is usually an empty
> file. Conjecture: blocks are being allocated, the file points at the new
> blocks, the old data has not been copied yet.
> - Multiple bugs in the file system checker. Nothing that messes with
> data integrity, thankfully! I have needed multiple passes though, as a
> single run does not fully clean up the file system. (Noticed this one
> when cleaning up after the go failures :P)
>         - Also seen a deadlock while running `check fix` in the console
> while
> loading the file system, I think, but I don't remember for sure.
> 
> I've almost certainly run into more than this. I run into fossil bugs
> probably once every two or three months and usually haven't bothered
> noting them down because I don't lose data when they happen and they're
> rare enough I haven't bothered investigating most of them yet.
> 


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

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

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

[-- Attachment #2: Type: text/html, Size: 3479 bytes --]

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

[Richard Miller]

Noam Preil:
> I demonstrated one
> of the problems with fossil by (attempting to) install Go, which crashes
> the file system _every single time_.

This is a useful bit of evidence that needs following up.  The go test
suite (which begins by installing and completely rebuilding go) is
running 24/7 on a cluster of Raspberry Pi machines in my front hall,
using fossil from 9legacy source.  If you look in the plan9 arm column
on https://build.golang.org you can click on any 'ok' entry (and
nearly any 'fail' entry) and you'll see a successful installation of
go on fossil ...  literally thousands of them if you follow the
sequence of 'older' pages.

If you get in touch with me off list, I'd really like to
work with you to find out what is different between my environment
and yours which leads to such different observations. My principal
reason for running the go tests has been to try to shake out more bugs
from Plan 9 and fossil. So any other replicatable data I can get is
most welcome.

> I have found multiple deadlocks over the last few years, and only
> bothered fixing one of them.

In a discussion on 9fans in April 2023, the fossil-deadlocks.diff
patch on 9legacy.org was mentioned. Have you witnessed any more
deadlocks since you applied that one?


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-Mfa75a342b512fd72b7c71720
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Noam Preil]

Responding off list shortly :)

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-M3fe517cc779e245e44a024b1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[David du Colombier]

> Responding off list shortly :)

I'd like to be included into the discussion as well.

Thanks.

-- 
David du Colombier

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-M789b993f6eb5e311f7e78821
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[wb.kloke]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

Just a simple note. When I compared the fossil version posted by Moody in the original discussion thread to the one I am using (and IIRC  it is the one in the 9legacy git repository), I found that they differed in 2 points. One was the increase of a msg buffer, which is probably no big issue, but the other one was the omission of one deadlock patchin 9leagcy git distro.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-Mb3c05a4482ba034b77b68284
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1099 bytes --]

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

Please include me as well. I have an unambitious plan I would like to
experiment with. And the most advanced version of Fossil would fit
nicely into that. Also, am I mistaken in believing that in all of 9legacy,
9front and p9p, Fossil and Venti need to be treated as a bundle, possibly
starting with Venti as one component, but with Fossil quite dependent on
Venti?

Lucio.

On Fri, May 17, 2024 at 9:16 PM David du Colombier <0intro@gmail.com> wrote:

> > Responding off list shortly :)
> 
> I'd like to be included into the discussion as well.
> 
> Thanks.
> 
> --
> David du Colombier


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

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

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-M54298a47e9abafc58833832c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2381 bytes --]

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

Fossil will run without venti, but the moment you connect it to a venti, it
cannot be standalone again, as it stands.

On Sat, 18 May 2024 at 14:50, Lucio De Re <lucio.dere@gmail.com> wrote:

> Please include me as well. I have an unambitious plan I would like to
> experiment with. And the most advanced version of Fossil would fit
> nicely into that. Also, am I mistaken in believing that in all of 9legacy,
> 9front and p9p, Fossil and Venti need to be treated as a bundle, possibly
> starting with Venti as one component, but with Fossil quite dependent on
> Venti?
>
> Lucio.
>
> On Fri, May 17, 2024 at 9:16 PM David du Colombier <0intro@gmail.com>
> wrote:
>
>> > Responding off list shortly :)
>> 
>> I'd like to be included into the discussion as well.
>> 
>> Thanks.
>> 
>> --
>> David du Colombier
>
>
> --
> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-M54298a47e9abafc58833832c>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-Meb7ca5e2f90ca82dcee4f634
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2871 bytes --]

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]

Indeed, the coupling is moderately loose (I found one constant shared in
the code I compiled for 9front -  Fossil from somewhere, probably p9p, but
maybe not - the 56000-byte Venti block size, I believe). But Fossil without
Venti is a much less valuable component, as I understand it. And Fossil
without improvements will eventually go extinct, possibly taking Venti to
its grave as well.

I don't think it's just sentimentalism on my part that keeps me interested,
it is the implicit, as yet unrealised promise. At least from my point of
view.

Lucio.

On Sat, May 18, 2024 at 4:07 PM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> Fossil will run without venti, but the moment you connect it to a venti,
> it cannot be standalone again, as it stands.
>
> On Sat, 18 May 2024 at 14:50, Lucio De Re <lucio.dere@gmail.com> wrote:
>
>> Please include me as well. I have an unambitious plan I would like to
>> experiment with. And the most advanced version of Fossil would fit
>> nicely into that. Also, am I mistaken in believing that in all of 9legacy,
>> 9front and p9p, Fossil and Venti need to be treated as a bundle, possibly
>> starting with Venti as one component, but with Fossil quite dependent on
>> Venti?
>>
>> Lucio.
>>
>> On Fri, May 17, 2024 at 9:16 PM David du Colombier <0intro@gmail.com>
>> wrote:
>>
>>> > Responding off list shortly :)
>>> 
>>> I'd like to be included into the discussion as well.
>>> 
>>> Thanks.
>>> 
>>> --
>>> David du Colombier
>>
>>
>> --
>> 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 <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-Meb7ca5e2f90ca82dcee4f634>
>


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

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

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-M9c87cb5f32a582b79300605b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4172 bytes --]

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

[Jacob Moody]

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

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

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


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

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

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 2686 bytes --]

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

On Wed, May 15, 2024 at 11:53 AM Jacob Moody <moody@posixcafe.org> wrote:

> On 5/15/24 10:20, Don Bailey wrote:
> > This is part of the issue I've had with 9front. If there are valid
> reasons for things to disappear or not be used, that's OK. But please
> document them and provide rationale/evidence for their removal. That way,
> even if another group chooses not to remove those items, they can learn
> from other teams' decision making. This is especially imperative for file
> system stability, for those that have not had trouble with Fossil, but need
> to understand that it is problematic enough to be pulled from
> > 9front. How was the lack-of-stability tested? To what degree was it
> tested? etc.
> 
> I think many of the reasons and rational has been explained in this list.
> Really we don't entirely rip out programs often.
> It's fairly rare. This change was made fairly early on in 9front's
> history, I think things would have gone over different
> these days. A technical write-up would be nice, sure I don't disagree but
> I think people just wanted to stop dealing with
> the crash reports and lost data and get back to spending time on code they
> enjoyed to work on.
> 
> For what it is worth I think our commit messages these days are quite
> descriptive of the problem being addressed, the details
> put in commonly directly include the crash repro or failure state or
> technical description as to why things were done.
> Also a huge portion of things are discussed on irc, nearly everything that
> gets put in to the system is discussed with
> at least 1 additional person and usually more depending on the weight of
> the patch. There is a lot of thought that
> goes in to what changes these days.
> 

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

[-- Attachment #2: Type: text/html, Size: 3964 bytes --]

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.

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

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

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.

D


On Wed, May 15, 2024 at 12:07 PM hiro <23hiro@gmail.com> wrote:

> > 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-M435b857d58b79d576dd5d2bb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2720 bytes --]

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.

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Back to square one, are we lol

On Wed, May 15, 2024 at 12:24 PM hiro <23hiro@gmail.com> wrote:

> > 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-Mc2a3faaa519542ff486e7e0b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1891 bytes --]

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

[Jacob Moody]

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

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

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

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


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

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

[Don Bailey]

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

Sounds good.

D


On Wed, May 15, 2024 at 12:19 PM Jacob Moody <moody@posixcafe.org> wrote:

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

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

[-- Attachment #2: Type: text/html, Size: 3720 bytes --]

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

[Jacob Moody]

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

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

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

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

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

[Jacob Moody]

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

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


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

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

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

What is missing from my description?

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

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




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

Re: [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.

[Jacob Moody]

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

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



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

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

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

[vic.thacker]

On Wed, May 15, 2024, at 01:30, B. Atticus Grobe wrote:
> Oh, I think it's great that people are using it. I simply find the
> obfuscatory nature of your presentation to be suspicious. It is generally
> considered to be good etiquette to disclose affiliations to a company
> during discussions. Failure to do so is not necessarily damning, but is
> certainly a 'red flag', at least for me.

Sure, I see your point. It's similar to when people post without using 
their real names. While it's not necessarily incriminating, it does raise 
a 'red flag' and can be a cause for suspicion.

Vic

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

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

[John the Scott]

finding nothing on google for Nantahala.  any links?

-john

On Mon, May 13, 2024 at 3:42 AM <vic.thacker@fastmail.fm> 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



-- 
Fast is fine, But accuracy is final.
You must learn to be slow in a hurry.
        - Wyatt Earp

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

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

[vic.thacker]

On Wed, May 15, 2024, at 14:48, John the Scott wrote:
> finding nothing on google for Nantahala.  any links?
>
> -john

Yes, that is by design.  Working with a small number of clients is preferred.   

https://nantahala.systems is the site that mentions Plan 9.  It deals with the hardware and software aspect.  

https://nantahalaoperations.com is a courtesy site for clients.  Being a very small company, face to face pre-sale interactions are preferred for type of clients I deal with.   

Nantahala Holdings LLC does not have a website as it is not required. Since taking it down, there has been a reduction in the amount of bothersome solicitations by Citi and others. 
  
Vic

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

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

[Wes Kussmaul]

Fromm Crunchbase:

Nantahala Outdoor Center — Nantahala Outdoor Center is a sports company 
offering whitewater rafting, mountain biking, and flatwater paddling.

Nantahala Bank & Trust Company — Nantahala Bank & Trust Company is a 
financial service company offering & lending mortgages and loans and 
other financial services.

Nantahala Capital Management — Nantahala Capital Management is a hedge fund.

Nantahala Real Estate Company — Nantahala Real Estate Company provides 
property management, consulting, home selling, and buying services.

GHSS Manathala — GHSS Manathala is a secondary education school.



On 5/15/24 01:48, John the Scott wrote:
> finding nothing on google for Nantahala.  any links?
> 
> -john
> 
> On Mon, May 13, 2024 at 3:42 AM <vic.thacker@fastmail.fm> 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
> 
> 
> 

-- 

*Wes Kussmaul*

*Reliable Identities, Inc.*
an Authenticity Enterprise
738 Main Street
Waltham, MA 02451 USA
t: +1 781 790 1674
m: +1 781 330 1881
e: wes@ReliableID.com <mailto:wes@ReliableID.com>

Ranked *#12*in the *Thinkers 360*list of

*Top 50 Global Top Thought Leaders *

*and Influencers on Security 2023*

Learn About Authenticity <http://authenticityworks.video/>

This message is confidential. It may also be privileged or otherwise
protected by work product immunity or other legal rules. If you have
received it by mistake, please let us know by e-mail reply and delete it
from your system; you may not copy this message or disclose its contents
to anyone. The integrity and security of this message cannot be assured
unless it is digitally signed by the PEN of an identity certificate with
an IDQA score that is sufficient for your purposes.




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

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

[vester.thacker]

On Wed, May 15, 2024, at 22:18, Wes Kussmaul wrote:
> Fromm Crunchbase:
>
> Nantahala Outdoor Center — Nantahala Outdoor Center is a sports company 
> offering whitewater rafting, mountain biking, and flatwater paddling.
>
> Nantahala Bank & Trust Company — Nantahala Bank & Trust Company is a 
> financial service company offering & lending mortgages and loans and 
> other financial services.
>
> Nantahala Capital Management — Nantahala Capital Management is a hedge fund.
>
> Nantahala Real Estate Company — Nantahala Real Estate Company provides 
> property management, consulting, home selling, and buying services.
>
> GHSS Manathala — GHSS Manathala is a secondary education school.
>
>
>
> On 5/15/24 01:48, John the Scott wrote:
>> finding nothing on google for Nantahala.  any links?
>> 
>> -john
>> 
>> On Mon, May 13, 2024 at 3:42 AM <vic.thacker@fastmail.fm> 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
>> 
>> 
>> 
>
> -- 
>
> *Wes Kussmaul*
>
> *Reliable Identities, Inc.*
> an Authenticity Enterprise
> 738 Main Street
> Waltham, MA 02451 USA
> t: +1 781 790 1674
> m: +1 781 330 1881
> e: wes@ReliableID.com <mailto:wes@ReliableID.com>


Great, just pile on the hazing guys. You know how to make someone feel unwelcomed.

Vic

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

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

[Noam Preil]

The only company listed there is yours, no?

That's not a good look.



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

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

[vester.thacker]

On Sat, May 18, 2024, at 01:26, Noam Preil wrote:
> The only company listed there is yours, no?
>
> That's not a good look.

On a long enough timeline, it will not matter.  

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 5101 bytes --]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

[-- Attachment #2: Type: text/html, Size: 6394 bytes --]

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

[vic.thacker]

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

I think that is a constructive way to view it. 

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

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

Vic

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

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

[sirjofri]

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

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

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

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

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

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

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

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

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

>> I would make a big difference between what plan 9 is and what the licenses are. Software doesn't care about licenses. People do (and they should!).
>> 
>> So what is plan 9 even? Can we compare it to UNIX™ or unix or posix? Who knows...
>> 
>> I guess I could say a lot more about that topic, but I guess that's enough and you can puzzle everything else yourself.
> 
> plan9 is simply the final release made by bell labs and now owned by p9f. Thats not my interpretation this is a fact. Everything beyond that point is a fork based on plan9. 
> 
> Everyone is allowed to derive his/her work from this provided version of plan9.
> 
> 9front is a fork, 9legacy is a fork and there were other forks. I have my own fork. If tomorrow another one decides to fork plan9 than thats okay.
> 
> 9front isn't plan9. 9front is a fork based on plan9. Why is it that you can't accept this fact. You aren't the owners of plan9 and you don't  even own the trademark plan9.
> 
> Your fork is called 9front and its absolutely okay to fork from code with a license that allows this.
> 
> Your fork based on plan9 is extremely close to the original. But that doesn't mean you are the continuation of plan9.
> 
> The only thing we can agree on as fork developers is what is officially called plan9 as a basement for exchange of code ideas aso. Code that can be compiled and executed on the official release is one that can be exchanged.
> 
> There is only one group on this messaging board which has a problem with this definition of plan9 thats 9front. You insist on being seen as the continuation of plan9 but you aren't. You could have become this by buying plan9 from nokia and the trademark or nokia could have chosen you to hand it over to you but they didn't. p9f owns plan9 and if they ever decide to hand it over to you than you become officially the owner and continuation of plan9 but this won't change the fact that meanwhile others have forked from plan9 and call themselves fork xyz based on plan9 and you to respect this.
> 
> Why is it so difficult for folks of 9front to accept that they are providing a fork based on plan9.
> 
>> [1] (I would be very careful with such bold words. I feel like 9front people have heard this phrase a lot and it's probably very thin ice for a few people.)
>> 
> 
> And so what ? Compared to the replies of some folks from 9front regarding simple questions there is nothing bold about my statements. This is 9fans and if you start the same discussions over and over again than you have to live with answers like mine. Neither you nor I own plan9 while people outside 9front have no problem with facts you have this problem. You can't just accept the fact that 9front is a fork like many others. You may do a good job for your users and many enjoy using 9front as stated many times here on this board but but you do your job others do their job and you are in no position to give directions to others. I respect your work continue with it but don't act as if you are the ones who are in possession of plan9 or can dictate directions you can't and I also can't. I'm fed up with the regularly disputes you search with people who don't want to use your fork. I'm not using it and nothing will change my mind.
> 
>> About another topic: you mentioned that plan 9 is in use for commercial products, and you explicitly mention german medical sensors. I've never heard about that and I'd like to learn more, as well as about other companies who actually use plan 9.
>> 
>> Everything I always hear in the industry is that plan 9 is outdated and nobody uses it and nobody wants to hear about it. I only know of a single company that uses it (coraid), plus a few little projects by taw that could evolve into commercial products.
> 
> I am and have acted as an advisor for many of these projects. The license change made it attractive for such projects cause you can keep your code closed source. The only duty to fulfill is providing the terms of the MIT license. You don't have to make your technology open source like you would have to if you used Linux.
> 
> Don't underestimate the potential. Another example for a tiny os which is wide spread is Xinu which no one would expect. Plan9 has advantages over other systems that makes it attractive. I can only talk about those projects I know but be assured there are millions of devices around which run plan9 without anyone noticing.
> 
> 
> Again for the x-th time : I don't have a problem with 9front. I don't use it but I respect your work. The only think I dislike is the never ending discussions about plan9 being dead and 9front being the only choice and the attitude in some replies to questions of people on this board in an harsh and aggressive way. The moment one asks about 9legacy or plan9 and one from 9front advices to use 9front without success many of 9front getting aggressive and thats not right.
> 
> 
> 
> *9fans[https://9fans.topicbox.com/latest]* / 9fans / see discussions[https://9fans.topicbox.com/groups/9fans] + participants[https://9fans.topicbox.com/groups/9fans/members] + delivery options[https://9fans.topicbox.com/groups/9fans/subscription] Permalink[https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M7e742d8d84209fb41f920f30]

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

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

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

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

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

[-- Attachment #2: Type: text/html, Size: 1745 bytes --]

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

[sirjofri]

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

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

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

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

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

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

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

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

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

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

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

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

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

[-- Attachment #2: Type: text/html, Size: 1753 bytes --]

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)

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

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

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

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


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

[-- Attachment #2: Type: text/html, Size: 1362 bytes --]

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

[G B via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

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


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

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


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

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


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

[-- Attachment #2: Type: text/html, Size: 3177 bytes --]

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

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

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

[-- Attachment #2: Type: text/html, Size: 1701 bytes --]

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

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

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



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

[-- Attachment #2: Type: text/html, Size: 1229 bytes --]

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

[ori]

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

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

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

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

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

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

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

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)

[Jacob Moody]

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

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

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


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

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

[hiro]

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

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

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

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

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

[Kurt H Maier via 9fans]

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

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

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

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

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

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

khm

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

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

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

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

[-- Attachment #2: Type: text/html, Size: 3729 bytes --]

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

[Kurt H Maier via 9fans]

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

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

khm

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

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

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

[tlaronde]

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

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

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

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

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

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

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

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

What has still to be done:

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

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

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

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

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

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

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

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

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

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

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


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

[-- Attachment #2: Type: text/html, Size: 2072 bytes --]

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

[tlaronde]

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

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

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

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

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

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

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

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

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

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

[-- Attachment #2: Type: text/html, Size: 1703 bytes --]

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 9front is a fork but p9f's provided final release is the real thing with a clear ownership and license. 9legacy would be the right choice as the current plan9 but it contains code from sources which bare the risk of infecting a MIT licensed plan9 if no measures are taken regarding these problems.

I don't think p9f has ever provided anything apart from that
misleading website and some kind of money transfers to people that i
don't know.
9legacy has both 9front and 4th edition code, as you already said. and
many other people contributed stuff to both 9legacy and 9front, and
other forks.

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 4150 bytes --]

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

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

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

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

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

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

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

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

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

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

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

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

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

[-- Attachment #2: Type: text/html, Size: 5514 bytes --]

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

[Ori Bernstein]

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

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

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


-- 
    Ori Bernstein

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

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

[clinton]

[-- Attachment #1: Type: text/plain, Size: 4717 bytes --]

As a very long time lurker to the plan9 mailing list, something
occasionally catches my eye strewn amongst the arcana. The very first
computer I ever actually touched was in 1979, it had these state of the ark
mag stripe cardboard cards which held the enormous amount of 2kb. It wasn't
mine, my engineer father brought it home from work and it took up a large
proportion of the dining room table. I was very strictly punished for
laying a finger on the thing, as it was astronomically expensive and my
father was responsible for it. This was just the start of my masochistic
relationship with these fiddly cantankerous things you see.
Over the years I have seen a $5,500 486dx 2 66mHz be reduced to a $25 pile
of junk less than a decade later, a $200 60gb hard drive forlornly sitting
by the side of the road in hard rubbish a decade later, and many other
similar saddening examples.
There of course is a need for using old hardware these days as it seems so
wasteful to just junk something with a 1gHz CPU in it when you fondly
remember your days with a MOS 6510!
If I were completely naive to actually  running plan9 but with many clues
about other operating systems and hardware, would it be better for me to
install 9legacy on some mildly obsolescent but still quite serviceable and
reliable hardware, or start with 9front on something more modern? Is the
learning curve the same for both varieties? Would it help getting to know
9front if I spent a bit of time with her older sister 9legacy? Can 9legacy
be considered the gateway drug to 9front?
I await the scorching flames for my great impudence of interjecting into a
vociferous discussion with such a pragmatic tangent!

On Monday, May 13, 2024, <ori@eigenstate.org> wrote:

> I don't think this approach has ever worked in
> the open source world -- it always starts with
> someone building something useful. The vision
> and goal is defined by the work being done.
>
> After something useful is built, people start
> to join in and contribute.
>
> After enough people join in, it makes sense to
> have more organization.
>
> Quoth vester.thacker@fastmail.fm:
> > The complexity of communication in this medium often necessitates
> detailed discussions.  You highlighted the need for additional personnel to
> manage the workload (e.g. do the work).  From my perspective, this requires
> a well-defined vision, clear objectives, and a prioritized list of
> deliverables to align efforts effectively.  Currently, it seems the role of
> product managers is collectively held, though it's unclear who exactly is
> responsible.  Typically, a team of two or more individuals would focus on
> these deliverables.  In past projects, I've seen the use of a project board
> to keep everyone updated on tasks—an approach known as "information
> radiator" in project management.  I'm open to other methods if you had
> something different in mind that I may have overlooked.  If you are
> considering a meritocracy, I would recommend caution.  Experience has shown
> that what we truly need is increased collaboration and unity, rather than a
> system that could potentially encourage competition and division.  I
> apologize if my message is obtuse, I am trying to keep this message
> concise, I can expound more for clarity.  I hope my explanation helps.
> >
> > Vic
> >
> >
> > On Mon, May 13, 2024, at 03:36, ori@eigenstate.org wrote:
> > > that's not what I said.
> > >
> > > Quoth vic.thacker@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, plan6@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-Me459c34f6ecb73275ab783df
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 6379 bytes --]

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

[ori]

9front and 9legacy look very similar to the untrained eye.
The way you use them is nearly identical, but there are a
lot of small bits of polish added to 9front, as well as
a number of larger tools and utilities.

Even 9legacy binaries run on 9front. (And vice versa, as
long as the binaries don't depend on new services like
mixfs [the audio mixer], or new capabilities in existing
services, such as custom response headers in webfs)

There's a few things 9legacy has that 9front doesn't. These
are mostly kernels for some of the older virtex FPGAs, the
removal of some obsolete architectures like sparc, and a few
utilities like jtagfs. But as far as I'm aware, most of the
desirable changes made in 9legacy and p9p have already been
imported into 9front. If I've missed some, let me know, and
they may just show up.

Quoth clinton <clintonclinton@gmail.com>:
> As a very long time lurker to the plan9 mailing list, something
> occasionally catches my eye strewn amongst the arcana. The very first
> computer I ever actually touched was in 1979, it had these state of the ark
> mag stripe cardboard cards which held the enormous amount of 2kb. It wasn't
> mine, my engineer father brought it home from work and it took up a large
> proportion of the dining room table. I was very strictly punished for
> laying a finger on the thing, as it was astronomically expensive and my
> father was responsible for it. This was just the start of my masochistic
> relationship with these fiddly cantankerous things you see.
> Over the years I have seen a $5,500 486dx 2 66mHz be reduced to a $25 pile
> of junk less than a decade later, a $200 60gb hard drive forlornly sitting
> by the side of the road in hard rubbish a decade later, and many other
> similar saddening examples.
> There of course is a need for using old hardware these days as it seems so
> wasteful to just junk something with a 1gHz CPU in it when you fondly
> remember your days with a MOS 6510!
> If I were completely naive to actually  running plan9 but with many clues
> about other operating systems and hardware, would it be better for me to
> install 9legacy on some mildly obsolescent but still quite serviceable and
> reliable hardware, or start with 9front on something more modern? Is the
> learning curve the same for both varieties? Would it help getting to know
> 9front if I spent a bit of time with her older sister 9legacy? Can 9legacy
> be considered the gateway drug to 9front?
> I await the scorching flames for my great impudence of interjecting into a
> vociferous discussion with such a pragmatic tangent!
> 
> On Monday, May 13, 2024, <ori@eigenstate.org> wrote:
> 
> > I don't think this approach has ever worked in
> > the open source world -- it always starts with
> > someone building something useful. The vision
> > and goal is defined by the work being done.
> >
> > After something useful is built, people start
> > to join in and contribute.
> >
> > After enough people join in, it makes sense to
> > have more organization.
> >
> > Quoth vester.thacker@fastmail.fm:
> > > The complexity of communication in this medium often necessitates
> > detailed discussions.  You highlighted the need for additional personnel to
> > manage the workload (e.g. do the work).  From my perspective, this requires
> > a well-defined vision, clear objectives, and a prioritized list of
> > deliverables to align efforts effectively.  Currently, it seems the role of
> > product managers is collectively held, though it's unclear who exactly is
> > responsible.  Typically, a team of two or more individuals would focus on
> > these deliverables.  In past projects, I've seen the use of a project board
> > to keep everyone updated on tasks—an approach known as "information
> > radiator" in project management.  I'm open to other methods if you had
> > something different in mind that I may have overlooked.  If you are
> > considering a meritocracy, I would recommend caution.  Experience has shown
> > that what we truly need is increased collaboration and unity, rather than a
> > system that could potentially encourage competition and division.  I
> > apologize if my message is obtuse, I am trying to keep this message
> > concise, I can expound more for clarity.  I hope my explanation helps.
> > >
> > > Vic
> > >
> > >
> > > On Mon, May 13, 2024, at 03:36, ori@eigenstate.org wrote:
> > > > that's not what I said.
> > > >
> > > > Quoth vic.thacker@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, plan6@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-M81117d268b8f840b41281f04
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Kurt H Maier via 9fans]

On Mon, May 13, 2024 at 11:46:59AM +0930, clinton wrote:
> I await the scorching flames for my great impudence of interjecting into a
> vociferous discussion with such a pragmatic tangent!

If you don't intend to have anything hanging out with a direct internet
connection, just use whatever looks cool and is supported by the
hardware you have at hand.  

If your installation is going to be subject to transmitting packets
across the internet, 9front has better crypto.  As has been mentioned
recently in this list, porting that crypto back to 9legacy may be a fun
way to get your hands dirty, if you're into that sort of thing.

Either way you're not really missing anything by picking one to play
with, and if you feel like you are, it will still be there when you feel
like trying the other one out.

Reading all the stuff in /sys/doc is a great way to start learning on
either distribution.

khm

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 905 bytes --]

Sorry for the double post ...

try to use an older version of 9legacy cause after the integration of 9git in the latest CD a full system compile will stop. I don't know why such software which can't be considered a patch to the 4th edition became part of the src tree instead of putting it in a contrib folder. I personally would expect from 9legacy being 4th edition with only patches for files which were part of the official release and contributions made by original developers from bell (like compilers from personal archives aso). The first thing I do when testing a new release of 9legacy is to clean up the system from such enhancements. But thats another topic ...

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

[-- Attachment #2: Type: text/html, Size: 1452 bytes --]

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

[adventures in9]

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

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

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

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

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

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

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


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

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

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

[vic.thacker]

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

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

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

Vic


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

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

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

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

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

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

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

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

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

Those are the rules.

> And Java runs on a billion devices.

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

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

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

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

[-- Attachment #2: Type: text/html, Size: 4221 bytes --]

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

The last post had some paste copy issues :

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

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


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

[-- Attachment #2: Type: text/html, Size: 1379 bytes --]

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

[Kurt H Maier via 9fans]

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

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

Hope this helps,
khm

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

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

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

[Jacob Moody]

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

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

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

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

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

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

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

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

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

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

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

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

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

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


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

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

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

[-- Attachment #2: Type: text/html, Size: 3308 bytes --]

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)

[Kurt H Maier via 9fans]

On Mon, May 13, 2024 at 09:21:20AM +0900, vester.thacker@fastmail.fm wrote:
> unclear who exactly is responsible.  Typically, a team of two or more 
> individuals would focus on these deliverables.   

nobody is "responsible" and there are no "deliverables"

the people who covet bureaucracy have one to play with.  if you are one
of them, I suggest you visit plan9foundation.org and get involved with
it.

otherwise, there are no problems here to fix, all this shit you're
talking about is in your head and has nothing to do with us.

please don't respond to this message.

khm

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

On Monday, 13 May 2024, at 4:17 AM, clinton wrote:
> If I were completely naive to actually  running plan9 but with many clues about other operating systems and hardware, would it be better for me to install 9legacy on some mildly obsolescent but still quite serviceable and reliable hardware, or start with 9front on something more modern?

If you are familar with linux and have a veteran computer with 8 GB I would start with 9vx and a 9legacy iso. This will simplify your first steps. Otherwise you will have to get used to so many different things at once that you will perhaps loose your confidence. 

The advantages taking this root are :

i) No filesystem problems
ii) No hardware problems
iii) The ability to edit files in an editor of your choice
iv) The ability to start all kinds of services from terminal, cpu server, file server aso on a single computer to try all those things out compile kernels write scripts try them out.
...

After you get used to rio, acme, acid rc the next step I would suggest is build a network out of virtual machines with the filesystem of your choice. And even while doing so using one 9vx emulation will help you establish connections to all those virtual machines and allow you to make adjustments.

After you have collected enough experience I would stay with 9legacy and ignore 9front. 9vx allows you to create boot media for old as well as new computers. You find everything necessary on the 9legacy CD (but also things which shouldn't have been back ported to 9legacy).

If you need help walking this road don't hesitate to ask. I think a cold start with plan9 9legacy or 9front with so many different things will just take the fun away but using 9vx you will keep the fun and can immediatly start using plan 9 and 9vx is extremly fast. 9vx has some shortcomings like missing support for some devices but don't mind them cause you will end up installing plan9 on bare metal after you get used to it anyway.

To sum up :

1. Step : Linux + 9vx + 9legacy (started for times)
2. Step : qemu + 9legacy (cpu, fileserver, terminal) + 9vx (for adjustments and as a rescue terminal)
3. Step : qemu + 9legacy (cpu, fileserver, terminal) + drawterm
4. Step : Bare metal as you like


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

[-- Attachment #2: Type: text/html, Size: 3412 bytes --]

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 <vester.thacker@fastmail.fm> 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, ori@eigenstate.org wrote:
> > that's not what I said.
> >
> > Quoth vic.thacker@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, plan6@room3420.net wrote:
> >> > "tl;dr: you need people doing the work before you can try
> >> > to organize them; the way to get people doing the work is
> >> >  to bootstrap it by doing work and showing value." [from Ori].
> >> >  or
> >> >  "Don't be the kid who can't play [whatever]ball but wants to teach
> >> > everybody and be the team coach, just because he read a book."

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

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

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

[-- Attachment #2: Type: text/html, Size: 1017 bytes --]

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

[hiro]

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

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

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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

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

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

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

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

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

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

[-- Attachment #2: Type: text/html, Size: 3270 bytes --]

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

[hiro]

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

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

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

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

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

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

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

[Jacob Moody]

On 5/13/24 06:56, ibrahim via 9fans wrote:
> On Monday, 13 May 2024, at 1:11 PM, hiro wrote:
>> i mean contributing to the plan9 team. i don't share in your discrimination of 9front vs. non9front code. i bet if all of us can be gainfully employed to work on "real plan9" we can all stop contributing to 9front. please enlighten me who my future coworkers might be. who else is going to join the team?
> 
> I don't discriminate 9front at all. What I'm trying to say is if we want contribute to each other we need a compatibility layer and the simplest choice is the final edition of plan9. Its well defined and well documented.

Are you interested in sharing code between your fork and us? If you have no intention of making your fork freely available then I don't think
there is really much of a point in having some sort of compatibility layer.

If there were a couple of open source Plan 9 forks that each saw active development and we were having issues with keeping the source code
ported between them sure I could see this as a reason to do that. We have however never found that the source code proved much of a challenge
for porting things from 9legacy et all.

> 
> There won't ever be a real plan9 interpretations satisfying all who are interested in plan9. My fork makes use of segments dynld I use a binary interface instead of 9p to achive higher performance regarding data transfer between processes and especially the framebuffer. I have a gui which is portable to linux, windows aso. I can compile my software for plan9 linux and windows without a single change of lines. I use wrapper interfaces to achive this and a preprocessor which produces C code for
> the compiler on the destination system. My users need shortcut keys so I have a further device which reflects keystates parallel to the operation of keyboard. All those changes differ from the concepts of plan9.  My fork is making use of concept possible with plan9 but not really the plan9 way of doing things. I don't use fossil and others as my filesystem and I don't have a 9fat partition anymore. So how could we possibly agree on a real plan9 we can't. Each fork has its own use case and there
> is nothing wrong about this.
> 
> I never asked you to stop 9front in favour of a real plan9 no one has the right to make such a demand any more. You have your user community and are doing a great job.
> 
> If we want to share contributions between forks we need a compatibility layer if we don't want to we don't have to.
> 
> I don't have a problem respecting any fork of plan9. I will give back to other forks as much as I take from them. And if I contribute code to plan9 than I will make sure that it doesn't make use of enhancements I am using within my fork respect the coding styles of such a compatibility layer if one is ever defined. The whole discussion is about interoperability between forks.

Well that is the topic of discussion now, after you got bored of making incorrect claims about our license, and after we got here from some new user asking about whether
or not they should use 9legacy or 9front. Your initial objection to 9front being recommended was licensing issues, that was proven false, so now the goal posts have
moved to "well you're not REAL plan 9" as if that has any sort of impact to any user asking for which code to use to learn the system. Seems like not wanting to call
OpenBSD a "UNIX" because it's not technically a direct release from AT&T/Nokia/whoever. While technically true, you'd get a pretty similar response if you went around
telling people to use research UNIX over OpenBSD.

Fine my dude, you don't have to call us Plan 9, you don't have to want to use our code. However I ask that you be mindful in how you talk to new users and don't assume that they
have this same level of care for authenticity and "pure" code origins as you. If these things are a showstopper for people they are usually explicitly stated.

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

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

[ori]

Quoth Jacob Moody <moody@posixcafe.org>:
> If there were a couple of open source Plan 9 forks that each saw
> active development and we were having issues with keeping the source
> code  ported between them sure I could see this as a reason to do
> that.  We have however never found that the source code proved much of
> a challenge

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

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

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

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


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

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote:
> Are you interested in sharing code between your fork and us? If you have no intention of making your fork freely available then I don't think
there is really much of a point in having some sort of compatibility layer.

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


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

[-- Attachment #2: Type: text/html, Size: 1831 bytes --]

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

[ibrahim via 9fans]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]


On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote:
> Fine my dude, you don't have to call us Plan 9, you don't have to want to use our code. However I ask that you be mindful in how you talk to new users and don't assume that they
have this same level of care for authenticity and "pure" code origins as you.

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

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

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

[-- Attachment #2: Type: text/html, Size: 2471 bytes --]

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

[Jacob Moody]

On 5/13/24 10:56, ibrahim via 9fans wrote:
> 
> On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote:
>> Fine my dude, you don't have to call us Plan 9, you don't have to want to use our code. However I ask that you be mindful in how you talk to new users and don't assume that they have this same level of care for authenticity and "pure" code origins as you.
> 
> You should read more carefully what I replied to the new user. It had nothing to do with licenses at all.

In your original email, you only mention:

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

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


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

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

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

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



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

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

[Ori Bernstein]

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

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

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

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

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

I have no idea what windows is up to.

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

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

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

[adventures in9]

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

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

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

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

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

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

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

[Matt Wilbur]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

On Mon, May 13, 2024 at 3:20 PM adventures in9 <adventuresin9@gmail.com>
wrote:

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


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

Matt





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

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

[-- Attachment #2: Type: text/html, Size: 4153 bytes --]

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)

[samuel.reader via 9fans]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1061 bytes --]

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

[ori]

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

Unfortunately, it doesn't provide a correct overview.

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

The rest of this seems similarly accurate.


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

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

[hiro]

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

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

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

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

[plan6]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1106 bytes --]

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)

[Clout Tolstoy]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

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 <23hiro@gmail.com> wrote:

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

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

[-- Attachment #2: Type: text/html, Size: 2824 bytes --]

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

[Samuel Reader via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

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.reader@proton.me.

Thank you.

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

On Friday, May 17th, 2024 at 10:50 PM, Clout Tolstoy <tolstoyclout@gmail.com> 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 <23hiro@gmail.com> wrote:
>
>> Great that you're building AI prompts instead of operating systems.
>> More trollfactories for "cyber" "warfare" will mean that all our
>> trolls will be out of a job soon. Vic, what you post on linkedin
>> sounds mainly like a big "fuck you" towards 9front, not a fair answer
>> given the technical contributions brought here by others.
>> 
>> Again, please send patches, not propaganda.
>
> [9fans](https://9fans.topicbox.com/latest) / 9fans / see [discussions](https://9fans.topicbox.com/groups/9fans) + [participants](https://9fans.topicbox.com/groups/9fans/members) + [delivery options](https://9fans.topicbox.com/groups/9fans/subscription) [Permalink](https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me91e0ebfcfac416764fad981)
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M6fc7012e78a90b1230049d6a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4549 bytes --]

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.reader@proton.me.
>
> Thank you.
>
> Sent with Proton Mail secure email.
>
> On Friday, May 17th, 2024 at 10:50 PM, Clout Tolstoy <tolstoyclout@gmail.com> 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 <23hiro@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)

[Dave Eckhardt]

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

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

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

Dave Eckhardt

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

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

[Kurt H Maier via 9fans]

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

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

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

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

khm

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

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

[qwx via 9fans]

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

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

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

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

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

Thanks,
qwx

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

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

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

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

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

Chapter 2: Networking
[...]

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

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

[Samuel Reader via 9fans]

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

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

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

[Jacob Moody]

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

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


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

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

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

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

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

[Michael Kerpan]

[-- Attachment #1: Type: text/plain, Size: 5614 bytes --]

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

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

[-- Attachment #2: Type: text/html, Size: 8585 bytes --]

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

[Jacob Moody]

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

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

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

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M5eaae46171320263f784eeb1
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 <mjkerpan@kerpan.com> 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 <23hiro@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 <moody@posixcafe.org> 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, plan6@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 / see discussions + participants + delivery options Permalink

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

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

[Noam Preil]

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

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

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

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

- Noam Preil


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

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

[hiro]

he already admitted he's using grammarly.

On Fri, May 17, 2024 at 7:00 PM Noam Preil <noam@pixelhero.dev> 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)

[fig]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

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

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

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

[-- Attachment #2: Type: text/html, Size: 2149 bytes --]

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

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

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

Lucio.

On Fri, May 17, 2024 at 7:51 PM fig <type9freak@gmail.com> wrote:

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


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

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

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

[-- Attachment #2: Type: text/html, Size: 3170 bytes --]

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)

[fig]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

> i would not call people "losers"

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

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

[-- Attachment #2: Type: text/html, Size: 1861 bytes --]

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)

[Jacob Moody]

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

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

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

- Moody

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

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

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

[vester.thacker]

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

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

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

Sincerely,
Vic    


On Fri, May 17, 2024, at 23:49, Jacob Moody wrote:
> Hit the enter key a bit early...
> This is directed at Vic, if that is not clear already.
> To everyone else who called me out for assuming malice on victor's part 
> because he was "just trying to help", does this not
> make my claim more obvious now? This likewise is including AI bullshit, 
> and I suspect my claims about his other mails
> being LLM trash are also correct too. There was no apology owed and 
> none should have been given. This is about the
> furthest thing from "helping" that there is.
>
> To be direct, I have found the misinformation about 9front on this list 
> to be at best highly incompetent and at
> worst actively malicious to spread misinformation. Is this really what 
> our resident "9front-haters" are going to rally behind?
> Like I respect that some people don't like us, that's fine. I get that 
> some people have some differences but AI generated misinformation
> is downright insulting. The demands that 9front do something or change 
> their behavior to match some noncontributor's opinion here is
> frankly also insulting our time. I've generally held respect for the 
> people here who have been around a lot longer, while I may disagree
> I will read and think about what is said here. However is this is the 
> type of behavior that is defended (and therefore encouraged) I am
> not interested at all.
>
> I'll be around on this list to argue against the misinformation 
> campaigns, it is clear that if we were to go away this type of 
> misinformation
> would run rampant. I really expected better.
>
> - Moody
>
> On 5/17/24 09:14, Jacob Moody wrote:
>> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f/
>> 
>> This linked-in article is frankly disgusting, I suggest you take this incorrect garbage down.
>> 
>> 
>> On 5/17/24 07:43, Samuel Reader via 9fans wrote:
>>> It is only a first draft, and it is not a finished product. I'll correct the mistakes found. 
>>>
>>> Thank you for the kind feedback.
>>>
>>>
>>>
>>>
>>> Sent with Proton Mail secure email.
>>>
>>> On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> wrote:
>>>
>>>> On Fri May 17 13:33:21 +0200 2024, plan6@room3420.net wrote:
>>>>
>>>>> an other interesting reading :
>>>>> https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card
>>>>
>>>>
>>>> I'm appalled and frankly furious about this article. It's blatant
>>>> slander which can affect me in my professional career. I'm a phD
>>>> candidate and my work is based on Plan 9 and developed on 9front; I
>>>> was going to present it at iwp9 but could not once the venue was
>>>> changed as it rendered it incompatible with my time table.
>>>>
>>>> The article lacks references to many of its claims, and the remaining
>>>> ones directly contradict its points. The Register article is even
>>>> linked incorrectly. A superficial reader would not bother to try to
>>>> follow the links or find the article. For me this is clearly
>>>> malicious attention-seeking.
>>>>
>>>> Regarding the pdf posted earlier[1], almost all of it is factually
>>>> incorrect. As an example, there are no drivers for modern nvidia or
>>>> amd chips or bluetooth. Many of the "system calls" listed in the pdf
>>>> are not system calls (proccreate) or simply don't exit (vlongtime),
>>>> and so on. In addition, it is trivial to recreate the same content
>>>> with a query like the following: `Generate a detailed book-style
>>>> document called "Revitalizing Plan 9: integrating modern enhacements
>>>> into 9legacy" detailing all improvements introduced in 9front compared
>>>> to 9legacy'. See for yourself in an excerpt below my email.
>>>>
>>>> I don't understand what the goal here is. All this post and pdf
>>>> accomplish is spreading misinformation, promoting cancel culture,
>>>> fostering community division and discouraging collaboration with
>>>> 9front and even 9legacy, directly contradicting both Vic's claims and
>>>> that of those who have sided with him in the thread. At this point,
>>>> use of chatgpt in this thread is blatant and harmful. Please stop.
>>>>
>>>> Thanks,
>>>> qwx
>>>>
>>>> [1] https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf
>>>> ---
>>>>
>>>> Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy
>>>> Introduction
>>>> Plan 9 from Bell Labs has long been recognized for its innovative approach to distributed computing. However, as hardware and software technologies advanced, the need for a more modernized version of Plan 9 became apparent. This need led to the development of 9front, a fork of Plan 9 that incorporates numerous enhancements and updates, surpassing 9legacy in several key areas. This document details these improvements, offering a comprehensive comparison of the advancements introduced in 9front over 9legacy.
>>>>
>>>> Chapter 1: Graphics and Video Drivers
>>>> Improved Graphics Hardware Support
>>>> One of the most significant areas of enhancement in 9front is its support for modern graphics hardware. This includes:
>>>>
>>>> Support for Newer GPUs: 9front integrates drivers for the latest GPU models, ensuring compatibility with modern graphics cards from manufacturers like NVIDIA and AMD.
>>>> Enhanced Frame Buffer Device: The frame buffer device driver has been optimized for better performance, providing smoother graphics rendering and faster display updates.
>>>> Broad Chipset Compatibility: 9front supports a wider range of graphics chipsets, allowing it to run on diverse hardware configurations with improved stability and performance.
>>>> Advanced Video Handling
>>>> 9front has made considerable strides in handling video output, particularly with high-resolution and multi-monitor setups.
>>>>
>>>> High-Resolution Display Support: Enhanced support for high-resolution displays, including 4K monitors, ensures crisp and clear visuals.
>>>> Multi-Monitor Configurations: Improved multi-monitor support allows users to extend their desktop across multiple screens seamlessly, enhancing productivity and usability.
>>>>
>>>> Chapter 2: Networking
>>>> [...]

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

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

[Noam Preil]

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

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

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

[ori]

I'm not sure it is interesting.

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

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

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

[Kurt H Maier via 9fans]

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

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

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

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

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

khm

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M4bc8405899fcc7a94bd431ef
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vester.thacker]

On Sat, May 18, 2024, at 00:51, Kurt H Maier wrote:
> I love this article very much.  Unhelpful, bossy blowhards should
> experience exactly these emotions.  My favorite part was the accusation
> of "cancel culture," which I have learned is Boomer code for
> "accountability."  They really hate that shit!

I'm pleased it got a conversation going. The topic needed to be addressed. I took it down as I realized that when dealing with others expressing narcissistic tendencies, the article would not have any impact on their behavior anyway. I think I can see now who the narcissists are, as they double down on their abusive behavior.  Abusers often don't realize they're abusing anyone. However, victims of their abuse do recognize it. 

> If 9front has constructed a culture where someone who calls themselves
> "Innovator Harnessing the Power of Open Source: Transforming Businesses,
> Empowering Solutions" does not feel welcome, then I am profoundly
> satsified with that culture, and commend everyone involved in its
> creation.

I fed my resume into an LLM and it suggested that tagline. I was amused and used it.   

> Anyway, just for the record, nobody in the 9front project has any ill
> will toward 9legacy.  Technical concerns like p9sk1, yes, but everyone
> agrees there should be *more* Plan 9 out there, not less.  We keep
> suggesting that people fork 9front as well, and make 9front Suit And Tie
> Edition, Empowering Harnessed Transformative Innovations, with all of
> the technical goodies and none of the humor or fun, but nobody seems to
> have the drive to make that happen.

I looked at behaviors and outcomes when making that assessment.

> If anyone wants help bootstrapping such a project, please let me know
> and I'll help however I can.  The existence of something like that might
> help deflect all the unfunded mandates people keep trying to demand of
> the 9front project, and create a nice home for the sorts of people whose
> primary qualifications are that they like to watch and they've been
> watching for decades.

9legacy can use a hand.

Dealing with a social issues on this mailing list is akin to standing in a summer sun, if I deal with them too long I'll become sun burned, and I'll find myself in need to step out of the sun to reduce the severity of the pain. If I can stop getting sun burned, my chances of contributing would improve. I often wonder how many more contributors there might have been if the environment were different. Fostering a better environment would help improve the chance for collaboration is what I'm saying. It seems that hiring someone to help do this for me is a better idea. That way I can step out of the sun. 

Take care.

Kind regards,
Vic

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M8a1cd9f1c0679edc3c916eb5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[sirjofri]

18.05.2024 05:33:10 vester.thacker@fastmail.fm:
> Dealing with a social issues on this mailing list is akin to standing in a summer sun, if I deal with them too long I'll become sun burned, and I'll find myself in need to step out of the sun to reduce the severity of the pain. If I can stop getting sun burned, my chances of contributing would improve. I often wonder how many more contributors there might have been if the environment were different. Fostering a better environment would help improve the chance for collaboration is what I'm saying. It seems that hiring someone to help do this for me is a better idea. That way I can step out of the sun.

Makes sense. There's a simple rule on the internet: don't feed the troll. We have a troll here (and if you read other threads or join the 9front communication channels every now and then, you'll quickly notice them). I never tried to change their behavior, because they're adults, and usually that kind of trolling stays within borders and they usually have a point (showing the absurdity of questions, for example).

It's important to know what you can ignore and what you can learn from it. I can safely say that I ignore many of those troll mails. I read them, I find the relevant truth, ignore everything else in that mail, then I go on with the next mail in that thread.

It's far from a professional environment. On the other hand, most of us do Plan 9 as a hobby. Don't take everything so seriously. In the 9front mailing list some mails are just links to music or funny videos/articles. It's only natural that some of this relaxed behavior spills over to the 9fans mailing list. If you want a true™®© professional environment, just set up a slack. And yes, this is somewhat of a troll (I'm not good at it).

> Take care

This is very important. Take care.

Have a nice day and enjoy the sun from the shadows.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M95a4cb9d7708227dad7d179b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[samuel.reader via 9fans]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

I've included 9front git history. Here is the results. 

"I reviewed the 9front Git repository to confirm details about the differences between 9front and 9legacy. Here are some key points:
 1. *Syscall Changes*: As mentioned, 9front did not add new syscalls beyond the 'nsec' syscall, which 9legacy had already included. This syscall was needed to run Go binaries, although it was deprecated upon import.


 2. *Kernel and Driver Enhancements*: 9front has made numerous improvements to the kernel and drivers. For example, they have added support for new hardware, such as the i219-LM Ethernet device, and improved existing drivers, like the virtio drivers for disk and Ethernet. 


 3. *Library Updates*: There have been updates to various libraries, such as lib9p, libsec, and libtags. These updates include bug fixes, performance enhancements, and new features like support for additional audio formats in libtags.


 4. *Program Improvements*: Many user programs have seen enhancements and bug fixes. Notable examples include the acme editor, which received improvements from Plan9port, and the git suite, which has been updated to handle modern workflows more effectively. I reviewed the 9front Git repository to confirm details about the differences between 9front and 9legacy. Here are some key points:


 5. *Syscall Changes*: As mentioned, 9front did not add new syscalls beyond the 'nsec' syscall, which 9legacy had already included. This syscall was needed to run Go binaries, although it was deprecated upon import.


 6. *Kernel and Driver Enhancements*: 9front has made numerous improvements to the kernel and drivers. For example, they have added support for new hardware, such as the i219-LM Ethernet device, and improved existing drivers, like the virtio drivers for disk and Ethernet.


 7. *Library Updates*: There have been updates to various libraries, such as lib9p, libsec, and libtags. These updates include bug fixes, performance enhancements, and new features like support for additional audio formats in libtags


 8. *Program Improvements*: Many user programs have seen enhancements and bug fixes. Notable examples include the acme editor, which received improvements from Plan9port, and the git suite, which has been updated to handle modern workflows more effectively."



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Md2f5a6f7ba20e50e4320a235
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3451 bytes --]

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Steve Simon]

i got very suspicious at the mention of a procinfo syscall - unlikely in plan9, and i couldn't imagine a use for such a thing given we have /proc already.

-Steve



------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M506b4d09d5f1ea68f7f1a8cd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[plan6]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

I guess that Vic Thacker and Samuel Reader are the very same person. And Ori, I was trying to be sarcastic when I called the linkedin paper "interesting". :)
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M29f298f8c9c2e6a54cc3e4a7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 883 bytes --]

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)

[vic.thacker]

Thanks Jacob for catching the mistake.

Vic


On Sun, May 12, 2024, at 16:12, Jacob Moody wrote:
> You just sent to this to just me, not the list. Shame not everyone 
> could see this LLM drivel :(
>
> On 5/12/24 00:46, vic.thacker@fastmail.fm wrote:
>> I've noticed the growing divide within our community, and I believe it's crucial for us to strive for an inclusive environment that transcends any "us versus them" mentality.  A shared vision and values are essential for guiding our direction and efforts within the Plan 9 community.  Let's focus on bridging this gap and fostering a space where collaboration and unity not only exist but thrive.  
>> 
>> It is important to acknowledge that adopting a "my way or the highway" attitude serves no positive purpose for the Plan 9 community.  Moving towards less polarization will enhance our capacity to welcome and encourage diverse contributions, making our community stronger and more innovative.
>> 
>> I want to express my gratitude to everyone who has shown a commitment to improving collaboration.  True collaboration requires effort from all sides, and I am hopeful that both 9front and 9legacy can reap equal benefits from our collective endeavors.  Let’s work together to build a community we are all proud to be part of.
>> 
>> Vic
>> 
>> 
>> On Sun, May 12, 2024, at 11:55, Jacob Moody wrote:
>>> I've gone ahead and made a repository[0] for an up to
>>> date fossil* for 9front. I didn't have to do more then
>>> clone the 4e repository, apply the 9legacy patches and
>>> type mk. Took all of 10 minutes. Testing is left as
>>> an exercise for the reader.
>>>
>>> * No warranty given or implied.
>>> [0] http://only9fans.com/moody/fossil/HEAD/info.html
>>>
>>> On 5/11/24 19:43, ori@eigenstate.org wrote:
>>>> As far as I can tell, 9front doesn't have a problem
>>>> on this side; we just imported the Power64 compilers,
>>>> have working versions of risc64, etc, all pulled in
>>>> from the 9legacy world.
>>>>
>>>> The work to port usually ranges between negligible
>>>> and trivial.
>>>>
>>>> As far as I can tell, the only thing preventing 9front
>>>> changes from making their way back to 9legacy is a lack
>>>> of hands to do the work.
>>>>
>>>> And while I'm happy to lend a hand, help debug, and even
>>>> make trivial changes to enhance portability, I personally
>>>> don't care to spend time porting software to a system I
>>>> don't intend to use.
>>>>
>>>> tl;dr: you need people doing the work before you can try
>>>> to organize them; the way to get people doing the work is
>>>> to bootstrap it by doing work and showing value.
>>>>
>>>> Quoth vic.thacker@fastmail.fm:
>>>>> Perhaps adopting this mindset could be beneficial. When developing a feature, it's worth considering its potential for portability and usefulness to other communities.
>>>>>
>>>>> Vic
>>>>>
>>>>> On Sun, May 12, 2024, at 07:27, hiro wrote:
>>>>>> just send the code then
>>>>>>
>>>>>> On Sun, May 12, 2024 at 12:22 AM <vic.thacker@fastmail.fm> 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 <lucio.dere@gmail.com> 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 <kvik@a-b.xyz> 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-Mfd1d1b7e548a6446f8c84f68
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[Noam Preil]

It is not, but in fairness, some people really do write the same way
that the LLMs do, so it's not impossible for a real person to appear to
be an LLM.

I'm leaning towards LLM-generated, anyways. It's far too similar in
structure / syntax to other AI spam I've had to deal with recently.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M6b07d6fc6ad01c998e34b8ed
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Interoperating between 9legacy and 9front

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 11267 bytes --]

> why don't you just let 9legacy die?

You are not paying attention: I have a multi-gigabyte commitment to Fossil.
I am not convinced *I* could "just port" Fossil to 9front (if it was all
that easy, why was it discarded entirely?) and I don't have the hardware to
migrate the data to a different disk representation. In fact, I can't even
justify attempting to migrate my setup to P9P under Linux (or NetBSD, which
is my preferred POSIX flavour) where Fossil may be better supported than
under 9front. And if the question "why don't you just let 9legacy die?" has
any validity, then Windows or Linux could be said to justify
the analogous "why don't you just let 9front die?"

Hiro, if there was no conflict, in the sense of an hostile attitude, then
Moodly would not have accused me of being lazy in a public forum. Nor would
you consider it good manners in the same forum to demand that people should
follow some "true way" as you suggest. That's where Vic's attitude is so
much less antagonistic than your own. And I have believed since I first met
Cinap in Greece in 2008 that neither he nor his development colleagues
share your attitude. You may br factually right, but that is really not
enough.

Lucio.

On Thu, May 9, 2024 at 9:52 PM hiro <23hiro@gmail.com> wrote:

> 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 <vic.thacker@fastmail.fm> 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 <vester.thacker@fastmail.fm> 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 sound like you're trying to make this someone else's problem.
> > >> > Being stuck in a hardware pickle when there are ample existing
> software
> > >> > solutions is not
> > >> > a good reason to ask someone else to go out of their way to write
> > >> > software.
> > >> >
> > >> > Fossil can be pulled in largely without modifications as I
> understand it,
> > >> > I don't run fossil but some people in the 9front community do and
> it does
> > >> > not appear to me that they've had issues with continuing to have it
> work
> > >> > (other then fossil bugs itself).
> > >> >
> > >> >>
> > >> >> I managed to share the Fossil cache through a NetBSD server
> providing u9fs services, but that host does not have the capacity to store
> the Venti arenas, nor can I really justify spending the amount of time it
> would take to pass it between the 9legacy and 9front devices via NetBSD, no
> matter how I try to arrange that. It does baffle me, though, that a NetBSD
> intermediary is more competent than the two "native" platforms.
> > >> >
> > >> > Are you blaming us for moving on from AES 53 bit keys that can be
> brute
> > >> > forced in an afternoon?
> > >> > I have tried to open a dialogue for getting dp9ik on 9legacy a
> couple
> > >> > times now, when I had brought it
> > >> > up I am told to write the patch. Something about being asked to
> spend
> > >> > the work to write a patch for 9legacy given
> > >> > the historical context of why 9front exists does not sit right with
> me.
> > >> > So it wont be me, sorry.
> > >> > Sure it sucks that things have drifted, but all our code is there,
> > >> > neatly organized out in to commits, if someone
> > >> > wants to import our work it is readily available. However something
> > >> > tells me most people are just going to use 9front as is.
> > >> >
> > >> > Good luck,
> > >> > moody
> > >> >


-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M5f89ff6ce95412bd3c10da5d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 14495 bytes --]

Re: [9fans] Interoperating between 9legacy and 9front

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

>
> (if it was all that easy, why was it discarded entirely?


I suspect no-one wanted to maintain it (in 9front).

> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M5f89ff6ce95412bd3c10da5d>
>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M2effb4edbec9b284fda30ced
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1176 bytes --]

Re: [9fans] Interoperating between 9legacy and 9front

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

Granted, but neither 9front nor 9legacy are tied to any promise of support.
All it took in the past was to include an indication in the
/sys/src/cmd/mkfile that the code for Fossil should not be compiled and
deployed as part of any installation. By omitting the sources, as I
explained, it denied the followers the option to provide that support
altogether. That's not the exact opposite of offering to support it.

Lucio.

On Fri, May 10, 2024 at 10:27 AM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> (if it was all that easy, why was it discarded entirely?
>
>
> I suspect no-one wanted to maintain it (in 9front).
>
>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M2effb4edbec9b284fda30ced>
>


-- 
Lucio De Re
2 Piet Retief St
Kestell (Eastern Free State)
9860 South Africa

Ph.: +27 58 653 1433
Cell: +27 83 251 5824

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M6058f9d0000c3a3407d55788
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2297 bytes --]

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] Interoperating between 9legacy and 9front

[Jacob Moody]

For the sake of time I am going to just reply here after
reading all of the existing thread

On 5/10/24 03:17, Lucio De Re wrote:
>> why don't you just let 9legacy die?
> 
> You are not paying attention: I have a multi-gigabyte commitment to Fossil. I am not convinced *I* could "just port" Fossil to 9front (if it was all that easy, why was it discarded entirely?) and I don't have the hardware to migrate the data to a different disk representation. In fact, I can't even justify attempting to migrate my setup to P9P under Linux (or NetBSD, which is my preferred POSIX flavour) where Fossil may be better supported than under 9front. And if the question "why don't you
> just let 9legacy die?" has any validity, then Windows or Linux could be said to justify the analogous "why don't you just let 9front die?"
> 
> Hiro, if there was no conflict, in the sense of an hostile attitude, then Moodly would not have accused me of being lazy in a public forum. Nor would you consider it good manners in the same forum to demand that people should follow some "true way" as you suggest. That's where Vic's attitude is so much less antagonistic than your own. And I have believed since I first met Cinap in Greece in 2008 that neither he nor his development colleagues share your attitude. You may br factually right, but
> that is really not enough.
> 

My intention was to not call you lazy, I was trying to communicate that if the system is not doing what you want and you would like someone else to fix
that for you there are better ways of doing so then being snide about the interoperability between 9front and 9legacy. Had the conversation been
"I need help doing this with 9front" without the finger pointing I would have been happy to sit down and point you in the right direction without retorting.

Fossil was removed long before my time in 9front, it was removed because it kept eating people's data and the maintainers at the time did not want to deal
with it when we have perfectly good alternatives. So what Charles says is right on the money. I agree that for your specific usecase (and anyone else
migrating from 9legacy) this is less than ideal. As kvik and qwx both mentioned there are places where you can find find a "ready to go" fossil for
use with 9front, please try that and come back to us with specific questions. However I am telling you now that your request for fossil to be included
again just because it helps you out personally is not going to convince anyone. The system (and us as part of its maintainers) do not exist
to service you individually, sorry. We've pointed you in the right direction and your response of "that's over my head so I wont even try" is frustrating.
If you have specific questions of how to get started with things, or issues we can likely advise.

I will add that 9front does still support p9sk1, that code was not removed from the system.
If you are using 9front as the auth server you need to pass an additional flag to authsrv(6) to allow
it to respond to p9sk1 queries. I don't know why your setup is not working as is, but I don't have any
interest in standing up a similar environment in attempts to reproduce the issue.

Good luck


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Me800250b9bbae6fff6ca0c6f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Interoperating between 9legacy and 9front

[David du Colombier]

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-Md268ebc03be7431c29cb1d30
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 <0intro@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

[Dan Cross]

On Sat, May 11, 2024 at 3:52 PM hiro <23hiro@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 <0intro@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-M909e62763fe790d21eb88c72
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 <crossd@gmail.com> wrote:
>
> On Sat, May 11, 2024 at 3:52 PM hiro <23hiro@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 <0intro@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

[Dan Cross]

On Sat, May 11, 2024 at 4:05 PM hiro <23hiro@gmail.com> wrote:
> are you discontinuing 9legacy?

I'm not doing anything, just explaining why it hasn't happened.

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.

        - Dan C.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M0a433758862ca1b4a69e2e90
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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

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 <23hiro@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
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mba709492bbbdbb5d57fd8505
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1919 bytes --]

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
<skip.tavakkolian@gmail.com> 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 <23hiro@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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Sorry, that was just a courtesy. But don't worry I'll name it after you and
another comedic hero Don Rickles.

On Sat, May 11, 2024, 2:05 PM hiro <23hiro@gmail.com> wrote:

> 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
> <skip.tavakkolian@gmail.com> 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 <23hiro@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-M45c3b01b264a1e2ef02dac4b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2743 bytes --]

[9fans] fossil

[Charles Forsyth]

anyone else ever seen things like this from fossil? it seems a bit wayward...

# on the fossil console, after `disk full' returned in errors:

main: df
	main: 10,046,783,488 used + 35,180,756,598,784 free = 6,431,293,440 (156% used)
main: snapclean 3600
main: df
	main: 3,000,909,824 used + 3,430,383,616 free = 6,431,293,440 (46% used)

the server goes into `disk full' state.  i think one underlying problem
is that i haven't applied the change to remove floating-point calculations
from fossil's timer routine, and thus at least sometimes it can never quite
get to the right time to do the snapclean itself.  even so, i've only seen
this effect since i updated fossil in january after several years.
i've had periodic `disk full' problems since then.

Re: [9fans] fossil

[erik quanstrom]

On Thu Jun  4 05:11:02 EDT 2009, forsyth@terzarima.net wrote:
> anyone else ever seen things like this from fossil? it seems a bit wayward...
>
> # on the fossil console, after `disk full' returned in errors:
>
> main: df
> 	main: 10,046,783,488 used + 35,180,756,598,784 free = 6,431,293,440 (156% used)
> main: snapclean 3600
> main: df
> 	main: 3,000,909,824 used + 3,430,383,616 free = 6,431,293,440 (46% used)

i suspect the free should be printed as a signed quanity. ☺

the management of fl->nused seems to permit a hole
(which isn't new) that could prevent fl->nused from being
decremented while still removing stuff from the fl in doRemoveLink.

perhaps i've misread the code.

it would be interesting to see what the difference between
the output of df would be if cacheCountUsed could be
asked to return both the cached fl->nused and also compute
it as it does if the epochs don't match.

it would be even more interesting if they differ, if resetting
fl->nused with the newly computed value just does the right
thing.

- erik

[9fans] fossil

[Bruce Ellis]

ok.  it's happened again.  i have a buggered fossil on a machine
that uses fossil as its root.  (corrupted superblock).  i have no idea
how it happened. i guess the obvious is to rebuild the machine
with an extra disk and cd-rom and boot from that and poke around.
any chances of retrieving the significant work i've done since the
last venti snap?

brucee

Re: [9fans] fossil

[Russ Cox]

if you've been doing regular non-venti snaps,
the super-block actually has very little important data.
the really important part is the root blocks.  every new
file system snapshot has a new root block, and a root
block is enough to get the rest of the system.

On Tue, 4 Jan 2005 05:37:45 +1100, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> ok.  it's happened again.  i have a buggered fossil on a machine
> that uses fossil as its root.  (corrupted superblock).  i have no idea
> how it happened. i guess the obvious is to rebuild the machine
> with an extra disk and cd-rom and boot from that and poke around.
> any chances of retrieving the significant work i've done since the
> last venti snap?
> 
> brucee
>

Re: [9fans] fossil

[Russ Cox]

> ok.  it's happened again.  i have a buggered fossil on a machine
> that uses fossil as its root.  (corrupted superblock).  i have no idea
> how it happened. i guess the obvious is to rebuild the machine
> with an extra disk and cd-rom and boot from that and poke around.
> any chances of retrieving the significant work i've done since the
> last venti snap?

brucee and i figured this out.  there was a bug in the epoch
command.  if you ran epoch 0 or even epoch foo (or epoch
help!) then epoch would set the low epoch to 0, resulting in
an invalid super block.

the bug is fixed on sources.  until you rebuild fossil and your
kernels, be careful what you say to "epoch".

russ

[9fans] fossil

[Russ Cox]

there's a new fossil on sources that should
fix the leaks people have been encountering.
as i mentioned in the other thread, the
console "check" command should be used
in place of flchk.  in particular, to fix your leaks
you can do

fsys main
check fix pdir

(of course, snap -a and wait for the vac first,
just in case.)  the pdir is optional, but it is good
for seeing that something is going on.

russ

[9fans] fossil

[David Presotto]

We fixed a pretty major security whole on Mar 11th.
Make sure you're up to date.

[9fans] fossil

[Andrew]

This has been nagging at me for a while. Currently my plan9 system has
the standard old fs server, and auth server and some terms. Everything
boots from floppies or small hard drives, then mounts its root from the
file server. I want to update to fossil, and do away with the old file
server. Is there an [easy] way to make the fossil server boot up on its
own in the same way fs does? Im just not really clear on how it all
fits together.

Re: [9fans] fossil

[Russ Cox]

The wiki has instructions about making a standalone fossil boot kernel.
It's not quite as simple as the current fs, but it's not too hard.
I put a link to the "Setting up Fossil" page on the front page.  Not sure
why it wasn't there already.

Re: [9fans] fossil

[Andrew]

I had read that, it seemed a little forbidding so i wanted to check if
there was an easier or better way around it first. Thanks.

Andrew

On Tue, Apr 15, 2003 at 11:12:45AM -0400, Russ Cox wrote:
> The wiki has instructions about making a standalone fossil boot kernel.
> It's not quite as simple as the current fs, but it's not too hard.
> I put a link to the "Setting up Fossil" page on the front page.  Not sure
> why it wasn't there already.
>