From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: from tb-ob0.topicbox.com (tb-ob0.topicbox.com [64.147.108.117]) by inbox.vuxu.org (Postfix) with ESMTP id 8718E24271 for ; Thu, 9 May 2024 12:51:22 +0200 (CEST) Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob0.topicbox.com (Postfix) with ESMTP id 4DF9E2C6B4 for ; Thu, 9 May 2024 06:51:22 -0400 (EDT) (envelope-from bounce.mM5f676a1637898c965565e8ed.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id 4AD7017F3A1F; Thu, 9 May 2024 06:51:22 -0400 (EDT) ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=VhZ/kARt header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; spf=pass smtp.mailfrom=lucio.dere@gmail.com smtp.helo=mail-wr1-f50.google.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type:list-help:list-id:list-post :list-subscribe:reply-to:content-transfer-encoding :list-unsubscribe; s=sysmsg-1; t=1715251882; bh=4aOmjGpkTBzbfcoM ybvqQ65Nrxgyuqwrn0EOzM9TQ8Q=; b=a2ySQcslxG8YkKSvvVpEp6rv8GlJGyvD 2vItkdt7kTRm3r786mZtSTVdPYqLzkTkJdW0NNfD9ERn1JfzACxX/yporesddQE+ Sbca5qFCiTkEds/YLYWR7ipGOIocuV+XB11p81RY2ex+fPmIsGAKVG51k6Rdggw2 t1OO8L0WA6Y= ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t= 1715251882; b=I1dqPA+KscAnr6TajJmXkPJ61kHA7fTwx40ud0q2u+gYQMtN7B 4m+k+C0UbjFE+gCNolTFVM0cBpP6WZ0T9Wml9xjo6NZlk0piqYvNogGhdSs+6o7I IJXHAErEa8vifumk6fxbTlLqbtYNYd97tOngT3d1R/hYp0QlsDYRwsDVA= Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=VhZ/kARt header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; spf=pass smtp.mailfrom=lucio.dere@gmail.com smtp.helo=mail-wr1-f50.google.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) X-Received-Authentication-Results: tb-mx0.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=VhZ/kARt header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.221.50 (mail-wr1-f50.google.com); spf=pass smtp.mailfrom=lucio.dere@gmail.com smtp.helo=mail-wr1-f50.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=teX5gyo6; x-me-sender=none; x-ptr=pass smtp.helo=mail-wr1-f50.google.com policy.ptr=mail-wr1-f50.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt4.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt4.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:content-type:list-help:list-id:list-post:list-subscribe :reply-to:content-transfer-encoding:list-unsubscribe; s=dkim-1; t=1715251882; x=1715338282; bh=gETMQmstSsWwsAK+uuBFiEZrPekEuv3C ug34Pmuktew=; b=R3YjASBwmgmvcWCn+vavMbcvkIbkQ9BUxwFjaESLjdFeSGhr 6HnxskXrwBkKSEDKXQAYVscnSLBbDzg7AY5tg5l44US1zNRJZdaZs3PaiKBxyXy5 eAC21NlpIseqS2G4SD3KbU0Ev8SqqoTXQG0eI8AQYSA9qHeUCTN6Y9IpuVQ= Received: from tb-mx0.topicbox.com (localhost.local [127.0.0.1]) by tb-mx0.topicbox.com (Postfix) with ESMTP id 4A98D17F35C3 for <9fans@9fans.net>; Thu, 9 May 2024 06:51:02 -0400 (EDT) (envelope-from lucio.dere@gmail.com) Received: from tb-mx0.topicbox.com (localhost [127.0.0.1]) by tb-mx0.topicbox.com (Authentication Milter) with ESMTP id DD25169F1FD; Thu, 9 May 2024 06:51:02 -0400 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1715251862; b=eeVXWIUGj0JV3N6K+bXziOF8TyqH1Y005Icbf+S5R4NlKHGML+ T8p49DrS2s2Mn0LxDgLBdvHRWxWmgSgOqiLrBZx/MQHyPczZWJBT6YWs1bMDMYIO +Cz2MyZEWs9LpEo5+Iay+QGPd6bfxnFap7bPqWELYudYKLMVz4RnCSM3nUbs+vDi xyqyFbBNuS4Z0/cL+OoNaSVPGUeEBCWfoBpDMd7xM+sMPt/+uoy38GbTqgRQMOQ/ BjsSMFzabrQ+Yv6pAIQcXxZIba43tJQOOOr9OVeZANkGacQFat1wWbqiAmBRu/J1 vzrR6mqksrTw3HQ9omIQ/yIigQEarjcYA6CQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; s=arcseal; t=1715251862; bh=KNqcnO5fES68xduEEjc4CGs4kLDAedMUzMFb0LzsdqM=; b=UefTpzBIqczZ ho2m2yP1hmXlOUBedcJ7jDF7vB3yC1fesI0lvqQLKKNpMaq3FdSaLY/n/nqfmimi jqHcBTSR3nMVwtKfT2eAuPbsojAbzWgvfRgRHBCSEO36BodjCC4oWX9DhlTnIogj GO+LKqKltqYfB4PRcF/n26JkJUMjIk48WGnn5nDb3Ah2wpR0FImliS3D0242vS3H qIZYiEZGA3ov3NhIsKmIrlmFewN1AhKNweIm4rveChjxrzQXkrziLduOIhQ6mAbm Xh7ysxxMsBwQ5uU8hDM5pItyvErjij4rZCWS9o3i3CiJoREyHV9Ca5LG42tlVv7o Th/whP0Lcw== ARC-Authentication-Results: i=1; tb-mx0.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=VhZ/kARt header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.221.50 (mail-wr1-f50.google.com); spf=pass smtp.mailfrom=lucio.dere@gmail.com smtp.helo=mail-wr1-f50.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=teX5gyo6; x-me-sender=none; x-ptr=pass smtp.helo=mail-wr1-f50.google.com policy.ptr=mail-wr1-f50.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt4.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt4.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgedvledrvdefvddgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeggfhgjhf ffkffuvfgtsegrtderredttdejnecuhfhrohhmpefnuhgtihhoucffvgcutfgvuceolhhu tghiohdruggvrhgvsehgmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpefhhedthe ffgedvfeduvdduhedvhfetfeehjeduvdehhfeghedugffgiedthfehffenucffohhmrghi nhepthhophhitggsohigrdgtohhmnecukfhppedvtdelrdekhedrvddvuddrhedtnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddtledrkeehrddvvddu rdehtddphhgvlhhopehmrghilhdqfihruddqfhehtddrghhoohhglhgvrdgtohhmpdhmrg hilhhfrhhomhepoehluhgtihhordguvghrvgesghhmrghilhdrtghomheqpdhnsggprhgt phhtthhopedupdhrtghpthhtohepoeelfhgrnhhsseelfhgrnhhsrdhnvghtqe X-ME-VSScore: 0 X-ME-VSCategory: clean Received-SPF: pass (gmail.com ... _spf.google.com: Sender is authorized to use 'lucio.dere@gmail.com' in 'mfrom' identity (mechanism 'include:_netblocks.google.com' matched)) receiver=tb-mx0.topicbox.com; identity=mailfrom; envelope-from="lucio.dere@gmail.com"; helo=mail-wr1-f50.google.com; client-ip=209.85.221.50 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tb-mx0.topicbox.com (Postfix) with ESMTPS for <9fans@9fans.net>; Thu, 9 May 2024 06:51:01 -0400 (EDT) (envelope-from lucio.dere@gmail.com) Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-34e667905d2so494754f8f.1 for <9fans@9fans.net>; Thu, 09 May 2024 03:51:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715251860; x=1715856660; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KNqcnO5fES68xduEEjc4CGs4kLDAedMUzMFb0LzsdqM=; b=teX5gyo66J36gKeIJZl0DBXIJHmhR9bEOPEpDwm6lZ8lAi5w89Svhofc/+my/V0yMq kHzkWpTCMul5CbcHqaC3Kpn1N7U1+wjLabAZL8qhafpCEI3cJfwOXsXyFgC6QKfSqeMc NCXYJzHvpuchn9cVkIzOI72sCtGGEv/u0VcJOqoDxNOX/DPk5RmuKyyza2JM8o0Ztm2T R2TZ/uHlSTHjQnK66/N7dStevOgLN/87/nGmnCwXNheW3Ou3RulxGhhh6Q3xaH+b+o2F xaUsslAc9PBfn8iT9Ta2CY5zuWw959DdPvrRuUpGdK8MqHnLAXSZuCCLERDwZQfrXoTB bl/g== X-Gm-Message-State: AOJu0YyUz2aVClfU2yHYxgxZfoMM+88ZdRiv9fXUBH6ZCEwnTSl/hAfn 4e6FJ/PzE8YRgc0dTKbETg/pAydjLndZgxovt0fV7sVdOEIAd2Q5pa4dtOtZaLP65s+kNKeiYxu SigZLl9oC8BifJINtswJI1rnUK0Zsqg== X-Google-Smtp-Source: AGHT+IEXETo8j8Yv4K01rz019caXfIiSAP84xU+smVKKDBjbaHukw70JnHWVCiwKRqG/0s1YWXYilxKgqS+pRJTYLf4= X-Received: by 2002:adf:ed8c:0:b0:34c:e9b5:d746 with SMTP id ffacd0b85a97d-34fcaddda3cmr3457758f8f.6.1715251859351; Thu, 09 May 2024 03:50:59 -0700 (PDT) MIME-Version: 1.0 References: <53b297f4-31d4-48fd-86f4-6b5c2393edc0@app.fastmail.com> <84aa1c7f-1f39-43eb-81a2-b73cc432196a@app.fastmail.com> In-Reply-To: <84aa1c7f-1f39-43eb-81a2-b73cc432196a@app.fastmail.com> From: Lucio De Re Date: Thu, 9 May 2024 12:55:31 +0200 Message-ID: Subject: Re: [9fans] Interoperating between 9legacy and 9front To: 9fans <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000000000000c6f29206180331c0 Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 0deffeae-0df2-11ef-ad77-3978018c7b06 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UZGUyY2EyYWRkYTM4M2EzYS1NNWY2NzZhMTYzNzg5OGM5NjU1NjVl?= =?UTF-8?B?OGVkPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Content-Transfer-Encoding: 7bit List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M5f676a1637898c965565e8ed:1:5PnRhSU0Vu4QU05PfxZgZbFidHVlR6x1nyzqY-RV9u4 --000000000000c6f29206180331c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM 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 motivat= ed > 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=E2=80=AFPM wro= te: > >> > >> 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 tha= t. > >> > > >> > 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 di= sk > 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 > >> > --=20 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-M5f676= a1637898c965565e8ed Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --000000000000c6f29206180331c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, Vic, for your efforts. My perc= eptions about the conflicts that seem to be stirred by any posts that compa= res 9front with the original, poorly defined, shall we say, "heritage&= quot; Plan 9 release are well reflected in your original, detailed posting.=
I was planning to address the issue, but you have done that more proac= tively than I would manage.

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

