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

[Noam Preil]

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

Actually, adding fossil back in to 9front is extremely simple; I have a
branch at https://git.sr.ht/~pixelherodev/plan9 which has fossil
integrated.

The talk I gave at IWP9 was running from fossil on my 9front branch.

If my changes are too extensive compared to 9front (it's a personal
branch, so I wouldn't blame you for thinking that), I'm happy to even
create a branch that's just 9front+fossil. It's really not hard.

- Noam Preil


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mf4487e7706a5d7b4363ebe2e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

to answer my own question:

> Who is Eric Grosse?
>

  author =   "Russ Cox and Eric Grosse and Rob Pike and Dave
 Presotto and Sean Quinlan",
  title ="Security in {Plan 9}",

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M180b18bbcd970ebf78b9ccea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Skip Tavakkolian]

Sorry, that was just a courtesy. But don't worry I'll name it after you and
another comedic hero Don Rickles.

On Sat, May 11, 2024, 2:05 PM hiro <23h...@gmail.com> wrote:

> i do mind. please do not. but thanks for this medium-to-low-quality
> trolling attempt.
>
> On Sat, May 11, 2024 at 11:00 PM Skip Tavakkolian
>  wrote:
> >
> > Hiro, I hope you don't mind if I use your correspondence on 9fans to
> train a very annoying LLM.
> >
> > On Sat, May 11, 2024, 1:30 PM hiro <23h...@gmail.com> wrote:
> >> > Hey! It's a nice day out. A bit chilly with some wind, but sunny. I
> >> > don't know about you, but I'm going fishing.
> >>
> >> oh, i guess you are not Fish? i confused you. why are you speaking for
> >> Fish though, it's his decision to put it into 9legacy, no?
> >
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M45c3b01b264a1e2ef02dac4b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

i do mind. please do not. but thanks for this medium-to-low-quality
trolling attempt.

On Sat, May 11, 2024 at 11:00 PM Skip Tavakkolian
 wrote:
>
> Hiro, I hope you don't mind if I use your correspondence on 9fans to train a 
> very annoying LLM.
>
> On Sat, May 11, 2024, 1:30 PM hiro <23h...@gmail.com> wrote:
>> > Hey! It's a nice day out. A bit chilly with some wind, but sunny. I
>> > don't know about you, but I'm going fishing.
>> 
>> oh, i guess you are not Fish? i confused you. why are you speaking for
>> Fish though, it's his decision to put it into 9legacy, no?
>
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M3f9bb8085132822cbf7d7fd3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Skip Tavakkolian]

Hiro, I hope you don't mind if I use your correspondence on 9fans to train
a very annoying LLM.

On Sat, May 11, 2024, 1:30 PM hiro <23h...@gmail.com> wrote:

> > Hey! It's a nice day out. A bit chilly with some wind, but sunny. I
> > don't know about you, but I'm going fishing.
> 
> oh, i guess you are not Fish? i confused you. why are you speaking for
> Fish though, it's his decision to put it into 9legacy, no?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mba709492bbbdbb5d57fd8505
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

> Hey! It's a nice day out. A bit chilly with some wind, but sunny. I
> don't know about you, but I'm going fishing.

oh, i guess you are not Fish? i confused you. why are you speaking for
Fish though, it's his decision to put it into 9legacy, no?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mb0fe5a0ea3d1a11f2e454296
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Dan Cross]

On Sat, May 11, 2024 at 4:17 PM Jacob Moody  wrote:
> On 5/11/24 14:59, Dan Cross wrote:
> > On Sat, May 11, 2024 at 3:36 PM hiro <23h...@gmail.com> wrote:
> >>> explanation of dp9ik, which while useful, only
> >>> addresses what (I believe) Richard was referring to in passing, simply
> >>> noting the small key size of DES and how the shared secret is
> >>> vulnerable to dictionary attacks.
> >>
> >> i don't remember what richard was mentioning, but the small key size
> >> wasn't the only issue, the second issue is that this can be done
> >> completely offline. why do you say "only", what do you think is
> >> missing that should have been documented in addition to that?
> >
> > Probably how a random teenager could break it in an afternoon. :-)
>
> If we agree that:
>
> 1) p9sk1 allows the shared secret to be brute-forced offline.
> 2) The average consumer machine is fast enough to make a large amount of 
> attempts in a short time,
>in other words triple DES is not computationally hard to brute force these 
> days.
>
> I don't know how you don't see how this is trivial to do.
> A teenager can learn to download hashcat, all that is missing from this right 
> now is some python
> script to get the encrypted shared secret from a running p9sk1 server. All 
> the code for doing
> this is already written in C as part of the distribution, you just have to 
> only do half the
> negotiation and break out. I think you vastly underestimate the 
> resourcefulness of teenagers.
>
> I had previously stated I would publish the PoC that friends of mine in 
> university built
> as part of their class, I have been asked to not do that so I will not.

