Re: [9fans] List of companies that use Plan 9.
On Mon, May 13, 2024, at 21:56, hiro wrote: > citation needed https://sosenterprise.sd.gov/BusinessServices/Business/FictitiousDetail.aspx?CN=078243101203005056228191044241171252181195229085 -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M5340b592e5058450c0beef4f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
Yes, that is curious. On Mon, May 13, 2024, at 22:59, G B wrote: > 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 -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M0837cfbe72e42ecd86478a75 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)
> has an active community all working on the same fork. The most eye > opening thing about this whole long exchange is that the old Plan9 > people are largely working alone on private forks. apart from the ones who moved to plan9port on mac os. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mac4ea9b7e2d8cf96e33ca20d 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 5:56 PM ibrahim via 9fans <9fans@9fans.net> wrote: > > > 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 / see discussions + participants + delivery options Permalink no -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-Mfd2a21c2adc4b2b4c023bb8b 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)
Suggesting ways to try out a Plan9 system is not a hypothetical for me. I put myself out there doing videos demonstrating Plan9 systems, and so I get questions all the time. Everyone has access to amd64 machines. The used market is flooded with retired quad core amd64 Dell and Lenovo office desktops. Most experienced Linux users who want to try a Plan9 system can also navigate qemu. 9Front covers all these use cases. The typical problems that arise are lack of drivers, which 9Legacy is even worse with. Besides the hardware issue, the biggest benefit from 9Front is that it has an active community all working on the same fork. The most eye opening thing about this whole long exchange is that the old Plan9 people are largely working alone on private forks. On Mon, May 13, 2024 at 10:02 AM Ori Bernstein wrote: > > On Mon, 13 May 2024 11:56:20 -0400 > "ibrahim via 9fans" <9fans@9fans.net> wrote: > > > I'm wondering why you don't adjust it so that 9front can also be run there. > > Because 9vx is a hacky dead end; it fundamentally > only runs (and can only run) on 32-bit x86. It > works because of a quirk of 32-bit x86 addressing. > > Linux distros are wanting to drop support for > running 32 bit binaries (Ubuntu tried in 2019, > others have tried on and off). > > Macs no longer ship x86 processors, and even the > ones that have x86 cpus dropped support for 32-bit > binaries 5 years ago. > > I have no idea what windows is up to. > > Basically, qemu/drawterm works better in more or > less every way. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M97b5cd86db3eb04bac7ae05a 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, 13 May 2024 11:56:20 -0400 "ibrahim via 9fans" <9fans@9fans.net> wrote: > I'm wondering why you don't adjust it so that 9front can also be run there. Because 9vx is a hacky dead end; it fundamentally only runs (and can only run) on 32-bit x86. It works because of a quirk of 32-bit x86 addressing. Linux distros are wanting to drop support for running 32 bit binaries (Ubuntu tried in 2019, others have tried on and off). Macs no longer ship x86 processors, and even the ones that have x86 cpus dropped support for 32-bit binaries 5 years ago. I have no idea what windows is up to. Basically, qemu/drawterm works better in more or less every way. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M5d593a074dd95a16887f6a83 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 5/13/24 10:56, ibrahim via 9fans wrote: > > 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. In your original email, you only mention: > After you have collected enough experience I would stay with 9legacy and > ignore 9front. The reasoning for this is never given. By your immediate followup and complaining about licensing and "being REAL plan9" I figured this was your reason. 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 ? Because I don't know why I should care about 9vx when every computer has hardware accelerated virtual machines. What is less frustrating I wonder? Telling someone to use some random unmaintained x86 userspace emulation shim or using any existing virtual machine programs that are actively maintained, packaged for their operating system, and much much more documented? We have spent a decent chunk of time making sure our code works under these modern virtual machines (and with acceleration), including writing things like virtio drivers. A virtual machine combined with a local instance of drawterm to access it is how I suggest most new users get started. > > 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 ? I honestly thought that you were suggesting against using 9front for the reasons I stated, if you were indeed basing everything off of 9vx compatibility due to your opinion of it being a better choice than something like qemu or HyperV then I apologize for assuming incorrectly. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te051f230f2656bbb-M339bd65f5ceeb02ce28eedf7 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)
> As others have pointed out I think an "official" classification is of little > pragmatic benefit, but it would be nice > to not have this tired conversation every email thread. Of course I have > reason to believe that even if the p9f were > to recognize 9front as being a "Plan 9" it still would not be good enough. i don't really care that much how things are named, as long as 9front is recognized at all, for the value that it brings to the whole community. this would align very well with the official stated goals of the p9f: "promote and support continued research into lightweight distributed systems based on the ideas presented in the Plan 9 operating system and related technologies". -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M7fd2aebde93ca02686793fc8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
Jacob Moody: > I'm very glad we were able to communicate this and thank you for taking > the time to talk about this here in this thread. And thanks to you for pointing me to the GTX 4090 and https://crack.sh Both real eye openers. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2c85ac49e8d6a52c1732cc2c 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 5/13/24 04:22, ibrahim via 9fans wrote: >> 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. By this line of logic the only thing stopping 9front from "being Plan 9" is recognition from the p9f no? That could theoretically change any day, the p9f still continues to hold meetings where such things could be decided. As others have pointed out I think an "official" classification is of little pragmatic benefit, but it would be nice to not have this tired conversation every email thread. Of course I have reason to believe that even if the p9f were to recognize 9front as being a "Plan 9" it still would not be good enough. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Md28a80fc0abf285efca61e42 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)
Quoth Jacob Moody : > If there were a couple of open source Plan 9 forks that each saw > active development and we were having issues with keeping the source > code ported between them sure I could see this as a reason to do > that. We have however never found that the source code proved much of > a challenge Actually -- to that point: if someone is looking for organizational work to do, that work could be finding people with private forks of Plan 9, and then convincing them to make it public. Following that up with cataloguing the differences between the various forks would also be useful work. Harvey has actually done a decent amount of this, putting the forks into branches in the repo: https://github.com/Harvey-OS/harvey -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mc49aaeab71da21ea885cbe31 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 5/13/24 06:56, ibrahim via 9fans wrote: > 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. 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. If there were a couple of open source Plan 9 forks that each saw active development and we were having issues with keeping the source code ported between them sure I could see this as a reason to do that. We have however never found that the source code proved much of a challenge for porting things from 9legacy et all. > > 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. Well that is the topic of discussion now, after you got bored of making incorrect claims about our license, and after we got here from some new user asking about whether or not they should use 9legacy or 9front. Your initial objection to 9front being recommended was licensing issues, that was proven false, so now the goal posts have moved to "well you're not REAL plan 9" as if that has any sort of impact to any user asking for which code to use to learn the system. Seems like not wanting to call OpenBSD a "UNIX" because it's not technically a direct release from AT&T/Nokia/whoever. While technically true, you'd get a pretty similar response if you went around telling people to use research UNIX over OpenBSD. 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. If these things are a showstopper for people they are usually explicitly stated. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mfe4bba2bf6b9ee5d32d4978b 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)
Quoth ibrahim via 9fans <9fans@9fans.net>: > 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. > it's a sad system that can't even host its own sources. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mf6f39b8373cc63a544f217ef 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] one weird trick to break p9sk1 ?
> My point was only about the advantage of p9sk3 over p9sk1, not to > compare it with anything else. The intent was to counter the implication > that p9sk1 is terrible and completely broken, by suggesting that the One error in our naming is that it might imply dp9ik completely replaced p9sk1. quickly googling for the terms reveals others have amplified this misunderstanding. Instead, dp9ik *extends* the p9sk1 by an additional authentication procedure. Forgive the confusion everybody. > (with no change to the protocol on-the-wire). Of course it doesn't mitigate > the problem of users negligently choosing weak passwords. dp9ik has the > extra advantage of doing that too, by removing the opportunity for offline > dictionary attacks. Thank you for finding a better way to phrase that one also. This was indeed one of cinap's design goals. It is pretty near to the minimal amount of changes needed in the system that would achieve secure continued use of passwords with the same user experience as before. I have not seen another implementation that does quite the same either in the real world. Remember, everybody else just gave up on passwords, while here, passwords are now secure by design: Secure your authservers well, and you will have a very very modern and extremely unique security system, unalike anything else out there. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M5da7bb9c49b6387cc74e0a3b 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 we want to share contributions between forks we need a compatibility layer > if we don't want to we don't have to. adding more compatibility layers doesn't generally makes sharing of contributions easier. the more forks diverge the harder it will be, no matter how many layers you add. unless you actually *want* this complexity and measure your achieved progress in terms of how much complexity you generated... i prefer a more pragmatic approach, as much as 9front has diverged it's very easy to apply patches using the well known git principles based on a common initial commit. did you ever hear of the git implementation that ori has implemented? and, to contradict my earlier point maybe you could even call that "our compatibility layer". > 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. we even respect and worship the coding styles of bell-labs. so there would be no break, with or without compatibility layer, as long as you didn't break with that one either. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M4eb82cf98fb7d990a3b189f6 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] one weird trick to break p9sk1 ?
On 5/13/24 05:18, Richard Miller wrote: > Jacob and Ori, thank you for filling in some more details. Without > the specifics I had been making some wrong assumptions about where > the exact threat was. > > I think I now have a clearer picture: > > It's not particularly p9sk1 which is vulnerable, but the protocol > for ticket request / response, which leaks enough information to > allow offline exploration of user keys. The contribution of p9sk1 > is that its handshake protocol helpfully reveals a valid user name - > ie the authid - which can be used by an attacker to make a legitimate > ticket request, without any need for eavesdropping or guessing at > user names. Yes that is how I understand it. > > So, if you have an authentication service exposed to the ipv4 > internet (or to the ipv6 internet with a findable address), and > your authid or a known or guessable userid has a weak enough > password to succumb to a dictionary search, it's probably right > to say that a random attacker could make a cpu connection or > mount your file service with an afternoon's work on consumer > hardware. > > Nobody needs to have weak passwords, though. Using the !hex attribute > instead of !password with factotum, and/or using secstore(1), makes it > easy to have a randomly generated DES key with the full 56 bits of > entropy. This makes the attacker do more work ... but not all that > much more. I hadn't kept up with how powerful commodity GPUs have > become. (My most recent experience with High Performance Computing > involved transputer arrays and Cray T3Ds. Nowadays I specialise in > low performance computing.) It appears that investment of a few > thousand dollars and a few days compute time (maybe less if using > cloud services) is enough for a full brute-force exploration of the > single-DES keyspace. I'm very glad we were able to communicate this and thank you for taking the time to talk about this here in this thread. Thank you, Jacob Moody -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Me0355c116b61ac991520ac58 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
[9fans] golang dependency on python3
me: >> (OK, I know that's delusional because I've installed go. But maybe >> not for much longer, as google seems determined to introduce python3 >> as a dependency.) Charles Forsyth: > wat!?? citation: https://github.com/golang/go/issues/62025 -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf65bc1d5ccdc425e-M67a81834c7b5494c98da1cfe Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
>> (OK, I know that's delusional because I've installed go. But maybe >> not for much longer, as google seems determined to introduce python3 >> as a dependency.) > > wat!?? The Go team is willing to replace the CI builders written in Go by the Chromium builders, which are written in Python 3. So the CI will depend on Python to build Go and run tests. -- David du Colombier -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M0d3f319c9a3405266fa53279 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
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-M4e82602865db0e13e96d88a7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
> > (OK, I know that's delusional because I've installed go. But maybe > not for much longer, as google seems determined to introduce python3 > as a dependency.) wat!?? On Mon, 13 May 2024 at 13:48, Richard Miller <9f...@hamnavoe.com> wrote: > cro...@gmail.com: > > As for the proposed strawman `p9sk3`, I fail to see what advantage > > that would have over dp9ik > > My point was only about the advantage of p9sk3 over p9sk1, not to > compare it with anything else. The intent was to counter the implication > that p9sk1 is terrible and completely broken, by suggesting that the > threat of brute-forcing the entire keyspace can be mitigated with a > small, local and very easy to understand variation to the ticket service > (with no change to the protocol on-the-wire). Of course it doesn't > mitigate > the problem of users negligently choosing weak passwords. dp9ik has the > extra advantage of doing that too, by removing the opportunity for offline > dictionary attacks. > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Ma0d5d024db1989861dc8d9aa Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
cro...@gmail.com: > As for the proposed strawman `p9sk3`, I fail to see what advantage > that would have over dp9ik My point was only about the advantage of p9sk3 over p9sk1, not to compare it with anything else. The intent was to counter the implication that p9sk1 is terrible and completely broken, by suggesting that the threat of brute-forcing the entire keyspace can be mitigated with a small, local and very easy to understand variation to the ticket service (with no change to the protocol on-the-wire). Of course it doesn't mitigate the problem of users negligently choosing weak passwords. dp9ik has the extra advantage of doing that too, by removing the opportunity for offline dictionary attacks. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M86b283cc4c651efabdf9c3da 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] List of companies that use Plan 9.
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-M59ea1a26d206f6c427eaef2b 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] one weird trick to break p9sk1 ?
me: >> I try to take a >> minimum-intervention approach ... cro...@gmail.com: > Forgive my saying it, Richard, but I think this is a somewhat overly > staid view of things. You're welcome to say it. My minimalist attitude amounts to a religion, and therefore I don't need to justify it ☺. I know I'm at one extreme end of the scale. None of my machines are even running 9legacy, it's all 4th edition with enough hand-picked patches to make it useable for me. I wouldn't dream of pushing anyone else to follow my example. But personally, my Plan 9 network is a refuge from 21st century complexity, where I can in theory read and understand the infrastructure from top to bottom. (OK, I know that's delusional because I've installed go. But maybe not for much longer, as google seems determined to introduce python3 as a dependency.) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M7407b85b6cdcbb4f959b4ae9 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)
ibrahim you're further inventing misleading terms and definitions that contribute nothing useful to any reader. the "means of porting" is something that you have to go and invest the work into, that's it. it's time, sweat, work. technology cannot help you much with this, renaming the forks also changes nothing about the amount of work this will take. write the code, merge the code, that's the process now. anybody who cares just sends patches that anybody can import into their favourite fork to the mailinglist here, or they publish here some links to a git or hg repository so that others can check the latest updates there. that's my experience so far. 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. On Mon, May 13, 2024 at 1:02 PM ibrahim via 9fans <9fans@9fans.net> wrote: > > 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 / see discussions + participants + delivery options Permalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9dc00fdf72b76118da9b1e28 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 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. can you please share it with us? i couldn't find a plan9 distribution named "based on plan9" in my google assistant. > 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. respect includes not spreading lies and FUD about it without understanding what you're talking about. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M8fb04a2e74b6854d67d0988e 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, 13 May 2024 06:52:37 -0400, "ibrahim via 9fans" <9fans@9fans.net> wrote: > > 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. Indeed, it would be strange to find them, given that we don't ship freetype. -- Ori Bernstein -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Me2f7348f05a060950815e38e 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)
> Note that 9front never claimed to be a continuation, but a fork. The people > who desperately cry for a continuation of plan 9 either claim 9front as a > continuation, or explicitly not. yeah, I did, but that's just me. for me 9front is the perfect continuation of plan9, both in code and in spirit. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5034b3b390be1c4258d946cd 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 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? On Mon, May 13, 2024 at 11:45 AM ibrahim via 9fans <9fans@9fans.net> wrote: > > 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 / see discussions + participants + delivery options Permalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mf321ac8aca2f14bae5943865 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] one weird trick to break p9sk1 ?
> Have a look at authsrv(6) in the manual. The authenticator sends a > pair of tickets to the client, one encrypted with the client's own > key and one encrypted with the server's key. That's what allows > both the client and server to authenticate each other. i stand corrected. also i confused cpuserver and authserver. and i still don't have the details paged in, so thank you for contributing another good summary :) > Yes, I think you're probably right. I was thinking in terms of minimum > lines of code to change, but other factors are also important. i generally use the same tactic in regards to minimal changes, and i certainly see it isn't used often enough in the field. i think the rule also doesn't conflict with what happened: replacement of outdated systems without good incremental path for future improvements, with useful high-quality software developed from scratch. it can happen, despite the late hype around "enshittification". lastly, rules are meant to be broken. the details just happen to matter more than the rule of thumb here. and again, anybody who knows crypthographers, since the approach is rather modern, please help share cinap's paper, maybe even the code, have a look, the more eyes the more better ;) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M925311bc2b8c990e6ba917ed 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] one weird trick to break p9sk1 ?
> So, if you have an authentication service exposed to the ipv4 > internet (or to the ipv6 internet with a findable address), and > your authid or a known or guessable userid has a weak enough > password to succumb to a dictionary search, it's probably right > to say that a random attacker could make a cpu connection or > mount your file service with an afternoon's work on consumer > hardware. not only will they be able to make the connection, but they will be authenticated as a user that is probably more permissive than the 'none' user. for all the newbies reading this thread, this is the second reminder to read the auth paper. it is truly excellent ;) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Md3a8fecbefcca9c49ceeb87e 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)
> namespaces. A few of the commands have changed, like rimport and rcpu > , instead of import and cpu. and just in case some readers might not know, since this topic came up: the reason why it's not called import and cpu is explicitly for backwards(4th ed./legacy/other forks) comaptibility. personally i wouldn't even bothered, but as you can see the people practically in charge of 9front (not me) care about the whole community, even if this comes with costs like namechanges, duplication. > > In my case, 9Legacy was the gateway drug. I started with Miller's Pi > images on 3 rpi 3B's, so I could run a file server, cpu server, and correct me if i'm wrong, but IIRC 9legacy and miller's distributions were distinct? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcf81b6e9ab8c9838aca2deec 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)
13.05.2024 12:12:49 ibrahim via 9fans <9fans@9fans.net>: > 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. I guess that's the difference in nomenclature. For me, a plan9 system is a system in the spirit of plan 9 from bell labs, using the concepts described in the papers and implemented in the bellabs sources. Similar to unix, which includes all the unices. For you, plan9 is explicitly plan 9 from bell labs. I don't think any of those definitions is "wrong" because there's no official definition. But I believe that we have to talk about the different systems using words. If I think about grouping operating systems based on concepts, we have all the doses, all the windowses, all the unices, and then (based on your definition) "plan 9 and forks of plan 9". 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. > 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. I wish I contributed more. I once tried to get at least one mention per 9front release, but that didn't work out. Again, I think it's just different wording we use for "plan9 (systems)". -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9096f4a332e1934a9993293d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
23h...@gmail.com: > ... the server and client keys are the > same in p9sk1 as far as i understood. i would welcome public/private > key system though (is that what you were thinking of when separating > "server key" and "client key". that would add yet another set of > features that are currently missing. Have a look at authsrv(6) in the manual. The authenticator sends a pair of tickets to the client, one encrypted with the client's own key and one encrypted with the server's key. That's what allows both the client and server to authenticate each other. 23h...@gmail.com: > ... it seems to me that > concentrating on 3DES just for the sake of similarity to DES is taking > ocam's razor slightly too far. Yes, I think you're probably right. I was thinking in terms of minimum lines of code to change, but other factors are also important. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Mbc9a161e11837e5c464b2cd7 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 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. are you trying to imply 9front wouldn't have better code for using hardware made in the last millenium? i wasted a lot of years consuming bad linux advice about how to break my computer, that i could have spent with higher quality plan 9 systems, if the 9front bootloader was available back then. i like being able to boot from both master and slave IDE ports for example. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mdffe5281f4566330f79d10e2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
Jacob and Ori, thank you for filling in some more details. Without the specifics I had been making some wrong assumptions about where the exact threat was. I think I now have a clearer picture: It's not particularly p9sk1 which is vulnerable, but the protocol for ticket request / response, which leaks enough information to allow offline exploration of user keys. The contribution of p9sk1 is that its handshake protocol helpfully reveals a valid user name - ie the authid - which can be used by an attacker to make a legitimate ticket request, without any need for eavesdropping or guessing at user names. So, if you have an authentication service exposed to the ipv4 internet (or to the ipv6 internet with a findable address), and your authid or a known or guessable userid has a weak enough password to succumb to a dictionary search, it's probably right to say that a random attacker could make a cpu connection or mount your file service with an afternoon's work on consumer hardware. Nobody needs to have weak passwords, though. Using the !hex attribute instead of !password with factotum, and/or using secstore(1), makes it easy to have a randomly generated DES key with the full 56 bits of entropy. This makes the attacker do more work ... but not all that much more. I hadn't kept up with how powerful commodity GPUs have become. (My most recent experience with High Performance Computing involved transputer arrays and Cray T3Ds. Nowadays I specialise in low performance computing.) It appears that investment of a few thousand dollars and a few days compute time (maybe less if using cloud services) is enough for a full brute-force exploration of the single-DES keyspace. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2867926d1deafb39060269df 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 Mon, May 13, 2024 at 5:53 AM ibrahim via 9fans <9fans@9fans.net> wrote: ... > The reasoning is simple : p9f owns the rights for the final release and Nokia > has made this release available under a MIT license. Every one who uses plan9 > not only to toy around or his/her personal use but also as a system which > he/she distributes like I do can't afford risks with code integrated from > sources like 9front. There are some libraries taken from 9front derived from > other open source projects like freetype (truetype) where copyright notices > are absent and this isn't the only library where in code comments the sources > are named but the original copyright notices are absent. 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. > plan9 as represented by p9f has a clear license all parts which are not MIT > licensed are marked as such but code back ported from other forks like 9front > contain code where I have doubts if those are really under an MIT license huh? which files exactly do you have doubts about? > I respect your fork 9front but I won't and can't use it. 9front isn't plan9 > from my perspective. Plan 9 is the final release with patches for the files > from sources I can be sure that those aren't taken from open source projects > by copy and paste. The moment I and others who use plan9 for distribution or > embed it on systems we have to be absolutely sure about the sources of the > code. I can trust Bell Labs, Nokia, p9f but I won't trust some guys who toy > around with their fork of plan9. the department in bell labs/nokia that you like to trust here doesn't exist any more. maybe you can contribute to 9front to make it more trustable. > The first thing I am doing after downloading an iso from 9 legacy is to > remove all files which were not part of the final plan9 release. The second > thing I have always to do is removing all patches from the iso which came > from sources I can't be sure if they really followed licensing rules. The > third thing I have to do before distributing my fork of plan9 is to remove > fonts ghostscript diff page and other parts of the system which would infect > the distribution media to make sure the created system is not depending on > viral licensed code. I am glad that you have such important production systems running that you have to consider even license legalities. i hope more companies will make serious money (and be able to afford such other related overheads as legal advice) using excellent software like plan9 in the future. 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. > My fork isn't the only one which gets distributed. I'm sure there exist > millions of devices with plan9 integrated without anyone noticing except for > those who look into the documentation where the MIT licensed copyright is > placed. how is your fork called? where can i find it? where can i find hints to what these millions of devices might be? i would love to have a commercial plan9 device. > If people from forks like 9front are talking about numbers of their users I > always have to laugh. My fork is right now used by about 500 people per > semester more users. And be assured this is an unimportant number. This is great for the whole community. I hope we can find out more. I don't see it as competition at all, and please relax yourself, too! :) Thank you for making it possible for so many people to learn from Plan 9. > Not a single developer who uses plan9 for distributed systems, commercial > products will dare to use a system like 9front as the sources. The reason is > quite simple : > > 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. 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. > 9front is a fork your fork I respect your work. But all your commits and > enhancements are absolutly useless for people who intend or use plan9 not > only to play around with this system but make professional use of it. The > first thing such people have to check is the way you handle licenses. 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. > Therefore 9
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
So, with that definition, the system described in the paper "Plan 9 from bell labs" is not plan9, because it describes any system that uses the same concepts? So, plan9 is like UNIX™ and there's no such thing as a concept about plan 9? Note that 9front never claimed to be a continuation, but a fork. The people who desperately cry for a continuation of plan 9 either claim 9front as a continuation, or explicitly not. People who want a continuation of plan 9 missed the train a long time ago. There won't be an official continuation of plan 9, and that's a fact, because p9f won't do it. It's not the devs who claim a continuation of plan9, it's the people asking for it. 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. 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. Similar to how UNIX™ is a unix, as is any linux system, bsd and mac. 13.05.2024 11:23:16 ibrahim via 9fans <9fans@9fans.net>: >> 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
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, May 13, 2024, at 18:22, ibrahim wrote: ... > 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. I think that is a constructive way to view it. ... > 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. That is a good point. However, the question becomes how can we contribute to the original source repository? It would be nice to have the baseline updated so that more forks can be created with fewer updates needed to be relevant. Vic -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M0bef10695cfd8b7a823b2ce4 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)
are you contributing the team? and paying the team? On Mon, May 13, 2024 at 2:22 AM wrote: > > The complexity of communication in this medium often necessitates detailed > discussions. You highlighted the need for additional personnel to manage the > workload (e.g. do the work). From my perspective, this requires a > well-defined vision, clear objectives, and a prioritized list of deliverables > to align efforts effectively. Currently, it seems the role of product > managers is collectively held, though it's unclear who exactly is > responsible. Typically, a team of two or more individuals would focus on > these deliverables. In past projects, I've seen the use of a project board > to keep everyone updated on tasks—an approach known as "information radiator" > in project management. I'm open to other methods if you had something > different in mind that I may have overlooked. If you are considering a > meritocracy, I would recommend caution. Experience has shown that what we > truly need is increased collaboration and unity, rather than a system that > could potentially encourage competition and division. I apologize if my > message is obtuse, I am trying to keep this message concise, I can expound > more for clarity. I hope my explanation helps. > > Vic > > > On Mon, May 13, 2024, at 03:36, o...@eigenstate.org wrote: > > that's not what I said. > > > > Quoth vic.thac...@fastmail.fm: > >> I agree that having a clear vision and charter is essential before forming > >> a team. Regarding building an inclusive Plan 9 community that encompasses > >> multiple groups, it's important to establish common goals and values that > >> resonate with all members. What are your thoughts on creating open > >> channels for dialogue and collaboration? How can we ensure that everyone > >> feels valued and heard? This approach could foster a more cooperative and > >> inclusive environment. > >> > >> Vic > >> > >> > >> On Sun, May 12, 2024, at 16:19, pl...@room3420.net wrote: > >> > "tl;dr: you need people doing the work before you can try > >> > to organize them; the way to get people doing the work is > >> > to bootstrap it by doing work and showing value." [from Ori]. > >> > or > >> > "Don't be the kid who can't play [whatever]ball but wants to teach > >> > everybody and be the team coach, just because he read a book." -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1f94e4e212bbb9d19954d53a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] List of companies that use Plan 9.
how did you find out about this company, i never saw it mentioned anywhere before? On Mon, May 13, 2024 at 10:43 AM wrote: > > Thank you, Sirjofri, nice idea. > > There are two private U.S. companies that are investing, developing, and > using a closed source Plan 9 distribution called ᴁOS (aka ᴁ9). The companies > have been in existence since 2020. > > Nantahala Holdings, LLC > Nantahala Operations, LLC (dba Nantahala Systems) > > Vic > > > On Mon, May 13, 2024, at 17:10, sirjofri wrote: > > Hey all, > > > > Just about one topic mentioned by ibrahim: > > > > You mentioned that 9front can't be plan 9 in your perspective because > > of this licensing and the "origin" of the licensing. > > > >> 9front isn't plan9 from my perspective. Plan 9 is the final release with > >> patches for the files from sources I can be sure that those aren't taken > >> from open source projects by copy and paste. > > [1] > > > > 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. > > > > [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.) > > > > --- > > > > 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 sometimes thought about building a list of companies that use plan 9 > > technology, just so people can get involved with them, and now that I'm > > searching for a new job that's even more interesting for me personally. > > (Not sure if I want to do plan 9 as $dayjob, but I could see it as an > > option.) That topic should end up in a new thread however (or even a > > DM). > > > > sirjofri -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M68bdf06983f3f12b72383d9b 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 from 9front advices to use 9front without success many of 9front getting aggressive and thats not right. -- 9fans: 9fans Permalink: https://9fans.topicbox.co
[9fans] List of companies that use Plan 9.
Thank you, Sirjofri, nice idea. There are two private U.S. companies that are investing, developing, and using a closed source Plan 9 distribution called ᴁOS (aka ᴁ9). The companies have been in existence since 2020. Nantahala Holdings, LLC Nantahala Operations, LLC (dba Nantahala Systems) Vic On Mon, May 13, 2024, at 17:10, sirjofri wrote: > Hey all, > > Just about one topic mentioned by ibrahim: > > You mentioned that 9front can't be plan 9 in your perspective because > of this licensing and the "origin" of the licensing. > >> 9front isn't plan9 from my perspective. Plan 9 is the final release with >> patches for the files from sources I can be sure that those aren't taken >> from open source projects by copy and paste. > [1] > > 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. > > [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.) > > --- > > 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 sometimes thought about building a list of companies that use plan 9 > technology, just so people can get involved with them, and now that I'm > searching for a new job that's even more interesting for me personally. > (Not sure if I want to do plan 9 as $dayjob, but I could see it as an > option.) That topic should end up in a new thread however (or even a > DM). > > sirjofri -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tad3dc0c93039a7d2-M3cce19283b50acc036e39c94 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)
Hey all, Just about one topic mentioned by ibrahim: You mentioned that 9front can't be plan 9 in your perspective because of this licensing and the "origin" of the licensing. > 9front isn't plan9 from my perspective. Plan 9 is the final release with > patches for the files from sources I can be sure that those aren't taken from > open source projects by copy and paste. [1] 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. [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.) --- 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 sometimes thought about building a list of companies that use plan 9 technology, just so people can get involved with them, and now that I'm searching for a new job that's even more interesting for me personally. (Not sure if I want to do plan 9 as $dayjob, but I could see it as an option.) That topic should end up in a new thread however (or even a DM). sirjofri -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Md69516f3df7ddcfdffa75613 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 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 Sun, May 12, 2024 at 7:17 PM 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? Is the > learning curve the same for both varieties? Would it help getting to know > 9front if I spent a bit of time with her older sister 9legacy? Can 9legacy be > considered the gateway drug to 9front? > I await the scorching flames for my great impudence of interjecting into a > vociferous discussion with such a pragmatic tangent! Having done a variety of Plan9 and 9Front installs on various pieces of hardware and VMs... I would, and do, tell most people to just go with 9Front. It does all the same core Plan9 concepts. It all speaks 9P and has per-process namespaces. A few of the commands have changed, like rimport and rcpu , instead of import and cpu. It has a few new things, like auto mounting usb thumb drives in /shr. When you work your way up to managing a grid, there are a lot of changes, but nothing that really gets away from the core concepts. I run 9Front on plenty of old hardware. I boot it on mips based router boards with only 64MB of ram. I run it on very new but rather meager and cheap hardware and have done videos demonstrating it. I've ran it on Virtualbox in Windows on a 10 year old laptop, and bhyve on a FreeBSD file server with pci passthrough to the nic, both cases running on a single core. 9Front does all the stuff classic Plan9 does as far as teaching one the basic concepts of Plan9. It also has the advantage of more hardware drivers and an active community adding more drivers and documentation. I see a lot of arguments about 9Legacy having a more pristine license. But nothing about it doing anything better than 9Front. Or any arguments that 9Front does anything in a very non-Plan9 way. In my case, 9Legacy was the gateway drug. I started with Miller's Pi images on 3 rpi 3B's, so I could run a file server, cpu server, and terminal. But the difficulty moving from that to some retired Dell office computers is why I jumped over to 9Front. The 9Front usb install image just works better on a wider variety of old and new hardware. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M3a7329a3b7b10d8eefdd1453 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 03:27:16AM -0400, ibrahim via 9fans wrote: > > 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. 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. There was a TeX engine called pdfTeX, that replaced DVI with PDF. The end result was that they depended on an external PDF library that they have to adapt and, soon, they simply drop the updates and froze the version they used because they were unable to follow the evolution of this external code they depended upon. Furthermore, if you are very careful about licenses, the more you add dependencies, the more you have to be careful. PDF doesn't protect for some claim, some day, from a lawyers' gang, pretending that PDF files contain the result of some infringement of some patent---it is notorious that the crazy US system of patents have led some big enterprises to have a huge patents portfolio, some patents being real ones, and some being crap, but just in order to frighten opponents: "don't try to play this game with me, or I will be able to demonstrate that you are using a number of my patents, and I will sue you to death." Problem: what will become of these portfolios if the big enterprise is declining and is bought by financial sharks? Furthermore, having the obligation to add a Linux system to render a man page is not exactly simplification. Is it? ;-) -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ http://nunc-et-hic.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M673079c862fdba46a4c15ae0 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
