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