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

[Lucio De Re <lucio.dere@gmail.com>]

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