Re: [9fans] Interoperating between 9legacy and 9front
Hi Hiro et al, This mailing list is focused on Plan 9 discussions. Noticing conflicts between the 9legacy and 9front communities indicates that adopting collaborative strategies could be advantageous. In my detailed post, I aimed to provide a comprehensive overview to fully encapsulate the topic. Having observed conflicts evolve over more than two decades, I am motivated to suggest improvements rather than seeing history repeat itself. I contributed my comments in hopes of fostering meaningful positive change. I value both 9front and 9legacy but choose to remain neutral and refrain from taking sides. In my view, there's no advantage in picking sides, particularly among us 9fans. The need for collaboration seems great, I'm astonished that more collaboration hasn't happened over the years. Kind regards, Vester On Thu, May 9, 2024, at 05:10, hiro wrote: > vester, why do you recommend all these things so overly > methodologically that are all already a reality in the 9front > community? are you a bot? > > On Wed, May 8, 2024 at 9:18 PM wrote: >> >> Dear Members of the 9legacy and 9front Communities, >> >> This message is intended to share thoughts on potential improvements to >> collaborative processes between systems. The aim is to foster an environment >> that encourages ongoing enhancement and mutual support. >> >> Community Efforts >> Appreciation is extended to all community members for their dedication in >> updating and maintaining these systems. Their efforts are vital to >> collective progress. >> >> Community Dialogue >> An open forum for all members to share insights, discuss challenges, and >> propose solutions related to system updates and integration efforts could >> prove beneficial. Such dialogue can help better understand different >> perspectives and formulate effective strategies collaboratively. >> >> Collaborative Working Group >> The creation of a working group to address specific technical challenges, >> such as integrating the dp9ik security protocol, could facilitate smoother >> and more efficient integration. Interested members might consider >> participating in such a group. >> >> Transparency in Decision-Making >> Improving the transparency of decision-making processes is a goal. Sharing >> regular informational updates could keep everyone informed about the >> progress and decisions that affect both communities. >> >> Inclusive Decision-Making Processes >> Exploring ways to ensure that decision-making processes reflect the >> community's needs and inputs is under consideration. Contributions on how to >> achieve this are highly valued. >> >> Recognition Program >> Recognizing the hard work and achievements of community members is >> important. Plans to introduce a recognition program that highlights >> significant contributions and successes are being explored. >> >> Addressing Historical Concerns >> Dedicating time to openly discuss historical concerns is crucial for moving >> forward. This could help reconcile and strengthen community ties. >> >> 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
Re: [9fans] Re: Raspberry pi with a largish screen?
4k@59hz works here. but only if i disable bluetooth. On Wed, May 8, 2024 at 9:56 PM wrote: > > Thanks, that’s promising. What’s your monitor? > 9fans / 9fans / see discussions + participants + delivery options Permalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcb982002ae12827e-M80dcfdccde1b1faf52f7e8a8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Interoperating between 9legacy and 9front
vester, why do you recommend all these things so overly
methodologically that are all already a reality in the 9front
community? are you a bot?
On Wed, May 8, 2024 at 9:18 PM wrote:
>
> Dear Members of the 9legacy and 9front Communities,
>
> This message is intended to share thoughts on potential improvements to
> collaborative processes between systems. The aim is to foster an environment
> that encourages ongoing enhancement and mutual support.
>
> Community Efforts
> Appreciation is extended to all community members for their dedication in
> updating and maintaining these systems. Their efforts are vital to collective
> progress.
>
> Community Dialogue
> An open forum for all members to share insights, discuss challenges, and
> propose solutions related to system updates and integration efforts could
> prove beneficial. Such dialogue can help better understand different
> perspectives and formulate effective strategies collaboratively.
>
> Collaborative Working Group
> The creation of a working group to address specific technical challenges,
> such as integrating the dp9ik security protocol, could facilitate smoother
> and more efficient integration. Interested members might consider
> participating in such a group.
>
> Transparency in Decision-Making
> Improving the transparency of decision-making processes is a goal. Sharing
> regular informational updates could keep everyone informed about the progress
> and decisions that affect both communities.
>
> Inclusive Decision-Making Processes
> Exploring ways to ensure that decision-making processes reflect the
> community's needs and inputs is under consideration. Contributions on how to
> achieve this are highly valued.
>
> Recognition Program
> Recognizing the hard work and achievements of community members is important.
> Plans to introduce a recognition program that highlights significant
> contributions and successes are being explored.
>
> Addressing Historical Concerns
> Dedicating time to openly discuss historical concerns is crucial for moving
> forward. This could help reconcile and strengthen community ties.
>
> Feedback on these suggestions and potential interest in participating in
> these initiatives is invited. Contributions from community members are
> invaluable and will help shape the direction of collaborative efforts.
>
> Thank you for your engagement and commitment to the community.
>
> Best regards,
> Vester
>
>
> On Thu, May 9, 2024, at 01:29, Jacob Moody wrote:
> > On 5/8/24 11:06, Lucio De Re wrote:
> >> There is much I would like to explain, but the problem I am attempting to
> >> solve ought to have an obvious answer that I am clearly missing.
> >>
> >> I can't seem to get a 9front workstation to mount a networked 9legacy
> >> fossil service. The FS is a fairly pristine 9legacy installation, on a
> >> somewhat old 386 platform. I did need to tweak various parameters on both
> >> side, but eventually I got to the point where both hosts declare that the
> >> connection has been established; now on the 9front workstation I get the
> >> message
> >> "srv net!192.96.33.148!9fs: mount failed: fossil authCheck: auth
> >> protocol not finished"
> >> I suspect the culprit is the lack of the newer "dp9ik" security on
> >> 9legacy, in which case it would be helpful to know how to work around that.
> >
> > Probably. Why not just temporarily disable auth checks for the fossil
> > 9legacy machine?
> > Or perhaps just take a disk/mkfs backup and tar that. You really have
> > chosen the most painful way of accomplishing this (which you seem to
> > acknowledge).
> > Or just exportfs the root? There are so many ways of just getting the
> > files.
> >
> >>
> >> Why am I mixing my platforms like this? Because the hardware on which I am
> >> attempting to recover a rather large historical file system is split
> >> between IDE and SATA and I have no hardware that can handle both disk
> >> modes and I need to move information between the two media types. I am not
> >> describing all the dead ends I tried, incidentally, that would take too
> >> long and really expose my limited understanding.
> >>
> >> It took almost a day to copy the Fossil cache (or lose a lot of the most
> >> recent changes) and now I need (or at least want) to update the default
> >> boot ("arenas") Venti configuration on a SATA drive which I can only
> >> access on hardware I can't install 9legacy on. It's complicated and I'm
> >> sure there are people here who would not find this so daunting, but that's
> >> where I am at. To be precise, I need to change the Fossil default
> >> configuration (in the "fossil" cache) so it points to the correct Venti
> >> arenas. I'll deal with the analogous Venti situation when I get past the
> >> total absence of Fossil tools on 9front.
> >>
> >> I guess I can port fossil/conf to 9front, but I'm not sure I have the
> >> stomach to try that. Maybe now that I have raised the possibility...
> >
> > It
[9fans] Re: Raspberry pi with a largish screen?
Thanks, that’s promising. What’s your monitor? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcb982002ae12827e-Md8ee947e62368b9743804cd2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: Raspberry pi with a largish screen?
This is my whole config.txt: [pi4] kernel=9pi4 arm_64bit=1 [pi3] kernel=9pi3 arm_64bit=1 [all] gpu_mem=16 core_freq=250 enable_uart=1 boot_delay=1 hdmi_group=2 hdmi_mode=87 hdmi_cvt=2560 1440 60 3 0 0 1 max_framebuffer_width=2560 max_framebuffer_height=1440 hdmi_pixel_freq_limit=25000 It gives me a 2560x1440 screen with no black borders. That's on a Raspberry Pi 4. That is with 9Front. Hope that helps. Garry -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcb982002ae12827e-M2870ab144dbaf67aea473f22 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Interoperating between 9legacy and 9front
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
[9fans] Raspberry pi with a largish screen?
Is anyone running a Raspberry pi with a largish display? I've not been able to get anything over 1920x1080 working. If you are, I'd love to see your config.txt and hear about anything you had to do beyond flashing the "normal" image. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcb982002ae12827e-M5a6bf9e3a57b896c715561f7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Interoperating between 9legacy and 9front
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
[9fans] Interoperating between 9legacy and 9front
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
