Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)

[vic . thacker]

Hi Hiro et al,

I view Plan 9 4th Edition as a version that remains largely unchanged, serving 
as a snapshot in time, while 9legacy represents an active, distinct 
distribution. Conversely, 9front is a fork that has evolved significantly from 
Plan 9 4th Edition, making considerable advancements in recent years.

I appreciate the push for modernization with 9front, but I also see value in 
maintaining support for older versions like Plan 9 4th Edition and 9legacy.  
Living in Japan, I have access to inexpensive hardware—local computer resellers 
often offer older computers for as little as 2,000 yen each (e.g. $12.85 USD).  
For about 8,000 yen, it is possible to set up a functional Plan 9 system.  This 
isn’t about leading the charge with the latest and greatest OS; it's about the 
joy of tinkering and making the most of accessible resources.  For hobbyists 
like myself, the ability to use and experiment with older systems is 
invaluable.  Maintaining some level of support or compatibility in the 
community can enhance the inclusiveness and experimental spirit that is 
fundamental to Plan 9’s ethos.

Maintaining updates and compatibility between Plan 9 4th Edition, 9legacy, and 
9front can provide several benefits, especially in a diverse community like 
that of Plan 9.  Here are some of the key advantages:

(1) Broader Hardware Support:  By keeping Plan 9 4th Edition and 9legacy 
updated, users who rely on older or less common hardware configurations that 
may not be fully supported by 9front can still benefit from updates and 
improvements.  This is particularly useful in academic or hobbyist settings 
where newer hardware may not be readily available or economically feasible.

(2) Incremental Upgrades:  Some users may prefer an incremental approach to 
system upgrades rather than a complete switch to a newer version. Integrating 
changes from 9front into 9legacy and Plan 9 4th Edition allows these users to 
benefit from specific enhancements without the need to overhaul their entire 
system setup.

(3) Community Engagement:  Keeping these versions updated helps engage 
different segments of the Plan 9 community.  It acknowledges the needs and 
preferences of those who might prefer the familiarity of 9legacy or Plan 9 4th 
Edition, fostering a more inclusive and vibrant community.

(4) Preservation of Educational and Historical Value:  Plan 9 has significant 
educational and historical importance in the field of operating systems.  
Maintaining and updating older versions ensures that this legacy is preserved, 
allowing new generations of students and enthusiasts to learn from and 
experiment with these systems.

(5) Security and Stability:  Regular updates can address security 
vulnerabilities and fix bugs across all versions, ensuring that even older 
deployments remain secure and stable.  This is crucial for maintaining the 
integrity and usability of the systems over time.

(6) Customization:  Some users or organizations might have customized their 
systems based on older versions of Plan 9.  Keeping these systems updated with 
changes from 9front can provide a path for these custom setups to receive new 
features and improvements while maintaining their unique configurations.

Overall, the integration of updates across different versions of Plan 9 can 
help keep the system modern, secure, and accessible to a wide range of users, 
enhancing both its utility and appeal.

In embracing both the new and preserving the old, we not only honor the rich 
legacy of Plan 9 but also ensure its relevance and accessibility for all users, 
regardless of their hardware or specific needs. By updating 9legacy and Plan 9 
4th Edition alongside 9front, we foster a community that values progress and 
innovation while respecting and supporting the diverse ways in which people 
interact with our beloved operating system. Together, let's continue to build a 
welcoming and vibrant Plan 9 community that thrives on both change and 
tradition.

Kind regards,
Vester "Vic" Thacker


On Fri, May 10, 2024, at 04:50, hiro 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 

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 

Re: [9fans] Re: Raspberry pi with a largish screen?

[a]

Thank you, this exact set of lines ends up being exactly right for driving my 
LG 27UK850-W at 1/4 resolution (native resolution would need some work put into 
the window system and fonts to be more comfortable). I don't believe I'd tried 
the max_framebuffer_* or hdmi_pixel_freq_limit settings before.
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcb982002ae12827e-Madc51a7b43040886c75da40c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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 

Re: [9fans] Re: Raspberry pi with a largish screen?

[Garry Taylor]

I'm using a Lenovo C32Q-20 with that config.txt and it works perfectly.

On Thu, May 9, 2024 at 5:55 AM  wrote:

> Thanks, that’s promising. What’s your monitor?
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcb982002ae12827e-M9bf78cfd5f791da4bb5d60c0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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