To be clear: _I'm_ not saying it can't be done. I don't know that it
can be done in an _afternoon_; maybe a day or two, but I honestly
don't know. I was just trying to clarify what (I think) Richard was
asking for.

- Dan C.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Me442d3920e7aeed16791c3f8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Jacob Moody]

On 5/11/24 14:59, Dan Cross wrote:
> On Sat, May 11, 2024 at 3:36 PM hiro <23h...@gmail.com> wrote:
>>> explanation of dp9ik, which while useful, only
>>> addresses what (I believe) Richard was referring to in passing, simply
>>> noting the small key size of DES and how the shared secret is
>>> vulnerable to dictionary attacks.
>>
>> i don't remember what richard was mentioning, but the small key size
>> wasn't the only issue, the second issue is that this can be done
>> completely offline. why do you say "only", what do you think is
>> missing that should have been documented in addition to that?
> 
> Probably how a random teenager could break it in an afternoon. :-)

If we agree that:

1) p9sk1 allows the shared secret to be brute-forced offline.
2) The average consumer machine is fast enough to make a large amount of 
attempts in a short time,
   in other words triple DES is not computationally hard to brute force these 
days.

I don't know how you don't see how this is trivial to do.
A teenager can learn to download hashcat, all that is missing from this right 
now is some python
script to get the encrypted shared secret from a running p9sk1 server. All the 
code for doing
this is already written in C as part of the distribution, you just have to only 
do half the
negotiation and break out. I think you vastly underestimate the resourcefulness 
of teenagers.

I had previously stated I would publish the PoC that friends of mine in 
university built
as part of their class, I have been asked to not do that so I will not.

- moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mf9740abb168ade9f12c1caa5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Dan Cross]

On Sat, May 11, 2024 at 4:05 PM hiro <23h...@gmail.com> wrote:
> are you discontinuing 9legacy?

I'm not doing anything, just explaining why it hasn't happened.

Hey! It's a nice day out. A bit chilly with some wind, but sunny. I
don't know about you, but I'm going fishing.

- Dan C.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M0a433758862ca1b4a69e2e90
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

are you discontinuing 9legacy?

On Sat, May 11, 2024 at 10:01 PM Dan Cross  wrote:
>
> On Sat, May 11, 2024 at 3:52 PM hiro <23h...@gmail.com> wrote:
> > it's YOUR fork, why aren't you doing it?
>
> For a simple reason: time.
>
> The work to integrate it in isn't technically that difficult, but
> requires time, which is always in short supply.
>
> - Dan C.
>
> > On Sat, May 11, 2024 at 11:47 AM David du Colombier <0in...@gmail.com> 
> > wrote:
> > >
> > > I'd be very pleased if someone could port the
> > > dp9ik authentication protocol to 9legacy.
> > >
> > > --
> > > David du Colombier

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M2ad003b92c9eb23dc97171eb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Dan Cross]

On Sat, May 11, 2024 at 3:52 PM hiro <23h...@gmail.com> wrote:
> it's YOUR fork, why aren't you doing it?

For a simple reason: time.

The work to integrate it in isn't technically that difficult, but
requires time, which is always in short supply.

- Dan C.

> On Sat, May 11, 2024 at 11:47 AM David du Colombier <0in...@gmail.com> wrote:
> >
> > I'd be very pleased if someone could port the
> > dp9ik authentication protocol to 9legacy.
> >
> > --
> > David du Colombier

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M909e62763fe790d21eb88c72
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Dan Cross]

On Sat, May 11, 2024 at 3:36 PM hiro <23h...@gmail.com> wrote:
> > explanation of dp9ik, which while useful, only
> > addresses what (I believe) Richard was referring to in passing, simply
> > noting the small key size of DES and how the shared secret is
> > vulnerable to dictionary attacks.
>
> i don't remember what richard was mentioning, but the small key size
> wasn't the only issue, the second issue is that this can be done
> completely offline. why do you say "only", what do you think is
> missing that should have been documented in addition to that?

Probably how a random teenager could break it in an afternoon. :-)

