Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
On Aug 4, 2024, at 10:33 PM, o...@eigenstate.org wrote: > > Quoth Bakul Shah via 9fans <9fans@9fans.net>: >> >> Looks like an opportunity to update upas (or Erik Quanstrom's nupas) :-) >> AFAIK neither has support for filtering on the "From" line. > > take a look at upas/filter -- you could do something like: > >/bin/upas/filter -h $1 $2 'From: kalona.ayeli...@fastmail.us' /dev/null > > in your pipeto file I stand corrected. Thanks! [I never got around to using upas seriously]. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M1255b2346bff5bd0618be841 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
On Aug 4, 2024, at 4:40 PM, Michael Grunditz wrote: > > I wonder if there is a email client with some kind of killfile like many old > usenet clients have. Looks like an opportunity to update upas (or Erik Quanstrom's nupas) :-) AFAIK neither has support for filtering on the "From" line. But since you use gmail, you can set up a filter for this on the https://mail.google.com/mail/u/0/#settings/filters page. Not as easy as a killfile though! Or you can just ride out this storm in a teacup. ---------- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M2ee1f86ac98791b87a5e3920 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
On Sun, Aug 04, 2024 at 02:50:55PM -0400, kalona.ayeli...@fastmail.us wrote:
> I am sharing my perspective, but it seems you disagree with my viewpoint and
> want to label me negatively. Is this how your group handles differing
> opinions?
This approach to community engagement is called "DARVO." After you
attacked the list with spambot, you:
D - Denied any harm ("I'm just trying to help!")
A - Attacked the people asking for you to stop ("You're so mean!")
RVO - Reversed Victim and Offender roles ("Is this how you treat new
people?")
It's a common pattern in abusive people, probably because it's so
effective. But it doesn't work as well when it's executed so poorly,
like most of your messages.
Better luck next time,
khm
------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M896048966f1d4f416e769150
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
On Sun, Aug 04, 2024 at 02:27:58PM -0400, kalona.ayeli...@fastmail.us wrote: > From a newcomer's perspective, it feels like dealing with a cult run by scam > artists. It seems someone wants to profit from me by selling books on Amazon, > like a multi-level marketing group. People say others here are on a spectrum, > but it feels more like psychosis, with a loss of contact with reality. I > really feel like I'm being gaslighted. I might seem like a troll, but you > don't understand how you appear to others. > > I am looking for a Plan 9 group that doesn't behave this way. If anyone is > interested, let's form a group that isn't cult-like, that just wants to help > newcomers and not prey on them. Why are you now pretending to be a newcomer? Assuming a false identity is against the Topicbox terms of service. I recommend you knock it off. khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M82cb14c20b4f616d665c7d13 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
On August 4, 2024 7:01:11 p.m. GMT+09:00, kalona.ayeli...@fastmail.us wrote: >I am not the only one with Plan 9 issues. Here is another person with similar >problems: https://driusan.github.io/plan9.html. Wow. I don't know how you found that. Please leave the me of 10 years ago out of this thread while I decide if I should delete that site or leave it as a historical artifact. - Dave ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M26d091ea16498b4e142db497 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
On Sunday, 4 August 2024, at 1:09 AM, Bakul Shah wrote: > As we used to say in the Usenet era, \|||/ (o o) ,ooO--(_)---. | Please| | don't feed the | | TROLL's ! | '--Ooo--' |___|___| ooO Ooo Deny them attention and they will go away eventually. On Sunday, 4 August 2024, at 12:42 AM, ori wrote: > In light of the low quality of posts on this list, the p9f set up a new, moderated, 9users list, and sent initial invites to people who attended iwp9. Anyone currently on the list can propose new invites. AI slop will not be tolerated there. Nice to know that there now exists a list for selected members. What follows next ? ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M060f029eb0503fef2a389c60 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
As we used to say in the Usenet era, \|||/ (o o) ,ooO--(_)---. | Please| | don't feed the | | TROLL's ! | '--Ooo--' |__|__| ooO Ooo Deny them attention and they will go away eventually. On Aug 3, 2024, at 3:40 PM, o...@eigenstate.org wrote: > > In light of the low quality of posts on this list, the p9f set up > a new, moderated, 9users list, and sent initial invites to people > who attended iwp9. > > Anyone currently on the list can propose new invites. > > AI slop will not be tolerated there. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M9228726d2782fc0a9005796c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Moving files to a USB thumb drive.
Thank you very much, Lyndon and Ori, for your help. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4f67493d8e7306fc-M2d5d01085ebe24972922d24d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Moving files to a USB thumb drive.
I want to copy text files from a Windows PC to a Plan 9 computer using a USB thumb drive. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4f67493d8e7306fc-Me9bbed315a4b8fd586d9fb5f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Moving files to a USB thumb drive.
Hi 9fans, How do I set up and manage external storage devices in Plan 9? I would like to attach a USB thumb drive to move files. -Jas -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4f67493d8e7306fc-Mde9490dc851a0dee1678f4c0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] venti/mirrorarenas usage
On Sat, Aug 03, 2024 at 02:27:14PM -0400, kalona.ayeli...@fastmail.us wrote: > khm, you can think whatever you like. If true, then all you can do is let it > be. I don't need your permission to think whatever I like, and there are tons of other things I can do, like informing you that you're a useless source of misinformation. > > My point is accurate information should be easy to find and read, like in a > wiki. Mailing lists are for discussions, not for searching answers. It’s > ideal when discussions lead to action items that improve the overall state. > Here's an action item: go start a wiki and put your LLM content there. That way, people who don't want their computers to work can easily find it, you can feel like you've contributed to anything, and the mailing list will have less spam from doddering fools. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tca0eb0fbb2404e31-Mdbc30492c946960e211820b5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] venti/mirrorarenas usage
On Sat, Aug 03, 2024 at 02:10:43PM -0400, kalona.ayeli...@fastmail.us wrote: > > cron '*/5 * * * * fs(3) -m /dev/sdE0/arena /dev/sdE1/arena' > When you generate bullshit with an LLM and then post it without reading it, nobody thinks the LLM is stupid. We think *you* are stupid. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tca0eb0fbb2404e31-Me34ea25d97634623454450c7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: How do you control screen brightness?
Thank you, plan6. -Jas -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T0977db5668cc3d9f-M1d84ad1ec99e7f7065299560 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] How do you control screen brightness?
Hi 9fans, How do you control screen brightness? -Jas -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T0977db5668cc3d9f-M988402b763a5368db078a6d1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] How do you handle long paths in acme?
In p9 from user space I make ample use of symbolic links. /robby schrieb am Do., 1. Aug. 2024, 18:50: > Basically, the title says it. The projects I work on reside in a deeply > nested hierarchy, like this: > > /Users/azkhabibulin/gitlab.example.com/team/project > > This does not seem to be really big, but when I open a lot of files they > all have this same prefix, which is somewhat off-putting. The header also > takes two lines. > > Is there an idiomatic approach to relieve this pain? > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/T3c29ca5315bf5c86-Madda13b21ed65794c9d67845> > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T3c29ca5315bf5c86-M050e837a0a29b759e10de6e3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: venti/mirrorarenas usage
On Wed, Jul 31, 2024 at 10:34:29PM -0400, kalona.ayeli...@fastmail.us wrote: > I'm working to find an answer for Marco despite hardware issues. I hope to > replace my mainboard when funds allow. Trying is better than not trying. If > Marco gets a fair answer, we're done. Until then, let's get him closer. > Attacking someone for trying to help is surprising. I thought 9fans was a > place to both receive and give help. If others attended to Marco as much as > they do me, perhaps he'd have an answer. The point is to help Marco if > possible. If you can't help, that's fine. If you're willing to help, please > do. > > If Marco has already written to Geoff or Sape and received an answer, it > would be good to post it here and share the knowledge. You forgot to attach a copyright notice to your entitled whining. Hope this receives and gives help, khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tca0eb0fbb2404e31-M154cb32c265136c44d486e43 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: venti/mirrorarenas usage
On Tue, Jul 30, 2024 at 09:33:31PM -0400, kalona.ayeli...@fastmail.us wrote: > I did all the work myself. If you choose to be dismissive, that is your > prerogative. The original question remains unanswered; you have only > complained and criticized, doing little to address it. Vic? Is that you? There was no 'work.' You didn't ask a question. You made unhelpful demands that other people bolster your shitty LLM output on their own time. That is not how peer review works. Specifically, you are nobody here's peer. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tca0eb0fbb2404e31-M90030c8ba87daa73678709ee Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: venti/mirrorarenas usage
On Tue, Jul 30, 2024 at 08:09:44PM -0400, kalona.ayeli...@fastmail.us wrote: > Please elaborate on any issues you find in my work and explain where I am > wrong. Why? So you can type that into an LLM prompt as well? kalona ayeliski are supposed to torture dying people, not computer mailing lists -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tca0eb0fbb2404e31-M3d892db19a6c4c857438a6dc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Cherokee [Re: [9fans] Re: venti/mirrorarenas usage)]
Okay, you successfully sniped me. What does your Cherokee translate to in English? > ᎦᎦᏐᎩ ᏚᎵᏍᏗ, > ᏓᏟᎶᏍᏛ ᎢᎦᏍᏗᎢ, > ᏴᏫ ᎤᏍᏗᏁᎸ.* ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf51f328550395a72-M64eceb645b5051605d40b95d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] mk results in rc: suicide:
o...@eigenstate.org wrote: ori: asm()/casm() shows assembly. The PC you crashed on ori: is 0xb5d9, which happens to be in the middle of ori: this comparison instruction: ori: ori: > Readdir+0x2c 0xb5d8 CMPLdir+0x8(SB)(CX*1),AX ori: > Readdir+0x33 0xb5df JNE Readdir+0xd8(SB) ori: ori: which tells me whatever jumped into the code here ori: is junk; either a bad function pointer, a flipped ori: bit in your binary, or something else. At this point, this is really sounding like a hardware issue. I'm betting it only happens after the build's been going for a while. My bet would be it's heat-related, and could be in the CPU or in memory, leaning towards CPU. Check your case and CPU fans, blow out dust, make sure everything's firmly seated, etc. If you built the machine yourself, in particular installing the CPU, did you use thermal paste between the CPU and the heatsink? Reseat anything that's socketed, including cables. Also, make sure that there's a free air path to and from all vents in the case. Also, check the BIOS logs and such for temperature excursions, assuming your BIOS reports such things. Dworkin ---------- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T68f44cf88ca61ff3-Mc77820658e37f59385b949d6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] mk results in rc: suicide:
To avoid such problems while rebuilding kernels + libraries + commands you can use namespaces or some tricks as in http://9p.io/wiki/plan9/compiling_kernels/index.html There is also divergefs for plan9 which I personally don't use but you can give it a try. Avoid recompiling your kernel, libraries and commands directly in /sys/src. Good luck -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T68f44cf88ca61ff3-M60506689a3962f863de10655 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] mk results in rc: suicide:
I made this experience some time ago and suspect one of your static libraries didn't get rebuild. To verify this have a look in your /386/lib folder and verify the timestamp of your libraries. If you find the culprit manually change to that library and do "mk nuke ; mk ; mk install". I would guess you tried to add a system call to the kernel and your libc wasn't rebuild - but thats only a guess. ---------- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T68f44cf88ca61ff3-M87a7792e7cf56899ef10fb12 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Fri, May 17, 2024 at 07:32:18AM -0400, pl...@room3420.net wrote: > an other interesting reading : > https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card I love this article very much. Unhelpful, bossy blowhards should experience exactly these emotions. My favorite part was the accusation of "cancel culture," which I have learned is Boomer code for "accountability." They really hate that shit! If 9front has constructed a culture where someone who calls themselves "Innovator Harnessing the Power of Open Source: Transforming Businesses, Empowering Solutions" does not feel welcome, then I am profoundly satsified with that culture, and commend everyone involved in its creation. Anyway, just for the record, nobody in the 9front project has any ill will toward 9legacy. Technical concerns like p9sk1, yes, but everyone agrees there should be *more* Plan 9 out there, not less. We keep suggesting that people fork 9front as well, and make 9front Suit And Tie Edition, Empowering Harnessed Transformative Innovations, with all of the technical goodies and none of the humor or fun, but nobody seems to have the drive to make that happen. If anyone wants help bootstrapping such a project, please let me know and I'll help however I can. The existence of something like that might help deflect all the unfunded mandates people keep trying to demand of the 9front project, and create a nice home for the sorts of people whose primary qualifications are that they like to watch and they've been watching for decades. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M4bc8405899fcc7a94bd431ef Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Fri, May 17, 2024 at 02:22:01PM +, Samuel Reader via 9fans wrote: > The 2nd draft is out. I've made some corrections as mentioned by others, and > I have added those who have helped to the acknowledgements. This draft is > only for those that are interested in the content. If you are not interested > please disregard. I confirmed the model was trained on 9front resources, > including git history. > > https://link.storjshare.io/s/juh72ktckqt2mpdaeebljo7mve2q/revitalizing-project/RevitalizingPlan9.pdf This document is full of lies, and I don't think you trained a model at all. I'd wager you only applied an inference step, and from an inexpensive model at that. Your claim that you "confirmed the model was trained" just tells me you know as little about large-language models as you do about Plan 9: you're the wrong person for this job. This is not a meaningful contribution to the literature. Nobody will be helped by this. Samuel Reader was an American hero who fought with John Brown. If you share a name with such a famous writer, maybe you can take inspiration from him and anctually try to write something. khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M524e78627dc57f60f74081ab Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
The 2nd draft is out. I've made some corrections as mentioned by others, and I have added those who have helped to the acknowledgements. This draft is only for those that are interested in the content. If you are not interested please disregard. I confirmed the model was trained on 9front resources, including git history. https://link.storjshare.io/s/juh72ktckqt2mpdaeebljo7mve2q/revitalizing-project/RevitalizingPlan9.pdf I will not continue to post the URL and comment. If you like to help with corrections please do. I'll continue to work on the document until it is as accurate as possible. I can be reached at samuel.rea...@proton.me. Thank you. Sent with [Proton Mail](https://proton.me/) secure email. On Friday, May 17th, 2024 at 10:50 PM, Clout Tolstoy wrote: > It's very clear at this point Vic Has never read the 9front FAQ or perhaps > any other documentation provided by 9front. > > Some of the things they ask from the community seem I'll informed because of > that and other reasons (like asking for GPU drivers from the community for > Nvidia or AMD is out of context of what an open source community can provide) > > Another won't fix issue is that it seems that they're unsure if they can port > some 9front code for 9legacy because it might not survive a closed source > audit for resale. > > It doesn't seem they want to bring value to the project and just take control. > > Am I missing something? > > On Fri, May 17, 2024, 6:33 AM hiro <23h...@gmail.com> wrote: > >> Great that you're building AI prompts instead of operating systems. >> More trollfactories for "cyber" "warfare" will mean that all our >> trolls will be out of a job soon. Vic, what you post on linkedin >> sounds mainly like a big "fuck you" towards 9front, not a fair answer >> given the technical contributions brought here by others. >> >> Again, please send patches, not propaganda. > > [9fans](https://9fans.topicbox.com/latest) / 9fans / see > [discussions](https://9fans.topicbox.com/groups/9fans) + > [participants](https://9fans.topicbox.com/groups/9fans/members) + [delivery > options](https://9fans.topicbox.com/groups/9fans/subscription) > [Permalink](https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me91e0ebfcfac416764fad981) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M6fc7012e78a90b1230049d6a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
It is only a first draft, and it is not a finished product. I'll correct the mistakes found. Thank you for the kind feedback. Sent with Proton Mail secure email. On Friday, May 17th, 2024 at 9:31 PM, qwx via 9fans <9fans@9fans.net> wrote: > On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote: > > > an other interesting reading : > > https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card > > > I'm appalled and frankly furious about this article. It's blatant > slander which can affect me in my professional career. I'm a phD > candidate and my work is based on Plan 9 and developed on 9front; I > was going to present it at iwp9 but could not once the venue was > changed as it rendered it incompatible with my time table. > > The article lacks references to many of its claims, and the remaining > ones directly contradict its points. The Register article is even > linked incorrectly. A superficial reader would not bother to try to > follow the links or find the article. For me this is clearly > malicious attention-seeking. > > Regarding the pdf posted earlier[1], almost all of it is factually > incorrect. As an example, there are no drivers for modern nvidia or > amd chips or bluetooth. Many of the "system calls" listed in the pdf > are not system calls (proccreate) or simply don't exit (vlongtime), > and so on. In addition, it is trivial to recreate the same content > with a query like the following: `Generate a detailed book-style > document called "Revitalizing Plan 9: integrating modern enhacements > into 9legacy" detailing all improvements introduced in 9front compared > to 9legacy'. See for yourself in an excerpt below my email. > > I don't understand what the goal here is. All this post and pdf > accomplish is spreading misinformation, promoting cancel culture, > fostering community division and discouraging collaboration with > 9front and even 9legacy, directly contradicting both Vic's claims and > that of those who have sided with him in the thread. At this point, > use of chatgpt in this thread is blatant and harmful. Please stop. > > Thanks, > qwx > > [1] > https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf > --- > > Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy > Introduction > Plan 9 from Bell Labs has long been recognized for its innovative approach to > distributed computing. However, as hardware and software technologies > advanced, the need for a more modernized version of Plan 9 became apparent. > This need led to the development of 9front, a fork of Plan 9 that > incorporates numerous enhancements and updates, surpassing 9legacy in several > key areas. This document details these improvements, offering a comprehensive > comparison of the advancements introduced in 9front over 9legacy. > > Chapter 1: Graphics and Video Drivers > Improved Graphics Hardware Support > One of the most significant areas of enhancement in 9front is its support for > modern graphics hardware. This includes: > > Support for Newer GPUs: 9front integrates drivers for the latest GPU models, > ensuring compatibility with modern graphics cards from manufacturers like > NVIDIA and AMD. > Enhanced Frame Buffer Device: The frame buffer device driver has been > optimized for better performance, providing smoother graphics rendering and > faster display updates. > Broad Chipset Compatibility: 9front supports a wider range of graphics > chipsets, allowing it to run on diverse hardware configurations with improved > stability and performance. > Advanced Video Handling > 9front has made considerable strides in handling video output, particularly > with high-resolution and multi-monitor setups. > > High-Resolution Display Support: Enhanced support for high-resolution > displays, including 4K monitors, ensures crisp and clear visuals. > Multi-Monitor Configurations: Improved multi-monitor support allows users to > extend their desktop across multiple screens seamlessly, enhancing > productivity and usability. > > Chapter 2: Networking > [...] -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mb2f857e131344e3b02d181db Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Fri May 17 13:33:21 +0200 2024, pl...@room3420.net wrote: > an other interesting reading : > https://www.linkedin.com/pulse/critical-analysis-9front-community-conflict-vester-thacker-htt3f?trk=article-ssr-frontend-pulse_more-articles_related-content-card I'm appalled and frankly furious about this article. It's blatant slander which can affect me in my professional career. I'm a phD candidate and my work is based on Plan 9 and developed on 9front; I was going to present it at iwp9 but could not once the venue was changed as it rendered it incompatible with my time table. The article lacks references to many of its claims, and the remaining ones directly contradict its points. The Register article is even linked incorrectly. A superficial reader would not bother to try to follow the links or find the article. For me this is clearly malicious attention-seeking. Regarding the pdf posted earlier[1], almost all of it is factually incorrect. As an example, there are no drivers for modern nvidia or amd chips or bluetooth. Many of the "system calls" listed in the pdf are not system calls (proccreate) or simply don't exit (vlongtime), and so on. In addition, it is trivial to recreate the same content with a query like the following: `Generate a detailed book-style document called "Revitalizing Plan 9: integrating modern enhacements into 9legacy" detailing all improvements introduced in 9front compared to 9legacy'. See for yourself in an excerpt below my email. I don't understand what the goal here is. All this post and pdf accomplish is spreading misinformation, promoting cancel culture, fostering community division and discouraging collaboration with 9front and even 9legacy, directly contradicting both Vic's claims and that of those who have sided with him in the thread. At this point, use of chatgpt in this thread is blatant and harmful. Please stop. Thanks, qwx [1] https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf --- Revitalizing Plan 9: Integrating Modern Enhancements into 9legacy Introduction Plan 9 from Bell Labs has long been recognized for its innovative approach to distributed computing. However, as hardware and software technologies advanced, the need for a more modernized version of Plan 9 became apparent. This need led to the development of 9front, a fork of Plan 9 that incorporates numerous enhancements and updates, surpassing 9legacy in several key areas. This document details these improvements, offering a comprehensive comparison of the advancements introduced in 9front over 9legacy. Chapter 1: Graphics and Video Drivers Improved Graphics Hardware Support One of the most significant areas of enhancement in 9front is its support for modern graphics hardware. This includes: Support for Newer GPUs: 9front integrates drivers for the latest GPU models, ensuring compatibility with modern graphics cards from manufacturers like NVIDIA and AMD. Enhanced Frame Buffer Device: The frame buffer device driver has been optimized for better performance, providing smoother graphics rendering and faster display updates. Broad Chipset Compatibility: 9front supports a wider range of graphics chipsets, allowing it to run on diverse hardware configurations with improved stability and performance. Advanced Video Handling 9front has made considerable strides in handling video output, particularly with high-resolution and multi-monitor setups. High-Resolution Display Support: Enhanced support for high-resolution displays, including 4K monitors, ensures crisp and clear visuals. Multi-Monitor Configurations: Improved multi-monitor support allows users to extend their desktop across multiple screens seamlessly, enhancing productivity and usability. Chapter 2: Networking [...] -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M680864af80eddaf3fa87c1bf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
I've included 9front git history. Here is the results. "I reviewed the 9front Git repository to confirm details about the differences between 9front and 9legacy. Here are some key points: 1. *Syscall Changes*: As mentioned, 9front did not add new syscalls beyond the 'nsec' syscall, which 9legacy had already included. This syscall was needed to run Go binaries, although it was deprecated upon import. 2. *Kernel and Driver Enhancements*: 9front has made numerous improvements to the kernel and drivers. For example, they have added support for new hardware, such as the i219-LM Ethernet device, and improved existing drivers, like the virtio drivers for disk and Ethernet. 3. *Library Updates*: There have been updates to various libraries, such as lib9p, libsec, and libtags. These updates include bug fixes, performance enhancements, and new features like support for additional audio formats in libtags. 4. *Program Improvements*: Many user programs have seen enhancements and bug fixes. Notable examples include the acme editor, which received improvements from Plan9port, and the git suite, which has been updated to handle modern workflows more effectively. I reviewed the 9front Git repository to confirm details about the differences between 9front and 9legacy. Here are some key points: 5. *Syscall Changes*: As mentioned, 9front did not add new syscalls beyond the 'nsec' syscall, which 9legacy had already included. This syscall was needed to run Go binaries, although it was deprecated upon import. 6. *Kernel and Driver Enhancements*: 9front has made numerous improvements to the kernel and drivers. For example, they have added support for new hardware, such as the i219-LM Ethernet device, and improved existing drivers, like the virtio drivers for disk and Ethernet. 7. *Library Updates*: There have been updates to various libraries, such as lib9p, libsec, and libtags. These updates include bug fixes, performance enhancements, and new features like support for additional audio formats in libtags 8. *Program Improvements*: Many user programs have seen enhancements and bug fixes. Notable examples include the acme editor, which received improvements from Plan9port, and the git suite, which has been updated to handle modern workflows more effectively." ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Md2f5a6f7ba20e50e4320a235 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
Someone asked about the differences between 9front and 9legacy. This first draft provides a brief overview. https://link.storjshare.io/s/jx6tw46kfxskld45ussjek46ccpq/revitalizing-project/RevitalizingPlan9.pdf -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Me50dc0bbdf1af1428124189a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] RISC-V SoC available in Europe?
This presentation by Geoff Collyer "Plan 9 on 64-bit RISC-V" describes the work that has been done and mentions some hardware too. https://www.youtube.com/watch?v=EOg6UzSss2A ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T06718162d07aded1-Md1e867fe5ebfba04014a4211 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
On Wed, May 15, 2024 at 12:54:41PM -0400, Don Bailey wrote: > You handwave insults off by pretending like they aren't directed at the > exact person you're responding to :-) > > It's quite tiresome, and yet persistent. When else has it happened? Do I always do it? Are there firmware differences? Have you collected logs on the matter? I just don't think you have the data to back up this persistence claim. I'm generally pretty direct when I want to insult someone. It's not like there are meaningful consequences. If you feel like you were subject to the category of people I was describing, there's not much I can do about that, I guess. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M7a9282fa0e9032a09d8324c6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
On Wed, May 15, 2024 at 12:20:04PM -0400, Don Bailey wrote: > Again, this is a core example I'm talking about. In this email you've > called me gross, a bootlicker, etc, while ignoring my concerns and brushing > them off as "emotional". What part of "not directed at you, Don" did you fail to parse? What other entire clauses in my email messages have you failed to parse? This is a concerning development. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M25dc0e8c9d6985413fddbe2a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
On Wed, May 15, 2024 at 11:53:28AM -0400, Don Bailey wrote: > It's not gaslighting to ask for evidence. I was here, I remember the > complains with Fossil. But to what degree was that /actually/ Fossil? What > degree was it the configurations, the hardware, the firmware, the > consistency of management/usage? What investigations have gone into those > bits, as well. Setting up and running Fossil requires some knowledge and > maintenance. It is not unlike a classic Volkswagen. They run great if you > constantly bother with them. Believe me, it causes me great personal pain to say this, as a dude who just sold an 85 Jetta and must physically restrain himself from filling his yard with air-cooled Boxers, but "constantly bothering" and "running great" are mutually exclusive. > It isn't gaslighting to ask for those details. And if we are a code-centric > community, as we claim to be, point to the code that shows me it's > problematic and unstable. Have you found it? And I don't say that to be > coy... where can we demonstrably show that Fossil is volatile? What data > backs that up? It's great that you're willing to take bug reports seriously! If that had been the prevailing attitude on 9fans some years back, 9front probably wouldn't exist, much less exist without an in-tree Fossil. But your "point to the code" demand is not a great look. That *is* more like the old-school response to Fossil bug reports. In a way, deleting Fossil was the grandest test of all -- since it's gone, Fossil has stopped corrupting my data for sure. So there's the code causing the problem, at the granularity I consider worthwhile to pursue. Nobody owes you a scientific analysis. But if you (or anyone else) wants to put this stuff back in the 9front tree, it needs to be clearly demonstrated that it won't be a massive timesink and a distraction from the other, more fun filesystems we have. > So this is, again, the problem I have with what has occurred on this list. > Anything certain parties here disagree with is brushed off as trolling or > "gaslighting" or any other such term that rationalizes dismissal. Let's be > prescriptive, instead. No, not "anything." Specifically this Fossil nonsense. I don't know why so many people have deep emotional ties to Fossil, and I'm not really interested in finding out, but the years of hostility torward problem reports regarding Fossil, interspersed with "fixes" that weren't, led me (as an outsider) to conclude that nobody actually understands how the damn thing works, and if they do they're not interested in helping maintain it... and that alone is a great reason to delete the code. Anyway I don't understand why everyone is pissed about this. Anyone who wants Fossil can install it. If you want a 'canonical' Fossil, upload it somewhere and canonize it. Problem solved. As an aside, not directed at you, Don: this weird bootlicking where a commercial entity has to be involved to make something 'real' is pretty gross. We don't need bureaucracy to help one another, and I will never give a shit if someone's use of the software is for-profit or not, and I don't understand why it matters at all. khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-Mda8af7748da9f37163180f4d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
On Wed, May 15, 2024 at 11:20:48AM -0400, Don Bailey wrote:
> But please document them and provide rationale/evidence for their
removal.
You've been on this list a while. You should remember therefore that
Fossil was a *constant* topic of debate here for *years*.
Specifically, people kept reporting that Fossil had beshit their data,
and other people deemed that a skill issue and insisted Fossil was fine.
As bug fixes trickled out, Fossil continued to be fine, and people's
data kept getting corrupted. Maybe Fossil is fixed now! Maybe it
isn't! It's not worth finding out, and the situation was never helped
by the "there is no war in Ba Sing Se" crowd refusing to take bug
reports -- and actively attacking bug reporters.
So, the backstory of Fossil on 9fans is what led to it getting deleted.
Asking for 'evidence' is just more of the same gaslighting that happened
on this very list.
> How was the lack-of-stability tested? To what degree was it tested?
etc.
Not how it works. The burden of support is on the distributor. Part of
forking software is, when it breaks, people come knocking on your
door/mailing list/ircnet complaining that "your" software ate their
computer. We *knew* Fossil was unreliable, so continuing to ship it in
that state was idiotic. Removing it was an act of self-defense and/or
housekeeping, depending on how militant you like your metaphors.
Meanwhile, since the defossilization of 9front, Fossil itself continued
to receive attention. It sounds like the sp9sss dropped the ball on
coordinating some of that, but we are assured that Fossil is great now.
The problem is: we were assured Fossil was great then, too, especially
when it wasn't. Therefore it is the burden of the Chamber of Fossil
Fraternity Et Exuberance to prove that it is stable, and test it to such
a degree that it's worth considering again. The rest of us are tired of
driving in that circle.
You can even store it on our sources server, or put the code on our git9
repo host. We don't hate Fossil users. We just don't want to take
responsibility for it.
khm
------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-Me2967c4df12180934fde1181
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote: > Fine my dude, you don't have to call us Plan 9, you don't have to want to use > our code. However I ask that you be mindful in how you talk to new users and > don't assume that they have this same level of care for authenticity and "pure" code origins as you. You should read more carefully what I replied to the new user. It had nothing to do with licenses at all. I drew a path which spares him the frustrations during the time where he gets used to the system. And using 9vx is one way to set one step after the other. I'm wondering why you don't adjust it so that 9front can also be run there. As far as I can tell from once experimenting the reason why 9front doesn't run are your extensions to the kernel interface. 9vx is by far a better more plan9-ish way to virtualize under linux. But thats your decision. The path I suggested is the simplest one at least I think so. It takes less than 30 min to have a running plan9 installation without any problems arising from file servers without the problems of networking or data exchange. If you really believe that the path I suggested was a bad one or isn't simpler than directly using on of the plan9 distros I would really be surprised. This new guy has to learn rc, acme, rio, about plan9.ini about mouse shortcuts in acme. And do you really believe doing this directly on 9legacy or 9front is simpler than by using 9vx ? If this guy reaches the 4.step he will find his own path to whatever fork he pleases. So where exactly was my reply mindless ? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M71a22bd1f90c60a96961d626 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:39 PM, Jacob Moody wrote: > Are you interested in sharing code between your fork and us? If you have no > intention of making your fork freely available then I don't think there is really much of a point in having some sort of compatibility layer. Of course I am interested in contributing. As an example i patched aux/vga while testing my fork on different hardware 9legacy couldn't switch to vga mode and I got blank screens on six different thin client models. Sometimes caused by not recognizing PCI bridges but many times by the way mode selection happens in aux/vga. This is a problem thats not only affecting my fork but many forks. I wrote a patch which tries to find the next possible 32 bpp mode available in the bios. While preselecting a fixed mode in plan9.ini led to blank screens with this simple change you get a mode that is supported an lies next to your choice in the ini file. This works until now for all devices I tested. Only a small example. ---------- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M252ef88ca11ebfce7119ae06 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:32 PM, ori wrote: > it's a sad system that can't even host its own sources. If you are running a network for your work there is nothing sad about placing services on different OS'es. I'm using fossil-scm for about one decade had never problems it has nearly zero administration needs, an integratec ticket system, wiki documentation if you want to a web interface. When I decided to substitute CVS I choose fossil-scm and never regreted this desision. It has a BSD license and I'm grateful for this software. And using Linux as its host system is something you don't recognize. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1e5bff53873c27fb388e6645 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:01 PM, hiro wrote: > did you ever hear of the git implementation that ori has implemented? It was placed on the latest 9legacy CD and I'm not needing/using it. I'm using fossil-scm which replaced cvs for me. Fossil is running on a linux machine in my network and is remotly accessible from plan9. But the choice of a scm is a question of taste. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mdaa67e50520b81d782e013be Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
Curiously, I searched for Nantalala Systems and found an https link to NANTAHALA SYSTEMS. *BEWARE: SEEMS TO BE BOGUS* Under "store" they list two workstations they sell, both listed as "sold out" that are - OS: FreeBSD with ᴁBSD customizations Under ᴁOS (aka ᴁ9) installation media for x86™ computers and ᴁOS (aka ᴁ9) installation media for Raspberry PI™ computers there are "Learn more" links that lead to "page not found." At the bottom of the page: - ᴁBSD (AMD64) is ᴁBSD customizations on FreeBSD 14.0-STABLE. - GhostBSD is based on FreeBSD 14.0-STABLE. - ᴁBSD (AARCH64) is ᴁBSD customizations on FreeBSD 15-CURRENT. - ᴁOS (aka ᴁ9) is based on Plan 9. On the Support page, if you happened to somehow purchase one of those workstations and need assistance, you need to contact them the only way possible: Email: hello@nantahala.systems Netcraft shows the hosting country as Australia. The domain registrar is unknown. The SSL/TLS certificate issued by Let's Encrypt is for "From Mar 14 2024 to Jun 12 2024 (2 months, 4 weeks)" . On Monday, May 13, 2024 at 07:58:20 AM CDT, hiro <23h...@gmail.com> wrote: citation needed On Mon, May 13, 2024 at 1:58 PM wrote: > > On Mon, May 13, 2024, at 18:38, hiro wrote: > > how did you find out about this company, i never saw it mentioned > > anywhere before? > > I don't spend my time trolling 9fans. ;-) > > Vic ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-Mf58cc718484d6a1fce4d858b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 3:35 PM, G B wrote: > Then you are still driving a Benz Patent-Motorwagen built in 1885, which is > regarded as the first practical modern automobile instead of driving > something newer like a Mercedes Benz S-Class or Lexus or Acura since these > newer automobiles are not automobiles from your perspective? Is this some kind of shift working from 9front defenders ? If so perhaps you could exchange state information before you change shifts. If you use 9front that's fine with me do as you please I prefer the final plan9 release and I don't have to justify my decision. And I don't want my arguments. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mc3b0cd4ec4f8c03885597e31 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
"I respect your fork 9front but I won't and can't use it. 9front isn't plan9 from my perspective." Then you are still driving a Benz Patent-Motorwagen built in 1885, which is regarded as the first practical modern automobile instead of driving something newer like a Mercedes Benz S-Class or Lexus or Acura since these newer automobiles are not automobiles from your perspective? On Monday, May 13, 2024 at 07:09:38 AM CDT, ibrahim via 9fans <9fans@9fans.net> wrote: On Monday, 13 May 2024, at 1:26 PM, hiro wrote: at this point all you're doing is speculation at best, it's verboseand spammy, and full of untruths. I do not welcome it, please stopgenerating noise. You don't have to read nor to reply to my posts. The amount of noise you create exceeds mine by far. If you prefer this kind of conversation I don't have a problem with that too. I don't use 9front so spare me your lecturing this is not 9front's message board but 9fans. 9fans / 9fans / seediscussions +participants +delivery optionsPermalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M22db0e0190f0d9ca12a76a03 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 1:26 PM, hiro wrote: > at this point all you're doing is speculation at best, it's verbose and spammy, and full of untruths. I do not welcome it, please stop generating noise. You don't have to read nor to reply to my posts. The amount of noise you create exceeds mine by far. If you prefer this kind of conversation I don't have a problem with that too. I don't use 9front so spare me your lecturing this is not 9front's message board but 9fans. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Maeacb3484e14957786de7f7f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 1:11 PM, hiro wrote: > i mean contributing to the plan9 team. i don't share in your discrimination of 9front vs. non9front code. i bet if all of us can be gainfully employed to work on "real plan9" we can all stop contributing to 9front. please enlighten me who my future coworkers might be. who else is going to join the team? I don't discriminate 9front at all. What I'm trying to say is if we want contribute to each other we need a compatibility layer and the simplest choice is the final edition of plan9. Its well defined and well documented. There won't ever be a real plan9 interpretations satisfying all who are interested in plan9. My fork makes use of segments dynld I use a binary interface instead of 9p to achive higher performance regarding data transfer between processes and especially the framebuffer. I have a gui which is portable to linux, windows aso. I can compile my software for plan9 linux and windows without a single change of lines. I use wrapper interfaces to achive this and a preprocessor which produces C code for the compiler on the destination system. My users need shortcut keys so I have a further device which reflects keystates parallel to the operation of keyboard. All those changes differ from the concepts of plan9. My fork is making use of concept possible with plan9 but not really the plan9 way of doing things. I don't use fossil and others as my filesystem and I don't have a 9fat partition anymore. So how could we possibly agree on a real plan9 we can't. Each fork has its own use case and there is nothing wrong about this. I never asked you to stop 9front in favour of a real plan9 no one has the right to make such a demand any more. You have your user community and are doing a great job. If we want to share contributions between forks we need a compatibility layer if we don't want to we don't have to. I don't have a problem respecting any fork of plan9. I will give back to other forks as much as I take from them. And if I contribute code to plan9 than I will make sure that it doesn't make use of enhancements I am using within my fork respect the coding styles of such a compatibility layer if one is ever defined. The whole discussion is about interoperability between forks. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M42e70cabcf18e8b68a5b30c7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 12:40 PM, sirjofri wrote: > For me, it's "all plan9 systems", which includes belllabs plan9, 9legacy, > 9front and so on. That's one of the reasons I name 9front "a plan9 system", > not "the plan9 system", because there are a few different distributions/forks. The reason why I'm distinguishing between the plan9 and systems based on is quite simple. The moment we agree on such a fact we have a way to exchange code bug fixes participate in discussions. By this definition everything that can directly compiled and run on the final release of plan9 is usable by all forks cause each fork will have means of porting from this "mothership" and if people from different forks discuss than we discuss about things part of this mothership. Its okay that each fork has different views for things outside of this definition but this would end the never ending discussions. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1595216f59332b3651b45df6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> if you notice missing copyright messages: please send a patch. i have no clue what is required, but if you represent freetype or truetype or can imagine their legal requirements, please help us out there. it will be highly appreciated. btw, i hear about this for the first time. This was an example and I didn't find the original licenses from freetype in the folder or in the code. Perhaps they got lost while porting this code to 9front. I don't represent freetype and never claimed to > huh? which files exactly do you have doubts about? Any files where I don't know who and how wrote it. Was is ported is it just a reimplementation. I didn't sit by your side when you wrote your contributions or sources. and most when not all files in your distro have no hints about the author or the copyrights. Or did I miss any special folder where you provide the information regarding authorship of your sources ? > to me plan9 is indeed a toy. i wish it was otherwise. though it's a > toy that is to me personally much more useful than most "professional" > software. Nothing wrong about using an operating system in this way. As long as I'm using my fork for my personal needs I call it toy tool the moment I have to deliver something to others I can't view it anymore as a toy. So as always you misinterpreted this sentence : I didn't name 9front a toy that would be rude 9front is used by users and the moment you distribute it its a serious work which everyone me included has to respect. I didn't call 9front a toy but the purpose of its use. You can of course use plan9 for any tasks you can imagine and not the system is a toy. I would be really surprised if a programmer mistook this statement of mine. > That is a lie. We never ignored the license that plan9 was placed > under - and it was the lucent public license, which is extremely > permissive. > We completely ignored the work done later (by others) around > dual-licensing the GPL bec. we don't consider that an acceptably > permissive license and we disagree with that philosophy. I already replied to this and said that I didn't know you used the LPL version instead of GPL. I didn't know that you made that clear Ron defended your actions too so that's something I made a false assumption. Sorry for that. > Do not contribute to 9front if you are not ok with the MIT license. To > me this is why 9front is useful, but everybody has different legal > interpretations, so i'm only sorry that you can not see it's worth. If I contribute to plan9 than this will be made with an MIT license and all necessary information so that others can use the code if they see fit and this is also valid for 9front you can but thats your decision. On Monday, 13 May 2024, at 12:05 PM, hiro wrote: > I don't think p9f has ever provided anything apart from that misleading website and some kind of money transfers to people that i don't know. They are the ones chosen by Nokia and make plan9 available with an MIT license thats more than enough. To be honest with the fact that they until now decided to just distribute the final release instead of contributing enhancements to the system itself. I'm sure the outcome of such enhancements and contributions would have started never ending discussions arguments from 9front. They preserve plan9 as of the final release and forks can take this as a basement with clean licenses. I'm grateful to their acting for what they accomplished and respect the fact that they didn't change anything till now. On Monday, 13 May 2024, at 12:05 PM, hiro wrote: > 9legacy has both 9front and 4th edition code, as you already said. and many other people contributed stuff to both 9legacy and 9front, and other forks. For my personal taste 9legacy has should restrict itself to bugpatches for the final release. Anything beyond that should be part of /n/sources. But thats my opinion. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Me6f3d0b36f444b6ea666d4c1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 11:57 AM, sirjofri wrote: > So, you could say, plan 9 from bell labs is the last released version, 4th > edition. The others (9legacy, 9front, ...) are also plan 9, just not plan 9 > from bell labs. I personally prefer to call my fork based on plan9. I didn't write or invent plan9. Nor is my version a replacement or a continuation of plan9 it is fork based on plan9. On Monday, 13 May 2024, at 11:57 AM, sirjofri wrote: > And if people want just a continuation of the concepts (the concepts which > are commonly understood as "plan 9"), 9front is also one of those > continuations, same as 9legacy or any other fork that tries to live those > concepts. As I said before I view 9front as one fork of plan9 and one I'm respecting. You do a good job and people who use your fork surely benefit from your work. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9e9f2a281196eedb3a94429f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 11:39 AM, hiro wrote: > are you contributing the team? and paying the team? If you asked me. I don't use 9front or any of your contributions why should I pay for or contribute to your team ? ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mfd203382b8fd745cca9f025b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> I would make a big difference between what plan 9 is and what the licenses > are. Software doesn't care about licenses. People do (and they should!). > > So what is plan 9 even? Can we compare it to UNIX™ or unix or posix? Who > knows... > > I guess I could say a lot more about that topic, but I guess that's enough > and you can puzzle everything else yourself. plan9 is simply the final release made by bell labs and now owned by p9f. Thats not my interpretation this is a fact. Everything beyond that point is a fork based on plan9. Everyone is allowed to derive his/her work from this provided version of plan9. 9front is a fork, 9legacy is a fork and there were other forks. I have my own fork. If tomorrow another one decides to fork plan9 than thats okay. 9front isn't plan9. 9front is a fork based on plan9. Why is it that you can't accept this fact. You aren't the owners of plan9 and you don't even own the trademark plan9. Your fork is called 9front and its absolutely okay to fork from code with a license that allows this. Your fork based on plan9 is extremely close to the original. But that doesn't mean you are the continuation of plan9. The only thing we can agree on as fork developers is what is officially called plan9 as a basement for exchange of code ideas aso. Code that can be compiled and executed on the official release is one that can be exchanged. There is only one group on this messaging board which has a problem with this definition of plan9 thats 9front. You insist on being seen as the continuation of plan9 but you aren't. You could have become this by buying plan9 from nokia and the trademark or nokia could have chosen you to hand it over to you but they didn't. p9f owns plan9 and if they ever decide to hand it over to you than you become officially the owner and continuation of plan9 but this won't change the fact that meanwhile others have forked from plan9 and call themselves fork xyz based on plan9 and you to respect this. Why is it so difficult for folks of 9front to accept that they are providing a fork based on plan9. > [1] (I would be very careful with such bold words. I feel like 9front people > have heard this phrase a lot and it's probably very thin ice for a few > people.) > And so what ? Compared to the replies of some folks from 9front regarding simple questions there is nothing bold about my statements. This is 9fans and if you start the same discussions over and over again than you have to live with answers like mine. Neither you nor I own plan9 while people outside 9front have no problem with facts you have this problem. You can't just accept the fact that 9front is a fork like many others. You may do a good job for your users and many enjoy using 9front as stated many times here on this board but but you do your job others do their job and you are in no position to give directions to others. I respect your work continue with it but don't act as if you are the ones who are in possession of plan9 or can dictate directions you can't and I also can't. I'm fed up with the regularly disputes you search with people who don't want to use your fork. I'm not using it and nothing will change my mind. > About another topic: you mentioned that plan 9 is in use for commercial > products, and you explicitly mention german medical sensors. I've never heard > about that and I'd like to learn more, as well as about other companies who > actually use plan 9. > > Everything I always hear in the industry is that plan 9 is outdated and > nobody uses it and nobody wants to hear about it. I only know of a single > company that uses it (coraid), plus a few little projects by taw that could > evolve into commercial products. I am and have acted as an advisor for many of these projects. The license change made it attractive for such projects cause you can keep your code closed source. The only duty to fulfill is providing the terms of the MIT license. You don't have to make your technology open source like you would have to if you used Linux. Don't underestimate the potential. Another example for a tiny os which is wide spread is Xinu which no one would expect. Plan9 has advantages over other systems that makes it attractive. I can only talk about those projects I know but be assured there are millions of devices around which run plan9 without anyone noticing. Again for the x-th time : I don't have a problem with 9front. I don't use it but I respect your work. The only think I dislike is the never ending discussions about plan9 being dead and 9front being the only choice and the attitude in some replies to questions of people on this board in an harsh and aggressive way. The moment one asks about 9legacy or plan9 and one
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> I don't want to depend on anything. Your method is just adding other > dependencies to ghostscript if you start with ps, and other > dependencies, if not ghostscript, including C++ code that is inability > to port on Plan9, if you use pdf. > I don't have any dependences remaining you misinterpreted something. In the first time I needed some way to handle pdf files I had to connect to a linux machine in my network where the conversion from pdf to ps was done by using command line tools. The result of this conversion were first jpeg files afterwards svg files for which I wrote a renderer in plan9. The second step was to write a converter pdftosvg which works for pdf files I had to handle. No C++ no postscript interpreter. If you have to handle pdf files with embedded postscript than I wish you good luck. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mb94a807ef23009e0c91d9042 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 7:33 AM, ron minnich wrote: > So, Ibrahim, I can not agree with your statement here. I missed that they combined LPL licensed code instead of combining GPL licensed one. Thanks for the insides and sorry for the late response. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcd9e17b18ec5bfa7a0b4c527 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> For the ghostscript thing, and for the record (noting that, in this > area, I have put my code-money where my mouth is): > > I too want to get rid of Ghostscript. The path adopted is the > TeX/METAFONT way with the following: > > - A PostScript interpreter can be, functionnally, divided in two > parts: 1) a general purpose language allowing computation but aimed > for images and supposed, finally, to produce primitive graphics > directives (fixed results); 2) a rasterizer to produce a matricial > image; Converting pdf and ps to svg and rendering svg is the simpler approach. During the first time I used this method I just added a linux computer to my network and made use of pdftocairo with svg export. The advantage of this method is that the resulting container kept page information and also all glyphs are embedded in the resulting svg file which than gets rendered by a tiny svg renderer. Substituting ghostscript with a new interpreter wasn't worth the effort in my case. By reading the pdf metadata you also can keep the outline and other information. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Md9b6263712929d39588a677a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote: > I was making fun of your bragging because you implicated more installs > equated to higher quality. I never said that more installs equate higher quality and I never said that the quality of your code sucks or my code quality is better. On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote: > I trust that the licensing in 9front has been handled correctly. I have to make my decisions cause by distributing my fork I am the one who is liable. On Monday, 13 May 2024, at 8:22 AM, Kurt H Maier wrote: > Hope this helps, Yes it does. As it seems you used code licensed with LPL and made changes while avoiding the use of GPL licensed code which would have caused problems. On Monday, 13 May 2024, at 8:02 AM, Kurt H Maier wrote: > One by one we're getting rid of the third-party software -- I particularly look forward to the day we can finally ditch Ghostscript -- but in the meantime these accusations of license violations are misinformed and have no basis in reality. You don't have to ditch Ghostscript. You can provide this as a seperated download. The user of your system is free to download GPL'ed programs or code as he pleases. This won't infect other parts of the system which don't rely on the existence of such programs. On Monday, 13 May 2024, at 8:21 AM, Jacob Moody wrote: > I was trying to communicate that for the purposes of using hardware made this > millennia (as any "professional" would do), 9front clearly has better code > for doing so. I trust that the licensing in 9front has been handled correctly. I don't doubt that your fork runs on more systems out of the box compared to plan9 final edition. But with minor changes in the final edition of plan9 I also don't have problems to make my fork work on hardware made for this millennia. I tried your system on some thin clients and except for a few with bugs in the bios or in uefi and some issues with timer interrupts your system was also running. I respect your fork but I won't use it for distributed systems. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mf4269410df19d9e1e7239526 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, May 13, 2024 at 02:18:54AM -0400, ibrahim via 9fans wrote: > You really should read the GPL. Your changes were included with GPL'ed code > even in the same file and not distributed as independent patches so the > modified work as a whole got infected by the GPL license. This is explicitly allowed by the GPL as explained by the FSF. [1] But that's moot, since we never shipped a GPL upstream. We went from LPL, sat out the GPL, and switched to MIT directly. See previous email for revision history. khm 1 - https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M791ca8b4f0060d0f07822405 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, May 13, 2024 at 02:04:24AM -0400, ibrahim via 9fans wrote: > > There are many companies who double license code. As the owners of such code > they are free to do this. Users can't relicense code as they please > especially not GPL licensed code. At no point did we 'relicense' anything. We have never been in control of the license terms of Labs-provided code. The code we write, we licensed MIT. We then released both as a mixture; this is explicitly allowed under the GPL (the FSF calls MIT the "expat" license, see [1] for their declaration that it is compatible) and also under Lucent Public License Section 3 A. We comply with LPL section 3 C by providing complete revision history in a source control system; anyone may inspect it to identify the originator of any of the code. Hope this helps, khm 1 - https://www.gnu.org/licenses/license-list.en.html#Expat ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M24a9625c1ca2e86426c517fa Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
> You have apparently not read our licensing document at > /lib/legal/NOTICE, which explicitly names the terms of the original Plan > 9 code, and assigns the MIT license only to changes produced by 9front. > > As the labs-provided code has been made available under different > licenses, we have updated this to reflect the changes, from Lucent > Public License, through the GPL relicense, and then the MIT license. > At all times we've complied with the distribution requirements of all > applicable licenses. > 2. You may modify your copy or copies of the Program or any portion of it, > thus forming a work based on the Program, and copy and distribute such > modifications or work under the terms of Section 1 above, provided that you > also meet all of these conditions: > > a) You must cause the modified files to carry prominent notices stating > that you changed the files and the date of any change. > b) You must cause any work that you distribute or publish, that in whole > or in part contains or is derived from the Program or any part thereof, to be > licensed as a whole at no charge to all third parties under the terms of this > License. > c) If the modified program normally reads commands interactively when > run, you must cause it, when started running for such interactive use in the > most ordinary way, to print or display an announcement including an > appropriate copyright notice and a notice that there is no warranty (or else, > saying that you provide a warranty) and that users may redistribute the > program under these conditions, and telling the user how to view a copy of > this License. (Exception: if the Program itself is interactive but does not > normally print such an announcement, your work based on the Program is not > required to print an announcement.) > > These requirements apply to the modified work as a whole. If identifiable > sections of that work are not derived from the Program, and can be reasonably > considered independent and separate works in themselves, then this License, > and its terms, do not apply to those sections when you distribute them as > separate works. But when you distribute the same sections as part of a whole > which is a work based on the Program, the distribution of the whole must be > on the terms of this License, whose permissions for other licensees extend to > the entire whole, and thus to each and every part regardless of who wrote it. You really should read the GPL. Your changes were included with GPL'ed code even in the same file and not distributed as independent patches so the modified work as a whole got infected by the GPL license. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcbca2e6474097e0d12b334e9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, May 13, 2024 at 01:54:27AM -0400, ibrahim via 9fans wrote: > > Please correct me if I'm wrong. > Happily. Here's the original revision of /lib/legal/NOTICE: http://code.9front.org/hg/plan9front/file/944787349e93/lib/legal/NOTICE > The Plan 9 software is provided under the terms of the > Lucent Public License, Version 1.02, reproduced in the > file /lib/legal/lpl, with the following notable exceptions: a later revision, specifying the license for 9front-originated code, and adding exceptions for Python and Mercurial: http://code.9front.org/hg/plan9front/file/84ba3046886d/lib/legal/NOTICE > Plan 9 from Bell Labs is provided under the terms of the Lucent Public > License, > Version 1.02, reproduced in the file /lib/legal/lpl. > > Any additions or changes (as recorded in Mercurial history) made by 9front > are provided > under the terms of the MIT License, reproduced in the file /lib/legal/mit, > unless > otherwise indicated. > > The following exceptions apply: When the Labs released the code under GPL, it was still *also* available under the Lucent Public License 1.02. The software was, at that point, dual-licensed under LPL and GPL. We didn't see any benefit from acknowledging this, since the previous license was still valid and compatible with our needs. Once the MIT-licensed release was made available, we rebased on that: http://code.9front.org/hg/plan9front/file/87d8e72ffb5c/lib/legal/NOTICE > Plan 9 from Bell Labs is provided under the terms of the MIT license, > reproduced in the file /lib/legal/mit. > > Any additions or changes (as recorded in Mercurial history) made by 9front > are also provided under the same MIT License, unless otherwise > indicated. The only material change since then was moving from Mercurial to Git as source control, at which time we deleted Python and Mercurial from the tree, and removed the relevant clauses from /lib/legal/NOTICE. Third-party software not mentioned in the NOTICE file, but covered by non-MIT licenses, has always explicitly been identified as having their special cases addressed in-tree: > Other, less notable exceptions are marked in the file tree with > COPYING, COPYRIGHT, or LICENSE files. That practice predates 9front. Hope this clears up the history. khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mbdebd79c701e669045af7f62 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
The last post had some paste copy issues : There are many companies who double license code. As the owners of such code they are free to do this. Users can't relicense code as they please especially not GPL licensed code. If you download code that is GPL licensed you can't change the license to the MIT license. The only one who had the right to make a change of the license was Nokia they were the owners and they decided to do so after this bold action from 9front. If I'm wrong it would be nice if you tell me where exactly lies my mistake. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M08dd52c34338ab27c6590836 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Sun, May 12, 2024 at 11:52:29PM -0400, ibrahim via 9fans wrote: > > You ignore copyrights as you please and distributed 9front under an MIT > license long before Nokia as the owner of it decided to do so. You did > that at a time when plan9 was placed under GPL. You have apparently not read our licensing document at /lib/legal/NOTICE, which explicitly names the terms of the original Plan 9 code, and assigns the MIT license only to changes produced by 9front. As the labs-provided code has been made available under different licenses, we have updated this to reflect the changes, from Lucent Public License, through the GPL relicense, and then the MIT license. At all times we've complied with the distribution requirements of all applicable licenses. > The first thing such people have to check is the way you handle licenses. Yes, and our handling of them has been impeccable, with a wonderful end state where all of the Plan 9 code, both from the Labs and from 9front, can live happily ever after under the same license thanks to a lot of work from people who cared. One by one we're getting rid of the third-party software -- I particularly look forward to the day we can finally ditch Ghostscript -- but in the meantime these accusations of license violations are misinformed and have no basis in reality. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M27e972c2ed30ae3748f1d0d4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 7:33 AM, ron minnich wrote: > At no time in all this was there any evidence of incorrect behavior on the > part of 9front. None. Zip. Zero. Zed. They have always been careful to follow > the rules. > > Further, when people in 9front wrote new code, they released it under MIT, > and Cinap among others was very kind in letting Harvey use it. > > So, Ibrahim, I can not agree with your statement here. > 0.2.4.4 - PRAISE FOR 9FRONT’S BOLD ACTION, RE: LICENSING > > Any additions or changes (as recorded in git history) made by 9front are > provided under the terms of the MIT License, reproduced in the file > /lib/legal/mit, unless otherwise indicated. > > Read: /lib/legal/NOTICE. > > 0.2.4.5 - Everyone loves the Plan 9 license (circa 2021) > > In 2021, the Plan 9 Foundation (aka P9F—no relation) convinced Nokia to > re-license all historical editions of the Plan9 source code under the MIT > Public License. > > As a consequence, all of 9front is now provided under the MIT License unless > otherwise indicated. > > Re-read: /lib/legal/mit This is a citation of the current FQA and in older ones predating the relicensing by Nokia the same paragraphs were present. If those statements from the 9front documentation are correct than your MIT relicensing predates the moment where the owner of plan9 Nokia made such a decission. This paragraph regarding the "bold action" of relicensing appeard before the owners of the code made it available under MIT license. Please correct me if I'm wrong. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M87ce4c9f9e82fb2fa4b938f2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
libttf was one example and because it made its way into 9legacy i inspected it. > Are you implying that a majority of users are using Plan9 in a commercial > setting? That seems a bit absurd. > For personal use I think these license issues (if they do even exist) are of > no concern. I think you are greatly > exaggerating the possible issue here for your average user. I could tell you about more than two dozens of projects alone at german universities where plan9 was used in medical sensor devices. Calling something absurd which lies beyond your experience gives reason enough to not name any of those projects. > Again, I think in your situation of distributing hardware with plan 9 or > whatever, then it makes sense to do whatever your lawyer says. > I think advising against using 9front for every user on these grounds though > is misleading at best. Its not the lawyer who is responsible to avoid copyright issues its the duty of the developer. Not the lawyer gets sued but the one who distributes the system. Everyone is free to use 9front. But I won't use 9front for a distributed system because I don't have the legal certainty as with plan9. I know who developed plan9 and I know that Nokia owned it before they relicensed it. But I don't this trust in 9front code. And so I wouldn't advise others who make use of plan9 in ways like I do to use 9front. > Do you also remove the Lucida and printer fonts? These were released as part > of the original source but have interesting claims as to the ability to > redistribute them. > Do you also strip out the parts of ape that include ancient GNU utilities? > Are you running your system without a diff and patch? Of course I removed all fonts from the system. I have my own font library with scaleable vector fonts based on caligraphy. As I stated before I removed any GNU utilities ghostview postscript page and all tools which have clearly GPL licenses are removed. Patch and diff are replaced with BSD licensed versions taken from OpenBSD. Those are the rules. > And Java runs on a billion devices. And I can't distribute Java, Linux, commercial operating systems because those can't be distributed as you please their licenses don't allow distribution as the MIT license does. > I'm quite curious as to your definition of "professional" in one where none > of the work done by 9front would be seen as beneficial. I can assure you I respect your fork and the state you reached. Professional use as a distributed operating system needs legal certainty. If you include code from sources and I use your fork than I am the one who is doomed not you because you are no legal entity. I have to make sure that my distributions has no legal issues. The way you answer to such licensing problems makes clear you don't care about them and take the issue lightly. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5c4cdcf81f1cd752663d81e5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
ystem but make professional use of it. The first thing such people have to check is the way you handle licenses. Therefore 9front is a fork but p9f's provided final release is the real thing with a clear ownership and license. 9legacy would be the right choice as the current plan9 but it contains code from sources which bare the risk of infecting a MIT licensed plan9 if no measures are taken regarding these problems. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M0ab3105590e43b53a386c847 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
Sorry for the double post ... try to use an older version of 9legacy cause after the integration of 9git in the latest CD a full system compile will stop. I don't know why such software which can't be considered a patch to the 4th edition became part of the src tree instead of putting it in a contrib folder. I personally would expect from 9legacy being 4th edition with only patches for files which were part of the official release and contributions made by original developers from bell (like compilers from personal archives aso). The first thing I do when testing a new release of 9legacy is to clean up the system from such enhancements. But thats another topic ... ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9df35c16c3c2bbeb846ea0cf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:17 AM, clinton wrote: > If I were completely naive to actually running plan9 but with many clues > about other operating systems and hardware, would it be better for me to > install 9legacy on some mildly obsolescent but still quite serviceable and > reliable hardware, or start with 9front on something more modern? If you are familar with linux and have a veteran computer with 8 GB I would start with 9vx and a 9legacy iso. This will simplify your first steps. Otherwise you will have to get used to so many different things at once that you will perhaps loose your confidence. The advantages taking this root are : i) No filesystem problems ii) No hardware problems iii) The ability to edit files in an editor of your choice iv) The ability to start all kinds of services from terminal, cpu server, file server aso on a single computer to try all those things out compile kernels write scripts try them out. ... After you get used to rio, acme, acid rc the next step I would suggest is build a network out of virtual machines with the filesystem of your choice. And even while doing so using one 9vx emulation will help you establish connections to all those virtual machines and allow you to make adjustments. After you have collected enough experience I would stay with 9legacy and ignore 9front. 9vx allows you to create boot media for old as well as new computers. You find everything necessary on the 9legacy CD (but also things which shouldn't have been back ported to 9legacy). If you need help walking this road don't hesitate to ask. I think a cold start with plan9 9legacy or 9front with so many different things will just take the fun away but using 9vx you will keep the fun and can immediatly start using plan 9 and 9vx is extremly fast. 9vx has some shortcomings like missing support for some devices but don't mind them cause you will end up installing plan9 on bare metal after you get used to it anyway. To sum up : 1. Step : Linux + 9vx + 9legacy (started for times) 2. Step : qemu + 9legacy (cpu, fileserver, terminal) + 9vx (for adjustments and as a rescue terminal) 3. Step : qemu + 9legacy (cpu, fileserver, terminal) + drawterm 4. Step : Bare metal as you like ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Ma839ab8f84a91bbe25ff8ed3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, May 13, 2024 at 11:46:59AM +0930, clinton wrote: > I await the scorching flames for my great impudence of interjecting into a > vociferous discussion with such a pragmatic tangent! If you don't intend to have anything hanging out with a direct internet connection, just use whatever looks cool and is supported by the hardware you have at hand. If your installation is going to be subject to transmitting packets across the internet, 9front has better crypto. As has been mentioned recently in this list, porting that crypto back to 9legacy may be a fun way to get your hands dirty, if you're into that sort of thing. Either way you're not really missing anything by picking one to play with, and if you feel like you are, it will still be there when you feel like trying the other one out. Reading all the stuff in /sys/doc is a great way to start learning on either distribution. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M4264d1a4bf2b692f45d27184 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Sun, May 12, 2024 at 09:46:12PM -0400, Dan Cross wrote: > > So what is it, exactly, that people want? The only people who feel like there's some conflict to resolve are people who do not use the software and have nothing to offer except for social commentary. This "us vs them" shit is only of interest to people who are unaware that the argument stopped happening years ago. "What people want" is in general to feel like they're helping, but these days it's a rare 9fan whose head is inserted so deep that middle management seems like the helping hand we all need. Everyone in the Plan 9 world has what they want, at this point, except maybe unlimited free time to pursue the to-do list. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M945a6c0bfefaec1e617cb9f7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, May 13, 2024 at 09:21:20AM +0900, vester.thac...@fastmail.fm wrote: > unclear who exactly is responsible. Typically, a team of two or more > individuals would focus on these deliverables. nobody is "responsible" and there are no "deliverables" the people who covet bureaucracy have one to play with. if you are one of them, I suggest you visit plan9foundation.org and get involved with it. otherwise, there are no problems here to fix, all this shit you're talking about is in your head and has nothing to do with us. please don't respond to this message. khm ---------- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5bee9f213d1f12c8ad7568a2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
On Sun, May 12, 2024 at 02:16:47PM +0100, Richard Miller wrote: > > That's quadrillions of years. Not what most people would call "trivial". > And that's generously assuming the implementation of meet-in-the-middle > is zero cost. Without meet-in-the-middle, we're looking at a 168-bit > keyspace and an even more preposterous number of years. Meanwhile, sweet32 exists, all this shit has already been prosecuted on other venues, and NIST shitcanned 3DES entirely last year. Not deprecated. Disallowed. Why? Because no matter how many numbers you paste into an email, it costs thirty bucks to crack it on someone else's ASIC farm. Pretending that getting access to $100k hash-cracking arrays is any more inconvenient than Uber Eats is straight-up disingenuous. It is extremely gross to be defending 3DES in 2024. You should know better. I don't particularly care if 9legacy adopts dp9ik, but there are people who will come reading this list archive down the road, and they'll be under the assumption that your arguments are in good faith. I hope they are not, because this crap is at best irresponsible. Occam's razor does not advocate ignoring the entire standardized best practices of the industry because you have emotional attachments to broken software and have used a pocket calculator to convince yourself you know better than everyone else on Earth. Advocating a switch to 3DES because it's backward-compatible with DES if you use it wrong is magnificent trolling, or depressing malpractice, depending on your intent. I can't ever know that, so I'll just state for posterity: kids, don't do this. It's a terrible plan. Do better, khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M6ef048148514ce58cf76ead5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] best place to be sent a patch
Thank you, David, hiro. I'm going to try to update libsec, if it works, I will send a patch to both David and here. 2024年5月12日(日) 23:39 hiro <23h...@gmail.com>: > > best is here on the mailinglist as you can attach the patches easily, > and even if david doesn't have time to respond, others here might help > you on the path, others might appreciate taking part in your adventure > and others might learn from it, too. i guess you can cc david if > getting into 9legacy is your goal. > > On Sun, May 12, 2024 at 4:31 PM Kyohei Kadota via 9fans <9fans@9fans.net> > wrote: > > > > I have a question: where is the *best* place to be sent a patch for > > 9legacy? replica? GitHub? or here? > > > > I'm motivated, but I don't like to get no feedback as before. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T57377acea9350f32-M05c32cbdd35d0a32d92b70e1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] best place to be sent a patch
I have a question: where is the *best* place to be sent a patch for 9legacy? replica? GitHub? or here? I'm motivated, but I don't like to get no feedback as before. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T57377acea9350f32-Mc6c4a32fa25c0420b9839ba8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Sun May 12 14:43:17 +0200 2024, vester.thac...@fastmail.fm wrote: > I don't mind the ad hominem attacks. I just hope things improve. I do find > it ironic that I'm addressing the 9front community about collaboration and > inclusiveness when I recall those as being two reasons for the inception of > 9front. > > Vic You hit the nail on the head there. Why *are* you addressing just the 9front community or assuming there is no willingness to collaborate on its part? 9legacy users so far have expressed interest in someone else porting dp9ik (David for instance) or demanded explanations about DES cracking (Richard) or asked for others to port or fix fossil on 9front (Lucio), but who explicitely said that they would like to put in some work themselves and collaborate with 9front people? Maybe I'm beginning to misremember the rest of the thread, am I missing anything? Could you point to *specific examples*? 9front users demand code because they've already put in a lot of work and it has been often ignored or dismissed, and because it would be up to them to backport it to 9legacy -- why would they do double duty for a system they don't use and a community which is generally not receptive to their work? Also, do you realize that 9front right now has upwards of 10500 changes in the repository, after 13 years? Bringing 9legacy up to date as you've proposed would require a colossal amount of work, all just to obtain... 9front. Do you believe it has diverged to the point where backporting hardware support, fixing bugs and broken or incomplete implementations and so on will result in anything other than what 9front already is? You yourself demand everyone, especially the 9front community, to make suggestions, start projects, etc. What about you? What do you suggest to do and which projects would you take part in? That's what "just send the code" implies. Promises don't fix bugs or help implement programs, nor help fix this one-sided conversation. I'm asking these questions yet I fear that they will meet radio silence or more empty walls of text, as it happens too often here when asking "why" or how it came to this. I hope I'm wrong. Thanks, qwx PS: I was about to hit send when I received Richard's mail. Richard, thank you for the constructive and detailed response. I hope this marks a turn of the tide. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M6a6ba83828236109b9c23a90 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Fri May 10 13:55:58 +0200 2024, lucio.d...@gmail.com wrote: > I am not allowed to ignore some advice when Vic raises a much more > interesting subject matter and does it in a perfectly justified and well > formulated fashion - and gets accused of being an AI or at minimum playing > one on 9fans? So you're ignoring the answers and advice people are giving you, including my own, because it's just not interesting enough? > How do you know that I did not follow any of Moodley's advice, which > incidentally I acknowledged I may not be competent to follow? Then which of Moody's suggestions did you try, and what worked? > None of the > legacy people I have noted responding have been even remotely as offensive > as those who are determined to deify 9front in legacy's place - when there > is no effort on legacy's side to promote our particular preference, nor to > justify such preference as being superior in any manner. > > What I notice - correct me if I am mistaken - is that any comparison > between 9front and 9legacy seems to needle a few members (very few, there > are many names from that community that have not participated, specifically > the ones I know hand have long respectes, ask them) of the 9front community > that seem to take offence unless 9front is painted in a better light. I > guess that's permissible, but please mind your manners if you choose to go > that route, this is 9fans and 9front I believe has its own discussion > groups. I'm puzzled why you feel there's any kind of crusade against 9legacy going on. Moody was direct about problems he has had trying to collaborate in the past, and hiro questioned some of Vic's statements, essentially just asking "why". I don't see where the pitchforks or the deification is, I must be just stupid. Can you point to specific statements you feel are so abrasive or offensive? Thanks, qwx -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M0d2760ed993d5ea50dc12f2b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Interoperating between 9legacy and 9front
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] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
His name is Moody, you keep spelling it differently in what I can only assume is a passive aggressive way to insult him? — thedæmon On Friday, May 10th, 2024 at 6:53 AM, Lucio De Re wrote: > I am not allowed to ignore some advice when Vic raises a much more > interesting subject matter and does it in a perfectly justified and well > formulated fashion - and gets accused of being an AI or at minimum playing > one on 9fans? > > How do you know that I did not follow any of Moodley's advice, which > incidentally I acknowledged I may not be competent to follow? None of the > legacy people I have noted responding have been even remotely as offensive as > those who are determined to deify 9front in legacy's place - when there is no > effort on legacy's side to promote our particular preference, nor to justify > such preference as being superior in any manner. > > What I notice - correct me if I am mistaken - is that any comparison between > 9front and 9legacy seems to needle a few members (very few, there are many > names from that community that have not participated, specifically the ones I > know hand have long respectes, ask them) of the 9front community that seem to > take offence unless 9front is painted in a better light. I guess that's > permissible, but please mind your manners if you choose to go that route, > this is 9fans and 9front I believe has its own discussion groups. > > Lucio. > > On Fri, May 10, 2024 at 12:22 PM qwx via 9fans <9fans@9fans.net> wrote: > >> On Fri May 10 11:09:32 +0200 2024, lucio.d...@gmail.com wrote: >> >>> I'm finding it ironic, though, that the defenders of the true 9front faith >>> find it necessary to insult their "enemies" in a forum dedicated to the >>> very subject matter they are so disapproving of. Surely they realise that >>> 9fans is a stupid place to do so? >>> >>> Lucio. >> >> Several people, including 9front users, have tried to help you and >> provided you with ways to accomplish your task; they have been so far >> ignored. Even Moody himself gave you alternatives and arguably easier >> ways to do it. Here's another one: mycroftiv's ANTS was in sync with >> 9front for a while and fully supports fossil; it is now out of date >> but the last ANTS release will probably work on your hardware. iirc >> noam had also tried to update it based on latest 9front some time >> ago, but I'm not sure where that lives. >> >> You have everything you need, courtesy of your "enemies", the >> "defenders of the true 9front faith", whatever that is supposed to >> mean. What have you tried so far, did it work? >> >> Thanks, >> qwx > > -- > > 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](https://9fans.topicbox.com/latest) / 9fans / see > [discussions](https://9fans.topicbox.com/groups/9fans) + > [participants](https://9fans.topicbox.com/groups/9fans/members) + [delivery > options](https://9fans.topicbox.com/groups/9fans/subscription) > [Permalink](https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M8d97eaec0e9d4e395d19361b) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcca3cba6e150de7a1db2fd9d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Fri May 10 11:09:32 +0200 2024, lucio.d...@gmail.com wrote: > I'm finding it ironic, though, that the defenders of the true 9front faith > find it necessary to insult their "enemies" in a forum dedicated to the > very subject matter they are so disapproving of. Surely they realise that > 9fans is a stupid place to do so? > > Lucio. Several people, including 9front users, have tried to help you and provided you with ways to accomplish your task; they have been so far ignored. Even Moody himself gave you alternatives and arguably easier ways to do it. Here's another one: mycroftiv's ANTS was in sync with 9front for a while and fully supports fossil; it is now out of date but the last ANTS release will probably work on your hardware. iirc noam had also tried to update it based on latest 9front some time ago, but I'm not sure where that lives. You have everything you need, courtesy of your "enemies", the "defenders of the true 9front faith", whatever that is supposed to mean. What have you tried so far, did it work? Thanks, qwx ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1c1e596f85b044c93a1ab637 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Name duplication in union directories
Thanks! -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf4c3dc658874afea-M36739d26a8ea4c9534babbdc Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Name duplication in union directories
Is the presence of the duplicate names when reading a union directory actually needed/used anywhere? Or is it just an artefact of the most straightforward implementation for Plan 9? I ask because I'm implementing the Plan 9 system calls on my own OS. If I don't have to implement the name duplication in union directories, then I may be able to get away with less code. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf4c3dc658874afea-M65300584831da4f8f8d56134 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] VCS on Plan9
On Apr 18, 2024, at 2:48 PM, Shawn Rutledge wrote: > > Just another reason to eventually have Rust on Plan 9… Yeah. Compiles are too damn fast; no time to make masala chai :-) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M56e1b18e4d67c6281934993d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] VCS on Plan9
On Apr 18, 2024, at 1:41 PM, Dan Cross wrote:
>
> Culturally, there was a feeling that source revision a la RCS, SCCS,
> etc, were unnecessary because the dump filesystem gave you snapshots
> already. Moreover, those were automatic and covered more than one file
> at a time; RCS/SCCS required some discipline in that one had to
> remember to check in a new revision. And as Paul said, the idea of an
> atomic, multi-file changeset was revolutionary at the time.
Readers here may be interested in our experience (circa 1982!)
At Fortune Systems, in 1982, Dave Yost come up with "cloned
tree" system for source code control. The idea was, each
developer gets their own src tree where all the files are
initally hard linked with the mastr tree (& are readonly). We
modified vi to always save the old file foo as ,foo and write
out a new file foo. [Note that the Rand editor e which many
of us used already did this.] This makes it easy to see that
files with link count == 1 are modified locally. When some
feature / bugix is complete, someone would manually "commit"
changes to the "master" branch using diff to review them.
Dave wrote a paper about this called "A Rich Man's SCCS" in
Usenix Summer 1985.
Looking back, we had some (fuzzy) idea of a change set. But
we didn't have a way to keep a log of what changed and why.
And we didn't automate "commit". We did have a way of naming
top level trees ("frozen" ones by the date of the latest
modified file, development ones by the version we were
working on + developer name). We also modified tar to allow
saving and restoring a set of trees (recreating links for
identical files).
------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-Me7d866a5dbc8db8e84dd93be
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] VCS on Plan9
Did anyone try to port sccs to plan9? > On Apr 18, 2024, at 9:11 AM, Paul Lalonde wrote: > > The Bell Labs approach to source control was, I'm, weak. It relied on > snapshots of the tree and out-of-band communication. Don't forget how small > and tight-knit that development team was, and how valuable perfect historic > snapshots were. > > Add that 40 years ago source code revision control systems were incredibly > primitive. The idea of an atomic change set (in Unix land at least) was > revolutionary in the early 90s. > > This is one place where 35 years of evolution in software practices has very > much improved. > > Paul > > On Thu, Apr 18, 2024, 8:55 a.m. certanan via 9fans <9fans@9fans.net > <mailto:9fans@9fans.net>> wrote: >> Hi, >> >> is there any more "organic/natural" way to do source control on today's >> Plan9 (9front specifically), other than Ori's Git? >> >> In other words, how (if at all) did people at Bell Labs and the community >> alike originally manage their contributions in a way that would allow them >> to create patches without much hassle? >> >> Was it as simple as backing a source tree up, making some changes, and then >> comparing the two? Venti? Replica? >> >> tom > > 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription>Permalink > <https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M1b6d6751f6d830d2a70a696f> -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M65f0bf5f4f88547e7f42ac54 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] VCS on Plan9
> From what I understand folks used to make diffs against the last release. > There was also some use of replica as you eluded to. That answers my question. Thanks. tom -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M6d2f0ac53564e61ec64621ee Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] VCS on Plan9
Hi, is there any more "organic/natural" way to do source control on today's Plan9 (9front specifically), other than Ori's Git? In other words, how (if at all) did people at Bell Labs and the community alike originally manage their contributions in a way that would allow them to create patches without much hassle? Was it as simple as backing a source tree up, making some changes, and then comparing the two? Venti? Replica? tom ---------- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M3ad4cc51ed9aebb728fe83f8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] troll paper
Isn't Cue YACL (Yet Another Configuration Language)? Absolutely no way one can deprecate YAML and just use Cue, so all one is doing essentially is adding one more thing to learn and keep updated. And since it hasn't released 1.0, what happens if the new YACL never materializes but was adopted? Good luck ripping that out to return to YAML. On Tuesday, April 16, 2024 at 09:26:28 AM CDT, Charles Forsyth wrote: Although cue itself is more generally useful, applied that way it's a coping mechanism that indeed doesn't address the fundamental point:like those Sendmail configuration languages that compiled down into the rewrite language instead of just replacing that. On Tue, 16 Apr 2024 at 15:19, wrote: Quoth Charles Forsyth : > > it's been a little while since i first looked at it, but i think one of the > example application is exactly how one might use it to avoid 80k lines of > yaml that you must look at directly. while it may help -- this is just stacking complexity on top of complexity. kubernetes may be a tool that some of us need to deal with for our jobs, but it has no place in a well designed rethink of the world. 9fans / 9fans / seediscussions +participants +delivery optionsPermalink ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-Me7b04f3e2f6e4c8db91448b5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] troll paper
On Apr 15, 2024, at 1:50 PM, Charles Forsyth wrote: > > And, if I hear about it being > “declarative” as a virtue, I point to the 81,000+ lines (and > growing) of YAML, that I defy any one human to comprehend. > > You might find help in culang.org Not sure how much the Cue language will help when the underlying model of Kubernetes is quite complex (pods, containers, deployments, nodes, schedulers, controllers, clusters, services, load balancing, tasks, kubelets, kube-proxies, api-servers, multi-tenancy, replicas, namespaces and so on). May be all you can do is push this complexity around but not conquer it. In any new design, at the start you often overbuild because you don't quite know what will work but soon you have to sense what is scaffolding and can be removed vs what is essential and must be left in. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M532d92757e5a02a419f67eac Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] openat()
I left the oven on for my partly-baked idea.
I'm now thinking that with fd 5 as an example:
open ("#d/5dir/a/b/c", ...)
might be a practical way to do this (the syntax I suggested earlier would
require walking from a file, which wouldn't be sensible).
So I went snorkeling in the kernel to see how hard this would be...
devdup.c uses the bottom bit of the qid.path to distinguish #d/0 from #d/0ctl,
so that would have to change to modulo 3 to allow the '5dir' virtual directory
to be found when qid.path % 3 == 2, and twicefd would have to change to
thricefd.
The idea is that a walk to #d/5dir would continue the walk at the cloned
unopened directory fid that fd 5 is also holding in its chan (as I suggested in
a previous post).
Currently, dupwalk just calls devwalk in dev.c, so we'd probably want to do the
first step in dupwalk, doing fd2chan, much like dupopen does. Then call
something else to walk from there. I'm not sure what though: walk() maybe?
I don't really know my way around the Plan 9 kernel, so this may not be the
right way to do this. There are some scary creatures in dev.c, including a
spikey backward pointing goto and some dark comments about contradictory rules
and ugly bits... :o
You'd want to get the effect of having the directory open on fd 5 bound to
#d/5dir without actually doing the bind (because you can't...).
Ideally if fd 5 is not a directory, then #d/5dir should not even appear.
The idea is that then:
int
openat (int fd, char *path, int mode)
{
char newpath[PATHSIZE];
sprintf (newpath, "#d/%ddir/%s", fd, path);
return open (newpath, mode);
}
could be a function in a library somewhere that would parcel it up in a more
convenient form, and the rest of the *at suite could follow the same pattern.
Maybe someone would want this for a version of APE emulating Linux?
So the idea is still partly-baked, and still very much in the realm of the
hypothetical:
Ron Minnich wrote:
"I don't want this to turn into a debate on the merits of openat"
I'm approaching this in the spirit of "if we had to implement this, how would
we do it while inflicting the least harm"... :)
------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M124c4e12c40240ab85dbdea0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] openat()
Well I got curious, and wrote a test program for my Linux RPi: Doing the equivalent of what du(1) does (a recursive tree walk statting every file) seemed to be about 15% faster with openat/fstatat than with open/lstat. This was on a local drive (SD card). Over 9p to my Plan 9 RPi from Linux it appeared to make no measurable difference at all (though I don't know whether v9fs can take advantage of the *at capability). Maybe there's some use case where it makes a more dramatic difference. My tests were not very scientific. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M5f33ea51d2130dafe5918a21 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] openat()
Faster for any command that operates on dir trees such as diff, du, rm, tar.When I first looked at plan9, I was a bit surprised its open *didn’t* workthis way! May be because of this earlier thread on comp.unix.wizardshttps://groups.google.com/g/comp.unix.wizards/c/i8vapj9BAqs/m/FlNUK705I0UJ (which has nothing to do with plan9 but people explored some researchy ideas)On Apr 6, 2024, at 10:37 AM, ron minnich wrote:openat gives you the effect of 'cd path; open file' without having to cd. I don't see a lot of benefit to it unless you're opening a lot of files at that path. 9fans / 9fans / see discussions + participants + delivery options Permalink
Re: [9fans] openat()
Moody wrote:
"What you _would_ want for this would be the ability to walk from the existing
fd, however the limits of 9p walk make this a bit impossible to implement in a
great way in my opinion. "
Maybe the chan could keep two fids: the original walked fid, and an opened
clone of that fid? The open one could be used for read/write, etc, and the
original could be used for subsequent walks.
Ron Minnich wrote:
"The question I had was, can I get the benefit of *at without doing
what linux is doing, namely, for all system calls with a path, make an
'...at' version.
I am guessing so, though I'm not sure it's as efficient."
Could you do something like
open ("/fd/5/as-dir/a/b/c", ...)
or
open ("#d/5/as-dir/a/b/c", ...)
where 5 is the file descriptor of an open directory, and "as-dir" is
effectively bound to the directory it has open?
The Linux docs make passing reference to "tricks involving /proc/../fd" which
seems like a better idea than adding all those *at system calls...
... from the department of partly-baked ideas...
------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M4f2926b33d54b9f6842c2078
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] openat()
Depending on the implementation of the file system, openat vs open can be more efficient if there’s a lot of metadata locking for file creation.Sent from my iPhoneOn Apr 6, 2024, at 1:36 PM, ron minnich wrote:openat gives you the effect of 'cd path; open file' without having to cd. I don't see a lot of benefit to it unless you're opening a lot of files at that path. My first reaction, assuming you have a lot of files in that directory, was something likebind /dir /n/x and then just open /n/x/file... for a lot of files. This would work for any system call that takes a path.The question I had was, can I get the benefit of *at without doing what linux is doing, namely, for all system calls with a path, make an '...at' version.I am guessing so, though I'm not sure it's as efficient.On Fri, Apr 5, 2024 at 8:19 PM <mo...@posixcafe.org> wrote:My two cents on this:
What you _would_ want for this would be the ability to walk from the existing fd, however the limits of 9p walk make this a bit impossible to implement in a great way in my opinion. From walk(5):
The fid must represent a directory unless zero path name elements(for just cloning the fid) are specified. The fid must be valid in the current session and must not have been opened for I/O by an open or create message.
Since not every fid is eligible for being walked from, in order to implement opanat() in any way that would be better than just batching the fd2path and open would be to keep a "last directory" associated, like what we do with the string used to open it. Also worth mentioning that fd2path is not without its own problems, it's possible that the namespace has changed since the file has been opened so the same path may not work the second time. So tagging the last directory Chan would be "more correct", but I am not sure how useful this is.
Answering some other comments made:As I understand it from the rationale section on the
linux man page, the call exists to avoid a race condition between
checking that a directory exists and doing something to a path
containing it. An additional motivator is providing the effect of
additional current working directories notably for Linux threads (which
presumably don't have their own. I think 'threads' (processes that
share memory) on Plan 9 do???).Each process has it's own current working directory:
% pwd
/home/moody
% @{cd /}
% pwd
% /home/moody
This is all based on the assumption that holding a file/directory open keeps it alive and in existence... which on Plan 9, I think it doesn't, does it? As I understand it, remove can remove a file or directory that is open, which is not like UNIX/Linux...
Depends on the file server implementation, I find that for more synthetic files they are indeed kept alive as long there is someone with a reference to the fid.
This is identifiable if all the cleanup happens on clunks(destroyfid in lib9p), which only happen when a fid's refcount hits zero.
For non-synthetic or more "disk" file servers the behavior can differ. Cwfs does not keep the data around, readers that attempt to read a deleted file, even if they already have a reference open to it will result in a phase error. However 9front's ramfs keeps the data around.
My test for this was as follows:win1% echo 'something' >/tmp/testwin2% win1% rm /tmp/test
# observe the error(if any) on win2So you really can't assume either case.Thanks,
moodyP.S.I apologize for the formatting, it seems my emails are not making it to the list when I attempt to send them from my mail server so I had to copy this response in to the web form. I would like to figure out why if possible.
9fans
/ 9fans / see
discussions
+
participants
+
delivery options
Permalink
Re: [9fans] openat()
Are you thinking narrowly about "What changes to the Plan 9 kernel would you make to emulate the Linux openat() system call" or more generally about "How would you design a facility for plan 9 that provides an equivalent service? As I understand it from the rationale section on the linux man page, the call exists to avoid a race condition between checking that a directory exists and doing something to a path containing it. An additional motivator is providing the effect of additional current working directories notably for Linux threads (which presumably don't have their own. I think 'threads' (processes that share memory) on Plan 9 do???). This is all based on the assumption that holding a file/directory open keeps it alive and in existence... which on Plan 9, I think it doesn't, does it? As I understand it, remove can remove a file or directory that is open, which is not like UNIX/Linux... Sorry, I'm just trying to understand the question. ---------- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M77db5ff0993c7da831142e92 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] openat()
To me this sounds very similar to open() given a path relative to your current working directory. > On Apr 5, 2024, at 2:22 PM, ron minnich wrote: > > not so much what I want, I'm curious about ideas people have about > implementing it that I would not think of. > > On Fri, Apr 5, 2024 at 1:38 PM Gorka Guardiola <mailto:pau...@gmail.com>> wrote: >> Hmm sorry. Now I see what you want. Not to rewalk. You can use the chan of >> the dirfd and walk just the remainder cloning it and creating a new one. >> That way the openat provides the guarantees you want. >> >> On Fri, Apr 5, 2024, 22:15 Gorka Guardiola > <mailto:pau...@gmail.com>> wrote: >>> I mean, if you want a new syscall jus copy or call the implementation of >>> these. >>> >>> >>> On Fri, Apr 5, 2024, 22:12 Gorka Guardiola >> <mailto:pau...@gmail.com>> wrote: >>>> ¿Isn't that fd2path, strcat and open? >>>> Or am I misunderstanding something? >>>> >>>> On Fri, Apr 5, 2024, 21:51 ron minnich >>> <mailto:rminn...@gmail.com>> wrote: >>>>> One of the folks I worked with, when we pulled a big chunk of plan 9 into >>>>> akaros, commented that he had implemented openat on akaros. >>>>> >>>>> I don't want this to turn into a debate on the merits of openat; I am >>>>> more curious: if you went to implement openat on Plan 9, how would you go >>>>> about it? I have a few ideas but I'm more interested in your ideas. >>>>> >>>>> Thanks > > 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription>Permalink > <https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0445ed55bee993d4cfbd3450> -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M0efc38028930341e0db8f794 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] 9legacy Raspberry Pi HDMI video questions
I was able to remove the black border by appending the following lines to
config.txt:
hdmi_group=2
hdmi_mode=82
hdmi_cvt=1920 1080 60 3 0 0 1
framebuffer_width=1920
framebuffer_height=1080
max_framebuffer_width=1920
max_framebuffer_height=1080
The lesson I learned was that the Pi needs to be physically powered off after
making changes to the config file. ctrl-t ctrl-t r is not sufficient.
/
> On 5. Apr 2024, at 16.33, slash 9fans wrote:
>
> Dear 9fans,
>
> I am booting my Raspberry Pi 4B off the 9legacy SD card image
> (http://www.9legacy.org/download.html) and it boots fine with the default
> config.txt, but there is a 48-pixel wide black border on the screen.
>
> term% echo `{ dd -if /dev/screen -bs 64 -count 1}
> 0+1 records in
> 0+1 records out
> r5g6b5 0 0 1824 984
>
> The Pi is connected to a standard 1080p 60Hz monitor via HDMI. How can I get
> rid of the black border i.e. expand the screen size to 1920x1080? If anyone
> has accomplished this, could you share your config.txt? Also, how can I
> enable 24bit colors? Thank you.
>
> /
>
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T3b1609b3926a2f19-M9826399302cb5bf55ac94e01
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] cmdline.txt for RPi 4 with QHD screen
Oooh! More pixels! This is wonderful, thank you! I had the same situation, but I didn't know this was possible. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M02cd60501c363e99ed9163bd Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] 9legacy Raspberry Pi HDMI video questions
Dear 9fans,
I am booting my Raspberry Pi 4B off the 9legacy SD card image
(http://www.9legacy.org/download.html) and it boots fine with the default
config.txt, but there is a 48-pixel wide black border on the screen.
term% echo `{ dd -if /dev/screen -bs 64 -count 1}
0+1 records in
0+1 records out
r5g6b5 0 0 1824 984
The Pi is connected to a standard 1080p 60Hz monitor via HDMI. How can I get
rid of the black border i.e. expand the screen size to 1920x1080? If anyone has
accomplished this, could you share your config.txt? Also, how can I enable
24bit colors? Thank you.
/
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T3b1609b3926a2f19-Maae5d0529903240b88db08b1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] How to PXE boot with "two" DHCP servers on one network
On Mon, Mar 25, 2024 at 04:52:29PM +0100, Marco Feichtinger wrote: > My router at home also serves as the DHCP server for the network. > > I have a plan9 file server and now want to pxe boot a second machine from it. > On the file server I have 'ip/dhcpd -sS' running, since it also serves bootp > requests. > > Now when i pxe boot the second machine, it loads 9boot, but when searching > for the > /cfg/pxe/ file, it uses the ip address of my router. > > Boot Message: > pxe on ether0 . > (!69): /cfg/pxe/ > .T.T.T.T.T.T.T.T.T.Ttftpread1st: failed to connect to server (!69) > > How can I pxe boot other machines, without my file server acting as dhcp > server for the whole network? don't run two dhcp servers. turn off the one on your fileserver and configure your router to pass next-server: to clients that should pxe boot from the fileserver. it just needs to support tftp. khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T47150b930c3726bd-M18f3db81c876c8802eec3748 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: Hello, RPi fixes and bind -b trouble
Well I had a go at this on my RPi. I altered libc.a to arrange that errstr()
removes the error string filename decoration, but print ("%r") doesn't, and
wrapped the open() call (as an example) to do its own error string decoration
and hand that back to the kernel.
Unfortunately I then looked in the kernel and discovered that namec (which does
the decorating) is called in about 50 places. If it stopped decorating error
strings, there are potentially a lot of places that would notice, and I haven't
chased them all down. That being so, my enthusiasm for this idea is much
dampened, and I think it's dipped below the worth-considering threshold. :(
I'll keep the code I wrote around in case it's ever useful. On the plus side, I
learned some things about the libc.a build process. And the awesome mkfile in
/sys/src/libc/9syscall.
I think it would still be worth fixing exportfs to strip off any decoration
before sending out an error string via Rerror, though, as that would fix v9fs's
problem and the nested mounts problem I was looking at earlier.
----------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-Mb935ad65e7512b2d0a6787a8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: Hello, RPi fixes and bind -b trouble
(Lucio posted while I've been thinking/composing/trying things...) Thanks for putting up with me! I confess I've been thinking about this a bit more, as something about this doesn't feel right: As I understand it, the kernel is getting an error string from some file server, and is decorating it with a filename/pathname for the benefit of the user, then returning it to userspace through errstr(2). exportfs(4) is then sending the decorated error string out to whatever mounts it. But, another machine that mounts that exported file system will then decorate it a second time... If that composite file system is exported to a third computer, then that system will mount it and its kernel will decorate it a third time... This being plan 9, you can do this all on the same machine, so I tried it. In each window I typed/snarfed/pasted something like: term% srv tcp!themachine!9123 step1 term% mount /srv/step1 /power term% aux/listen1 -t tcp!*!9124 /bin/service/tcp5564 (/power is just a handy unused directory to mount on. ;)) /bin/service/tcp5564 above is: #!/bin/rc exec /bin/exportfs -r / I created 3 windows, each mounting a composite file system exported from the previous one (by advancing the port numbers and srv names I used above). And sure enough, the error message strings get longer and longer! Eventually I got: term% echo >/lib /fd/0:10: > can't create: lib: is a directory: './power/lib': './power/power/lib': './power/power/power/lib': 'lib' I had to generate an 'is a directory' error to see this, rather than a 'file not found' error, as the latter seems to get treated a bit differently, and doesn't show this concatenative effect. This seems a bit daft. I was thinking that maybe exportfs should be stripping off the filename decoration after all: I'm not sure I can think of a scenario where sending it through Rerror is helpful. but this still doesn't feel right. exportfs is having to remove a decoration on an error string that the kernel added for the benefit of the user. I think the kernel should probably not be doing this. The outcome is nice, but maybe it would be better if it were done in libc, perhaps in the implementation of %r. Maybe the system call functions in user space could record the pathname in a global buffer when an error occurs, and %r could use that. Exportfs could then forward the error string without the kernel decorating it, and we could leave Linux v9fs alone. Would that be better? Although English is my first language, I live among people for whom it mostly isn't, so I see these issues every day. There's definitely a tension between the obvious practicality of using English as a "Lingua Franca" and not wanting to lose other languages, which is important to some people. The whole internationalisation thing is complicated and political, and thus hopefully something we can ignore here most of the time! I probably shouldn't have mentioned it. :D -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M000b059a9ae286c6ee128aea Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: Hello, RPi fixes and bind -b trouble
Well, my daughter has kindly given me a couple of her spare raspberry pis - a pi4 and a pi5. I've put 9front on the pi4, and have been having a look at it. I had to use the Raspberry Pi Imager program this time. windd didn't work (she thinks this might be a feature of the later Pis). There are 5 computers on my desk now! :) I'm running out of room for my teacup. I have a 2-port kvm, and I could be using drawterm for the Plan 9 installations, but if I do that I won't be motivated to finish implementing a drawterm for my own system... I tried mounting a 9front exportfs on Linux, but encountered the same problem I mentioned earlier: the error strings don't match what v9fs on Linux is expecting, with effect that I can't create files from Linux on a file system exported from 9front either. I think the problem is that v9fs tries to open a file before creating it: if it doesn't get an error that it can recognise as corresponding to ENOENT it won't attempt the subsequent create message. v9fs currently does an exact match on the error string returned in Rerror and will recognise any of the following strings: "No such file or directory" "directory entry not found" "file does not exist" "file not found" "illegal path element" "directory entry is not allocated" as being different ways of saying ENOENT (which has the numeric value of 2). It looks like the 4th Edition kernel prefixes these with the filename in quotes, e.g.: "'foo' file does not exist" I spoke earlier about my patch to exportfs(4) to get around this. On 9front, though, I'm seeing: "not found: 'foo'" or "file does not exist: 'foo'" depending on which file system is involved. Even if I apply my exportfs patch to 9front, it looks like hjfs(1) has introduced "not found" as a new way to say "file does not exist", and v9fs is not going to understand that either... I suppose I could add a special case in exportfs to translate that into "file not found". I see several problems: The first and most obvious one is that v9fs doesn't cope well with the variety of ways ENOENT gets encoded over 9p. The second is that there seems to be an assumption that: a) errors are only ever immediately reported to the user, and b) the user speaks English... For me, I have a very analogous problem with the 9p client file system adapter on my own OS: I'm thinking at this point that I'm going to have to extract the currently fixed strings it recognises into a file (which I can edit to keep up with the times) and also use regular expressions so that the entries in that file can actually pattern-match any embedded quoted filename, allowing for future creativity in the ways it can get inserted into the error string returned via Rerror... I'm not sure I quite believe I'm seriously contemplating doing this. Perhaps I'm missing something obvious. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M73bf1acd981988335f610ae6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: broken link in cat-v
On Sat, Feb 10, 2024 at 06:04:33PM +1100, Rob Pike wrote: > Thanks, but I don't know who owns that site these dayse. I'll forward to > the 9fans mailing list. > > -rob > > > On Sat, Feb 10, 2024 at 6:20 AM Douglas McIlroy < > douglas.mcil...@dartmouth.edu> wrote: > > > The link to plan 9 from outer space in sam.cat-v is wrong. I found a good > > link in wikipedia. > > sl runs cat-v.org these days. I'd recommend replacing the link to plan9.us with a link to https://9fans.github.io/plan9port/ I don't see a link to Plan 9 from Outer Space, so I reckon Doug was referring to the p9p link. khmOuter Space, so I reckon Doug was referring to the p9p link. khm ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Ta8cbb6bfc2a04158-M4159540a82e0f5d5917997df Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: Hello, RPi fixes and bind -b trouble
Mystery solved: the bug was in my Ropen code. I was not returning QTDIR in the qid.type when opening the directory. I'd hazard a guess that because Rwalk said it was a directory, but then Ropen said it was a file, sysfile.c:read() in the Plan 9 kernel didn't call unionread(), so only the first directory in the union mount was read. Maybe?? Anyway it works now. :) ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M4b5259ac6e9ab466572bbbf3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: Hello, RPi fixes and bind -b trouble
> On Sunday, 4 February 2024, at 4:46 PM, moody wrote: >> I would bet money on this being a bug in your walk code. That seems entirely possible! Thanks for the pointer. ------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M36646a9bf5752d3ed7b0863f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