I have two large data objects: a fossil cache and a venti backing ar= ena. They are held on one SATA drive. Both seem intact, although I am limit= ed to only superficial inspection because of the size of the objects and th= e limits in the hardware available to me. I have made various attempts at b= ooting the release Plan 9 legacy system on the available platform that supp= orts SATA drives - but not serial IDE - and have failed. The hardware invol= ved pre-dates UEFI so I am using the traditional boot procedure, to the bes= t of my ability. Booting the 9-legacy distribution from either a SATA optic= al 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 wi= th the legacy system which I have been using ever since 2nd Edition was rel= eased for sale - I still have the original CD-ROM and two volume documentat= ion) from a USB stick and eventually installed it on the SATA-capable platf= orm 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 boo= tstrap loader (legacy's 9load in preference to 9front's 9boot = for various reasons, not all perfectly water-tight), Fossil- and Venti-capa= ble kernel and the right Fossil and Venti embedded configurations to comple= te the Plan 9 bootstrap procedure.

As I'm pr= esently stuck with /386/pbslba (announcing itself as PBS2) reporting "= Bad format or I/O error" my guess is that either the kernel "boot= file" is being specified incorrectly or (a subset condition) I am inst= ructing the loader to look for the kernel on the wrong device. Specifically= , I was surprised to discover that 9front uses "sdC[01]" and &quo= t;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 possi= ble permutations, maybe I have missed one or more.