> significant effort has been spent not only to come up with dp9ik and
> verify it but also to document it openly and suggest it's use
> repeatedly to the whole plan9 community (even non-9front-users).
>
> it's beyond me why more 9fans people are not taking this contribution
> at face value.

I wonder if you read the rest of my email

> > I should note that a couple of years ago I talked to Eric Grosse about
> > dp9ik and p9sk1.
>
> Who is Eric Grosse?

https://n2vi.com/bio.html

> > I do
> > wish the name were different: c'mon guys, not _everything_ needs to be
> > snarky. ?;-)
>
> I do wish there wasn't ever any reasons to ever be snarky to anybody
> in the whole plan9 community.
>
> But sometimes it's easier to make some jokes than to solve all
> perceived interpersonal issues of all involved people in the
> community.

Huh.

- Dan C.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M12607f08d1ba7baaf4dc46ec
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

it's YOUR fork, why aren't you doing it?

On Sat, May 11, 2024 at 11:47 AM David du Colombier <0in...@gmail.com> wrote:
> 
> I'd be very pleased if someone could port the
> dp9ik authentication protocol to 9legacy.
> 
> --
> David du Colombier

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M50dc445eff38fdd058bd8bdc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

> explanation of dp9ik, which while useful, only
> addresses what (I believe) Richard was referring to in passing, simply
> noting the small key size of DES and how the shared secret is
> vulnerable to dictionary attacks.

i don't remember what richard was mentioning, but the small key size
wasn't the only issue, the second issue is that this can be done
completely offline. why do you say "only", what do you think is
missing that should have been documented in addition to that?

significant effort has been spent not only to come up with dp9ik and
verify it but also to document it openly and suggest it's use
repeatedly to the whole plan9 community (even non-9front-users).

it's beyond me why more 9fans people are not taking this contribution
at face value.

> I should note that a couple of years ago I talked to Eric Grosse about
> dp9ik and p9sk1.

Who is Eric Grosse?

> I do
> wish the name were different: c'mon guys, not _everything_ needs to be
> snarky. ?;-)

I do wish there wasn't ever any reasons to ever be snarky to anybody
in the whole plan9 community.

But sometimes it's easier to make some jokes than to solve all
perceived interpersonal issues of all involved people in the
community.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mc643283b7a50651f3279cee1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Dan Cross]

On Sat, May 11, 2024 at 2:26 PM hiro <23h...@gmail.com> wrote:
> On Fri, May 10, 2024 at 12:59 PM Richard Miller <9f...@hamnavoe.com> wrote:
> > > From: o...@eigenstate.org
> > > ...
> > > keep in mind that it can literally be brute forced in an
> > > afternoon by a teenager[1][2]; even a gpu isn't needed to do
> > > this in a reasonable amount of time.[1]
> >
> > [citation needed][1]
> >
>
> there you are[1].
> [1] http://felloff.net/usr/cinap_lenrek/newticket.txt

I believe the citation that Richard was asking for was one
demonstrating that p9sk1 could be broken by a teenager in an afternoon
(which, to be fair to Ori, is likely just a bit of fun hyperbole meant
to provide some flourish to an otherwise dry subject). The citation
you provided is to an explanation of dp9ik, which while useful, only
addresses what (I believe) Richard was referring to in passing, simply
noting the small key size of DES and how the shared secret is
vulnerable to dictionary attacks.

I should note that a couple of years ago I talked to Eric Grosse about
dp9ik and p9sk1. I'm sure he won't mind if I share that his (early)
impression was that dp9ik is a strict improvement over p9sk1, and that
p9sk1 should be phased out in favor of dp9ik. As a small quip, I do
wish the name were different: c'mon guys, not _everything_ needs to be
snarky. ?;-)

- Dan C.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mcb61bde6ee99250df4da09fb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

On Fri, May 10, 2024 at 12:59 PM Richard Miller <9f...@hamnavoe.com> wrote:
> > From: o...@eigenstate.org
> > ...
> > keep in mind that it can literally be brute forced in an
> > afternoon by a teenager[1][2]; even a gpu isn't needed to do
> > this in a reasonable amount of time.[1]
>
> [citation needed][1]
>

there you are[1].
[1] http://felloff.net/usr/cinap_lenrek/newticket.txt

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Macf821c0574d0acdaee773d9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[hiro]

> I suspect no-one wanted to maintain it (in 9front)

I think you meant: I suspect no-one wanted to maintain it.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mc64391ded8c1eeadfa19aa14
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[David du Colombier]

I'd be very pleased if someone could port the
dp9ik authentication protocol to 9legacy.

