Re: [9fans] Keeping 9pi up to date
Thanks a lot, it works! Kind Regards, Dante On 18.07.2014 16:59, Richard Miller wrote: Would a "replica/pull -v /dist/replica/network" result in the same system as the last 9pi kit (http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz)? Almost. See http://9fans.net/archive/2014/02/131 for details.
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 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 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 http://www.kergis.com/ http://www.renaissance-francaise.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] extern register
I don't have any opinion on whether R14 and R15 should be saved, but the justification posted in the top post seems weak. The stack is already per-process data. One can use _tos for per-proc data, just like privalloc(2) does. -- Aram Hăvărneanu
Re: [9fans] extern register
On 19 July 2014 02:57, wrote: > would it make sense to save and restore the two registers > on syscall entry/exit, so userspace programs could make use > of them for per process data? > Good question. None of the others need to be saved and restored because they are defined to be dead on entry to a function, but you're right that rule doesn't really apply to extern register, and they could be useful. _tos only works when every process has at least one stack always at the same fixed virtual address. On the other hand, a kernel that provides an alternative to that would also know to save and restore extern registers.
Re: [9fans] kbdputc() in devcons.c in 9front?
> You, 9front developpers, created kbdfs, and > lost kbdputc() in port/devcdons.c. Most of > pc/kbd.c stuffs are driven out to user space, kbdfs. > > In lab's or 9atom's distribution, I can have > /rc/bin/Kanji, like: > #!/bin/rc > > pipefile -r ktrans /dev/cons > rio -i $home/lib/windows > This assumes that the keyboard input from > stdin, and produces kanji translated character to > /dev/cons. This is solved by cinap to write a new program, pipekbd which works like pipefile for 9front's kbdfs. Now I can use Japanese on Plan9fron, too. Thanks cinap! Kenji
Re: [9fans] extern register
On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth wrote: > _tos only works when every process has > at least one stack always at the same fixed virtual address. Isn't this always true? -- Aram Hăvărneanu
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] extern register
On Sat Jul 19 10:40:49 EDT 2014, ara...@mgk.ro wrote: > On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth > wrote: > > _tos only works when every process has > > at least one stack always at the same fixed virtual address. > > Isn't this always true? does anyone have a use case for extern register in user space? come to think of it, extern register is defined to be one register per mach, which is a bit of a stretch for user space. - erik
Re: [9fans] Plan9 Sources Repository
On Sat, Jul 19, 2014 at 11:31 AM, dante 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?
[9fans] NetBSD venti server
Hello everyone. I'm turning my NetBSD gateway in a venti server with plan9port. Reading the list I have saw a lot of considerations about the configuration. I'll appreciate any information (links to docs?) about setting venti. The man pages and /sys/doc/venti/ are too much technical for me now!. Maybe it's time to dig in file systems/servers and study the venti implementation (Any introductory docs suggestion about this will be appreciated too) to be able to make my own decisions. Or just http://plan9.bell-labs.com/wiki/plan9/Setting_up_Venti/index.html Index 5% of Arenas, go on with the defaults, and see the sunset on the beach with my hands on my nape? I plan mirror the venti disk with RAIDframe (two 250GB sata disks), and use it to incremental backup my work with vac(1). I was thinking of encrypt the disks with cgd. Also, p9p doesn't support NetBSD-amd64, and current NetBSD-i386 is broken. I had to compile in Netbsd-i386 4.0 in Qemu, and use emulators/netbsd32_compat40: install netbsd32_compat40 Compile p9p in netbsd-4.0 i386 (needs perl) cp i386's libX11.so.6.2 to /emul/netbsd32/lib and soft link to libX11.so.6 libX11.so create /etc/ld.so.conf: /lib /usr/lib /emul/netbsd32/lib create ptys: # cd /dev # sh MAKEDEV opty For now, all is going like a charm. I hope this will be usefull to someone. Nice summer (Or winter). trebol.
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] extern register
On Sat, Jul 19, 2014 at 4:55 PM, erik quanstrom wrote: > does anyone have a use case for extern register in user space? Well Go uses it, but the meaning is different than in the Plan 9 kernel; they reused it for a different storage class. In Go, there were two external register variables, g and m (now there is only one for reasons outside the scope of this discussion). These variables are proc-local as oposed to mach-local. To make a streched analogy, a proc is to Go as a mach is to the kernel. Both are some "entities" which can "run" other schedulable entities (Go now has g's, m's, and p's, so the analogy no longer holds, but that was the original meaning). On arm, these variables are kept in registers on all operating systems. On 386 and amd64, non-Plan 9 systems use a form of TLS to keep these variables. TLS usually requires libc.so and ld.so interaction (ugh), so since Go doesn't usually use these, it usually executes some system call which sets up the base segment registers to some heap-allocated memory, and then accesses this space using the segment registers. On systems which don't have these special system calls, the base registers are usually initialized by the kernel/libc.so/ld.so with enough space for some slots, so the access is the same, only without initialization. Plan 9 has no such nonsense; the stack is at a fixed, and known address, so these variables can be kept on the stack. I recently simplified this for the plan9/386 Go port and made the plan9/amd64 Go port use the same mechanism. -- Aram Hăvărneanu
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 : 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 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" 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 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] extern register
ok, i preserve user R14 and R15 now. also removed the saving and restoring of DS/ES/FS/GS segment registers... they have no effect in long mode and there are no 32 bit tasks. someone write a proof of concept program that communicates with another process by morsing data on the segment registers by loading them with NULLSEL and UDSEL :) -- cinap
[9fans] Pull and compile latest kernel (sys call 53 error)
Hello,
How should I properly update to the latest kernel on a new install of Plan 9
from Bell Labs?
I downloaded Plan9, ran the "pull" script, and then tried to compile and
install a new kernel by running mk install in /sys/src/9/pc
Compilation seemed to go fine, but then I got an syscall 53 error (the error
seems to come from "ar", see below).
Thank you,
Patryk
-- snip --
8c -FTVw -I. ../port/sysproc.c
8c -FTVw -I. ../port/taslock.c
8c -FTVw -I. ../port/tod.c
8c -FTVw -I. ../port/xalloc.c
8c -FTVw main.c
names=`{membername $newprereq}
ar vu ../boot/libboot.a8 $names
rm $names
ar 856: bad sys call number 53 pc becd
ar 856: suicide: sys: bad sys call pc=0xbecd
mk: names=`{membername $newprereq} ar ... : exit status=rc 849: ar 856: sys:
bad sys call pc=0xbecd
term%
Re: [9fans] Pull and compile latest kernel (sys call 53 error)
> I downloaded Plan9, ran the "pull" script, and then tried to compile and > install a new kernel by running mk install in /sys/src/9/pc > > Compilation seemed to go fine, but then I got an syscall 53 error (the error > seems to come from "ar", see below). you need to reboot using one of the kernels you pulled first.
