* [9fans] p9p factotum available for plan 9 @ 2010-11-03 21:13 erik quanstrom 2010-11-09 3:37 ` erik quanstrom 0 siblings, 1 reply; 39+ messages in thread From: erik quanstrom @ 2010-11-03 21:13 UTC (permalink / raw) To: 9fans contrib/install quanstro/nfactotum thanks to a bunch of work by brian stuart and Coraid paying both of us to work on these things, we've gotten together a plan 9 version of p9p's factotum. the main purpose of doing this is to support dsa and rsa verify and sign. of course the huge side benefit is that it's much easier to add protocols to factotum. i am currently running nfactotum as the factotum in my terminal kernel, and i've been testing (but not depending on) a cpu kernel with nfactotum built in. it's verified that cpu, ssh 1 (client), telnet (client) work. imap/smtpd passwd and cram and are untested. i'm unsure if i've tested ssh server. p9cr is missing some bits to make vnc work. telnet (server) is known broken. i don't think it's a hard fix. however, the diagnostic is fortune-worthy: !factotum protocol botch 0 ok bad authentication failed - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-03 21:13 [9fans] p9p factotum available for plan 9 erik quanstrom @ 2010-11-09 3:37 ` erik quanstrom 2010-11-09 17:41 ` David Leimbach 0 siblings, 1 reply; 39+ messages in thread From: erik quanstrom @ 2010-11-09 3:37 UTC (permalink / raw) To: 9fans On Wed Nov 3 17:15:36 EDT 2010, quanstro@quanstro.net wrote: > contrib/install quanstro/nfactotum > > imap/smtpd passwd and cram and are untested. imap4d with a password (which uses cram) now works. imap4d with a cram challenge does not. > telnet (server) is known broken. i don't think it's a hard fix. telnet now works. - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-09 3:37 ` erik quanstrom @ 2010-11-09 17:41 ` David Leimbach 2010-11-09 17:51 ` erik quanstrom ` (3 more replies) 0 siblings, 4 replies; 39+ messages in thread From: David Leimbach @ 2010-11-09 17:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1292 bytes --] On Mon, Nov 8, 2010 at 7:37 PM, erik quanstrom <quanstro@quanstro.net>wrote: > On Wed Nov 3 17:15:36 EDT 2010, quanstro@quanstro.net wrote: > > contrib/install quanstro/nfactotum > > > > imap/smtpd passwd and cram and are untested. > > imap4d with a password (which uses cram) now works. > imap4d with a cram challenge does not. > > > telnet (server) is known broken. i don't think it's a hard fix. > > telnet now works. > > - erik > > This is tangential to the topic, but has anyone written up a "how I use p9p" configuration style document? I've not really tried to use factotum from p9p, because I was not even sure if it worked. Also the one time I tried to set up venti from p9p I basically failed horribly, and wasn't really sure what I did wrong. (I should read the installation scripts for Plan 9 and the man pages but haven't had time to get back to it). I'm wondering things like "can I use p9p venti as a snapshot back end to a VMWare Plan 9 Fossil? I'd also like to host the blocks for my guruplug on my Mac OS X system directly with p9p venti if I could. I feel I'm missing out on a few really great opportunities to use this stuff, and I doubt I'm the only one :-). That said, I use p9p Acme all the time, and it's wonderful! [-- Attachment #2: Type: text/html, Size: 1813 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-09 17:41 ` David Leimbach @ 2010-11-09 17:51 ` erik quanstrom 2010-11-10 0:37 ` erik quanstrom 2010-11-09 18:08 ` yy ` (2 subsequent siblings) 3 siblings, 1 reply; 39+ messages in thread From: erik quanstrom @ 2010-11-09 17:51 UTC (permalink / raw) To: 9fans > This is tangential to the topic, but has anyone written up a "how I use p9p" > configuration style document? I've not really tried to use factotum from > p9p, because I was not even sure if it worked. "recently", that is within the past 2 years, p9p factotum has stopped working with drawterm. it might be that porting back some of the fixes to p9p factotum in nfactotum would fix that. - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-09 17:51 ` erik quanstrom @ 2010-11-10 0:37 ` erik quanstrom 2010-11-10 1:49 ` Russ Cox 0 siblings, 1 reply; 39+ messages in thread From: erik quanstrom @ 2010-11-10 0:37 UTC (permalink / raw) To: 9fans On Tue Nov 9 13:01:17 EST 2010, quanstro@quanstro.net wrote: > > This is tangential to the topic, but has anyone written up a "how I use p9p" > > configuration style document? I've not really tried to use factotum from > > p9p, because I was not even sure if it worked. > > "recently", that is within the past 2 years, p9p factotum has stopped > working with drawterm. it might be that porting back some of the > fixes to p9p factotum in nfactotum would fix that. no dice. still hangs on startup: where #0 0x00007fb507c8440d in read () from /lib/libpthread.so.0 #1 0x0000000000410c77 in lfdread (c=0x6e0b60, buf=0x6e4e60, n=8192, off=0) at devlfd.c:86 #2 0x000000000040be90 in devbread (c=0x6e0b60, n=8192, offset=0) at dev.c:414 #3 0x00000000004128c6 in doread (m=0x6e0850, len=7) at devmnt.c:852 #4 0x000000000041296a in mntrpcread (m=0x6e0850, r=0x6e0dc0) at devmnt.c:874 #5 0x000000000041282c in mountio (m=0x6e0850, r=0x6e0dc0) at devmnt.c:837 #6 0x00000000004124ce in mountrpc (m=0x6e0850, r=0x6e0dc0) at devmnt.c:764 #7 0x0000000000411702 in mntattach (muxattach=0x7fff8a3da990 "`\vn") at devmnt.c:349 #8 0x0000000000415b23 in bindmount (ismount=1, fd=3, afd=-1, arg0=0x0, arg1=0x45be6e "/mnt/factotum", flag=0, spec=0x45bdf0 "") at sysfile.c:682 #9 0x0000000000415cba in _sysmount (fd=3, afd=-1, new=0x45be6e "/mnt/factotum", flag=0, spec=0x45bdf0 "") at sysfile.c:727 #10 0x0000000000416380 in sysmount (fd=3, afd=-1, new=0x45be6e "/mnt/factotum", flag=0, spec=0x45bdf0 "") at sysfile.c:988 #11 0x00000000004037a1 in mountfactotum () at cpu.c:87 #12 0x0000000000403ef9 in cpumain (argc=0, argv=0x7fff8a3dae70) at cpu.c:165 #13 0x0000000000403313 in main (argc=3, argv=0x7fff8a3dae58) at main.c:68 - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-10 0:37 ` erik quanstrom @ 2010-11-10 1:49 ` Russ Cox 2010-11-10 6:46 ` erik quanstrom 0 siblings, 1 reply; 39+ messages in thread From: Russ Cox @ 2010-11-10 1:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 75 bytes --] Factotum doesn't answer that message. You need to be looking at 9pserve. [-- Attachment #2: Type: text/html, Size: 90 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-10 1:49 ` Russ Cox @ 2010-11-10 6:46 ` erik quanstrom 2010-11-10 14:31 ` Russ Cox 0 siblings, 1 reply; 39+ messages in thread From: erik quanstrom @ 2010-11-10 6:46 UTC (permalink / raw) To: 9fans On Tue Nov 9 20:51:30 EST 2010, rsc@swtch.com wrote: > Factotum doesn't answer that message. > You need to be looking at 9pserve. maybe i'm missing something, but 9pserve is also the mechanism behind plumb, and it works. why would p9serve be broken, but only for factotum? more likely that drawterm itself is broken? - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-10 6:46 ` erik quanstrom @ 2010-11-10 14:31 ` Russ Cox 2010-11-12 3:35 ` Noah Evans 0 siblings, 1 reply; 39+ messages in thread From: Russ Cox @ 2010-11-10 14:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs >> Factotum doesn't answer that message. >> You need to be looking at 9pserve. > > maybe i'm missing something, but 9pserve is also the > mechanism behind plumb, and it works. why would > p9serve be broken, but only for factotum? more likely > that drawterm itself is broken? It's always hard to say which program is broken when two programs can't talk to each other. I was only trying to point out that the two programs involved are drawterm and 9pserve, not drawterm and factotum (you had made changes to factotum in hopes that would fix it). I suspect the problem has to do with the so-called 9P2000.u protocol negotiation that 9pserve supports. Russ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-10 14:31 ` Russ Cox @ 2010-11-12 3:35 ` Noah Evans 2010-11-12 5:34 ` erik quanstrom 0 siblings, 1 reply; 39+ messages in thread From: Noah Evans @ 2010-11-12 3:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs You can keep srv() from eating Tattach's and Tauth's without numeric userids with the following: --- a/src/cmd/9pserve.c Wed Nov 03 15:49:22 2010 -0400 +++ b/src/cmd/9pserve.c Thu Nov 11 19:27:02 2010 -0800 @@ -440,6 +440,8 @@ m->tx.uname = getuser(); /* what srv.c used */ repack(&m->tx, &m->tpkt, c->dotu); } + if(dotu && !c->dotu) + repack(&m->tx, &m->tpkt, dotu); break; case Twalk: if((m->fid = gethash(c->fid, m->tx.fid)) == nil){ @@ -474,6 +476,8 @@ continue; } m->afid->ref++; + if(dotu && !c->dotu) + repack(&m->tx, &m->tpkt, dotu); break; case Tcreate: if(dotu && !c->dotu && (m->tx.perm&(DMSYMLINK|DMDEVICE|DMNAMEDPIPE|DMSOCKET))){ knieriem also proposed a fix at: http://code.swtch.com/plan9port/issue/38/9pserve-not-translating-9p2000-client-msgs Russ does this approach blow up your ssh-agent? Noah On Wed, Nov 10, 2010 at 6:31 AM, Russ Cox <rsc@swtch.com> wrote: >>> Factotum doesn't answer that message. >>> You need to be looking at 9pserve. >> >> maybe i'm missing something, but 9pserve is also the >> mechanism behind plumb, and it works. why would >> p9serve be broken, but only for factotum? more likely >> that drawterm itself is broken? > > It's always hard to say which program is broken > when two programs can't talk to each other. > I was only trying to point out that the two programs > involved are drawterm and 9pserve, not drawterm > and factotum (you had made changes to factotum > in hopes that would fix it). > > I suspect the problem has to do with the so-called > 9P2000.u protocol negotiation that 9pserve supports. > > Russ > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 3:35 ` Noah Evans @ 2010-11-12 5:34 ` erik quanstrom 2010-11-12 5:46 ` Noah Evans 2010-11-12 6:03 ` Noah Evans 0 siblings, 2 replies; 39+ messages in thread From: erik quanstrom @ 2010-11-12 5:34 UTC (permalink / raw) To: 9fans > You can keep srv() from eating Tattach's and Tauth's without numeric > userids with the following: this patch + factotum + drawterm yields this for me on starting drawterm: console 9pserve: convS2Mu and sizeS2Mu disagree in drawterm <blah> mount rpc error - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 5:34 ` erik quanstrom @ 2010-11-12 5:46 ` Noah Evans 2010-11-12 6:03 ` Noah Evans 1 sibling, 0 replies; 39+ messages in thread From: Noah Evans @ 2010-11-12 5:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Are you using the tip of plan9ports? Noah On Thu, Nov 11, 2010 at 9:34 PM, erik quanstrom <quanstro@quanstro.net> wrote: >> You can keep srv() from eating Tattach's and Tauth's without numeric >> userids with the following: > > this patch + factotum + drawterm yields this for me > on starting drawterm: > > console > 9pserve: convS2Mu and sizeS2Mu disagree > in drawterm > <blah> mount rpc error > > - erik > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 5:34 ` erik quanstrom 2010-11-12 5:46 ` Noah Evans @ 2010-11-12 6:03 ` Noah Evans 2010-11-12 6:19 ` Russ Cox 1 sibling, 1 reply; 39+ messages in thread From: Noah Evans @ 2010-11-12 6:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Nope, you're right. I got your behavior. There's a race. Noah On Thu, Nov 11, 2010 at 9:34 PM, erik quanstrom <quanstro@quanstro.net> wrote: >> You can keep srv() from eating Tattach's and Tauth's without numeric >> userids with the following: > > this patch + factotum + drawterm yields this for me > on starting drawterm: > > console > 9pserve: convS2Mu and sizeS2Mu disagree > in drawterm > <blah> mount rpc error > > - erik > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 6:03 ` Noah Evans @ 2010-11-12 6:19 ` Russ Cox 2010-11-12 6:25 ` Noah Evans ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Russ Cox @ 2010-11-12 6:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Does anyone use 9P2000.u anymore? Can we just remove it from the p9p tree? Russ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 6:19 ` Russ Cox @ 2010-11-12 6:25 ` Noah Evans 2010-11-12 9:07 ` EBo 2010-11-12 15:19 ` Eric Van Hensbergen 2 siblings, 0 replies; 39+ messages in thread From: Noah Evans @ 2010-11-12 6:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I don't. I say go for it. Noah On Thu, Nov 11, 2010 at 10:19 PM, Russ Cox <rsc@swtch.com> wrote: > Does anyone use 9P2000.u anymore? > Can we just remove it from the p9p tree? > > Russ > > ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 6:19 ` Russ Cox 2010-11-12 6:25 ` Noah Evans @ 2010-11-12 9:07 ` EBo 2010-11-12 15:12 ` David Leimbach 2010-11-12 15:19 ` Eric Van Hensbergen 2 siblings, 1 reply; 39+ messages in thread From: EBo @ 2010-11-12 9:07 UTC (permalink / raw) To: 9fans > Does anyone use 9P2000.u anymore? > Can we just remove it from the p9p tree? Last summer when I was banging my head against the bug in alloctree I got it all to work when I removed 9P2000.u and some other stuff from lib9p/srv.c. At that time I got a comment back that the patches I proposed would likely not be accepted, in part because I removed the 9P2000.u code... If there are no objections to removing 9P2000.u, I can tell you that migrating p9p's srv.c code back to Plan 9's version does in fact fix the bugs in Tree. I was simply not sure how many of the changes had to be reverted to make alloctree work properly. EBo -- ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 9:07 ` EBo @ 2010-11-12 15:12 ` David Leimbach 0 siblings, 0 replies; 39+ messages in thread From: David Leimbach @ 2010-11-12 15:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 894 bytes --] On Fri, Nov 12, 2010 at 1:07 AM, EBo <ebo@sandien.com> wrote: > Does anyone use 9P2000.u anymore? >> Can we just remove it from the p9p tree? >> > > Last summer when I was banging my head against the bug in alloctree I got > it all to work when I removed 9P2000.u and some other stuff from > lib9p/srv.c. At that time I got a comment back that the patches I proposed > would likely not be accepted, in part because I removed the 9P2000.u code... > > If there are no objections to removing 9P2000.u, I can tell you that > migrating p9p's srv.c code back to Plan 9's version does in fact fix the > bugs in Tree. I was simply not sure how many of the changes had to be > reverted to make alloctree work properly. > > > It seems like a good idea to removing .u. I think I can add .u back to some other 9P implementations I have if I want it. Dave > EBo -- > > > [-- Attachment #2: Type: text/html, Size: 1505 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 6:19 ` Russ Cox 2010-11-12 6:25 ` Noah Evans 2010-11-12 9:07 ` EBo @ 2010-11-12 15:19 ` Eric Van Hensbergen 2010-11-12 15:35 ` erik quanstrom 2010-11-12 15:55 ` Russ Cox 2 siblings, 2 replies; 39+ messages in thread From: Eric Van Hensbergen @ 2010-11-12 15:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 12:19 AM, Russ Cox <rsc@swtch.com> wrote: > Does anyone use 9P2000.u anymore? > Can we just remove it from the p9p tree? > I don't use it from plan9ports. Not sure if Lucho is still using it (or variants). But.... why does version negotiation muck things up? It seems like if the other side isn't responding with .u then there shouldn't be any issues. -eric ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 15:19 ` Eric Van Hensbergen @ 2010-11-12 15:35 ` erik quanstrom 2010-11-12 15:55 ` Russ Cox 1 sibling, 0 replies; 39+ messages in thread From: erik quanstrom @ 2010-11-12 15:35 UTC (permalink / raw) To: 9fans > But.... why does version negotiation muck things up? It seems like if > the other side isn't responding with .u then there shouldn't be any > issues. i think that's exactly it. the .u stuff leaks out of the version negotiation phase and changes the behavior of other messages. - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 15:19 ` Eric Van Hensbergen 2010-11-12 15:35 ` erik quanstrom @ 2010-11-12 15:55 ` Russ Cox 2010-11-12 16:22 ` Eric Van Hensbergen 1 sibling, 1 reply; 39+ messages in thread From: Russ Cox @ 2010-11-12 15:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I don't use it from plan9ports. Not sure if Lucho is still using it > (or variants). > > But.... why does version negotiation muck things up? It seems like if > the other side isn't responding with .u then there shouldn't be any > issues. It just complicates everything, especially in a protocol multiplexer. You have to keep track of whether you're serving .u because it changes the layout of various messages and also the dir struct. I was happy to support the experiment but it sounds like the experiment has failed. Russ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 15:55 ` Russ Cox @ 2010-11-12 16:22 ` Eric Van Hensbergen 2010-11-12 19:55 ` ron minnich 0 siblings, 1 reply; 39+ messages in thread From: Eric Van Hensbergen @ 2010-11-12 16:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 9:55 AM, Russ Cox <rsc@swtch.com> wrote: >> I don't use it from plan9ports. Not sure if Lucho is still using it >> (or variants). >> >> But.... why does version negotiation muck things up? It seems like if >> the other side isn't responding with .u then there shouldn't be any >> issues. > > It just complicates everything, especially in a > protocol multiplexer. You have to keep track > of whether you're serving .u because it changes > the layout of various messages and also the dir > struct. I was happy to support the experiment but > it sounds like the experiment has failed. > The complications with overloading existing operations is why we started going with a new approach (.L). I just wanted to make sure I understood the issues in the p9p version to make sure we aren't repeating them. -eric ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 16:22 ` Eric Van Hensbergen @ 2010-11-12 19:55 ` ron minnich 2010-11-12 20:23 ` erik quanstrom ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: ron minnich @ 2010-11-12 19:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I never much liked .u so I'm happy to see it go away :-) But I wonder what the failure of .u says about the version mechanism. In the 9p stuff I did in 1998 for linux I used the SunRPC way of handling protocol variants: client asked to do an op (e.g. Treadlink) and got back an ENOSUPPORT if server couldn't do that. Client would then shortstop the operation on the client side from that point on, as it knew what the server could and could not do. That worked well for both me and SunRPC (i.e. NFS). (I had no choice at the time; this was a little bit before Tversion existed). That might work but Plan 9 servers currently silently discard T messages they don't understand, so this way of determining server capabilities can't be used. My impression is that if you see .L, then extra operations are supported and you assume they'll work; is that true? There are other issues with the versioning mechanism however. What if a server supports capabilities of two versions, e.g. .L and .op? Do we reply 9p2000.L+9p2000.op It seems we made the first real test of versioning with .u and things did not go as we hoped ... As for the uid/gid mess, the simplest way out it seemed to me was to send the numbers as strings; done. People can just put the strings for the numbers in /etc/passwd; that's what I did anyway. And, finally, errno and errstr. Plan 9 speaks strings, Unix integers, Windows strings IIRC. The solution for unix clients was reverse mapping of errstr to errno, which has not worked well for me. I'd still prefer the format I used before: sprint(rmsg.error, "%d:%s", errno, errstr); and let the client figure out which of these two things it wants. Obviously useless for Plan 9 servers but very useful for *nix clients/servers, which only want to talk errno. Even if the Plan 9 client sees an errstr in the number:message format, that could be helpful to users. So, sorry to disinter this old discussion, but my $.02 and the pinon coffee just woke me up a little. ron ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 19:55 ` ron minnich @ 2010-11-12 20:23 ` erik quanstrom 2010-11-12 20:31 ` Eric Van Hensbergen 2010-11-12 20:30 ` Eric Van Hensbergen 2010-11-12 21:12 ` Russ Cox 2 siblings, 1 reply; 39+ messages in thread From: erik quanstrom @ 2010-11-12 20:23 UTC (permalink / raw) To: 9fans > And, finally, errno and errstr. Plan 9 speaks strings, Unix integers, > Windows strings IIRC. The solution for unix clients was reverse > mapping of errstr to errno, which has not worked well for me. I'd > still prefer the format I used before: > sprint(rmsg.error, "%d:%s", errno, errstr); > and let the client figure out which of these two things it wants. > Obviously useless for Plan 9 servers but very useful for *nix > clients/servers, which only want to talk errno. Even if the Plan 9 > client sees an errstr in the number:message format, that could be > helpful to users. since plan 9 assumes that strings are null-terminated but 9p has explicit rle, one could send uids/errorno after the 0, but before the rle says the string is done. sleezy, and hackish, but it should work. also, one can always support many extensions by doing the following (a) extensions are [a-zA-Z] (b) all extensions start with "." then you can check for the existence of an extension with if(strstr(version, ".myextension") != nil) extensions |= Myextension; and P92000.l.op.xyz.pdq will be legal. - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 20:23 ` erik quanstrom @ 2010-11-12 20:31 ` Eric Van Hensbergen 2010-11-12 20:37 ` ron minnich 0 siblings, 1 reply; 39+ messages in thread From: Eric Van Hensbergen @ 2010-11-12 20:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 2:23 PM, erik quanstrom <quanstro@labs.coraid.com> wrote: > > since plan 9 assumes that strings are null-terminated but > 9p has explicit rle, one could send uids/errorno after the 0, > but before the rle says the string is done. > > sleezy, and hackish, but it should work. > FWIW I think this is a horrible idea. -eric ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 20:31 ` Eric Van Hensbergen @ 2010-11-12 20:37 ` ron minnich 0 siblings, 0 replies; 39+ messages in thread From: ron minnich @ 2010-11-12 20:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 12:31 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > On Fri, Nov 12, 2010 at 2:23 PM, erik quanstrom > <quanstro@labs.coraid.com> wrote: >> >> since plan 9 assumes that strings are null-terminated but >> 9p has explicit rle, one could send uids/errorno after the 0, >> but before the rle says the string is done. >> >> sleezy, and hackish, but it should work. >> > > FWIW I think this is a horrible idea. I agree. This kind of trickery just comes back to bite you at some point. We just learned this with .u, do we need to do it all over again and regret it in 6 years? ron ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 19:55 ` ron minnich 2010-11-12 20:23 ` erik quanstrom @ 2010-11-12 20:30 ` Eric Van Hensbergen 2010-11-12 20:41 ` ron minnich 2010-11-12 21:12 ` Russ Cox 2 siblings, 1 reply; 39+ messages in thread From: Eric Van Hensbergen @ 2010-11-12 20:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 1:55 PM, ron minnich <rminnich@gmail.com> wrote: > > That might work but Plan 9 servers currently silently discard T > messages they don't understand, so this way of determining server > capabilities can't be used. > Silent discard is a bit unfriendly and likely to hang the client. Returning Rerror for any T message you don't understand is a bit more friendly (and is what is written in the .L proposal). > My impression is that if you see .L, then extra operations are > supported and you assume they'll work; is that true? Not really, the intent was that servers could implement a subset of the .L features, and return Rerror for any that they don't. The intent was so that a client could degrade gracefully or report lack of features back to the application/user. The current client and server for .L (that I'm aware of) doesn't do this yet (it is still in development), but that is the intent. > > There are other issues with the versioning mechanism however. What if > a server supports capabilities of two versions, e.g. .L and .op? Do we > reply > 9p2000.L+9p2000.op > That isn't currently supported by anything (that I am aware of), although I imagine the right response woul dbe 9p2000.L.op. Of course, the op guys specified their stuff as an entirely different protocol, so not currently a problem. > It seems we made the first real test of versioning with .u and things > did not go as we hoped ... Well, the .u was a "clumsy" design intended to have minimum interference, but in fact changed the size of certain protocol messages which really threw a monkey wrench into certain clients or servers. The first test of the version stuff was 9p versus 9p2000, and that worked just fine, but I don't think much was done to test outside of these two conditions. > > As for the uid/gid mess, the simplest way out it seemed to me was to > send the numbers as strings; done. People can just put the strings for > the numbers in /etc/passwd; that's what I did anyway. > Doesn't really work in multi-account environments where uid on one system doesn't equal uid on the other system. Also introduces potential parse problems. > And, finally, errno and errstr. Plan 9 speaks strings, Unix integers, > Windows strings IIRC. The solution for unix clients was reverse > mapping of errstr to errno, which has not worked well for me. I'd > still prefer the format I used before: > sprint(rmsg.error, "%d:%s", errno, errstr); > and let the client figure out which of these two things it wants. > Obviously useless for Plan 9 servers but very useful for *nix > clients/servers, which only want to talk errno. Even if the Plan 9 > client sees an errstr in the number:message format, that could be > helpful to users. More or less what we did in .u (it had both, just not in the same string). In any case, if you are talking to Plan 9, you talk 9P2000 and everything is as it should be except errors are a little funny. If you are talking to Linux from Plan 9, you talk 9P2000 and get by. If you are talking Linux<->Linux then you really should use the Linux native structures, ids, errcodes, etc. This is the .L path. Hey man, IIRC you were Lucho's boss when he did the .u implementation -- so it's all your fault :P -eric ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 20:30 ` Eric Van Hensbergen @ 2010-11-12 20:41 ` ron minnich 2010-11-12 22:15 ` Eric Van Hensbergen 2010-11-15 17:50 ` John Floren 0 siblings, 2 replies; 39+ messages in thread From: ron minnich @ 2010-11-12 20:41 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > Not really, the intent was that servers could implement a subset of > the .L features, and return Rerror for any that they don't. Wonderful! Floren is already fixing plan 9 servers to work this way anyway :-) > That isn't currently supported by anything (that I am aware of), > although I imagine the right response woul dbe 9p2000.L.op. Of > course, the op guys specified their stuff as an entirely different > protocol, so not currently a problem. It was just an example, I picked op out of the air, I well know that it's not the right example ;-) > Doesn't really work in multi-account environments where uid on one > system doesn't equal uid on the other system. Also introduces > potential parse problems. but names are not guaranteed to be the either, right? I don't see that names solve this versus numbers. > Hey man, IIRC you were Lucho's boss when he did the .u implementation > -- so it's all your fault :P I was the guy who never liked it, but I figured you smart guys would work it all out :-) ron ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 20:41 ` ron minnich @ 2010-11-12 22:15 ` Eric Van Hensbergen 2010-11-12 22:20 ` ron minnich 2010-11-15 17:50 ` John Floren 1 sibling, 1 reply; 39+ messages in thread From: Eric Van Hensbergen @ 2010-11-12 22:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 2:41 PM, ron minnich <rminnich@gmail.com> wrote: >> Doesn't really work in multi-account environments where uid on one >> system doesn't equal uid on the other system. Also introduces >> potential parse problems. > > but names are not guaranteed to be the either, right? I don't see that > names solve this versus numbers. > No, that's true. I think this is actually a huge open issue for existing distributed file systems in general and I'm not sure of a good way around. Linux (Posix?) does make it much tougher by insisting that remote files must have owners mappable to the local numeric uid database. The asteroid to kill that dinosaur is still in orbit, let's hope it comes down soon. > > >> Hey man, IIRC you were Lucho's boss when he did the .u implementation >> -- so it's all your fault :P > > I was the guy who never liked it, but I figured you smart guys would > work it all out :-) > What's worse is that it was put in to make you happy! Your just trying to dodge blame now. -eric ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 22:15 ` Eric Van Hensbergen @ 2010-11-12 22:20 ` ron minnich 2010-11-12 22:36 ` Russ Cox ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: ron minnich @ 2010-11-12 22:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > No, that's true. I think this is actually a huge open issue for > existing distributed file systems in general and I'm not sure of a > good way around. yeah, we had lots of discussion of this about 8 years ago with 9grid and never worked it out. What's your global identify? How do you name it? How do you map it to a local identity? I have no clue. ron ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 22:20 ` ron minnich @ 2010-11-12 22:36 ` Russ Cox 2010-11-13 8:31 ` tlaronde 2010-11-14 22:49 ` Nathaniel W Filardo 2 siblings, 0 replies; 39+ messages in thread From: Russ Cox @ 2010-11-12 22:36 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Someone send me a patch to expunge .u and I will apply it. :-) Russ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 22:20 ` ron minnich 2010-11-12 22:36 ` Russ Cox @ 2010-11-13 8:31 ` tlaronde 2010-11-13 23:42 ` Dave Eckhardt 2010-11-14 22:49 ` Nathaniel W Filardo 2 siblings, 1 reply; 39+ messages in thread From: tlaronde @ 2010-11-13 8:31 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 02:20:35PM -0800, ron minnich wrote: > On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > > > No, that's true. I think this is actually a huge open issue for > > existing distributed file systems in general and I'm not sure of a > > good way around. > > yeah, we had lots of discussion of this about 8 years ago with 9grid > and never worked it out. What's your global identify? How do you name > it? How do you map it to a local identity? I have no clue. The problem with strings is that they are human oriented and human dependent, on mood and/or trend. Numbers are agnostic. Isn't a solution à la IP network numbers possible? I mean, a user, whatever string is locally associated to it (and this may change), is uniquely identified by a number that could encode a domain (with some numbers being absolutely local), the conversion between string to number being local (I'm called "god" on my personal systems, and may be called "dummy" elsewhere; well, in fact "god" is "root" on Unices, and this "god" is only a local thing, with external systems don't believing in it at all), and negociation being only with numbers. And separate logical user from physical user: a physical user can be, depending on the task, several distinct logical users; but the reverse is true: several distinct physical users can be an uniq logical user. This changes the way one thinks about the sharing of randomly writable files: only "the" (logical) user of a file can randomly write (by randomly, I mean not append) a file; but there can be several concurrent instances of "the" user writing to the file (an instance of a user is called a terminal; and a terminal is a temporary view of the data). And there are group writable files that are only append writable so long as a new record doesn't invalidate the previous ones [partition] (hence distinct logical users sharing a group writable file don't care about other writes when reading; when writing, an identifier is returned, and if the record already exists, added by another user, the existing identifier is returned, else it is added and the new identifier is returned). The use of numbers mapping to a string that can change is the principle I have adopted with my CVS: the "projects" are only numbers, and if the mood (or the "marketing") change, only the string associated changes, the hierarchy is left alone since the numbers are fixed from start. -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-13 8:31 ` tlaronde @ 2010-11-13 23:42 ` Dave Eckhardt 0 siblings, 0 replies; 39+ messages in thread From: Dave Eckhardt @ 2010-11-13 23:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > The problem with strings is that they are human oriented and human > dependent, on mood and/or trend. Numbers are agnostic. > > Isn't a solution a la IP network numbers possible? I mean, a user, > whatever string is locally associated to it (and this may change), > is uniquely identified by a number that could encode a domain (with > some numbers being absolutely local) [...] I think the Inferno guys have relevant art. Principals are identified by public keys (which are indeed numbers). But I am not an expert on how this plays out in practice, and I also have a sense that the current Inferno implementation is an approximation of the design goals. Dave Eckhardt ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 22:20 ` ron minnich 2010-11-12 22:36 ` Russ Cox 2010-11-13 8:31 ` tlaronde @ 2010-11-14 22:49 ` Nathaniel W Filardo 2010-11-15 16:22 ` erik quanstrom 2 siblings, 1 reply; 39+ messages in thread From: Nathaniel W Filardo @ 2010-11-14 22:49 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1003 bytes --] On Fri, Nov 12, 2010 at 02:20:35PM -0800, ron minnich wrote: > On Fri, Nov 12, 2010 at 2:15 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > > > No, that's true. I think this is actually a huge open issue for > > existing distributed file systems in general and I'm not sure of a > > good way around. > > yeah, we had lots of discussion of this about 8 years ago with 9grid > and never worked it out. One proposal would be... > What's your global identify? A public (SPKI) key or, more robustly, a halo of subkeys. > How do you name it? By the shortest path from the key currently used as root, which probably is the same as your public identity, so it gets stringified as "" or "." or "self" or somesuch. > How do you map it to a local identity? There's less need to, since most rights checks would be done using the key directly, but eve's factotum also probably has a SPKI key, and your identity can be stringified into a path of names if necessary. --nwf; [-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-14 22:49 ` Nathaniel W Filardo @ 2010-11-15 16:22 ` erik quanstrom 2010-11-15 17:40 ` Nathaniel W Filardo 0 siblings, 1 reply; 39+ messages in thread From: erik quanstrom @ 2010-11-15 16:22 UTC (permalink / raw) To: 9fans > > How do you map it to a local identity? > > There's less need to, since most rights checks would be done using the key > directly, but eve's factotum also probably has a SPKI key, and your identity > can be stringified into a path of names if necessary. in that case, what do you do with the username? do you have to change username if you rekey? - erik ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-15 16:22 ` erik quanstrom @ 2010-11-15 17:40 ` Nathaniel W Filardo 0 siblings, 0 replies; 39+ messages in thread From: Nathaniel W Filardo @ 2010-11-15 17:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 715 bytes --] On Mon, Nov 15, 2010 at 11:22:52AM -0500, erik quanstrom wrote: > > > How do you map it to a local identity? > > > > There's less need to, since most rights checks would be done using the key > > directly, but eve's factotum also probably has a SPKI key, and your identity > > can be stringified into a path of names if necessary. > > in that case, what do you do with the username? do you have > to change username if you rekey? Hm; I wasn't thinking about rekeying. You're free to use the path from eve's factotum, which may go via a local naming authority, if you like. Then the authority simply changes its view of names in response to your rekeying and everything stays the same. --nwf; [-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 20:41 ` ron minnich 2010-11-12 22:15 ` Eric Van Hensbergen @ 2010-11-15 17:50 ` John Floren 1 sibling, 0 replies; 39+ messages in thread From: John Floren @ 2010-11-15 17:50 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 3:41 PM, ron minnich <rminnich@gmail.com> wrote: > On Fri, Nov 12, 2010 at 12:30 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > >> Not really, the intent was that servers could implement a subset of >> the .L features, and return Rerror for any that they don't. > > Wonderful! Floren is already fixing plan 9 servers to work this way anyway :-) > Actually, I just have my streaming clients/servers give their versions as 9P2000.s; unrecognized T-messages still get silently dropped. I decided this was a better option for my current work, since it allows me to connect to any unmodified 9P file system, rather than go through and modify every single 9P server out there. That said, I definitely agree that unrecognized T-messages should get an Rerror back; I was kind of grossed out when I discovered that they were being dropped, I had figured that was part of the purpose of Rerror. If 9P ever has to change again (adding new T-messages), you'll find it a lot easier to interoperate old and new code if we get Rerrors on bogus T-messages. John ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-12 19:55 ` ron minnich 2010-11-12 20:23 ` erik quanstrom 2010-11-12 20:30 ` Eric Van Hensbergen @ 2010-11-12 21:12 ` Russ Cox 2 siblings, 0 replies; 39+ messages in thread From: Russ Cox @ 2010-11-12 21:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 12, 2010 at 2:55 PM, ron minnich <rminnich@gmail.com> wrote: > I never much liked .u so I'm happy to see it go away :-) > But I wonder what the failure of .u says about the version mechanism. I think it says you shouldn't use it to change the encoding of existing messages. Add messages all you want (and use the negotiation to make sure you agree on what they are) but don't change the messages that are already there, and especially don't change format of fundamental data structures like Dir. > In the 9p stuff I did in 1998 for linux I used the SunRPC way of > handling protocol variants: client asked to do an op (e.g. Treadlink) > and got back an ENOSUPPORT if server couldn't do that. Sun RPC can get away with that because there are 64+ bits describing a particular RPC request type. 9P has 8. You shouldn't just send an 8-bit value and hope the other side knows which one you mean. You should use the protocol negotiation. Russ ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-09 17:41 ` David Leimbach 2010-11-09 17:51 ` erik quanstrom @ 2010-11-09 18:08 ` yy 2010-11-09 19:17 ` Bakul Shah 2010-11-09 19:27 ` Russ Cox 3 siblings, 0 replies; 39+ messages in thread From: yy @ 2010-11-09 18:08 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2010/11/9 David Leimbach <leimy2k@gmail.com>: > I'm wondering things like "can I use p9p venti as a snapshot back end to a > VMWare Plan 9 Fossil? mycroftiv is doing it with qemu. He has writen about it and you can download the whole thing from 9gridchan.org. -- - yiyus || JGL . 4l77.com ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-09 17:41 ` David Leimbach 2010-11-09 17:51 ` erik quanstrom 2010-11-09 18:08 ` yy @ 2010-11-09 19:17 ` Bakul Shah 2010-11-09 19:27 ` Russ Cox 3 siblings, 0 replies; 39+ messages in thread From: Bakul Shah @ 2010-11-09 19:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Tue, 09 Nov 2010 09:41:26 PST David Leimbach <leimy2k@gmail.com> wrote: > > Also the one time I tried to set up venti from p9p I basically failed > horribly, and wasn't really sure what I did wrong. (I should read the > installation scripts for Plan 9 and the man pages but haven't had time to > get back to it). See $PLAN9/src/cmd/venti/srv/tester. When I was first playing with venti about 5 years back, I used a `newventi' script like the one below. It creates all the necessary data & conf files in $PWD. Modify as per taste. Once set up, start as $PLAN9/bin/venti/venti -c $conf You have to be a bit careful when shutting things down (flush dcache or something -- can't remember). If you decide to back up ffs/ffs2/hfs/ext2fs/fat filesystems, Russ's backup scripts are pretty handy. --- #!/bin/sh PATH=$PATH:$PLAN9/bin:$PLAN9/bin/venti export PATH d=$PWD bs=8k conf=venti.conf echo index main > $conf for i in 0 1 2 3 do rm -f arenas$i; touch arenas$i; truncate -s 32G arenas$i; fmtarenas -b $bs arenas$i. arenas$i echo arenas arenas$i >> $conf done isect=$d/isect0 rm -f $isect; touch $isect; truncate -s 8G $isect fmtisect -b $bs isect0. $isect echo isect $isect >> $conf bloom=$d/bloom rm -f $bloom; touch $bloom; truncate -s 64M $bloom; fmtbloom $bloom echo bloom $bloom >> $conf cat >> $conf <<EOF mem 128M bcmem 64M icmem 64M queuewrites webroot $d/www httpaddr tcp!*!9091 EOF fmtindex $conf ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [9fans] p9p factotum available for plan 9 2010-11-09 17:41 ` David Leimbach ` (2 preceding siblings ...) 2010-11-09 19:17 ` Bakul Shah @ 2010-11-09 19:27 ` Russ Cox 3 siblings, 0 replies; 39+ messages in thread From: Russ Cox @ 2010-11-09 19:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > This is tangential to the topic, but has anyone written up a "how I use p9p" > configuration style document? I've not really tried to use factotum from > p9p, because I was not even sure if it worked. http://9fans.net/archive/2007/11/120 Russ ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2010-11-15 17:50 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-03 21:13 [9fans] p9p factotum available for plan 9 erik quanstrom 2010-11-09 3:37 ` erik quanstrom 2010-11-09 17:41 ` David Leimbach 2010-11-09 17:51 ` erik quanstrom 2010-11-10 0:37 ` erik quanstrom 2010-11-10 1:49 ` Russ Cox 2010-11-10 6:46 ` erik quanstrom 2010-11-10 14:31 ` Russ Cox 2010-11-12 3:35 ` Noah Evans 2010-11-12 5:34 ` erik quanstrom 2010-11-12 5:46 ` Noah Evans 2010-11-12 6:03 ` Noah Evans 2010-11-12 6:19 ` Russ Cox 2010-11-12 6:25 ` Noah Evans 2010-11-12 9:07 ` EBo 2010-11-12 15:12 ` David Leimbach 2010-11-12 15:19 ` Eric Van Hensbergen 2010-11-12 15:35 ` erik quanstrom 2010-11-12 15:55 ` Russ Cox 2010-11-12 16:22 ` Eric Van Hensbergen 2010-11-12 19:55 ` ron minnich 2010-11-12 20:23 ` erik quanstrom 2010-11-12 20:31 ` Eric Van Hensbergen 2010-11-12 20:37 ` ron minnich 2010-11-12 20:30 ` Eric Van Hensbergen 2010-11-12 20:41 ` ron minnich 2010-11-12 22:15 ` Eric Van Hensbergen 2010-11-12 22:20 ` ron minnich 2010-11-12 22:36 ` Russ Cox 2010-11-13 8:31 ` tlaronde 2010-11-13 23:42 ` Dave Eckhardt 2010-11-14 22:49 ` Nathaniel W Filardo 2010-11-15 16:22 ` erik quanstrom 2010-11-15 17:40 ` Nathaniel W Filardo 2010-11-15 17:50 ` John Floren 2010-11-12 21:12 ` Russ Cox 2010-11-09 18:08 ` yy 2010-11-09 19:17 ` Bakul Shah 2010-11-09 19:27 ` Russ Cox
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).