-- 
David du Colombier

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Md268ebc03be7431c29cb1d30
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Jacob Moody]

For the sake of time I am going to just reply here after
reading all of the existing thread

On 5/10/24 03:17, Lucio De Re wrote:
>> 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.
> 

My intention was to not call you lazy, I was trying to communicate that if the 
system is not doing what you want and you would like someone else to fix
that for you there are better ways of doing so then being snide about the 
interoperability between 9front and 9legacy. Had the conversation been
"I need help doing this with 9front" without the finger pointing I would have 
been happy to sit down and point you in the right direction without retorting.

Fossil was removed long before my time in 9front, it was removed because it 
kept eating people's data and the maintainers at the time did not want to deal
with it when we have perfectly good alternatives. So what Charles says is right 
on the money. I agree that for your specific usecase (and anyone else
migrating from 9legacy) this is less than ideal. As kvik and qwx both mentioned 
there are places where you can find find a "ready to go" fossil for
use with 9front, please try that and come back to us with specific questions. 
However I am telling you now that your request for fossil to be included
again just because it helps you out personally is not going to convince anyone. 
The system (and us as part of its maintainers) do not exist
to service you individually, sorry. We've pointed you in the right direction 
and your response of "that's over my head so I wont even try" is frustrating.
If you have specific questions of how to get started with things, or issues we 
can likely advise.

I will add that 9front does still support p9sk1, that code was not removed from 
the system.
If you are using 9front as the auth server you need to pass an additional flag 
to authsrv(6) to allow
it to respond to p9sk1 queries. I don't know why your setup is not working as 
is, but I don't have any
interest in standing up a similar environment in attempts to reproduce the 
issue.

Good luck


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Me800250b9bbae6fff6ca0c6f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Jacob Moody]

On 5/10/24 05:58, Richard Miller wrote:
>> From: o...@eigenstate.org
>> ...
>> keep in mind that it can literally be brute forced in an
>> afternoon by a teenager; even a gpu isn't needed to do
>> this in a reasonable amount of time.
> 
> [citation needed]
> 

Two people have independently broken the encryption, there has been a lack of 
publication
about it out of a matter of respect, but if it that is what it takes I will be 
putting the
proof of concept online later today.




--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mcb0e37bf83a48c66b7a93269
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[ibrahim via 9fans]

Out of curiosity regarding your problem at hand Lucio :

You could use 9vx on 9legacy to establish a connection directly. You said you 
have an optical drive on your old machine so why don't you just use the 9legacy 
CD ROM ? You could also put your drive in an external hd case and access it 
running 9legacy (qemu or bare metal) or 9vx.

Creating a recovery stick of 9legacy to boot from an USB stick is also possible 
with 9vx or 9legacy with some tweaks simply integrated in a pre mk script is 
also no big deal. 

Did you solve your problem or do you need further details if so could you 
perhaps decide for on solution strategy ? If you just need to connect to a 
working plan9 I don't get the reason why you don't use 9legacy or 9vx instead 
of 9front. Perhaps I missed some reasoning. 


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M4c073a7a5f8954879334e1d2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Richard Miller]

> From: o...@eigenstate.org
> ...
> keep in mind that it can literally be brute forced in an
> afternoon by a teenager; even a gpu isn't needed to do
> this in a reasonable amount of time.

[citation needed]


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M7d533ce99e6dd4d6b157f0e0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Lucio De Re]

Granted, but neither 9front nor 9legacy are tied to any promise of support.
All it took in the past was to include an indication in the
/sys/src/cmd/mkfile that the code for Fossil should not be compiled and
deployed as part of any installation. By omitting the sources, as I
explained, it denied the followers the option to provide that support
altogether. That's not the exact opposite of offering to support it.

Lucio.

On Fri, May 10, 2024 at 10:27 AM Charles Forsyth 
wrote:

> (if it was all that easy, why was it discarded entirely?
>
>
> I suspect no-one wanted to maintain it (in 9front).
>
>> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>


-- 
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-M6058f9dc3a3407d55788
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Charles Forsyth]

>
> (if it was all that easy, why was it discarded entirely?


I suspect no-one wanted to maintain it (in 9front).

> Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M2effb4edbec9b284fda30ced
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Lucio De Re]

> 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 PM hiro <23h...@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 PM  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  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.
> Sha

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

[hiro]

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 PM  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  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

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

[kvik]

> Installing fossil on 9front is not really difficult.

