Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 7:33 AM, ron minnich wrote: > At no time in all this was there any evidence of incorrect behavior on the > part of 9front. None. Zip. Zero. Zed. They have always been careful to follow > the rules. > > Further, when people in 9front wrote new code, they released it under MIT, > and Cinap among others was very kind in letting Harvey use it. > > So, Ibrahim, I can not agree with your statement here. > 0.2.4.4 - PRAISE FOR 9FRONT’S BOLD ACTION, RE: LICENSING > > Any additions or changes (as recorded in git history) made by 9front are > provided under the terms of the MIT License, reproduced in the file > /lib/legal/mit, unless otherwise indicated. > > Read: /lib/legal/NOTICE. > > 0.2.4.5 - Everyone loves the Plan 9 license (circa 2021) > > In 2021, the Plan 9 Foundation (aka P9F—no relation) convinced Nokia to > re-license all historical editions of the Plan9 source code under the MIT > Public License. > > As a consequence, all of 9front is now provided under the MIT License unless > otherwise indicated. > > Re-read: /lib/legal/mit This is a citation of the current FQA and in older ones predating the relicensing by Nokia the same paragraphs were present. If those statements from the 9front documentation are correct than your MIT relicensing predates the moment where the owner of plan9 Nokia made such a decission. This paragraph regarding the "bold action" of relicensing appeard before the owners of the code made it available under MIT license. Please correct me if I'm wrong. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M87ce4c9f9e82fb2fa4b938f2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
libttf was one example and because it made its way into 9legacy i inspected it. > Are you implying that a majority of users are using Plan9 in a commercial > setting? That seems a bit absurd. > For personal use I think these license issues (if they do even exist) are of > no concern. I think you are greatly > exaggerating the possible issue here for your average user. I could tell you about more than two dozens of projects alone at german universities where plan9 was used in medical sensor devices. Calling something absurd which lies beyond your experience gives reason enough to not name any of those projects. > Again, I think in your situation of distributing hardware with plan 9 or > whatever, then it makes sense to do whatever your lawyer says. > I think advising against using 9front for every user on these grounds though > is misleading at best. Its not the lawyer who is responsible to avoid copyright issues its the duty of the developer. Not the lawyer gets sued but the one who distributes the system. Everyone is free to use 9front. But I won't use 9front for a distributed system because I don't have the legal certainty as with plan9. I know who developed plan9 and I know that Nokia owned it before they relicensed it. But I don't this trust in 9front code. And so I wouldn't advise others who make use of plan9 in ways like I do to use 9front. > Do you also remove the Lucida and printer fonts? These were released as part > of the original source but have interesting claims as to the ability to > redistribute them. > Do you also strip out the parts of ape that include ancient GNU utilities? > Are you running your system without a diff and patch? Of course I removed all fonts from the system. I have my own font library with scaleable vector fonts based on caligraphy. As I stated before I removed any GNU utilities ghostview postscript page and all tools which have clearly GPL licenses are removed. Patch and diff are replaced with BSD licensed versions taken from OpenBSD. Those are the rules. > And Java runs on a billion devices. And I can't distribute Java, Linux, commercial operating systems because those can't be distributed as you please their licenses don't allow distribution as the MIT license does. > I'm quite curious as to your definition of "professional" in one where none > of the work done by 9front would be seen as beneficial. I can assure you I respect your fork and the state you reached. Professional use as a distributed operating system needs legal certainty. If you include code from sources and I use your fork than I am the one who is doomed not you because you are no legal entity. I have to make sure that my distributions has no legal issues. The way you answer to such licensing problems makes clear you don't care about them and take the issue lightly. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5c4cdcf81f1cd752663d81e5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Sun, May 12, 2024 at 8:53 PM ibrahim via 9fans <9fans@9fans.net> wrote: > 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 > I do not agree with what you are saying here. I was involved in the license discussions starting in 2003, and was involved in both the GPL release and the more recent MIT license release. The choice of license, both times, was made by the same person in Bell Labs, even as the Bell Labs corporate parent changed. In fact, in 2013, we were *required* to use the GPL, whereas in the later release, the GPL was specifically mentioned as a license we could *not* use. I won't pretend to understand why. At no time in all this was there any evidence of incorrect behavior on the part of 9front. None. Zip. Zero. Zed. They have always been careful to follow the rules. Further, when people in 9front wrote new code, they released it under MIT, and Cinap among others was very kind in letting Harvey use it. So, Ibrahim, I can not agree with your statement here. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M3d0b948ec892b2d0de94a895 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)
Some excellent advice so far I have to say. A reasonable assumption is that I am at least a linux user (entirely accurate, I installed slackware from floppies a long time ago when the world was new and 486es were still moderately expensive). Would a BASIC interpreter count as an operating system I wonder? Well no matter, I don't have to live with one these days. Anyway, a nice pathway from linux to a plan9 of some description is quite helpful and I am very thankful. I should be rather careful with that DES implementation in 9legacy, is it the 1970s version or 3DES? Quite shocked if it is the former. Some very good advice indeed, thanks to everyone! I look forward to blundering around with 9front too I must say. On Monday, May 13, 2024, Jacob Moody wrote: > On 5/12/24 22:52, ibrahim via 9fans wrote: > > On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote: > >> When people suggest tossing that all out for a minimally patched 4e, I > think some people rightfully feel a bit annoyed. That's a lot of baby that > goes out with that bathwater. > > > > It's Davids decission what he includes as patches for the 4th edition > but I would toss everything out of 9legacy which isn't part of the 4th > edition or contributed by the team members at Bell Labs from their archives > as enhancements. > > > > 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. > > > > 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 as you state in your documentation cause deriving from a different > license or taking large amounts of code doesn't remove viral licenses like > LGPL or GPL. > > If you have a list of libraries that you feel do not represent their > license providence by /lib/legal/NOTICE in our 9front tree, let me know we > should probably get that updated. > Our libttf is not derived from freetype as I understand it. > > > > > It would be in the interest of plan9 and all who professionally use it > in embedded systems or as a distributed operating system to keep suspicious > code out of the 9legacy CD. If really necessary to provide such > contributions or back ports I wouldn't place them in the system folders but > as it was in the past in contrib folders for additional download. The risks > to infect a clearly licensed system gifted by Nokia to all of us to make > best use of it for free commercial private embedded ... > > solutions are to high and I would really prefer it when nothing from > forks like 9front would take its way into the 9legacy CD ROM which is > defined as : > > > > Plan 9 archives, reference releases of Plan 9. > > > > 9legacy, Plan 9 with many useful patches applied. Download page > has an > > installation CD image including 386, amd64, and arm kernels and > binaries; > > a bootable USB image for 386; a bootable SD card image for > Raspberry Pi; > > and virtual disk images for QEMU and GCE. > > > > The 4th Edition distribution from Bell Labs: > > live CD/install CD/USB image, installation notes, > > browse the source, additional software > > Are you implying that a majority of users are using Plan9 in a commercial > setting? That seems a bit absurd. > For personal use I think these license issues (if they do even exist) are > of no concern. I think you are greatly > exaggerating the possible issue here for your average user. > > > > > I 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 moment > > FSF or another organisation starts to suit me because they recognized > that some guy at any forked system has copy pasted code from a viral > licensed project I am the one who has to take the consequences. > > Again, I think in your situation of distributing hardware with plan 9 or > whatever, then it makes sense to do whatever your lawyer says. > I think advising
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On 5/12/24 22:52, ibrahim via 9fans wrote: > On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote: >> When people suggest tossing that all out for a minimally patched 4e, I think >> some people rightfully feel a bit annoyed. That's a lot of baby that goes >> out with that bathwater. > > It's Davids decission what he includes as patches for the 4th edition but I > would toss everything out of 9legacy which isn't part of the 4th edition or > contributed by the team members at Bell Labs from their archives as > enhancements. > > 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. > > 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 as > you state in your documentation cause deriving from a different license or > taking large amounts of code doesn't remove viral licenses like LGPL or GPL. If you have a list of libraries that you feel do not represent their license providence by /lib/legal/NOTICE in our 9front tree, let me know we should probably get that updated. Our libttf is not derived from freetype as I understand it. > > It would be in the interest of plan9 and all who professionally use it in > embedded systems or as a distributed operating system to keep suspicious code > out of the 9legacy CD. If really necessary to provide such contributions or > back ports I wouldn't place them in the system folders but as it was in the > past in contrib folders for additional download. The risks to infect a > clearly licensed system gifted by Nokia to all of us to make best use of it > for free commercial private embedded ... > solutions are to high and I would really prefer it when nothing from forks > like 9front would take its way into the 9legacy CD ROM which is defined as : > > Plan 9 archives, reference releases of Plan 9. > > 9legacy, Plan 9 with many useful patches applied. Download page has > an > installation CD image including 386, amd64, and arm kernels and > binaries; > a bootable USB image for 386; a bootable SD card image for Raspberry > Pi; > and virtual disk images for QEMU and GCE. > > The 4th Edition distribution from Bell Labs: > live CD/install CD/USB image, installation notes, > browse the source, additional software Are you implying that a majority of users are using Plan9 in a commercial setting? That seems a bit absurd. For personal use I think these license issues (if they do even exist) are of no concern. I think you are greatly exaggerating the possible issue here for your average user. > > I 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 moment > FSF or another organisation starts to suit me because they recognized that > some guy at any forked system has copy pasted code from a viral licensed > project I am the one who has to take the consequences. Again, I think in your situation of distributing hardware with plan 9 or whatever, then it makes sense to do whatever your lawyer says. I think advising against using 9front for every user on these grounds though is misleading at best. > > 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. Do you also remove the Lucida and printer fonts? These were released as part of the original source but have interesting claims as to the
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
Thank you, Ibrahim, for your comments. I can see where my suggestions do not make sense. It is too difficult a challenge for the communities to envisage. If no one can envisage it, then no one can do it. Vic On Mon, May 13, 2024, at 12:52, ibrahim wrote: > On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote: >> When people suggest tossing that all out for a minimally patched 4e, I think >> some people > rightfully feel a bit annoyed. That's a lot of baby that goes out with > that bathwater. > > It's Davids decission what he includes as patches for the 4th edition > but I would toss everything out of 9legacy which isn't part of the 4th > edition or contributed by the team members at Bell Labs from their > archives as enhancements. > > 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. > > 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 as you state in your documentation cause deriving from a > different license or taking large amounts of code doesn't remove viral > licenses like LGPL or GPL. > > It would be in the interest of plan9 and all who professionally use it > in embedded systems or as a distributed operating system to keep > suspicious code out of the 9legacy CD. If really necessary to provide > such contributions or back ports I wouldn't place them in the system > folders but as it was in the past in contrib folders for additional > download. The risks to infect a clearly licensed system gifted by Nokia > to all of us to make best use of it for free commercial private > embedded ... solutions are to high and I would really prefer it when > nothing from forks like 9front would take its way into the 9legacy CD > ROM which is defined as : > > Plan 9 archives, reference releases of Plan 9. > > 9legacy, Plan 9 with many useful patches applied. Download > page has an > installation CD image including 386, amd64, and arm kernels > and binaries; > a bootable USB image for 386; a bootable SD card image for > Raspberry Pi; > and virtual disk images for QEMU and GCE. > > The 4th Edition distribution from Bell Labs: > live CD/install CD/USB image, installation notes, > browse the source, additional software > > 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 moment FSF or another organisation starts to suit me because they > recognized that some guy at any forked system has copy pasted code from > a viral licensed project I am the one who has to take the consequences. > > 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. > > 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. > > 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. > > 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
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 5:09 AM, Jacob Moody wrote: > When people suggest tossing that all out for a minimally patched 4e, I think > some people rightfully feel a bit annoyed. That's a lot of baby that goes out with that bathwater. It's Davids decission what he includes as patches for the 4th edition but I would toss everything out of 9legacy which isn't part of the 4th edition or contributed by the team members at Bell Labs from their archives as enhancements. 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. 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 as you state in your documentation cause deriving from a different license or taking large amounts of code doesn't remove viral licenses like LGPL or GPL. It would be in the interest of plan9 and all who professionally use it in embedded systems or as a distributed operating system to keep suspicious code out of the 9legacy CD. If really necessary to provide such contributions or back ports I wouldn't place them in the system folders but as it was in the past in contrib folders for additional download. The risks to infect a clearly licensed system gifted by Nokia to all of us to make best use of it for free commercial private embedded ... solutions are to high and I would really prefer it when nothing from forks like 9front would take its way into the 9legacy CD ROM which is defined as : Plan 9 archives, reference releases of Plan 9. 9legacy, Plan 9 with many useful patches applied. Download page has an installation CD image including 386, amd64, and arm kernels and binaries; a bootable USB image for 386; a bootable SD card image for Raspberry Pi; and virtual disk images for QEMU and GCE. The 4th Edition distribution from Bell Labs: live CD/install CD/USB image, installation notes, browse the source, additional software 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 moment FSF or another organisation starts to suit me because they recognized that some guy at any forked system has copy pasted code from a viral licensed project I am the one who has to take the consequences. 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. 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. 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. 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. 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
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
The approach is effective in open source projects when there are leaders who excel in communication, provide a clear vision, and prioritize objectives. Its effectiveness diminishes in the absence of strong communication and planning. Clear expectations generally facilitate easier collaboration and sustained engagement. However, I am not referring to the 2% of individuals who engage only if it aligns with their own ideas. Prima donnas will act independently regardless, but for the majority who seek a constructive environment, like myself, establishing a structured system or model is beneficial. Competence levels vary within the community, and any system necessitates knowledge transfer. This can be achieved through mentorship or onboarding sponsorship programs. The onboarding process involves several stages: 1. Not knowing what you don't know, where clear direction is essential. 2. Knowing that you don't know, where coaching is necessary. 3. Knowing and performing tasks with conscious effort, where occasional correction may be required. 4. Performing tasks instinctively, where little to no correction is needed. There seems to be an implicit expectation that contributors should be at stage four, but many in the 9fans community may not yet be at this level. While I'm not an expert, my initial experiences with Plan 9 were enriched by several mentors who were willing to guide me and others; but in today's environment that might be a big ask, so you might be right. Vic On Mon, May 13, 2024, at 10:32, o...@eigenstate.org wrote: > I don't think this approach has ever worked in > the open source world -- it always starts with > someone building something useful. The vision > and goal is defined by the work being done. > > After something useful is built, people start > to join in and contribute. > > After enough people join in, it makes sense to > have more organization. > > Quoth vester.thac...@fastmail.fm: >> 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-Mee6775a4b239f8cd0dc57264 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/12/24 20:46, Dan Cross wrote: > On Sun, May 12, 2024 at 9:33 PM wrote: >> I don't think this approach has ever worked in >> the open source world -- it always starts with >> someone building something useful. The vision >> and goal is defined by the work being done. >> >> After something useful is built, people start >> to join in and contribute. >> >> After enough people join in, it makes sense to >> have more organization. > > I remain mystified by the desired end state here. For all intents and > purposes, as far as the wider world is concerned, 9front is plan 9. > I'm not sure I'd want that burden, to be honest, but that's just me. > That aside, realistically, 9front is the only thing in the plan 9 > world that has energy behind it. This doesn't seem about any "end result" here. I read it as more a direct response to whatever bureaucratic/project management/deliverables/hard core team Vic is imagining. This is pointing out that everything around organization falls out from people doing work and others choosing to work with them, which I agree with. However your question about the end state is interesting. As it has been discussed ad nauseam here, there is fairly high discontent at there being anything even close to acknowledgement about 9front being Plan 9. So much so that things like the p9f go out of their way to avoid talking about us. You seem to think as I do that this has had litle practical impact. However it is what I would call unfortunate. I don't bring this up to rehash this issue, just to explain part of what I feel the current situation is. We often find ourselves in these situations because of bogus claims made at 9front's expense. We're here in this thread because of such claims that 9front and 9legacy were wildly incompatible. > > On the other hand, there's 9legacy, which pulls together some useful > patches and attempts to carry on in a manner imagined to be closer to > what Bell Labs did. That's fine; it's low activity, but people are > busy, have lives to live, all that stuff. Regardless, some people seem > to be genuinely offended by its existence, and I can't really > understand why. I can really only speak for myself but I think some frustration comes at the direct comparisons between the two. 9front has seen a lot of work. As qwx mentioned we have 10,555 commits on top of our initial import from 2011 and we continue to receive bug fixes and improvements at regular intervals. Just talking about raw hours invested I think these projects are in different ballparks. When people suggest tossing that all out for a minimally patched 4e, I think some people rightfully feel a bit annoyed. That's a lot of baby that goes out with that bathwater. > > Meanwhile, the people actually doing any work are in communication > with one another, regardless of what label is applied to the software > running on their individual computers, which is as it should be. I think it's worth mentioning that I feel like this has improved since iwp9 was continued. I've learned so much by interacting more with the "old guard" and there has been much more discussions and code being passed around. I encourage more folks to join us in working on things. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M75f50b19e10239ae6e23e2e5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
Sorry for the double post ... try to use an older version of 9legacy cause after the integration of 9git in the latest CD a full system compile will stop. I don't know why such software which can't be considered a patch to the 4th edition became part of the src tree instead of putting it in a contrib folder. I personally would expect from 9legacy being 4th edition with only patches for files which were part of the official release and contributions made by original developers from bell (like compilers from personal archives aso). The first thing I do when testing a new release of 9legacy is to clean up the system from such enhancements. But thats another topic ... -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M9df35c16c3c2bbeb846ea0cf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Monday, 13 May 2024, at 4:17 AM, clinton wrote: > If I were completely naive to actually running plan9 but with many clues > about other operating systems and hardware, would it be better for me to > install 9legacy on some mildly obsolescent but still quite serviceable and > reliable hardware, or start with 9front on something more modern? If you are familar with linux and have a veteran computer with 8 GB I would start with 9vx and a 9legacy iso. This will simplify your first steps. Otherwise you will have to get used to so many different things at once that you will perhaps loose your confidence. The advantages taking this root are : i) No filesystem problems ii) No hardware problems iii) The ability to edit files in an editor of your choice iv) The ability to start all kinds of services from terminal, cpu server, file server aso on a single computer to try all those things out compile kernels write scripts try them out. ... After you get used to rio, acme, acid rc the next step I would suggest is build a network out of virtual machines with the filesystem of your choice. And even while doing so using one 9vx emulation will help you establish connections to all those virtual machines and allow you to make adjustments. After you have collected enough experience I would stay with 9legacy and ignore 9front. 9vx allows you to create boot media for old as well as new computers. You find everything necessary on the 9legacy CD (but also things which shouldn't have been back ported to 9legacy). If you need help walking this road don't hesitate to ask. I think a cold start with plan9 9legacy or 9front with so many different things will just take the fun away but using 9vx you will keep the fun and can immediatly start using plan 9 and 9vx is extremly fast. 9vx has some shortcomings like missing support for some devices but don't mind them cause you will end up installing plan9 on bare metal after you get used to it anyway. To sum up : 1. Step : Linux + 9vx + 9legacy (started for times) 2. Step : qemu + 9legacy (cpu, fileserver, terminal) + 9vx (for adjustments and as a rescue terminal) 3. Step : qemu + 9legacy (cpu, fileserver, terminal) + drawterm 4. Step : Bare metal as you like -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Ma839ab8f84a91bbe25ff8ed3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, May 13, 2024 at 11:46:59AM +0930, clinton wrote: > I await the scorching flames for my great impudence of interjecting into a > vociferous discussion with such a pragmatic tangent! If you don't intend to have anything hanging out with a direct internet connection, just use whatever looks cool and is supported by the hardware you have at hand. If your installation is going to be subject to transmitting packets across the internet, 9front has better crypto. As has been mentioned recently in this list, porting that crypto back to 9legacy may be a fun way to get your hands dirty, if you're into that sort of thing. Either way you're not really missing anything by picking one to play with, and if you feel like you are, it will still be there when you feel like trying the other one out. Reading all the stuff in /sys/doc is a great way to start learning on either distribution. khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M4264d1a4bf2b692f45d27184 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
9front and 9legacy look very similar to the untrained eye. The way you use them is nearly identical, but there are a lot of small bits of polish added to 9front, as well as a number of larger tools and utilities. Even 9legacy binaries run on 9front. (And vice versa, as long as the binaries don't depend on new services like mixfs [the audio mixer], or new capabilities in existing services, such as custom response headers in webfs) There's a few things 9legacy has that 9front doesn't. These are mostly kernels for some of the older virtex FPGAs, the removal of some obsolete architectures like sparc, and a few utilities like jtagfs. But as far as I'm aware, most of the desirable changes made in 9legacy and p9p have already been imported into 9front. If I've missed some, let me know, and they may just show up. Quoth clinton : > As a very long time lurker to the plan9 mailing list, something > occasionally catches my eye strewn amongst the arcana. The very first > computer I ever actually touched was in 1979, it had these state of the ark > mag stripe cardboard cards which held the enormous amount of 2kb. It wasn't > mine, my engineer father brought it home from work and it took up a large > proportion of the dining room table. I was very strictly punished for > laying a finger on the thing, as it was astronomically expensive and my > father was responsible for it. This was just the start of my masochistic > relationship with these fiddly cantankerous things you see. > Over the years I have seen a $5,500 486dx 2 66mHz be reduced to a $25 pile > of junk less than a decade later, a $200 60gb hard drive forlornly sitting > by the side of the road in hard rubbish a decade later, and many other > similar saddening examples. > There of course is a need for using old hardware these days as it seems so > wasteful to just junk something with a 1gHz CPU in it when you fondly > remember your days with a MOS 6510! > 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! > > On Monday, May 13, 2024, wrote: > > > I don't think this approach has ever worked in > > the open source world -- it always starts with > > someone building something useful. The vision > > and goal is defined by the work being done. > > > > After something useful is built, people start > > to join in and contribute. > > > > After enough people join in, it makes sense to > > have more organization. > > > > Quoth vester.thac...@fastmail.fm: > > > 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
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
As a very long time lurker to the plan9 mailing list, something occasionally catches my eye strewn amongst the arcana. The very first computer I ever actually touched was in 1979, it had these state of the ark mag stripe cardboard cards which held the enormous amount of 2kb. It wasn't mine, my engineer father brought it home from work and it took up a large proportion of the dining room table. I was very strictly punished for laying a finger on the thing, as it was astronomically expensive and my father was responsible for it. This was just the start of my masochistic relationship with these fiddly cantankerous things you see. Over the years I have seen a $5,500 486dx 2 66mHz be reduced to a $25 pile of junk less than a decade later, a $200 60gb hard drive forlornly sitting by the side of the road in hard rubbish a decade later, and many other similar saddening examples. There of course is a need for using old hardware these days as it seems so wasteful to just junk something with a 1gHz CPU in it when you fondly remember your days with a MOS 6510! 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! On Monday, May 13, 2024, wrote: > I don't think this approach has ever worked in > the open source world -- it always starts with > someone building something useful. The vision > and goal is defined by the work being done. > > After something useful is built, people start > to join in and contribute. > > After enough people join in, it makes sense to > have more organization. > > Quoth vester.thac...@fastmail.fm: > > 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-Me459c34f6ecb73275ab783df Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Sun, May 12, 2024 at 09:46:12PM -0400, Dan Cross wrote: > > So what is it, exactly, that people want? The only people who feel like there's some conflict to resolve are people who do not use the software and have nothing to offer except for social commentary. This "us vs them" shit is only of interest to people who are unaware that the argument stopped happening years ago. "What people want" is in general to feel like they're helping, but these days it's a rare 9fan whose head is inserted so deep that middle management seems like the helping hand we all need. Everyone in the Plan 9 world has what they want, at this point, except maybe unlimited free time to pursue the to-do list. khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M945a6c0bfefaec1e617cb9f7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Sun, May 12, 2024 at 9:33 PM wrote: > I don't think this approach has ever worked in > the open source world -- it always starts with > someone building something useful. The vision > and goal is defined by the work being done. > > After something useful is built, people start > to join in and contribute. > > After enough people join in, it makes sense to > have more organization. I remain mystified by the desired end state here. For all intents and purposes, as far as the wider world is concerned, 9front is plan 9. I'm not sure I'd want that burden, to be honest, but that's just me. That aside, realistically, 9front is the only thing in the plan 9 world that has energy behind it. On the other hand, there's 9legacy, which pulls together some useful patches and attempts to carry on in a manner imagined to be closer to what Bell Labs did. That's fine; it's low activity, but people are busy, have lives to live, all that stuff. Regardless, some people seem to be genuinely offended by its existence, and I can't really understand why. Meanwhile, the people actually doing any work are in communication with one another, regardless of what label is applied to the software running on their individual computers, which is as it should be. So what is it, exactly, that people want? - Dan C. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M8382853c36f5465da5c3743a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Mon, May 13, 2024 at 09:21:20AM +0900, vester.thac...@fastmail.fm wrote: > unclear who exactly is responsible. Typically, a team of two or more > individuals would focus on these deliverables. nobody is "responsible" and there are no "deliverables" the people who covet bureaucracy have one to play with. if you are one of them, I suggest you visit plan9foundation.org and get involved with it. otherwise, there are no problems here to fix, all this shit you're talking about is in your head and has nothing to do with us. please don't respond to this message. khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5bee9f213d1f12c8ad7568a2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
I don't think this approach has ever worked in the open source world -- it always starts with someone building something useful. The vision and goal is defined by the work being done. After something useful is built, people start to join in and contribute. After enough people join in, it makes sense to have more organization. Quoth vester.thac...@fastmail.fm: > 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-M0a94c7102286e462a972a310 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
The 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-M0ee970051b70040b8daee3a5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
On Sun, May 12, 2024 at 12:44 PM Richard Miller <9f...@hamnavoe.com> wrote: > 23h...@gmail.com: > > sorry for ignoring your ideas about a p9sk3, but is your mentioning of > > ocam's razor implying that dp9ik is too complicated? > > is there any other reason to stick with DES instead of AES in > > particular? i'm not a cryptographer by any means, but just curious. > > My comments are about p9sk1; I'm not implying anything about other > algorithms. When working with other people's software, whether > professionally or for my own purposes, I try to take a > minimum-intervention approach: because it's respectful, because of > Occam's Razor, because of Tony Hoare's observation that software can > be either so simple that it obviously has no bugs, or so complicated > that it has no obvious bugs. Forgive my saying it, Richard, but I think this is a somewhat overly staid view of things. Software, as a constructed object, is maybe unique in that it is almost infinitely malleable, and the "minimum intervention" approach is often not terribly useful. As for being respectful of other people's software, who are these other people? The original authors of plan 9 are no longer involved, and indeed, the intellectual property has been transferred to the foundation, and by any reasonable standard the "community" has been given responsibility for the evolution of the code. As for the proposed strawman `p9sk3`, I fail to see what advantage that would have over dp9ik, except perhaps a less silly name. The person who wrote the paper on plan 9 security sees it being superior to what's there now, after all, and frankly he'd know better than either Occam or Tony Hoare. - Dan C. > I thought of 3DES in the first instance because of this desire to be > minimally disruptive. Support for DES is already there and tested. > 3DES only needs extra keys in /mnt/keys, and because 3DES encryption > with all three keys the same becomes single DES, there's a graceful > fallback when users have access only via an older client with > unmodified p9sk1. Obviously the server ticket would always be protected > by 3DES. > > This is only the first scratching of an idea, not implemented yet. > > I've got nothing against AES. I'm not a cryptographer either, but I did once > have to build a javacard implementation for a proprietary smartcard which > involved a lot of crypto infrastructure, and had to pass EMV certification. > Naturally that needed AES, elliptic curves, and plenty of other esoterica > to fit in with the existing environment and specifications. > -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M76fe847d3ed83b053ad32e0f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
On Sun, May 12, 2024 at 02:16:47PM +0100, Richard Miller wrote: > > That's quadrillions of years. Not what most people would call "trivial". > And that's generously assuming the implementation of meet-in-the-middle > is zero cost. Without meet-in-the-middle, we're looking at a 168-bit > keyspace and an even more preposterous number of years. Meanwhile, sweet32 exists, all this shit has already been prosecuted on other venues, and NIST shitcanned 3DES entirely last year. Not deprecated. Disallowed. Why? Because no matter how many numbers you paste into an email, it costs thirty bucks to crack it on someone else's ASIC farm. Pretending that getting access to $100k hash-cracking arrays is any more inconvenient than Uber Eats is straight-up disingenuous. It is extremely gross to be defending 3DES in 2024. You should know better. I don't particularly care if 9legacy adopts dp9ik, but there are people who will come reading this list archive down the road, and they'll be under the assumption that your arguments are in good faith. I hope they are not, because this crap is at best irresponsible. Occam's razor does not advocate ignoring the entire standardized best practices of the industry because you have emotional attachments to broken software and have used a pocket calculator to convince yourself you know better than everyone else on Earth. Advocating a switch to 3DES because it's backward-compatible with DES if you use it wrong is magnificent trolling, or depressing malpractice, depending on your intent. I can't ever know that, so I'll just state for posterity: kids, don't do this. It's a terrible plan. Do better, khm -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M6ef048148514ce58cf76ead5 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
Quoth o...@eigenstate.org:
> Quoth Richard Miller <9f...@hamnavoe.com>:
> > I'm using a new subject [was: Interoperating between 9legacy and 9front]
> > in the hope of continuing discussion of the vulnerability of p9sk1 without
> > too many other distractions.
> >
> > mo...@posixcafe.org said:
> > > If we agree that:
> > >
> > > 1) p9sk1 allows the shared secret to be brute-forced offline.
> > > 2) The average consumer machine is fast enough to make a large amount of
> > > attempts in a short time,
> > >in other words triple DES is not computationally hard to brute force
> > > these days.
> > >
> > > I don't know how you don't see how this is trivial to do.
> >
> > I agree that 1) is true, but I don't think it's serious. The shared secret
> > is
> > only valid for the current session, so by the time it's brute forced, it may
> > be too late to use. I think the bad vulnerability is that the ticket request
> > and response can be used offline to brute force the (more permanent) DES
> > keys
> > of the client and server. Provided, of course, that the random teenager
> > somehow
> > is able to listen in on the conversation between my p9sk1 clients and
> > servers.
> >
> > On the other hand, it's hard to know whether to agree or disagree with 2),
> > without knowing exactly what is meant by "large amount", "short time",
> > "computationally hard", and "trivial".
> >
> > When Jacob told me at IWP9 in Waterloo that p9sk1 had been broken, not
> > just theoretically but in practice, I was looking forward to seeing
> > publication
> > of the details. Ori's recent claim in 9fans seemed more specific:
> >
>
> The intial exchange sends across the challenges:
>
> C→S: CHc
> S→C: AuthTreq, IDs, DN, CHs, -, -
>
Oops -- wrong messages; these are the ones
you want to be breaking:
C→A: AuthTreq, IDs, DN, CHs, IDc, IDr
A→C: AuthOK, Kc{AuthTc, CHs, IDc, IDr, Kn}, Ks{AuthTs, CHs,
IDc, IDr, Kn}
Thanks to cinap for pointing that out.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M396fa4f83c1770df9b18c6f1
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)
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-M29a8b8a91cbfeb7a6d3a88d3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Interoperating between 9legacy and 9front
to answer my own question:
> Who is Eric Grosse?
>
author = "Russ Cox and Eric Grosse and Rob Pike and Dave
Presotto and Sean Quinlan",
title ="Security in {Plan 9}",
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-M180b18bbcd970ebf78b9ccea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
Quoth Richard Miller <9f...@hamnavoe.com>:
> I'm using a new subject [was: Interoperating between 9legacy and 9front]
> in the hope of continuing discussion of the vulnerability of p9sk1 without
> too many other distractions.
>
> mo...@posixcafe.org said:
> > If we agree that:
> >
> > 1) p9sk1 allows the shared secret to be brute-forced offline.
> > 2) The average consumer machine is fast enough to make a large amount of
> > attempts in a short time,
> >in other words triple DES is not computationally hard to brute force
> > these days.
> >
> > I don't know how you don't see how this is trivial to do.
>
> I agree that 1) is true, but I don't think it's serious. The shared secret is
> only valid for the current session, so by the time it's brute forced, it may
> be too late to use. I think the bad vulnerability is that the ticket request
> and response can be used offline to brute force the (more permanent) DES keys
> of the client and server. Provided, of course, that the random teenager
> somehow
> is able to listen in on the conversation between my p9sk1 clients and servers.
>
> On the other hand, it's hard to know whether to agree or disagree with 2),
> without knowing exactly what is meant by "large amount", "short time",
> "computationally hard", and "trivial".
>
> When Jacob told me at IWP9 in Waterloo that p9sk1 had been broken, not
> just theoretically but in practice, I was looking forward to seeing
> publication
> of the details. Ori's recent claim in 9fans seemed more specific:
>
The intial exchange sends across the challenges:
C→S: CHc
S→C: AuthTreq, IDs, DN, CHs, -, -
Because the challenge and IDs are sent as plain text, if I
can decrypt the client message with a key and find my known
plain text, that key will work to authenticate the client.
For example, if I have a ticket, and a trace of the first
few packets of the key exchange, I have enough information
to do something like this:
ticketpair = {
Kc{AuthTc, CHs, IDc, IDr, Kn},
Ks{AuthTs, CHs, IDc, IDr, Kn}
}
cmsg = ticketpair[0]
for(k in keyspace){
m = decrypt(k, cmsg)
if(m.CHs == CHs && m.IDs == IDs)
probably_bingo()
}
At that point, I need to guess the username, but this often
is relatively easy -- often, this is posted publicly; you
can probably guess that my user is 'ori' without trouble.
With those bits of information, you're able to complete a
new exchange as the client, and log in successfully.
The EFF was cracking DES keys in 22 hours back in 1998.
https://en.wikipedia.org/wiki/EFF_DES_cracker
Hardware, in particular GPUs, have gotten quite a bit
better since then.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-Mbe7e83e1e06339063e6d8e8f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
> I thought of 3DES in the first instance because of this desire to be > minimally disruptive. Support for DES is already there and tested. > 3DES only needs extra keys in /mnt/keys, and because 3DES encryption > with all three keys the same becomes single DES, there's a graceful > fallback when users have access only via an older client with > unmodified p9sk1. Obviously the server ticket would always be protected > by 3DES. it is not obvious to me. but then, you know more about 3des than me. ;) there are some fundamental features in dp9ik that are still missing even when you increase the "quality" of the DES key by giving it arbitrarily longer lengths. also, 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. > This is only the first scratching of an idea, not implemented yet. i can offer strictly less than that even. but it seems to me that concentrating on 3DES just for the sake of similarity to DES is taking ocam's razor slightly too far. though i do find it generally happens that security mechanisms are claimed to be "outdated", resulting in less scientific processes and more popularity contests than anything else, so putting extra scrutiny is highly welcome. on my part i'm simply trusting cinap on his intent and research as i have no hope to ever understand any details. but the dp9ik approach has some novelties which should make it worthwhile for security researchers to study. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M3d84204e405a926acc80c609 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)
Thank you, Hiro, for your insights. I apologize to everyone for my intense and fervent approach; I acknowledge that I often overlook subtleties. To add a bit of humor, even my son has saved my contact as "Rambo" in his mobile phone. :-) Vic On Mon, May 13, 2024, at 00:55, hiro wrote: > this is mostly wild speculation. further, the numbers are not > representative at all. > since the import of the (possibly redundent) 9k amd64 work from "labs" > (which in this case might mean geoff+charles?) 2 years ago there were > zero active developers contributing to 9legacy. > > please note, that stuff has been developed in the dark and without any > kind of open community process, also not in 9legacy but in some other > fork (that is unknown to me). it was pulled in by 9legacy but i have > no clue from where and why. > there was near zero communication about that other fork, and what it's > plan was, or who might want to use 9k nowadays, and for what purposes. > since this was not developed in the open and not discussed with 9front > people we are at this point largely ignorant of what 9k can do. i > would appreciate a more in-depth comparison if possible, though i fear > 9k is about as dead as plan9 4th edition (and 9legacy for that matter) > at this point. sorry for my doubts. > > On Sun, May 12, 2024 at 5:13 PM wrote: >> >> My understanding is that the initial request came from a 9legacy member to >> the 9front community, and the responses were quite intriguing. It has led me >> to ponder how we might bridge the gap between these communities. There seems >> to be conflict on both sides, and for some reason, I hold 9front to higher >> standards—perhaps because of our more idealistic roots. The core mission of >> 9front was always to advance the Plan 9 tradition, but not at the cost of >> alienating others. >> >> From what I observe, there seem to be only a handful of active developers >> remaining in each group. Initially, I believed we had around 30 active >> developers in 9front and about 7 in 9legacy, but I now think I may have >> overestimated these numbers. It appears that many are staying on the >> sidelines, possibly due to past grievances, which could explain the >> responses I've seen. The developers who are active might be overextended, >> while those who are less active might feel marginalized. >> >> Vic >> >> >> On Sun, May 12, 2024, at 22:23, q...@nopenopenope.net wrote: >> > On Sun May 12 14:43:17 +0200 2024, vester.thac...@fastmail.fm wrote: >> >> I don't mind the ad hominem attacks. I just hope things improve. I do >> >> find it ironic that I'm addressing the 9front community about >> >> collaboration and inclusiveness when I recall those as being two reasons >> >> for the inception of 9front. >> >> >> >> Vic >> > >> > You hit the nail on the head there. Why *are* you addressing just the >> > 9front community or assuming there is no willingness to collaborate on >> > its part? 9legacy users so far have expressed interest in someone >> > else porting dp9ik (David for instance) or demanded explanations about >> > DES cracking (Richard) or asked for others to port or fix fossil on >> > 9front (Lucio), but who explicitely said that they would like to put >> > in some work themselves and collaborate with 9front people? Maybe I'm >> > beginning to misremember the rest of the thread, am I missing >> > anything? Could you point to *specific examples*? >> > >> > 9front users demand code because they've already put in a lot of work >> > and it has been often ignored or dismissed, and because it would be up >> > to them to backport it to 9legacy -- why would they do double duty for >> > a system they don't use and a community which is generally not >> > receptive to their work? Also, do you realize that 9front right now >> > has upwards of 10500 changes in the repository, after 13 years? >> > Bringing 9legacy up to date as you've proposed would require a >> > colossal amount of work, all just to obtain... 9front. Do you >> > believe it has diverged to the point where backporting hardware >> > support, fixing bugs and broken or incomplete implementations and so >> > on will result in anything other than what 9front already is? >> > >> > You yourself demand everyone, especially the 9front community, to make >> > suggestions, start projects, etc. What about you? What do you >> > suggest to do and which projects would you take part in? That's what >> > "just send the code" implies. Promises don't fix bugs or help >> > implement programs, nor help fix this one-sided conversation. >> > >> > I'm asking these questions yet I fear that they will meet radio >> > silence or more empty walls of text, as it happens too often here >> > when asking "why" or how it came to this. I hope I'm wrong. >> > >> > Thanks, >> > qwx >> > >> > PS: I was about to hit send when I received Richard's mail. >> > Richard, thank you for the constructive and detailed response. >> > I hope this marks a turn of
Re: [9fans] one weird trick to break p9sk1 ?
23h...@gmail.com: > sorry for ignoring your ideas about a p9sk3, but is your mentioning of > ocam's razor implying that dp9ik is too complicated? > is there any other reason to stick with DES instead of AES in > particular? i'm not a cryptographer by any means, but just curious. My comments are about p9sk1; I'm not implying anything about other algorithms. When working with other people's software, whether professionally or for my own purposes, I try to take a minimum-intervention approach: because it's respectful, because of Occam's Razor, because of Tony Hoare's observation that software can be either so simple that it obviously has no bugs, or so complicated that it has no obvious bugs. I thought of 3DES in the first instance because of this desire to be minimally disruptive. Support for DES is already there and tested. 3DES only needs extra keys in /mnt/keys, and because 3DES encryption with all three keys the same becomes single DES, there's a graceful fallback when users have access only via an older client with unmodified p9sk1. Obviously the server ticket would always be protected by 3DES. This is only the first scratching of an idea, not implemented yet. I've got nothing against AES. I'm not a cryptographer either, but I did once have to build a javacard implementation for a proprietary smartcard which involved a lot of crypto infrastructure, and had to pass EMV certification. Naturally that needed AES, elliptic curves, and plenty of other esoterica to fit in with the existing environment and specifications. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T56397eff6269af27-M2003e6b5eb34ea3270a33bec 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)
this is mostly wild speculation. further, the numbers are not representative at all. since the import of the (possibly redundent) 9k amd64 work from "labs" (which in this case might mean geoff+charles?) 2 years ago there were zero active developers contributing to 9legacy. please note, that stuff has been developed in the dark and without any kind of open community process, also not in 9legacy but in some other fork (that is unknown to me). it was pulled in by 9legacy but i have no clue from where and why. there was near zero communication about that other fork, and what it's plan was, or who might want to use 9k nowadays, and for what purposes. since this was not developed in the open and not discussed with 9front people we are at this point largely ignorant of what 9k can do. i would appreciate a more in-depth comparison if possible, though i fear 9k is about as dead as plan9 4th edition (and 9legacy for that matter) at this point. sorry for my doubts. On Sun, May 12, 2024 at 5:13 PM wrote: > > My understanding is that the initial request came from a 9legacy member to > the 9front community, and the responses were quite intriguing. It has led me > to ponder how we might bridge the gap between these communities. There seems > to be conflict on both sides, and for some reason, I hold 9front to higher > standards—perhaps because of our more idealistic roots. The core mission of > 9front was always to advance the Plan 9 tradition, but not at the cost of > alienating others. > > From what I observe, there seem to be only a handful of active developers > remaining in each group. Initially, I believed we had around 30 active > developers in 9front and about 7 in 9legacy, but I now think I may have > overestimated these numbers. It appears that many are staying on the > sidelines, possibly due to past grievances, which could explain the responses > I've seen. The developers who are active might be overextended, while those > who are less active might feel marginalized. > > Vic > > > On Sun, May 12, 2024, at 22:23, q...@nopenopenope.net wrote: > > On Sun May 12 14:43:17 +0200 2024, vester.thac...@fastmail.fm wrote: > >> I don't mind the ad hominem attacks. I just hope things improve. I do > >> find it ironic that I'm addressing the 9front community about > >> collaboration and inclusiveness when I recall those as being two reasons > >> for the inception of 9front. > >> > >> Vic > > > > You hit the nail on the head there. Why *are* you addressing just the > > 9front community or assuming there is no willingness to collaborate on > > its part? 9legacy users so far have expressed interest in someone > > else porting dp9ik (David for instance) or demanded explanations about > > DES cracking (Richard) or asked for others to port or fix fossil on > > 9front (Lucio), but who explicitely said that they would like to put > > in some work themselves and collaborate with 9front people? Maybe I'm > > beginning to misremember the rest of the thread, am I missing > > anything? Could you point to *specific examples*? > > > > 9front users demand code because they've already put in a lot of work > > and it has been often ignored or dismissed, and because it would be up > > to them to backport it to 9legacy -- why would they do double duty for > > a system they don't use and a community which is generally not > > receptive to their work? Also, do you realize that 9front right now > > has upwards of 10500 changes in the repository, after 13 years? > > Bringing 9legacy up to date as you've proposed would require a > > colossal amount of work, all just to obtain... 9front. Do you > > believe it has diverged to the point where backporting hardware > > support, fixing bugs and broken or incomplete implementations and so > > on will result in anything other than what 9front already is? > > > > You yourself demand everyone, especially the 9front community, to make > > suggestions, start projects, etc. What about you? What do you > > suggest to do and which projects would you take part in? That's what > > "just send the code" implies. Promises don't fix bugs or help > > implement programs, nor help fix this one-sided conversation. > > > > I'm asking these questions yet I fear that they will meet radio > > silence or more empty walls of text, as it happens too often here > > when asking "why" or how it came to this. I hope I'm wrong. > > > > Thanks, > > qwx > > > > PS: I was about to hit send when I received Richard's mail. > > Richard, thank you for the constructive and detailed response. > > I hope this marks a turn of the tide. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M055332c471671f1509d5fa17 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
On 5/12/24 08:16, Richard Miller wrote: > I'm using a new subject [was: Interoperating between 9legacy and 9front] > in the hope of continuing discussion of the vulnerability of p9sk1 without > too many other distractions. > > mo...@posixcafe.org said: >> If we agree that: >> >> 1) p9sk1 allows the shared secret to be brute-forced offline. >> 2) The average consumer machine is fast enough to make a large amount of >> attempts in a short time, >>in other words triple DES is not computationally hard to brute force >> these days. >> >> I don't know how you don't see how this is trivial to do. > > I agree that 1) is true, but I don't think it's serious. The shared secret is > only valid for the current session, so by the time it's brute forced, it may > be too late to use. I think the bad vulnerability is that the ticket request > and response can be used offline to brute force the (more permanent) DES keys > of the client and server. Provided, of course, that the random teenager > somehow > is able to listen in on the conversation between my p9sk1 clients and servers. You do not need to listen between clients in order to get the DES key to begin brute forcing of the password. A malicious client can initiate an authentication attempt without any current information about the user and leave with the encrypted DES key to perform the known plaintext attack. > > On the other hand, it's hard to know whether to agree or disagree with 2), > without knowing exactly what is meant by "large amount", "short time", > "computationally hard", and "trivial". > > When Jacob told me at IWP9 in Waterloo that p9sk1 had been broken, not > just theoretically but in practice, I was looking forward to seeing > publication > of the details. Ori's recent claim in 9fans seemed more specific: There are unfortunately some issues with the original paper done by my friends that have prevented me from posting it publicly. I think it would still be good to document this issue in a more concrete fashion, I am sorry this has turned in to such a mess. >> From: o...@eigenstate.org >> ... >> keep in mind that it can literally be brute forced in an >> afternoon by a teenager; even a gpu isn't needed to do >> this in a reasonable amount of time. > > I was hoping for a citation to the experimental result Ori's claim was > based on. If the "it" which can be brute forced refers to p9sk1, it > would be very interesting to learn if there are flaws in the algorithm > which will allow it to be broken without breaking DES. My assumption > was that "it" was referring simply to brute forcing DES keys with a > known-plaintext attack. In that case, a back of the envelope calculation > can help us to judge whether the "in an afternoon" claim is plausible. > > In an afternoon from noon to 6pm, there are 6*60*60 seconds. To crack > a single DES key by brute force, we'd expect to have to search on average > half the 56-bit key space, performing about 2^55 DES encryptions. So how > fast would the teenager's computer have to be? > > cpu% hoc > 2^55/(6*60*60) > 1667999861989 > 1/_ > 5.995204332976e-13 > > 1667 billion DES encryptions per second, or less than a picosecond > per encryption. I think just enumerating the keys at that speed would > be quite a challenge for "the average consumer machine" (even with a GPU). > > A bit of googling for actual results on DES brute force brings up > https://www.sciencedirect.com/science/article/abs/pii/S138376212266 > from March 2022, which says: > "Our best optimizations provided 3.87 billion key searches per second for > Des/3des > ... on an RTX 3070 GPU." > > So even with a GPU, the expected time to crack a random 56-bit key would be > something like: > > cpu% hoc > 2^55/3.87e9 > 9309766.671567 > _/(60*60*24) > 107.7519290691 > > More than three months. The same paper mentions someone else's purpose-built > machine called RIVYERA which "uses 128 Xilinx Spartan-6 LX150 FPGAs ... > can try 691 billion Des keys in a second ... costs around 100,000 Euros". > Still not quite fast enough to break a key in an afternoon. >From what I found online a GTX 4090 has a single DES hash rate of 146.6 GH/s cpu% hoc 2^55/146.6e9 245762.599038 _/(60*60*24) 2.8444745259 So Dan's guess of a couple of days is more accurate then Ori's hyperbole, but not by much. > > When Jacob says "triple DES is not computationally hard to brute force these > days", > I assume this is just a slip of the keyboard, since p9sk1 uses only single > DES. > But if we are worried about the shaky foundations of p9sk1 being based on > single DES, Occam's Razor indicates that we should look for the minimal and > simplest > possible extension to p9sk1 to mitigate the brute force threat. The manual > entry for > des(2) suggests that the Plan 9 authors were already thinking along these > lines: > > BUGS > Single DES can be realistically
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
My understanding is that the initial request came from a 9legacy member to the 9front community, and the responses were quite intriguing. It has led me to ponder how we might bridge the gap between these communities. There seems to be conflict on both sides, and for some reason, I hold 9front to higher standards—perhaps because of our more idealistic roots. The core mission of 9front was always to advance the Plan 9 tradition, but not at the cost of alienating others. >From what I observe, there seem to be only a handful of active developers >remaining in each group. Initially, I believed we had around 30 active >developers in 9front and about 7 in 9legacy, but I now think I may have >overestimated these numbers. It appears that many are staying on the >sidelines, possibly due to past grievances, which could explain the responses >I've seen. The developers who are active might be overextended, while those >who are less active might feel marginalized. Vic On Sun, May 12, 2024, at 22:23, q...@nopenopenope.net wrote: > On Sun May 12 14:43:17 +0200 2024, vester.thac...@fastmail.fm wrote: >> I don't mind the ad hominem attacks. I just hope things improve. I do find >> it ironic that I'm addressing the 9front community about collaboration and >> inclusiveness when I recall those as being two reasons for the inception of >> 9front. >> >> Vic > > You hit the nail on the head there. Why *are* you addressing just the > 9front community or assuming there is no willingness to collaborate on > its part? 9legacy users so far have expressed interest in someone > else porting dp9ik (David for instance) or demanded explanations about > DES cracking (Richard) or asked for others to port or fix fossil on > 9front (Lucio), but who explicitely said that they would like to put > in some work themselves and collaborate with 9front people? Maybe I'm > beginning to misremember the rest of the thread, am I missing > anything? Could you point to *specific examples*? > > 9front users demand code because they've already put in a lot of work > and it has been often ignored or dismissed, and because it would be up > to them to backport it to 9legacy -- why would they do double duty for > a system they don't use and a community which is generally not > receptive to their work? Also, do you realize that 9front right now > has upwards of 10500 changes in the repository, after 13 years? > Bringing 9legacy up to date as you've proposed would require a > colossal amount of work, all just to obtain... 9front. Do you > believe it has diverged to the point where backporting hardware > support, fixing bugs and broken or incomplete implementations and so > on will result in anything other than what 9front already is? > > You yourself demand everyone, especially the 9front community, to make > suggestions, start projects, etc. What about you? What do you > suggest to do and which projects would you take part in? That's what > "just send the code" implies. Promises don't fix bugs or help > implement programs, nor help fix this one-sided conversation. > > I'm asking these questions yet I fear that they will meet radio > silence or more empty walls of text, as it happens too often here > when asking "why" or how it came to this. I hope I'm wrong. > > Thanks, > qwx > > PS: I was about to hit send when I received Richard's mail. > Richard, thank you for the constructive and detailed response. > I hope this marks a turn of the tide. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M1a00fb7eb0c7bb27d1f4d4d9 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] best place to be sent a patch
Thank you, David, hiro. I'm going to try to update libsec, if it works, I will send a patch to both David and here. 2024年5月12日(日) 23:39 hiro <23h...@gmail.com>: > > best is here on the mailinglist as you can attach the patches easily, > and even if david doesn't have time to respond, others here might help > you on the path, others might appreciate taking part in your adventure > and others might learn from it, too. i guess you can cc david if > getting into 9legacy is your goal. > > On Sun, May 12, 2024 at 4:31 PM Kyohei Kadota via 9fans <9fans@9fans.net> > wrote: > > > > I have a question: where is the *best* place to be sent a patch for > > 9legacy? replica? GitHub? or here? > > > > I'm motivated, but I don't like to get no feedback as before. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T57377acea9350f32-M05c32cbdd35d0a32d92b70e1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] best place to be sent a patch
best is here on the mailinglist as you can attach the patches easily, and even if david doesn't have time to respond, others here might help you on the path, others might appreciate taking part in your adventure and others might learn from it, too. i guess you can cc david if getting into 9legacy is your goal. On Sun, May 12, 2024 at 4:31 PM Kyohei Kadota via 9fans <9fans@9fans.net> wrote: > > I have a question: where is the *best* place to be sent a patch for > 9legacy? replica? GitHub? or here? > > I'm motivated, but I don't like to get no feedback as before. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T57377acea9350f32-M962c9a20d2e9f6001e37325f Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] best place to be sent a patch
> I have a question: where is the *best* place to be sent a patch for > 9legacy? replica? GitHub? or here? You can send it by e-mail to me. -- David du Colombier -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T57377acea9350f32-M1857485cd0bec8c20853f1f7 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] best place to be sent a patch
I have a question: where is the *best* place to be sent a patch for 9legacy? replica? GitHub? or here? I'm motivated, but I don't like to get no feedback as before. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T57377acea9350f32-Mc6c4a32fa25c0420b9839ba8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] one weird trick to break p9sk1 ?
sorry for ignoring your ideas about a p9sk3, but is your mentioning of ocam's razor implying that dp9ik is too complicated? is there any other reason to stick with DES instead of AES in particular? i'm not a cryptographer by any means, but just curious. On Sun, May 12, 2024 at 3:17 PM Richard Miller <9f...@hamnavoe.com> wrote: > > I'm using a new subject [was: Interoperating between 9legacy and 9front] > in the hope of continuing discussion of the vulnerability of p9sk1 without > too many other distractions. > > mo...@posixcafe.org said: > > If we agree that: > > > > 1) p9sk1 allows the shared secret to be brute-forced offline. > > 2) The average consumer machine is fast enough to make a large amount of > > attempts in a short time, > >in other words triple DES is not computationally hard to brute force > > these days. > > > > I don't know how you don't see how this is trivial to do. > > I agree that 1) is true, but I don't think it's serious. The shared secret is > only valid for the current session, so by the time it's brute forced, it may > be too late to use. I think the bad vulnerability is that the ticket request > and response can be used offline to brute force the (more permanent) DES keys > of the client and server. Provided, of course, that the random teenager > somehow > is able to listen in on the conversation between my p9sk1 clients and servers. > > On the other hand, it's hard to know whether to agree or disagree with 2), > without knowing exactly what is meant by "large amount", "short time", > "computationally hard", and "trivial". > > When Jacob told me at IWP9 in Waterloo that p9sk1 had been broken, not > just theoretically but in practice, I was looking forward to seeing > publication > of the details. Ori's recent claim in 9fans seemed more specific: > > > From: o...@eigenstate.org > > ... > > keep in mind that it can literally be brute forced in an > > afternoon by a teenager; even a gpu isn't needed to do > > this in a reasonable amount of time. > > I was hoping for a citation to the experimental result Ori's claim was > based on. If the "it" which can be brute forced refers to p9sk1, it > would be very interesting to learn if there are flaws in the algorithm > which will allow it to be broken without breaking DES. My assumption > was that "it" was referring simply to brute forcing DES keys with a > known-plaintext attack. In that case, a back of the envelope calculation > can help us to judge whether the "in an afternoon" claim is plausible. > > In an afternoon from noon to 6pm, there are 6*60*60 seconds. To crack > a single DES key by brute force, we'd expect to have to search on average > half the 56-bit key space, performing about 2^55 DES encryptions. So how > fast would the teenager's computer have to be? > > cpu% hoc > 2^55/(6*60*60) > 1667999861989 > 1/_ > 5.995204332976e-13 > > 1667 billion DES encryptions per second, or less than a picosecond > per encryption. I think just enumerating the keys at that speed would > be quite a challenge for "the average consumer machine" (even with a GPU). > > A bit of googling for actual results on DES brute force brings up > https://www.sciencedirect.com/science/article/abs/pii/S138376212266 > from March 2022, which says: > "Our best optimizations provided 3.87 billion key searches per second for > Des/3des > ... on an RTX 3070 GPU." > > So even with a GPU, the expected time to crack a random 56-bit key would be > something like: > > cpu% hoc > 2^55/3.87e9 > 9309766.671567 > _/(60*60*24) > 107.7519290691 > > More than three months. The same paper mentions someone else's purpose-built > machine called RIVYERA which "uses 128 Xilinx Spartan-6 LX150 FPGAs ... > can try 691 billion Des keys in a second ... costs around 100,000 Euros". > Still not quite fast enough to break a key in an afternoon. > > When Jacob says "triple DES is not computationally hard to brute force these > days", > I assume this is just a slip of the keyboard, since p9sk1 uses only single > DES. > But if we are worried about the shaky foundations of p9sk1 being based on > single DES, Occam's Razor indicates that we should look for the minimal and > simplest > possible extension to p9sk1 to mitigate the brute force threat. The manual > entry for > des(2) suggests that the Plan 9 authors were already thinking along these > lines: > > BUGS > Single DES can be realistically broken by brute-force; its > 56-bit key is just too short. It should not be used in new > code, which should probably use aes(2) instead, or at least > triple DES. > > Let's postulate a p9sk3 which is identical to p9sk1 except that it encrypts > the > ticket responses using 3DES instead of DES. The effective keyspace of 3DES is > considered to be 112 bits because of the theoretical meet-in-the-middle > attack. > So brute forcing a 3DES key with commodity hardware (including GPU) would be > expected to take something like: > > cpu% hoc > 2^111/3.87e9 >
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
I'm stepping back to listen. Perhaps you're not a software engineer. It is good to discuss before starting. Vic On Sun, May 12, 2024, at 22:11, hiro wrote: > why step back. step forward and put your money where your mouth is. > > On Sun, May 12, 2024 at 2:42 PM wrote: >> >> Thank you for sharing your thoughts. I want to clarify that my intention is >> not to exert control or disrupt, but to foster better collaboration between >> communities. I understand that there may be concerns about redundancy and >> approaches, which is why I believe a dialogue about our common goals and how >> best to achieve them is crucial. I do not see much collaboration between >> 9legacy and 9front. From what I gather from this thread, it seems that one >> community wants to lord over another and not be helpful. At least this is >> how it appears to a hobbyist like me. It would be nice if things were more >> cordial and helpful. >> >> I am assuming everyone here is a hobbyist, so I speak as a hobbyist. It’s >> important to recognize that our shared interest in advancing the Plan 9 >> community is at the heart of these discussions. I am here not for personal >> gain but to contribute positively. I think we all bring valuable >> perspectives that, when combined, can lead to innovative solutions that >> benefit everyone involved. >> >> Let’s focus on how we can work together more effectively. I am open to >> suggestions and willing to step back where needed to allow for a more >> collective approach. I believe that through constructive dialogue and a >> shared commitment to our community’s goals, we can overcome >> misunderstandings and move forward together. >> >> I don't mind the ad hominem attacks. I just hope things improve. I do find >> it ironic that I'm addressing the 9front community about collaboration and >> inclusiveness when I recall those as being two reasons for the inception of >> 9front. >> >> Vic >> >> >> On Sun, May 12, 2024, at 21:18, pl...@room3420.net wrote: >> > The collaboration is already here. You try to create tools that already >> > exist. I'd like to pinpoint why you have this unbelievable need for >> > control and wonder if you're not just working for Microsoft, Google or >> > the guy who stole Freenode and just try to disrupt the plan9 community. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M3bd18cdbea206712408fc2e4 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
On Sun May 12 14:43:17 +0200 2024, vester.thac...@fastmail.fm wrote: > I don't mind the ad hominem attacks. I just hope things improve. I do find > it ironic that I'm addressing the 9front community about collaboration and > inclusiveness when I recall those as being two reasons for the inception of > 9front. > > Vic You hit the nail on the head there. Why *are* you addressing just the 9front community or assuming there is no willingness to collaborate on its part? 9legacy users so far have expressed interest in someone else porting dp9ik (David for instance) or demanded explanations about DES cracking (Richard) or asked for others to port or fix fossil on 9front (Lucio), but who explicitely said that they would like to put in some work themselves and collaborate with 9front people? Maybe I'm beginning to misremember the rest of the thread, am I missing anything? Could you point to *specific examples*? 9front users demand code because they've already put in a lot of work and it has been often ignored or dismissed, and because it would be up to them to backport it to 9legacy -- why would they do double duty for a system they don't use and a community which is generally not receptive to their work? Also, do you realize that 9front right now has upwards of 10500 changes in the repository, after 13 years? Bringing 9legacy up to date as you've proposed would require a colossal amount of work, all just to obtain... 9front. Do you believe it has diverged to the point where backporting hardware support, fixing bugs and broken or incomplete implementations and so on will result in anything other than what 9front already is? You yourself demand everyone, especially the 9front community, to make suggestions, start projects, etc. What about you? What do you suggest to do and which projects would you take part in? That's what "just send the code" implies. Promises don't fix bugs or help implement programs, nor help fix this one-sided conversation. I'm asking these questions yet I fear that they will meet radio silence or more empty walls of text, as it happens too often here when asking "why" or how it came to this. I hope I'm wrong. Thanks, qwx PS: I was about to hit send when I received Richard's mail. Richard, thank you for the constructive and detailed response. I hope this marks a turn of the tide. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M6a6ba83828236109b9c23a90 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
"what you really want"... Fuck, now I have the Spice Girls song in mind : / -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M936ff37e60f8d604f9181726 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] one weird trick to break p9sk1 ?
I'm using a new subject [was: Interoperating between 9legacy and 9front] in the hope of continuing discussion of the vulnerability of p9sk1 without too many other distractions. mo...@posixcafe.org said: > If we agree that: > > 1) p9sk1 allows the shared secret to be brute-forced offline. > 2) The average consumer machine is fast enough to make a large amount of > attempts in a short time, >in other words triple DES is not computationally hard to brute force these > days. > > I don't know how you don't see how this is trivial to do. I agree that 1) is true, but I don't think it's serious. The shared secret is only valid for the current session, so by the time it's brute forced, it may be too late to use. I think the bad vulnerability is that the ticket request and response can be used offline to brute force the (more permanent) DES keys of the client and server. Provided, of course, that the random teenager somehow is able to listen in on the conversation between my p9sk1 clients and servers. On the other hand, it's hard to know whether to agree or disagree with 2), without knowing exactly what is meant by "large amount", "short time", "computationally hard", and "trivial". When Jacob told me at IWP9 in Waterloo that p9sk1 had been broken, not just theoretically but in practice, I was looking forward to seeing publication of the details. Ori's recent claim in 9fans seemed more specific: > From: o...@eigenstate.org > ... > keep in mind that it can literally be brute forced in an > afternoon by a teenager; even a gpu isn't needed to do > this in a reasonable amount of time. I was hoping for a citation to the experimental result Ori's claim was based on. If the "it" which can be brute forced refers to p9sk1, it would be very interesting to learn if there are flaws in the algorithm which will allow it to be broken without breaking DES. My assumption was that "it" was referring simply to brute forcing DES keys with a known-plaintext attack. In that case, a back of the envelope calculation can help us to judge whether the "in an afternoon" claim is plausible. In an afternoon from noon to 6pm, there are 6*60*60 seconds. To crack a single DES key by brute force, we'd expect to have to search on average half the 56-bit key space, performing about 2^55 DES encryptions. So how fast would the teenager's computer have to be? cpu% hoc 2^55/(6*60*60) 1667999861989 1/_ 5.995204332976e-13 1667 billion DES encryptions per second, or less than a picosecond per encryption. I think just enumerating the keys at that speed would be quite a challenge for "the average consumer machine" (even with a GPU). A bit of googling for actual results on DES brute force brings up https://www.sciencedirect.com/science/article/abs/pii/S138376212266 from March 2022, which says: "Our best optimizations provided 3.87 billion key searches per second for Des/3des ... on an RTX 3070 GPU." So even with a GPU, the expected time to crack a random 56-bit key would be something like: cpu% hoc 2^55/3.87e9 9309766.671567 _/(60*60*24) 107.7519290691 More than three months. The same paper mentions someone else's purpose-built machine called RIVYERA which "uses 128 Xilinx Spartan-6 LX150 FPGAs ... can try 691 billion Des keys in a second ... costs around 100,000 Euros". Still not quite fast enough to break a key in an afternoon. When Jacob says "triple DES is not computationally hard to brute force these days", I assume this is just a slip of the keyboard, since p9sk1 uses only single DES. But if we are worried about the shaky foundations of p9sk1 being based on single DES, Occam's Razor indicates that we should look for the minimal and simplest possible extension to p9sk1 to mitigate the brute force threat. The manual entry for des(2) suggests that the Plan 9 authors were already thinking along these lines: BUGS Single DES can be realistically broken by brute-force; its 56-bit key is just too short. It should not be used in new code, which should probably use aes(2) instead, or at least triple DES. Let's postulate a p9sk3 which is identical to p9sk1 except that it encrypts the ticket responses using 3DES instead of DES. The effective keyspace of 3DES is considered to be 112 bits because of the theoretical meet-in-the-middle attack. So brute forcing a 3DES key with commodity hardware (including GPU) would be expected to take something like: cpu% hoc 2^111/3.87e9 6.708393874076e+23 _/(60*60*24*365.25) 2.125761741728e+16 That's quadrillions of years. Not what most people would call "trivial". And that's generously assuming the implementation of meet-in-the-middle is zero cost. Without meet-in-the-middle, we're looking at a 168-bit keyspace and an even more preposterous number of years. I was looking forward to the "proof of concept". Even if we can't see the
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
There's no attack, just questions. Let's say we speak with someone who rely on LLMs to get his point but still have a "need" that doesn't seem to be fulfilled by the community. I have real questions: What are your motivations? Why don't you simply ask for what you want personally and stop telling us that you speak for the community. How don't you understand that the "chatGPT" style is kind of irritating and redundant and that it won't help you to get what you really want? -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M395ea311dbde03e1f785722d 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)
why step back. step forward and put your money where your mouth is. On Sun, May 12, 2024 at 2:42 PM wrote: > > Thank you for sharing your thoughts. I want to clarify that my intention is > not to exert control or disrupt, but to foster better collaboration between > communities. I understand that there may be concerns about redundancy and > approaches, which is why I believe a dialogue about our common goals and how > best to achieve them is crucial. I do not see much collaboration between > 9legacy and 9front. From what I gather from this thread, it seems that one > community wants to lord over another and not be helpful. At least this is > how it appears to a hobbyist like me. It would be nice if things were more > cordial and helpful. > > I am assuming everyone here is a hobbyist, so I speak as a hobbyist. It’s > important to recognize that our shared interest in advancing the Plan 9 > community is at the heart of these discussions. I am here not for personal > gain but to contribute positively. I think we all bring valuable perspectives > that, when combined, can lead to innovative solutions that benefit everyone > involved. > > Let’s focus on how we can work together more effectively. I am open to > suggestions and willing to step back where needed to allow for a more > collective approach. I believe that through constructive dialogue and a > shared commitment to our community’s goals, we can overcome misunderstandings > and move forward together. > > I don't mind the ad hominem attacks. I just hope things improve. I do find > it ironic that I'm addressing the 9front community about collaboration and > inclusiveness when I recall those as being two reasons for the inception of > 9front. > > Vic > > > On Sun, May 12, 2024, at 21:18, pl...@room3420.net wrote: > > The collaboration is already here. You try to create tools that already > > exist. I'd like to pinpoint why you have this unbelievable need for > > control and wonder if you're not just working for Microsoft, Google or > > the guy who stole Freenode and just try to disrupt the plan9 community. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M5432f6f3c46a1f6121d1559c 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)
what fears? i welcome you making this collaboration greater by helping out the people that already are busy collaborating. thank you. On Sun, May 12, 2024 at 1:58 PM wrote: > > Why the fear about collaborating? Wouldn't greater 9legacy and 9front > collaboration be something good for the Plan 9 community? > > Vic > > > On Sun, May 12, 2024, at 20:53, hiro wrote: > >> How can we ensure that everyone feels valued and heard? > > > > easy. stop spamming LLM garbage and start contributing concise code > > and documentation, not this blabber. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M742c7aa1214ff4163d529e4a 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)
Thank you for sharing your thoughts. I want to clarify that my intention is not to exert control or disrupt, but to foster better collaboration between communities. I understand that there may be concerns about redundancy and approaches, which is why I believe a dialogue about our common goals and how best to achieve them is crucial. I do not see much collaboration between 9legacy and 9front. From what I gather from this thread, it seems that one community wants to lord over another and not be helpful. At least this is how it appears to a hobbyist like me. It would be nice if things were more cordial and helpful. I am assuming everyone here is a hobbyist, so I speak as a hobbyist. It’s important to recognize that our shared interest in advancing the Plan 9 community is at the heart of these discussions. I am here not for personal gain but to contribute positively. I think we all bring valuable perspectives that, when combined, can lead to innovative solutions that benefit everyone involved. Let’s focus on how we can work together more effectively. I am open to suggestions and willing to step back where needed to allow for a more collective approach. I believe that through constructive dialogue and a shared commitment to our community’s goals, we can overcome misunderstandings and move forward together. I don't mind the ad hominem attacks. I just hope things improve. I do find it ironic that I'm addressing the 9front community about collaboration and inclusiveness when I recall those as being two reasons for the inception of 9front. Vic On Sun, May 12, 2024, at 21:18, pl...@room3420.net wrote: > The collaboration is already here. You try to create tools that already > exist. I'd like to pinpoint why you have this unbelievable need for > control and wonder if you're not just working for Microsoft, Google or > the guy who stole Freenode and just try to disrupt the plan9 community. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mcbfa4fef559b42babac44bab Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
The collaboration is already here. You try to create tools that already exist. I'd like to pinpoint why you have this unbelievable need for control and wonder if you're not just working for Microsoft, Google or the guy who stole Freenode and just try to disrupt the plan9 community. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M527f1433bb6ae0ec70a6a99f 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)
Why the fear about collaborating? Wouldn't greater 9legacy and 9front collaboration be something good for the Plan 9 community? Vic On Sun, May 12, 2024, at 20:53, hiro wrote: >> How can we ensure that everyone feels valued and heard? > > easy. stop spamming LLM garbage and start contributing concise code > and documentation, not this blabber. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-Mc0fa30d5ea72f95df95970de 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)
> How can we ensure that everyone feels valued and heard? easy. stop spamming LLM garbage and start contributing concise code and documentation, not this blabber. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tcf128fa955b8aafc-M991bbf5c068039c0ba35b4ca 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 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-M9e2163e0d5b11f835cf9b2b2 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)
Thanks Jacob for catching the mistake. Vic On Sun, May 12, 2024, at 16:12, Jacob Moody wrote: > You just sent to this to just me, not the list. Shame not everyone > could see this LLM drivel :( > > On 5/12/24 00:46, vic.thac...@fastmail.fm wrote: >> I've noticed the growing divide within our community, and I believe it's >> crucial for us to strive for an inclusive environment that transcends any >> "us versus them" mentality. A shared vision and values are essential for >> guiding our direction and efforts within the Plan 9 community. Let's focus >> on bridging this gap and fostering a space where collaboration and unity not >> only exist but thrive. >> >> It is important to acknowledge that adopting a "my way or the highway" >> attitude serves no positive purpose for the Plan 9 community. Moving >> towards less polarization will enhance our capacity to welcome and encourage >> diverse contributions, making our community stronger and more innovative. >> >> I want to express my gratitude to everyone who has shown a commitment to >> improving collaboration. True collaboration requires effort from all sides, >> and I am hopeful that both 9front and 9legacy can reap equal benefits from >> our collective endeavors. Let’s work together to build a community we are >> all proud to be part of. >> >> Vic >> >> >> On Sun, May 12, 2024, at 11:55, Jacob Moody wrote: >>> I've gone ahead and made a repository[0] for an up to >>> date fossil* for 9front. I didn't have to do more then >>> clone the 4e repository, apply the 9legacy patches and >>> type mk. Took all of 10 minutes. Testing is left as >>> an exercise for the reader. >>> >>> * No warranty given or implied. >>> [0] http://only9fans.com/moody/fossil/HEAD/info.html >>> >>> On 5/11/24 19:43, o...@eigenstate.org wrote: As far as I can tell, 9front doesn't have a problem on this side; we just imported the Power64 compilers, have working versions of risc64, etc, all pulled in from the 9legacy world. The work to port usually ranges between negligible and trivial. As far as I can tell, the only thing preventing 9front changes from making their way back to 9legacy is a lack of hands to do the work. And while I'm happy to lend a hand, help debug, and even make trivial changes to enhance portability, I personally don't care to spend time porting software to a system I don't intend to use. 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. Quoth vic.thac...@fastmail.fm: > Perhaps adopting this mindset could be beneficial. When developing a > feature, it's worth considering its potential for portability and > usefulness to other communities. > > Vic > > On Sun, May 12, 2024, at 07:27, hiro wrote: >> just send the code then >> >> On Sun, May 12, 2024 at 12:22 AM wrote: >>> >>> Let me explain my intent and elaborate on my point of view. I started >>> a new thread to enhance the signal-to-noise ratio. It's easy for a >>> thread to become cluttered with multiple issues, so I believe creating >>> separate threads for distinct concerns helps streamline communication >>> and keeps discussions focused. >>> >>> As a hobbyist, I see we all share a passion for Plan 9 and its >>> development. Enhancing collaboration between communities would benefit >>> everyone involved, and potentially enhance decorum on 9fans. I am >>> curious to gauge whether there is any interest in activities that could >>> facilitate positive teamwork, foster stronger connections, and break >>> down barriers between communities. >>> >>> Fostering discord among communities seems to only perpetuate more >>> discord. In my mind, seeking to improve collaboration between >>> communities seemed, and still seems, worthwhile. >>> >>> As a hobbyist, I find myself pondering: What motivates individuals to >>> participate in 9fans if not for a genuine interest in supporting the >>> Plan 9 community? >>> >>> Vic >>> >>> >>> On Sun, May 12, 2024, at 01:26, hiro wrote: congrats for teaching the bot to create more email threads with new subjects. just what we need as a community. On Fri, May 10, 2024 at 4:55 PM Lucio De Re wrote: > > I guess we're on the same page, right up and including the fist > fight(s). But I think we are all entitled to be treated more > courteously in a public forum such as this, including not ascribing > malice unless it is explicit. Being touchy has plagued this forum > just about forever, it would be nicer if instead of calling out bad > behaviour, it got the benefit of the doubt. I
Re: [9fans] Balancing Progress and Accessibility in the Plan 9 Community. (Was: [9fans] Interoperating between 9legacy and 9front)
"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-M612a57d35367f2de904e3eb2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
