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-ob21.topicbox.com (tb-ob21.topicbox.com [173.228.157.67]) by inbox.vuxu.org (Postfix) with ESMTP id 002D2249F8 for ; Fri, 10 May 2024 10:18:00 +0200 (CEST) Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob21.topicbox.com (Postfix) with ESMTP id A5F0926837 for ; Fri, 10 May 2024 04:17:58 -0400 (EDT) (envelope-from bounce.mM5f89ff6ce95412bd3c10da5d.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id 5148B181D1CC; Fri, 10 May 2024 04:17:58 -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=NOHnhqX4 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-f46.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=1715329078; bh=dYKDBfgbsQCnoY1V QaxQZSQOILoVOnCwYdMyxyLudxg=; b=soSdZoQCUuH7nzKcxRt/KjFed5puHkwz mX56dH/0HG4zpPo1TlMhT+HFgf9pXFd4/o2AaxETBPFYKoz+lHxiIMuRNciARdb/ KljnCxZVRJM8BP+XPvLWjV0PbqhD7OXOgvqo3IGH+M0KSER9hiP5Y+4KnuJvdcQZ OGZp0a3egmE= ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t= 1715329078; b=PBWJBRlL0Ug+i94QpYmDZigq9KlgTAamQOrGSeNy7ucPQy95fV bQ0uW/wYk7gx1RzhKG+9DzlV3vvR14xuEHfPekZl5Evs6pSPmBNmSZiGRZIJxqqB uQg3uRvV84Ct6SHGTo2TLEULBZwvugKvBYOF1QRYtRemYNp7Ao/xpgJZw= Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=NOHnhqX4 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-f46.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=NOHnhqX4 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.46 (mail-wr1-f46.google.com); spf=pass smtp.mailfrom=lucio.dere@gmail.com smtp.helo=mail-wr1-f46.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=AGmYyZqJ; x-me-sender=none; x-ptr=pass smtp.helo=mail-wr1-f46.google.com policy.ptr=mail-wr1-f46.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt2.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt4.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: alt2.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt4.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=1715329078; x=1715415478; bh=+3vfc8DsG9/ZbsrtqjKXppNguwH3Or4H EWJOpBRGLRU=; b=Gm8yRur5oPq+ksL2zMIFjVEPXTNoHvdTgfG1E/URfPDVf8X7 KB/0Dwiv16dGuEsmIfpD/ocQaZikyLvfHWZgX2A+HysTlXJP4ceTrJ2E0CedmQd8 6iHCEIfltnsJGFDZJ98rJGMRlR6d5xrCAbYILk35PHZsy274kNUPhrOHstY= Received: from tb-mx0.topicbox.com (localhost.local [127.0.0.1]) by tb-mx0.topicbox.com (Postfix) with ESMTP id 2CE9E181CD8C for <9fans@9fans.net>; Fri, 10 May 2024 04:17:46 -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 7A9B8CB934C; Fri, 10 May 2024 04:17:46 -0400 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1715329066; b=WOwHdgw9F06F0QxhS29oX4aeqyQeTSxDZVwLVg6KDbyNQQp3W8 s4nDpXL3s2Pc2naFPH5DAONdK2EAl7DOfm8ABzFm/z7q3h982QLLXRsNVz89qT8y MG1PaI/cr0TP5uM9DZ0r5yFOnM21TeGUmImA5E+R91tTbS0p4njVOsfJFckOeAKa v+lkdQHwYI+0OXjd48zjxVw6ppV9HVvWDQKPeo5/SP8Nqw909wFX6NxQ9HD+b6LN e/6afoCUt6bhuUKJTqfFZVSGdmEQ/z5ZE4Y+O3XGE47dfLuEHD5wU82TYBwm+u6o vA+Bj9oC0vX5jnuTnBZVe3rk3KmMqRDuOSvw== 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=1715329066; bh=S/sdfKBNKxCaE34ydD0TGEvzv8UTrE62XwQqXOSkTJ4=; b=IX70jb4Ee5GY S1ykBvP23xRdnFZSkYoOZO+NART3puM5ggg99OEqFOhIez0IYkpdZqMGe8wmN3rD 3riUoOgobXGhmvFEAir9OcEtVrGLKHN1mitvuM3zRN5J2bG+Iqubb2l9QLL7S6SL u6Rfhnf3X33fQROx8icPZTspdXEZ94e2yIoEVn/vGIiniIF3nii2cuS01/mDEzPE 4HiPCnWkdi42wnSQDjurNxEMWxClQCFtRo8RofZZwbU3KhV2nsZphxU+pejWc5o3 SyV12WzlHy5fj8tClOjKTVfxrYDJ8UCw8jlF2LqLgPi3l3nsx76auDndRo325AqB CR3VnSNC5g== 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=NOHnhqX4 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.46 (mail-wr1-f46.google.com); spf=pass smtp.mailfrom=lucio.dere@gmail.com smtp.helo=mail-wr1-f46.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=AGmYyZqJ; x-me-sender=none; x-ptr=pass smtp.helo=mail-wr1-f46.google.com policy.ptr=mail-wr1-f46.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt2.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt4.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: alt2.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt4.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: gggruggvucftvghtrhhoucdtuddrgedvledrvdefkedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeggfhgjhf ffkffuvfgtsegrtderredttdejnecuhfhrohhmpefnuhgtihhoucffvgcutfgvuceolhhu tghiohdruggvrhgvsehgmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpefhhedthe ffgedvfeduvdduhedvhfetfeehjeduvdehhfeghedugffgiedthfehffenucffohhmrghi nhepthhophhitggsohigrdgtohhmnecukfhppedvtdelrdekhedrvddvuddrgeeinecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddtledrkeehrddvvddu rdegiedphhgvlhhopehmrghilhdqfihruddqfhegiedrghhoohhglhgvrdgtohhmpdhmrg 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-f46.google.com; client-ip=209.85.221.46 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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>; Fri, 10 May 2024 04:17:45 -0400 (EDT) (envelope-from lucio.dere@gmail.com) Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-34da4d6f543so1156306f8f.3 for <9fans@9fans.net>; Fri, 10 May 2024 01:17:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715329063; x=1715933863; 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=S/sdfKBNKxCaE34ydD0TGEvzv8UTrE62XwQqXOSkTJ4=; b=AGmYyZqJkqI54+jjLI/URZ3uLArRJDRsUhfURrBQ+gtkNbIItSFo+5s2VhYaAnatwB trG5JJJxHU30/5v1azM9c/WbONrZR2CMu9F2H/VUODDSQwkbqzNTUSqTWZDTuva0B6os cqMDby5NB1tAGkQ2wlvWalZVGTFrPwcH1vDh88mBGvSU3eWfsQljZthYezpv+tcUGj63 eIGv9Qwd/Y896YY9G4HN1VwfTL9Xcl9AX/az5y8zL5Z9yixZcDanghMkP3g/8xPH/7pQ VEMkQZFviZ8aYozwDHZ9B8NVtD4UaBnuKa/JQeoSq44cK86teuS8zgD3qIy2qPwfSInl HImg== X-Gm-Message-State: AOJu0YwruY2N2OFstvJcR1yg6jmx1rg1I2NqVKWp9D/Eaux6miijec1G q/iiK7AdZW6ClpKd/hxqHb/b9JiF5ljyKMNROUoUpDXEB5i67qRlM4G71BWFH1RcAEFESvqa6h4 hHBcjayrvA4W5peT3f//FGVkMcm9G/g== X-Google-Smtp-Source: AGHT+IH9S3ef/DuUpj2CJLzQ7GFQEka91iFABgWE1fGvX/SL3qZ6ONgDxiHCpQOfNxA0AgXQ3fBmIUwltpuJtFIGJZY= X-Received: by 2002:adf:ce0c:0:b0:34f:595:a390 with SMTP id ffacd0b85a97d-3504aa64a3amr1143562f8f.63.1715329063359; Fri, 10 May 2024 01:17:43 -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: From: Lucio De Re Date: Fri, 10 May 2024 10:17:30 +0200 Message-ID: Subject: Re: [9fans] Interoperating between 9legacy and 9front To: 9fans <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0000000000007ea0e70618152b8c Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: cb235792-0ea5-11ef-9c90-c846008c7b06 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UZGUyY2EyYWRkYTM4M2EzYS1NNWY4OWZmNmNlOTU0MTJiZDNjMTBk?= =?UTF-8?B?YTVkPg==?= 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:M5f89ff6ce95412bd3c10da5d:1:XOsst9q2alINt6Tt8E59-NsQg8xl3046a2jRS3rHcSM --0000000000007ea0e70618152b8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 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=E2=80=AFPM 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=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 w= rote: > > >> > > >> 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-M5f89f= f6ce95412bd3c10da5d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --0000000000007ea0e70618152b8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> why don't you just l= et 9legacy die?

You are not paying attention: I have a= multi-gigabyte commitment to Fossil. I am not convinced *I* could "ju= st port" Fossil to 9front (if it was all that easy, why was it discard= ed entirely?) and I don't have the hardware to migrate the data to a di= fferent disk representation. In fact, I can't even justify attempting t= o migrate my setup to P9P under Linux (or NetBSD, which is my preferred POS= IX flavour) where Fossil may be better supported than under 9front. And if = the question "why don't you just let 9legacy die?" has any va= lidity, then Windows or Linux could be said to justify the analogous&n= bsp;"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 V= ic's attitude is so much less antagonistic than your own. And I have be= lieved since I first met Cinap in Greece in 2008 that neither he nor his de= velopment 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 be= en
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 9lega= cy
die? is there a single 9legacy-only improvement that's worth having in<= br /> 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 con= flicts between the 9legacy and 9front communities indicates that adopting c= ollaborative strategies could be advantageous.  In my detailed post, I= aimed to provide a comprehensive overview to fully encapsulate the topic.&= nbsp; Having observed conflicts evolve over more than two decades, I am mot= ivated to suggest improvements rather than seeing history repeat itself.&nb= sp; I contributed my comments in hopes of fostering meaningful positive cha= nge.  I value both 9front and 9legacy but choose to remain neutral and= refrain from taking sides.  In my view, there's no advantage in p= icking sides, particularly among us 9fans.  The need for collaboration= seems great, I'm astonished that more collaboration hasn't happene= d 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 impro= vements 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 d= edication in updating and maintaining these systems. Their efforts are vita= l to collective progress.
> >>
> >> Community Dialogue
> >> An open forum for all members to share insights, discuss chal= lenges, and propose solutions related to system updates and integration eff= orts could prove beneficial. Such dialogue can help better understand diffe= rent 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 facilit= ate smoother and more efficient integration. Interested members might consi= der 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 ab= out the progress and decisions that affect both communities.
> >>
> >> Inclusive Decision-Making Processes
> >> Exploring ways to ensure that decision-making processes refle= ct the community's needs and inputs is under consideration. Contributio= ns on how to achieve this are highly valued.
> >>
> >> Recognition Program
> >> Recognizing the hard work and achievements of community membe= rs is important. Plans to introduce a recognition program that highlights s= ignificant contributions and successes are being explored.
> >>
> >> Addressing Historical Concerns
> >> Dedicating time to openly discuss historical concerns is cruc= ial for moving forward. This could help reconcile and strengthen community = ties.
> >>
> >> Feedback on these suggestions and potential interest in parti= cipating in these initiatives is invited. Contributions from community memb= ers are invaluable and will help shape the direction of collaborative effor= ts.
> >>
> >> 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 probl= em I am attempting to solve ought to have an obvious answer that I am clear= ly missing.
> >> >>
> >> >> I can't seem to get a 9front workstation to moun= t a networked 9legacy fossil service. The FS is a fairly pristine 9legacy i= nstallation, on a somewhat old 386 platform. I did need to tweak various pa= rameters on both side, but eventually I got to the point where both hosts d= eclare that the connection has been established; now on the 9front workstat= ion 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 f= or the fossil
> >> > 9legacy machine?
> >> > Or perhaps just take a disk/mkfs backup and tar that. Yo= u 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 jus= t 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 handl= e both disk modes and I need to move information between the two media type= s. 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 lo= se a lot of the most recent changes) and now I need (or at least want) to u= pdate the default boot ("arenas") Venti configuration on a SATA d= rive 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 fin= d 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) s= o it points to the correct Venti
> >> >> arenas. I'll deal with the analogous Venti situa= tion 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 els= e's problem.
> >> > Being stuck in a hardware pickle when there are ample ex= isting 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 com= munity do and it does
> >> > not appear to me that they've had issues with contin= uing 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 t= o store the Venti arenas, nor can I really justify spending the amount of t= ime it would take to pass it between the 9legacy and 9front devices via Net= BSD, no matter how I try to arrange that. It does baffle me, though, that a= NetBSD intermediary is more competent than the two "native" plat= forms.
> >> >
> >> > Are you blaming us for moving on from AES 53 bit keys th= at can be brute
> >> > forced in an afternoon?
> >> > I have tried to open a dialogue for getting dp9ik on 9le= gacy a couple
> >> > times now, when I had brought it
> >> > up I am told to write the patch. Something about being a= sked 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. Howeve= r 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-Mb4948fb5aeee2cee181a6f= eb
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
= --0000000000007ea0e70618152b8c--