Correct. You only need to grab the source of it from your favorite vendor,
place it into right places and build it like any other system program.

Here's a script I wrote some years ago to do exactly that:

  https://hg.sr.ht/~kvik/fossil-up/raw/mkfile?rev=tip

I've no idea if it still works as-is and you should probably just do the
steps manually anyway.

Integrating fossil back into 9front so that it can be installed from a live
CD and booted from in its many possible configurations is gonna take more
effort and be of dubious value.

You're all better off cheering for Ori for his progress on gefs, which might
finally let you to store some files on this cursed system and go to sleep.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M16add7975bb2204637bf08a3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[ori]

keep in mind that it can literally be brute forced in an
afternoon by a teenager; even a gpu isn't needed to do
this in a reasonable amount of time.

Quoth Lucas Francesco :
> https://seh.dev/p9sk1/
> 
> On Thu, 9 May 2024 at 08:01, Lucio De Re  wrote:
> >
> > That seems simple enough, but "enable p9sk1 for the hostowner on 9front" 
> > isn't something I'm familiar with. Is it an additional attribute in the 
> > network database that I am not aware of?
> >
> > I will check the manual pages, although I'm not sure what to look for. I 
> > did note when creating a user or similar activity that a special case was 
> > made to include p9sk1 somewhere and I did later wonder about it, which is 
> > what my long question was all about, but I could not see where the details 
> > were hiding.
> >
> > Much appreciated, in any case, thank you.
> >
> > And, yes, plan9port is based on what has now become 9legacy, but there are 
> > significant 9front contributions. It would have been quite helpful if p9p 
> > development had been farmed out to a team comprising developers (and 
> > designers) from both camps.
> >
> > Lucio.
> >
> > On Thu, May 9, 2024 at 11:06 AM  wrote:
> >>
> >> I am using fossil on plan9port (which should be similar to 9legacy) from 
> >> 9front. The only thing which I needed was to enable p9sk1 for the 
> >> hostowner on 9front  (the auth server) and a factotum entry for this in 
> >> the file server, IIRC.
> >
> >
> >
> > --
> > 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 / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M9ae912348a14965096f54bc2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Lucas Francesco]

https://seh.dev/p9sk1/

On Thu, 9 May 2024 at 08:01, Lucio De Re  wrote:
>
> That seems simple enough, but "enable p9sk1 for the hostowner on 9front" 
> isn't something I'm familiar with. Is it an additional attribute in the 
> network database that I am not aware of?
>
> I will check the manual pages, although I'm not sure what to look for. I did 
> note when creating a user or similar activity that a special case was made to 
> include p9sk1 somewhere and I did later wonder about it, which is what my 
> long question was all about, but I could not see where the details were 
> hiding.
>
> Much appreciated, in any case, thank you.
>
> And, yes, plan9port is based on what has now become 9legacy, but there are 
> significant 9front contributions. It would have been quite helpful if p9p 
> development had been farmed out to a team comprising developers (and 
> designers) from both camps.
>
> Lucio.
>
> On Thu, May 9, 2024 at 11:06 AM  wrote:
>>
>> I am using fossil on plan9port (which should be similar to 9legacy) from 
>> 9front. The only thing which I needed was to enable p9sk1 for the hostowner 
>> on 9front  (the auth server) and a factotum entry for this in the file 
>> server, IIRC.
>
>
>
> --
> 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 / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M5816d9f941744129e57c0c84
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[wb . kloke]

Installing fossil on 9front is not really difficult. Fossil is just a userland 
server which probably can even be copied as a binary, as long as the cpu is the 
same.

Here are the hostowner factotum/ctl readout from the auth server:

key proto=p9sk1 user=bootes dom=fritz.box  !password?
key proto=dp9ik user=bootes dom=fritz.box  !password?

and from the plan9port fossil server (which doesn't know dp9ik):
key dom=fritz.box proto=p9sk1 user=bootes !password?

I installed the standard /lib/ndb/auth:

hostid=bootes
      uid=!sys uid=!adm uid=*

Though, Moody's advice to try disabling auth in the fossil server  using the 
fossilcons may be a far simpler solution.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M680f6580845ab41d3d8cb120
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Lucio De Re]

That seems simple enough, but "enable p9sk1 for the hostowner on 9front"
isn't something I'm familiar with. Is it an additional attribute in the
network database that I am not aware of?

I will check the manual pages, although I'm not sure what to look for. I
did note when creating a user or similar activity that a special case was
made to include p9sk1 somewhere and I did later wonder about it, which is
what my long question was all about, but I could not see where the details
were hiding.