Now, I didn't explicitly indicate where 9front comes into this: I ma= nipulated the disk drive holding my precious data using 9front. Once I had = the means to edit the configuration in the Fossil cache partition - and rem= embered 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 bump= ed my shins against in this exercise; mostly of my own making as I am somew= hat lazy and not as sharp as I thought I was when younger.

=
The absence of Fossil from 9front was the one I found most diffi= cult to overcome, but at least in theory only the equivalent of "fossi= l/conf" (an rc script I eventually shoehorned from plan9port) is essen= tial. I can see how it would be inconvenient to need to support software th= at is significantly complex, especially when it must also be able to be emb= edded in the kernel.

Jacob makes the point that = porting Fossil to 9front is not a 9front responsibility, analogously he als= o 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 dis= agree with whomever has dropped the Fossil source code entirely from the 9f= ront release. Right or wrong, I think it will require assistance from the 9= front development community to get Fossil working on 9front and plenty of d= iplomacy 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 n= ot only hard to contemplate the option, but it is also quite likely that pr= ogress in that direction may already have been made but not shared with tho= se who may in turn also contribute to this.

My r= equest, therefore, is that anyone who has worked with the Fossil code in th= e 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.<= /div>

As far as dp9ik goes, I have personal reasons to= enhance 9legacy's security code, but it is a massive endeavour, at lea= st 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 th= e necessary cooperation will also materialise.

