Re: [9fans] Plan9 Sources Repository
done On 20.07.2014 00:30, erik quanstrom wrote: The Wiki seems to be frozen (i.e., not editable anymore): - no Edit button on http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ - no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki 444) edit from plan 9. - erik
Re: [9fans] Plan9 Sources Repository
thanks. On 20.07.2014 02:12, Brian L. Stuart wrote: My whole argument goes about the following hypotheses: 1. increasing the amount of contributions may not scale in the current model. 2. submitting trivial contributions is not trivial for the contributor. Both of these points seem to come from a mental model that just doesn't apply to Plan 9. In earlier messages, you used the word team to describe the set of people contributing to Plan 9. However, in reality, there isn't a Plan 9 team, per se. Essentially, Plan 9 is a research system. It's a platform and a vehicle for doing systems research. It is true that it has been very useful as the basis of products, as infrastructure, and as a daily-use OS. However, rather than being its raison d'etre, Plan 9's utility is a tribute to and the acid test of the research work done on it. After all, I'm hardly going to suggest that a file system I develop is worthy of study or use if I'm not willing to put my own data on it. (So yes, my main file server is running on thetafs, and has been for months.) Given that the primary function of Plan 9 is to be a research system, neither increasing numbers of contributions nor trivial contributions are to be expected. In fact, it's not clear they would be particularly desirable. The flip side of all this is that because it has been very useful, many of us use it heavily enough that we'd be loathe to return to a world where we'd have to do without it. So there is valid motivation to expand the set of supported hardware, fix bugs, make it easier to install and use, etc. While, I'm not in a position to speak for the principals involved, from my perspective, both 9atom and 9front are laregely so motivated. I don't think I'm speaking out of turn when I say that the maintainers of both of those systems would be more than happy to accept contributions to them. If, in the course of making such contributions, you reach a point where the contribution channel could be improved, then contributing an improved contribution mechanism would be just as welcome, I suspect. In other words, welcome to the Plan 9 community. We'll be glad to help you however we can. We encourage and look forward to seeing any contributions you make that emerge from what captures your interest. BLS
Re: [9fans] Plan9 Sources Repository
I would like first to thank everyone for the kind replies! Each was useful in it's own way. On 18.07.2014 16:36, erik quanstrom wrote: Yet: is there a source control system behind it? Would it be possible to check out directly from there? there is nothing most folks would recognize as a distributed revision control system. the repo is sources itself. history is through history(1). you can check out code with cp(1), tar(1), mkfs(8); you can keep up with the repo with replica(1). patches are submitted via patch(1). I would argument that the Status Quo has the following disadvantages when compared to the the current usual way of doing things: 1. The history is confined to Plan9. It is hard to do small fixes (typos, documentation) from another system. 2. There are no commit comments. There is no blame command. There are no release tags (allowing for unstable work in between). There are no branches (allowing for collective work on an unstable version). OK, my machine is my branch... 3. Contrib packages are tied to people; there is no common repository. This leads to the situation where you can't update a package of a long gone user. Please tell me how many Mercurial packages you can find in Contrib! I maintain my impression that the Status Quo, though good for a small team, does not allow the project to grow. Were there any efforts to change this? Or is it a controversial matter and it stays as it is? Or is the team indeed so small (or even loosing members), s.t. that a change won't make sense? Kind Regards, Dante If there is none, could it be that this contributes to the lack of popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy, PlanB, other plans...)? i would think the lack of popularity can be most directly attributed to the closed license in the early 90s, when there was an unfilled niche, and linux was seriously lacking. i starting doing something slightly different when il was pulled from the distribution while i was in no position to stop using it. it had nothing to do with source control. - erik
Re: [9fans] Plan9 Sources Repository
You are not the first one to bring this up. There is a chain titled CMS/MMS (VCS/SCM/DSCM) [was syscall 53] that discusses it. I'd suggest giving it a skim if you can find it in the archives. That said, in my opinion: 1. The history is confined to Plan9. It is hard to do small fixes (typos, documentation) from another system. I agree. 2. There are no commit comments. There is no blame command. There are no release tags (allowing for unstable work in between). There are no branches (allowing for collective work on an unstable version). OK, my machine is my branch... I recall reading in one of the wiki pages that there is a procedure to get a historical list of patches applied to the main sources and a message to go with it (might have been just a readme file). I took a quick look and can't find it again, perhaps someone else knows? 3. Contrib packages are tied to people; there is no common repository. This leads to the situation where you can't update a package of a long gone user. Please tell me how many Mercurial packages you can find in Contrib! I don't see how a repository would fix this. When the user is gone you would still lose the only person with write access to the repo. You would need to fork it. The only difference is now people just copy it. What's really missing is an index of what current versions live where. Or at least if it exists I am not aware of it. I maintain my impression that the Status Quo, though good for a small team, does not allow the project to grow. Were there any efforts to change this? Or is it a controversial matter and it stays as it is? Or is the team indeed so small (or even loosing members), s.t. that a change won't make sense? In the short time I've been here I think its came up twice. So it is something at least some people are interested in looking at. I'm sure it will keep coming up.
Re: [9fans] Plan9 Sources Repository
Plan9 in general doesn't follow the Bazaar model ( the current usual way of doing things ). On Sat, Jul 19, 2014 at 11:31 AM, dante subscripti...@posteo.eu wrote: I would like first to thank everyone for the kind replies! Each was useful in it's own way. On 18.07.2014 16:36, erik quanstrom wrote: Yet: is there a source control system behind it? Would it be possible to check out directly from there? there is nothing most folks would recognize as a distributed revision control system. the repo is sources itself. history is through history(1). you can check out code with cp(1), tar(1), mkfs(8); you can keep up with the repo with replica(1). patches are submitted via patch(1). I would argument that the Status Quo has the following disadvantages when compared to the the current usual way of doing things: 1. The history is confined to Plan9. It is hard to do small fixes (typos, documentation) from another system. 2. There are no commit comments. There is no blame command. There are no release tags (allowing for unstable work in between). There are no branches (allowing for collective work on an unstable version). OK, my machine is my branch... 3. Contrib packages are tied to people; there is no common repository. This leads to the situation where you can't update a package of a long gone user. Please tell me how many Mercurial packages you can find in Contrib! I maintain my impression that the Status Quo, though good for a small team, does not allow the project to grow. Were there any efforts to change this? Or is it a controversial matter and it stays as it is? Or is the team indeed so small (or even loosing members), s.t. that a change won't make sense? Kind Regards, Dante If there is none, could it be that this contributes to the lack of popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy, PlanB, other plans...)? i would think the lack of popularity can be most directly attributed to the closed license in the early 90s, when there was an unfilled niche, and linux was seriously lacking. i starting doing something slightly different when il was pulled from the distribution while i was in no position to stop using it. it had nothing to do with source control. - erik
Re: [9fans] Plan9 Sources Repository
Hi, On 19.07.2014 13:20, Riddler wrote: 3. Contrib packages are tied to people; there is no common repository. This leads to the situation where you can't update a package of a long gone user. Please tell me how many Mercurial packages you can find in Contrib! I don't see how a repository would fix this. When the user is gone you would still lose the only person with write access to the repo. You would need to fork it. The only difference is now people just copy it. Well, it takes 1 minute to hg mv a project from long_gone_user/project to contrib/project. As it is now, I have to convince the master to *create* the central contrib repository, then to copy the project there etc. Moreover, as the stuff is now spread all around, it is hard to set up a nightly build for all the stuff. As I said, the status quo is perfect for a small team, but I doubt that is encourages the project to get some traction. I maintain my impression that the Status Quo, though good for a small team, does not allow the project to grow. Were there any efforts to change this? Or is it a controversial matter and it stays as it is? Or is the team indeed so small (or even loosing members), s.t. that a change won't make sense? In the short time I've been here I think its came up twice. So it is something at least some people are interested in looking at. I'm sure it will keep coming up. I could help (a bit, time permitting), but I think that the most important thing is to get support from the current project maintainers (the people you submit patches to). This discussion can only be started by the veterans. I think that a solution that does not increase the burden on the current volunteer maintainers is possible. What do you people think? Kind Regards, Dante
Re: [9fans] Plan9 Sources Repository
On 19.07.2014 13:49, pmarin wrote: Plan9 in general doesn't follow the Bazaar model ( the current usual way of doing things ). And this might lead to the problems pointed in my previous mails. Or not, I might be wrong. Kind Regards, Dante
Re: [9fans] Plan9 Sources Repository
This was an unfair statement from you, pmarin. You make me answer twice. I did not imply anywhere that I proposed the bazaar model (whatever that is, no one wants the Linux . Scalability is also possible in projects maintained by a central authority. My whole argument goes about the following hypotheses: 1. increasing the amount of contributions may not scale in the current model. 2. submitting trivial contributions is not trivial for the contributor. Kind Regards, Dante On 19.07.2014 13:51, dante wrote: On 19.07.2014 13:49, pmarin wrote: Plan9 in general doesn't follow the Bazaar model ( the current usual way of doing things ). And this might lead to the problems pointed in my previous mails. Or not, I might be wrong. Kind Regards, Dante
Re: [9fans] Plan9 Sources Repository
On Sat, Jul 19, 2014 at 01:49:10PM +0200, pmarin wrote: Plan9 in general doesn't follow the Bazaar model ( the current usual way of doing things ). The Bazaar model is the one for not doing or undoing. Small is beautiful. The attraction for Plan9 is its consistency and size. As far as I'm concerned, the current organization is not a drawback from contributing more---time is. Another organization will not offer, for me, more opportunity to contribute. When I have something to contribute (and for now, this is only user level kerTeX), nothing impeds me from doing. This is for user level. For kernel, the problems may be more involved. But clearly, the number of persons able to contribute is far more limited. And consistency shall be the primary aim. So an organization good for a small team is an organization good for kernel level. My 1 cent, -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 Sources Repository
Please, be so kind and stop this Bazaar thread. The proposal was to use some maybe more scalable tools while maintaining the current responsibilities. This could allow for more contributions to be done with the same burden for the maintainers. An example for what it's worth could be OpenBSD. They have AFAIK a central package system with a couple of maintainers and nightly builds and many-many contributors. Not Linux. Linux is nowadays so complex that no one can understand the whole kernel. Linux is IMHO way too lax about new, orthogonal interfaces, functionality overlap and rewriting in a different flavour. Kind Regards, Dante On 19.07.2014 14:03, tlaro...@polynum.com wrote: On Sat, Jul 19, 2014 at 01:49:10PM +0200, pmarin wrote: Plan9 in general doesn't follow the Bazaar model ( the current usual way of doing things ). The Bazaar model is the one for not doing or undoing. Small is beautiful. The attraction for Plan9 is its consistency and size. As far as I'm concerned, the current organization is not a drawback from contributing more---time is. Another organization will not offer, for me, more opportunity to contribute. When I have something to contribute (and for now, this is only user level kerTeX), nothing impeds me from doing. This is for user level. For kernel, the problems may be more involved. But clearly, the number of persons able to contribute is far more limited. And consistency shall be the primary aim. So an organization good for a small team is an organization good for kernel level. My 1 cent, -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] Plan9 Sources Repository
1. The history is confined to Plan9. It is hard to do small fixes (typos, documentation) from another system. that's true. but it's easy to get a plan 9 system, or drawterm into one. in my experience, plan 9 is a system one spends siginficant time in. i would not want to change the system to support foreign patches unless it's a proven issue, and experiments show that such patches are of equal quailty to ones made from a plan 9 system. solutions like hg pull python into the system as a hard requirement, and i wouldn't want to make (more) external things like python a hard requirement, if possible. also, python doesn't currently work on arm or mips, so it would making the minimum requirements for a plan 9 system much greater. 2. There are no commit comments. There is no blame command. but there is! history(1) will display the last modifier of the file. in plan 9 the rule typically is: you touch it, you own it. There are no release tags (allowing for unstable work in between). There are no branches (allowing for collective work on an unstable version). OK, my machine is my branch... it's just a different model. given your questions, i am wondering if you have spent much time with the system. especially one with history enabled. - erik
Re: [9fans] Plan9 Sources Repository
On Sat, Jul 19, 2014 at 11:31 AM, dante subscripti...@posteo.eu wrote: It is hard to do small fixes (typos, documentation) from another system. One could argue this is a feature. Everything has to be tested. I've seen way too many botched patches that purportedly only fixed documentation. Also, how do you write documentation if you don't use the system? Typos are not worth fixing unless it is done systematically and many errors are corrected at once, otherwise they just create noise and break existing patches creating merge nightmares. This is true even with git, typos impact the precision of bisect and blame. Every change starts at -100 points. Unless the net benefit is positive it shouldn't go in. A change fixing a typo only gets you up to -99 points. It's not worth it. From my experience with Plan 9 and many other different open source projects like Linux, OpenBSD and Go, patches coming from people not really using the system are of very low quality. Changing the model is very disruptive and would not bring any more good contributions. Plan 9 is easy to get if you want it. There are no commit comments. Actually patches do have comments. The filesystem doesn't carry any metadata. Maybe it should, more likely it shouldn't; a changelog file is easy to write, one could even automate it from existing patch metadata. There is a net benefit to be gained, but the benefit is small, otherwise somebody would have done the work. One property of the existing model is that it works. You are proposing a new model, as if the existing model doesn't work. But it does. There are no release tags. It's just a different model. There's no evidence that one is superior to the other. There are no branches. Actually, Plan 9 private namespaces give you branches and much more. You can pick and choose; assemble any number of views over the tree as you like. You see, you're criticizing the Plan 9 development model by thinking in traditional terms. The Plan 9 model is simpler, perhaps too simple for Unix software, but Plan 9 is not Unix. Combining the Plan 9 model with orthogonal Plan 9 primitives gives you a much richer and cleaner environment that all falls naturally from the design of the system, rather than having all features backed in the vcs blob. -- Aram Hăvărneanu
Re: [9fans] Plan9 Sources Repository
Hi Eric, Thanks for your answers! They are really a good start for me with Plan9. So, you and the others convinced me that a source management system for the main system is not really necessary. What's left from my initial questions is if it won't be a bad idea to have an integrated contrib (or packages) system. Refined proposal: 1. Gather the good packages from the user's directories and other sources on the net into a central system, like the core Plan9. There is some work implied to check licenses and get permissions. 2. Someone should filter the subsequent submissions, just the same as with the core Plan9 (work:). If you guys don't like source control systems, let patch(1) be it. 3. Set up a maintenance routine for the whole package system, like regular builds on all architectures, not to speak of automated tests. Packages that fall out of the maintenance routine shall be removed after a while. 4. What could also happen in the long run is that some software is ported from POSIX/Ape/X11 to the native Plan9 interfaces. What do you think, 9fans? On 19.07.2014 16:41, erik quanstrom wrote: given your questions, i am wondering if you have spent much time with the system. especially one with history enabled. Sincerely: no. That's homework. Kind Regards, Dante
Re: [9fans] Plan9 Sources Repository
Are you intentionally trying to make plan bureaucratic?
Re: [9fans] Plan9 Sources Repository
Usable, not bureaucratic. And you don't need to invest work. Just use it if you like it. Take a look at how it works now. Is this OK with you? 1. /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib Why do I need to know about fgb, why not /n/sources/packages/contrib/rc/bin/contrib/install contrib ? 2. bichued/hg -- 1.0.2 jas/hg-src mjl/hgfs stallion/mercurial -- 2.2.3 Which one now? 3. What about http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ ? What about the broken links there? Can we still save that software? Archive.org? Regards, Dante P.S. I knew that I will receive a certain amount of conservative/negative answers for questioning the Status Quo. I also got some very helpful ones, see Eric. Maybe this is the right moment to ask such questions. For years, Plan9 was hard to install on common hardware, lacking drivers (I tried more than once and failed). This all changed with Raspberry Pi. There is a good, stable (in the medium/long term) platform that costs next to nothing for people to play with Plan9. The core system is very elegant and flexible. Yet, I have the impression that some potential users may be put off by the lack of polish in some other places (installer, ports etc.). These potential users are also potential contributors. More mass could mean: - having a useable (like useable in 2014) Web browser - having a useable (or having one at all) video/media player - having an SSH2 server (there is one in 9atom, but I didn't see it in the stock Plan9). Are you sure it doesn't have the Heartbleed? - having a useable driver for touch pads or 2-button-plus-wheel mice. I couldn't find a 3-button mouse these days, and clicking on the wheel is awful. - up-to-date versions of modern programming languages. I miss Ruby a lot. Wouldn't that be nice? 8D On 19.07.2014 17:11, Jacob Todd wrote: Are you intentionally trying to make plan bureaucratic?
Re: [9fans] Plan9 Sources Repository
1. Gather the good packages from the user's directories and other sources on the net into a central system, like the core Plan9. There is some work implied to check licenses and get permissions. Try 9front :)
Re: [9fans] Plan9 Sources Repository
yes On 19.07.2014 19:31, hiro wrote: 1. Gather the good packages from the user's directories and other sources on the net into a central system, like the core Plan9. There is some work implied to check licenses and get permissions. Try 9front :)
Re: [9fans] Plan9 Sources Repository
Quoting dante subscripti...@posteo.eu: Usable, not bureaucratic. Lots of people already use plan 9, therefore it is already useable. And you don't need to invest work. This seems like a load of garbage, since you're already demanding that other people do work to support your preferences. This all changed with Raspberry Pi. There is a good, stable (in the medium/long term) platform that costs next to nothing for people to play with Plan9. The Raspberry Pi is not universally considered a good platform, but maybe that's a discussion for a different thread. Yet, I have the impression that some potential users may be put off by the lack of polish in some other places (installer, ports etc.). These potential users are also potential contributors. Why would anyone want patches from someone unwilling to learn how this system works? More mass could mean: - having a useable (like useable in 2014) Web browser We already have operating systems that focus on this nonsense. Why must plan 9 also? - having a useable (or having one at all) video/media player see above - having an SSH2 server (there is one in 9atom, but I didn't see it in the stock Plan9). Are you sure it doesn't have the Heartbleed? Are *you*? Do you even know what heartbleed is? Why would we throw plan 9's existing communications standards in the trash? SSH is wildly inferior and makes tons of assumptions about the hosts that only really apply to unix or unix-wannabes. - having a useable driver for touch pads or 2-button-plus-wheel mice. I couldn't find a 3-button mouse these days, and clicking on the wheel is awful. Almost every mouse for sale to day has three buttons. Click your scroll wheel. - up-to-date versions of modern programming languages. I miss Ruby a lot. If you want Ruby, you know where to find it. Wouldn't that be nice? No. It sounds like you're trying to rewire the entire plan 9 community with the goal of turning plan 9 into ubuntu with a plan 9 theme. Why the hell would anyone who appreciates what plan 9 has to offer be interested in these enormous steps backwards? Why don't you just use the operating systems that already support all this crap? khm
Re: [9fans] Plan9 Sources Repository
1. /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib Why do I need to know about fgb, why not /n/sources/packages/contrib/rc/bin/contrib/install contrib ? 2. bichued/hg -- 1.0.2 jas/hg-src mjl/hgfs stallion/mercurial -- 2.2.3 Which one now? this is no different than any other system. there are a number of versions of ssl floating around google code, bitbucket and the like. by the way, jas' python follows the tip, so it might be interesting. 3. What about http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ ? What about the broken links there? Can we still save that software? Archive.org? you may edit the wiki yourself to correct these issues. Maybe this is the right moment to ask such questions. For years, Plan9 was hard to install on common hardware, lacking drivers (I tried more than once and failed). This all changed with Raspberry Pi. There is a good, stable (in the medium/long term) platform that costs next to nothing for people to play with Plan9. i agree with this. many thanks to richard for putting this together. - having a useable (like useable in 2014) Web browser - having a useable (or having one at all) video/media player this is an interesting problem. keeping the core simple is in conflict with the massive amount of code required for a usable-in-2014 browser. i don't have a solution. - having an SSH2 server (there is one in 9atom, but I didn't see it in the stock Plan9). Are you sure it doesn't have the Heartbleed? i'm sure it doesn't have heartbleed. code for that sort of renegotiation was never written. - having a useable driver for touch pads or 2-button-plus-wheel mice. I couldn't find a 3-button mouse these days, and clicking on the wheel is awful. i agree. if you come up with a patch solving this problem, it will be strongly considered for merging. - up-to-date versions of modern programming languages. I miss Ruby a lot. Wouldn't that be nice? we might differ on this point. :-) - erik
Re: [9fans] Plan9 Sources Repository
On Jul 19, 2014, at 8:02 , dante subscripti...@posteo.eu wrote: My whole argument goes about the following hypotheses: 1. increasing the amount of contributions may not scale in the current model. Okay, it *may* not. But we have no evidence of that. There's no indication that the current distribution model represents a scaling problem (it may represent a higher barrier to entry, but that's a different claim). I'm pretty convinced (from using the system, and having worked in shared environments using this model) that the limiting factor to scale is human attention. 2. submitting trivial contributions is not trivial for the contributor. While on Plan 9, it's pretty darn easy. I'll grant that it's not trivial if you're not on Plan 9. I'm not convinced that's worth spending much attention on fixing (I suspect we're likely to get better contributions from people using the system for real), but it is fixable without changing the model. It wouldn't be hard to write a patch(1) for plan9port. Go to town. But you'll want to do so after being familiar with the normal operation. Anthony signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] Plan9 Sources Repository
On Jul 19, 2014 1:17 PM, erik quanstrom quans...@quanstro.net wrote: [snip] - having an SSH2 server (there is one in 9atom, but I didn't see it in the stock Plan9). Are you sure it doesn't have the Heartbleed? i'm sure it doesn't have heartbleed. code for that sort of renegotiation was never written. Not to mention heartbleed has nothing to do with ssh... It was an implementation bug in openssl only; it wasn't even a protocol bug.
Re: [9fans] Plan9 Sources Repository
On Sat, Jul 19, 2014 at 9:20 PM, Christopher Nielsen cniel...@pobox.com wrote: Not to mention heartbleed has nothing to do with ssh... It was an implementation bug in openssl only; it wasn't even a protocol bug. Yes, OpenSSH doesn't even use OpenSSL. -- Aram Hăvărneanu
Re: [9fans] Plan9 Sources Repository
On 19.07.2014 20:17, erik quanstrom wrote: 3. What about http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ ? What about the broken links there? Can we still save that software? Archive.org? you may edit the wiki yourself to correct these issues. The Wiki seems to be frozen (i.e., not editable anymore): - no Edit button on http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ - no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki 444) Cheers, Dante
Re: [9fans] Plan9 Sources Repository
The Wiki seems to be frozen (i.e., not editable anymore): - no Edit button on http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ - no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki 444) edit from plan 9. - erik
Re: [9fans] Plan9 Sources Repository
you may edit the wiki yourself to correct these issues. The Wiki seems to be frozen (i.e., not editable anymore): - no Edit button on http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ It was changed some time back to allow edits only using the acme wiki interface, rather than a web browser. BLS
Re: [9fans] Plan9 Sources Repository
- having an SSH2 server (there is one in 9atom, but I didn't see it in the stock Plan9). Geoff included the same ssh implementation as 9atom has in /sys/src/cmd/ssh2 but with some code clean-up. So the server code is there. I've been meaning to go back an reconcile the two different versions, including some bug fixes in the 9atom version, but my supply of round tuits is small. Are you sure it doesn't have the Heartbleed? For a number of reasons, yes, I am. The Plan 9 ssh v2 implementation is completely new and doesn't share any code with either OpenSSH or OpenSSL. That decision was made for a lot of reasons, one of which was to make the system less susceptible to the script kiddies. While I certainly don't have the hubris to suggest it is without flaws, I'm pretty sure its flaws are different than those of the mainstream implementations. So one is unlikely to get very far using a mainstream exploit. Having said all that, I would not recommend running an SSH server on Plan 9, unless you have a really compelling reason. With all due respect to those who developed the protocol, its authentication model is not, in my opinion, as solid as that of Plan 9. If you want to remotely log into a Plan 9 system from a foreign system, use drawterm, or cpu from a virtualized Plan 9 terminal. BLS
Re: [9fans] Plan9 Sources Repository
My whole argument goes about the following hypotheses: 1. increasing the amount of contributions may not scale in the current model. 2. submitting trivial contributions is not trivial for the contributor. Both of these points seem to come from a mental model that just doesn't apply to Plan 9. In earlier messages, you used the word team to describe the set of people contributing to Plan 9. However, in reality, there isn't a Plan 9 team, per se. Essentially, Plan 9 is a research system. It's a platform and a vehicle for doing systems research. It is true that it has been very useful as the basis of products, as infrastructure, and as a daily-use OS. However, rather than being its raison d'etre, Plan 9's utility is a tribute to and the acid test of the research work done on it. After all, I'm hardly going to suggest that a file system I develop is worthy of study or use if I'm not willing to put my own data on it. (So yes, my main file server is running on thetafs, and has been for months.) Given that the primary function of Plan 9 is to be a research system, neither increasing numbers of contributions nor trivial contributions are to be expected. In fact, it's not clear they would be particularly desirable. The flip side of all this is that because it has been very useful, many of us use it heavily enough that we'd be loathe to return to a world where we'd have to do without it. So there is valid motivation to expand the set of supported hardware, fix bugs, make it easier to install and use, etc. While, I'm not in a position to speak for the principals involved, from my perspective, both 9atom and 9front are laregely so motivated. I don't think I'm speaking out of turn when I say that the maintainers of both of those systems would be more than happy to accept contributions to them. If, in the course of making such contributions, you reach a point where the contribution channel could be improved, then contributing an improved contribution mechanism would be just as welcome, I suspect. In other words, welcome to the Plan 9 community. We'll be glad to help you however we can. We encourage and look forward to seeing any contributions you make that emerge from what captures your interest. BLS
Re: [9fans] Plan9 Sources Repository
Sources is not kept up-to-date by volunteers, unless you mean contrib, it is maintained by the Labs. Also, in a way, the sources server *is* Plan 9, rather than being updated *with* Plan 9. Plan 9 doesn't traditionally use version control. Rather, most disk-based Plan 9 file servers offer some form of history in the form of dumps or snapshots. 9fs sourcesdump will mount the sources dump, and you can inspect daily changes starting around some 12 years ago using regular Plan 9 tools such as editors, yesterday(1) and diffy(1). History management is superior in Plan 9 compared to git and mercurial. What git does better (at least according to some people), is patch management. The Labs and 9atom use some patch management technology best described in their manuals rather than on the mailing list. 9front uses mercurial for patch management. -- Aram Hăvărneanu
Re: [9fans] Plan9 Sources Repository
Yet: is there a source control system behind it? Would it be possible to check out directly from there? for the bell-labs distribution, the filesystem itself keeps a daily record of the source tree. you can access it with 9fs sourcesdump and the daily state of sources will be in /n/sourcesdump. If there is none, could it be that this contributes to the lack of popularity 9front and 9legacy both use mercurial as their revision control systems. 9legacy keeps a mirror of the bell-labs distribution in mercurial as well if that suits your needs. 9front's repo: http://code.google.com/p/plan9front 9legacy's various repositories and mirrors: https://hg.9grid.fr/ and to the fragmentation of Plan9 (9front, 9atom, 9legacy, PlanB, other plans...)? the reason for the different distributions is really no different than the motivation for the different bsd or linux distributions: they each have their own goals and purpose.
Re: [9fans] Plan9 Sources Repository
Yet: is there a source control system behind it? Would it be possible to check out directly from there? there is nothing most folks would recognize as a distributed revision control system. the repo is sources itself. history is through history(1). you can check out code with cp(1), tar(1), mkfs(8); you can keep up with the repo with replica(1). patches are submitted via patch(1). If there is none, could it be that this contributes to the lack of popularity and to the fragmentation of Plan9 (9front, 9atom, 9legacy, PlanB, other plans...)? i would think the lack of popularity can be most directly attributed to the closed license in the early 90s, when there was an unfilled niche, and linux was seriously lacking. i starting doing something slightly different when il was pulled from the distribution while i was in no position to stop using it. it had nothing to do with source control. - erik