Much appreciated, in any case, thank you.

And, yes, plan9port is based on what has now become 9legacy, but there are
significant 9front contributions. It would have been quite helpful if p9p
development had been farmed out to a team comprising developers (and
designers) from both camps.

Lucio.

On Thu, May 9, 2024 at 11:06 AM  wrote:

> I am using fossil on plan9port (which should be similar to 9legacy) from
> 9front. The only thing which I needed was to enable p9sk1 for the hostowner
> on 9front  (the auth server) and a factotum entry for this in the file
> server, IIRC.
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>


-- 
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-M493c2be338f5613bcd075759
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Lucio De Re]

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 es

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

[wb . kloke]

I am using fossil on plan9port (which should be similar to 9legacy) from 
9front. The only thing which I needed was to enable p9sk1 for the hostowner on 
9front  (the auth server) and a factotum entry for this in the file server, 
IIRC.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M7ea4a9b3813f6d25dfac622b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[vic . thacker]

Hi Hiro et al,

This mailing list is focused on Plan 9 discussions.  Noticing conflicts between 
the 9legacy and 9front communities indicates that adopting collaborative 
strategies could be advantageous.  In my detailed post, I aimed to provide a 
comprehensive overview to fully encapsulate the topic.  Having observed 
conflicts evolve over more than two decades, I am motivated to suggest 
improvements rather than seeing history repeat itself.  I contributed my 
comments in hopes of fostering meaningful positive change.  I value both 9front 
and 9legacy but choose to remain neutral and refrain from taking sides.  In my 
view, there's no advantage in picking sides, particularly among us 9fans.  The 
need for collaboration seems great, I'm astonished that more collaboration 
hasn't happened over the years.

Kind regards,
Vester

On Thu, May 9, 2024, at 05:10, hiro wrote:
> vester, why do you recommend all these things so overly
> methodologically that are all already a reality in the 9front
> community? are you a bot?
>
> On Wed, May 8, 2024 at 9:18 PM  wrote:
>>
>> Dear Members of the 9legacy and 9front Communities,
>>
>> This message is intended to share thoughts on potential improvements to 
>> collaborative processes between systems. The aim is to foster an environment 
>> that encourages ongoing enhancement and mutual support.
>>
>> Community Efforts
>> Appreciation is extended to all community members for their dedication in 
>> updating and maintaining these systems. Their efforts are vital to 
>> collective progress.
>>
>> Community Dialogue
>> An open forum for all members to share insights, discuss challenges, and 
>> propose solutions related to system updates and integration efforts could 
>> prove beneficial. Such dialogue can help better understand different 
>> perspectives and formulate effective strategies collaboratively.
>>
>> Collaborative Working Group
>> The creation of a working group to address specific technical challenges, 
>> such as integrating the dp9ik security protocol, could facilitate smoother 
>> and more efficient integration. Interested members might consider 
>> participating in such a group.
>>
>> Transparency in Decision-Making
>> Improving the transparency of decision-making processes is a goal. Sharing 
>> regular informational updates could keep everyone informed about the 
>> progress and decisions that affect both communities.
>>
>> Inclusive Decision-Making Processes
>> Exploring ways to ensure that decision-making processes reflect the 
>> community's needs and inputs is under consideration. Contributions on how to 
>> achieve this are highly valued.
>>
>> Recognition Program
>> Recognizing the hard work and achievements of community members is 
>> important. Plans to introduce a recognition program that highlights 
>> significant contributions and successes are being explored.
>>
>> Addressing Historical Concerns
>> Dedicating time to openly discuss historical concerns is crucial for moving 
>> forward. This could help reconcile and strengthen community ties.
>>
>> Feedback on these suggestions and potential interest in participating in 
>> these initiatives is invited. Contributions from community members are 
>> invaluable and will help shape the direction of collaborative efforts.
>>
>> Thank you for your engagement and commitment to the community.
>>
>> Best regards,
>> Vester
>>
>>
>> On Thu, May 9, 2024, at 01:29, Jacob Moody wrote:
>> > On 5/8/24 11:06, Lucio De Re wrote:
>> >> There is much I would like to explain, but the problem I am attempting to 
>> >> solve ought to have an obvious answer that I am clearly missing.
>> >>
>> >> I can't seem to get a 9front workstation to mount a networked 9legacy 
>> >> fossil service. The FS is a fairly pristine 9legacy installation, on a 
>> >> somewhat old 386 platform. I did need to tweak various parameters on both 
>> >> side, but eventually I got to the point where both hosts declare that the 
>> >> connection has been established; now on the 9front workstation I get the 
>> >> message
>> >> "srv net!192.96.33.148!9fs: mount failed: fossil authCheck: auth 
>> >> protocol not finished"
>> >> I suspect the culprit is the lack of the newer "dp9ik" security on 
>> >> 9legacy, in which case it would be helpful to know how to work around 
>> >> that.
>> >
>> > Probably. Why not just temporarily disable auth checks for the fossil
>> > 9legacy machine?
>> > Or perhaps just take a disk/mkfs backup and tar that. You really have
>> > chosen the most painful way of accomplishing this (which you seem to
>> > acknowledge).
>> > Or just exportfs the root? There are so many ways of just getting the
>> > files.
>> >
>> >>
>> >> Why am I mixing my platforms like this? Because the hardware on which I 
>> >> am attempting to recover a rather large historical file system is split 
>> >> between IDE and SATA and I have no hardware that can handle both disk 
>> >> modes and I need to move information between the two media types.

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