M= y 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.

<= div class=3D"gmail_attr" dir=3D"ltr">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 conflict= s between the 9legacy and 9front communities indicates that adopting collab= orative strategies could be advantageous.  In my detailed post, I aime= d to provide a comprehensive overview to fully encapsulate the topic. = Having observed conflicts evolve over more than two decades, I am motivate= d to suggest improvements rather than seeing history repeat itself.  I= contributed my comments in hopes of fostering meaningful positive change.&= nbsp; I value both 9front and 9legacy but choose to remain neutral and refr= ain from taking sides.  In my view, there's no advantage in pickin= g sides, particularly among us 9fans.  The need for collaboration seem= s great, I'm astonished that more collaboration hasn't happened ove= r 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> wrot= e:
>>
>> Dear Members of the 9legacy and 9front Communities,
>>
>> This message is intended to share thoughts on potential improvemen= ts to collaborative processes between systems. The aim is to foster an envi= ronment that encourages ongoing enhancement and mutual support.
>>
>> Community Efforts
>> Appreciation is extended to all community members for their dedica= tion 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 challenge= s, 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 chal= lenges, such as integrating the dp9ik security protocol, could facilitate s= moother and more efficient integration. Interested members might consider p= articipating 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 t= he progress and decisions that affect both communities.
>>
>> Inclusive Decision-Making Processes
>> Exploring ways to ensure that decision-making processes reflect th= e 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 signif= icant contributions and successes are being explored.
>>
>> Addressing Historical Concerns
>> Dedicating time to openly discuss historical concerns is crucial f= or moving forward. This could help reconcile and strengthen community ties.=
>>
>> Feedback on these suggestions and potential interest in participat= ing in these initiatives is invited. Contributions from community members a= re 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 mi= ssing.
>> >>
>> >> I can't seem to get a 9front workstation to mount a n= etworked 9legacy fossil service. The FS is a fairly pristine 9legacy instal= lation, on a somewhat old 386 platform. I did need to tweak various paramet= ers on both side, but eventually I got to the point where both hosts declar= e 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 "dp9i= k" 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 th= e fossil
>> > 9legacy machine?
>> > Or perhaps just take a disk/mkfs backup and tar that. You rea= lly 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 get= ting the
>> > files.
>> >
>> >>
>> >> Why am I mixing my platforms like this? Because the hardw= are on which I am attempting to recover a rather large historical file syst= em is split between IDE and SATA and I have no hardware that can handle bot= h 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 thi= s so daunting, but that's where I am at. To be precise, I need to chang= e 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 poss= ibility...
>> >
>> > It sound like you're trying to make this someone else'= ;s problem.
>> > Being stuck in a hardware pickle when there are ample existin= g software
>> > solutions is not
>> > a good reason to ask someone else to go out of their way to w= rite
>> > software.
>> >
>> > Fossil can be pulled in largely without modifications as I un= derstand it,
>> > I don't run fossil but some people in the 9front communit= y 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 serv= er providing u9fs services, but that host does not have the capacity to sto= re the Venti arenas, nor can I really justify spending the amount of time i= t 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 NetB= SD intermediary is more competent than the two "native" platforms= .
>> >
>> > Are you blaming us for moving on from AES 53 bit keys that ca= n 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 righ= t with me.
>> > So it wont be me, sorry.
>> > Sure it sucks that things have drifted, but all our code is t= here,
>> > neatly organized out in to commits, if someone
>> > wants to import our work it is readily available. However som= ething
>> > 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-M816b94e66f927574088f66= 28
Delivery options: https://9fans.topicbox.com/gro= ups/9fans/subscription


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

Ph.: +27 58 = 653 1433
Cell: +27 83 251 5824
= --000000000000c6f29206180331c0--