[hiro]

vester, why do you recommend all these things so overly
methodologically that are all already a reality in the 9front
community? are you a bot?

On Wed, May 8, 2024 at 9:18 PM  wrote:
>
> Dear Members of the 9legacy and 9front Communities,
>
> This message is intended to share thoughts on potential improvements to 
> collaborative processes between systems. The aim is to foster an environment 
> that encourages ongoing enhancement and mutual support.
>
> Community Efforts
> Appreciation is extended to all community members for their dedication in 
> updating and maintaining these systems. Their efforts are vital to collective 
> progress.
>
> Community Dialogue
> An open forum for all members to share insights, discuss challenges, and 
> propose solutions related to system updates and integration efforts could 
> prove beneficial. Such dialogue can help better understand different 
> perspectives and formulate effective strategies collaboratively.
>
> Collaborative Working Group
> The creation of a working group to address specific technical challenges, 
> such as integrating the dp9ik security protocol, could facilitate smoother 
> and more efficient integration. Interested members might consider 
> participating in such a group.
>
> Transparency in Decision-Making
> Improving the transparency of decision-making processes is a goal. Sharing 
> regular informational updates could keep everyone informed about the progress 
> and decisions that affect both communities.
>
> Inclusive Decision-Making Processes
> Exploring ways to ensure that decision-making processes reflect the 
> community's needs and inputs is under consideration. Contributions on how to 
> achieve this are highly valued.
>
> Recognition Program
> Recognizing the hard work and achievements of community members is important. 
> Plans to introduce a recognition program that highlights significant 
> contributions and successes are being explored.
>
> Addressing Historical Concerns
> Dedicating time to openly discuss historical concerns is crucial for moving 
> forward. This could help reconcile and strengthen community ties.
>
> Feedback on these suggestions and potential interest in participating in 
> these initiatives is invited. Contributions from community members are 
> invaluable and will help shape the direction of collaborative efforts.
>
> Thank you for your engagement and commitment to the community.
>
> Best regards,
> Vester
>
>
> On Thu, May 9, 2024, at 01:29, Jacob Moody wrote:
> > On 5/8/24 11:06, Lucio De Re wrote:
> >> There is much I would like to explain, but the problem I am attempting to 
> >> solve ought to have an obvious answer that I am clearly missing.
> >>
> >> I can't seem to get a 9front workstation to mount a networked 9legacy 
> >> fossil service. The FS is a fairly pristine 9legacy installation, on a 
> >> somewhat old 386 platform. I did need to tweak various parameters on both 
> >> side, but eventually I got to the point where both hosts declare that the 
> >> connection has been established; now on the 9front workstation I get the 
> >> message
> >> "srv net!192.96.33.148!9fs: mount failed: fossil authCheck: auth 
> >> protocol not finished"
> >> I suspect the culprit is the lack of the newer "dp9ik" security on 
> >> 9legacy, in which case it would be helpful to know how to work around that.
> >
> > Probably. Why not just temporarily disable auth checks for the fossil
> > 9legacy machine?
> > Or perhaps just take a disk/mkfs backup and tar that. You really have
> > chosen the most painful way of accomplishing this (which you seem to
> > acknowledge).
> > Or just exportfs the root? There are so many ways of just getting the
> > files.
> >
> >>
> >> Why am I mixing my platforms like this? Because the hardware on which I am 
> >> attempting to recover a rather large historical file system is split 
> >> between IDE and SATA and I have no hardware that can handle both disk 
> >> modes and I need to move information between the two media types. I am not 
> >> describing all the dead ends I tried, incidentally, that would take too 
> >> long and really expose my limited understanding.
> >>
> >> It took almost a day to copy the Fossil cache (or lose a lot of the most 
> >> recent changes) and now I need (or at least want) to update the default 
> >> boot ("arenas") Venti configuration on a SATA drive which I can only 
> >> access on hardware I can't install 9legacy on. It's complicated and I'm 
> >> sure there are people here who would not find this so daunting, but that's 
> >> where I am at. To be precise, I need to change the Fossil default 
> >> configuration (in the "fossil" cache) so it points to the correct Venti
> >> arenas. I'll deal with the analogous Venti situation when I get past the 
> >> total absence of Fossil tools on 9front.
> >>
> >> I guess I can port fossil/conf to 9front, but I'm not sure I have the 
> >> stomach to try that. Maybe now that I have raised the possibility...
> >
> > It so

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

[vester . thacker]

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 c

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

[Jacob Moody]

On 5/8/24 11:06, Lucio De Re wrote:
> There is much I would like to explain, but the problem I am attempting to 
> solve ought to have an obvious answer that I am clearly missing.
> 
> I can't seem to get a 9front workstation to mount a networked 9legacy fossil 
> service. The FS is a fairly pristine 9legacy installation, on a somewhat old 
> 386 platform. I did need to tweak various parameters on both side, but 
> eventually I got to the point where both hosts declare that the connection 
> has been established; now on the 9front workstation I get the message
>     "srv net!192.96.33.148!9fs: mount failed: fossil authCheck: auth protocol 
> not finished"
> I suspect the culprit is the lack of the newer "dp9ik" security on 9legacy, 
> in which case it would be helpful to know how to work around that.

Probably. Why not just temporarily disable auth checks for the fossil 9legacy 
machine?
Or perhaps just take a disk/mkfs backup and tar that. You really have chosen 
the most painful way of accomplishing this (which you seem to acknowledge).
Or just exportfs the root? There are so many ways of just getting the files.

> 
> Why am I mixing my platforms like this? Because the hardware on which I am 
> attempting to recover a rather large historical file system is split between 
> IDE and SATA and I have no hardware that can handle both disk modes and I 
> need to move information between the two media types. I am not describing all 
> the dead ends I tried, incidentally, that would take too long and really 
> expose my limited understanding.
> 
> It took almost a day to copy the Fossil cache (or lose a lot of the most 
> recent changes) and now I need (or at least want) to update the default boot 
> ("arenas") Venti configuration on a SATA drive which I can only access on 
> hardware I can't install 9legacy on. It's complicated and I'm sure there are 
> people here who would not find this so daunting, but that's where I am at. To 
> be precise, I need to change the Fossil default configuration (in the 
> "fossil" cache) so it points to the correct Venti
> arenas. I'll deal with the analogous Venti situation when I get past the 
> total absence of Fossil tools on 9front.
> 
> I guess I can port fossil/conf to 9front, but I'm not sure I have the stomach 
> to try that. Maybe now that I have raised the possibility...

It sound like you're trying to make this someone else's problem.
Being stuck in a hardware pickle when there are ample existing software 
solutions is not
a good reason to ask someone else to go out of their way to write software.

Fossil can be pulled in largely without modifications as I understand it,
I don't run fossil but some people in the 9front community do and it does
not appear to me that they've had issues with continuing to have it work
(other then fossil bugs itself).

> 
> I managed to share the Fossil cache through a NetBSD server providing u9fs 
> services, but that host does not have the capacity to store the Venti arenas, 
> nor can I really justify spending the amount of time it would take to pass it 
> between the 9legacy and 9front devices via NetBSD, no matter how I try to 
> arrange that. It does baffle me, though, that a NetBSD intermediary is more 
> competent than the two "native" platforms.

Are you blaming us for moving on from AES 53 bit keys that can be brute forced 
in an afternoon?
I have tried to open a dialogue for getting dp9ik on 9legacy a couple times 
now, when I had brought it
up I am told to write the patch. Something about being asked to spend the work 
to write a patch for 9legacy given
the historical context of why 9front exists does not sit right with me. So it 
wont be me, sorry.
Sure it sucks that things have drifted, but all our code is there, neatly 
organized out in to commits, if someone
wants to import our work it is readily available. However something tells me 
most people are just going to use 9front as is.


Good luck,
moody


--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M6a4b734a4d1906cf86d9da88
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription