You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(42) |
Nov
|
Dec
|
---|
From: Nathan Y. <na...@yo...> - 2002-10-29 01:12:59
|
Hey all - Dave has setup a private group and forum on the new CSCE Forums page: http://www.cs.plu.edu/forums/ After you have registered, drop him an email with your username and he will add you to the group. This forum is much better about code postings, quoting etc - so I think it will be a bit nicer for us over time. Thanks! Nate |
From: Nathan Y. <na...@yo...> - 2002-10-27 21:58:28
|
On Sun, 2002-10-27 at 12:52, David Wolff wrote: > Hmmm.. You make an interesting point. I guess the question is, how does > Linux handle a localhost socket connection? As far as I know, it > uses TCP/IP even though client and server are on the same host. Hence > my guess is that it is not just a communication over the bus. The > data may be routed through some kind of serial interface. I'm guessing > that we should expect slower performance than say just regular IPC. True - good point. I did some tests with other network services (apache/sftp/ftp) and file transfer rates on a localhost connection, and indeed i seem to transfer a 171 MB file in a little over a minute (making for about 300K/sec) - so we may be on the right track. > Yes, we definately should test it out with clients on different > machines. I've already done a little of that on my home network, but > I haven't compared the results to localhost communications. Cool - why dont we meet on Thursday and give this a shot? we can run it on our office machines as well as the oracle machine and shemp itself... should give us a pretty good idea of how things look. > > I agree - Very good news! :-) > > > Yeah! Have a beer in celebration (hey any chance to celebrate eh?). Celebration ;-) means more than just A beer hehe. Sounds like a damn good idea though, I think I will follow up on that. Later! Nate |
From: David W. <wo...@pl...> - 2002-10-27 20:52:09
|
> >>Yes, I believe that 9729 ~ 9.5K. However, there are 21 clients that >>are sharing the same "pipe" so that is actually 9.5K * 21 bytes/sec, or >>about 200K/sec. Now, this is assuming that they all start and end at >>the same time which is not exactly true, but hopefully close. Do you >>agree with that logic? > > > I agree with the logic, but over a local bus on the same machine we > should see a much bigger pipe that 200k/sec... Could have something to > do with how we recieve the messages too (byte by byte vs a whole buffer > at a time), but I would think we could get MUCH higher. Perhaps its > time we ran the server on shemp and beat against it with a few clients > to see what kind of responses we get? Hmmm.. You make an interesting point. I guess the question is, how does Linux handle a localhost socket connection? As far as I know, it uses TCP/IP even though client and server are on the same host. Hence my guess is that it is not just a communication over the bus. The data may be routed through some kind of serial interface. I'm guessing that we should expect slower performance than say just regular IPC. Yes, we definately should test it out with clients on different machines. I've already done a little of that on my home network, but I haven't compared the results to localhost communications. > > >>>I also get different sec/message rates depending on the # of clients. ~ >>>0.001 with < 10, 0.01 10-15, 0.1 15-20, but that makes sense, as each >>>must share bandwidth with the others. >>> >> >>Yes, I get that too, and that makes perfect sense. The important thing >>is that they share the load equally. My results show that all timings >>are consistent for all clients (seem to be sharing the load equally). >>Good news! > > > I agree - Very good news! :-) > Yeah! Have a beer in celebration (hey any chance to celebrate eh?). Dave -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
From: David W. <wo...@pl...> - 2002-10-27 20:47:16
|
> Perhaps we should have each fork also output its relative position to > the others (via a counter), or perhaps its token or something - just so > we can identify trends (if there are any) relating to order of > connection etc. Good idea, I just went ahead and added that. Dave ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
From: Nathan Y. <na...@yo...> - 2002-10-27 16:13:07
|
> Yeah, I think the gettimeofday routine is working fine for what > we want (wall clock time). I can't imagine how CPU time will be of > interest to us. Ditto > Yes, I believe that 9729 ~ 9.5K. However, there are 21 clients that > are sharing the same "pipe" so that is actually 9.5K * 21 bytes/sec, or > about 200K/sec. Now, this is assuming that they all start and end at > the same time which is not exactly true, but hopefully close. Do you > agree with that logic? I agree with the logic, but over a local bus on the same machine we should see a much bigger pipe that 200k/sec... Could have something to do with how we recieve the messages too (byte by byte vs a whole buffer at a time), but I would think we could get MUCH higher. Perhaps its time we ran the server on shemp and beat against it with a few clients to see what kind of responses we get? > > I also get different sec/message rates depending on the # of clients. ~ > > 0.001 with < 10, 0.01 10-15, 0.1 15-20, but that makes sense, as each > > must share bandwidth with the others. > > > > Yes, I get that too, and that makes perfect sense. The important thing > is that they share the load equally. My results show that all timings > are consistent for all clients (seem to be sharing the load equally). > Good news! I agree - Very good news! :-) Nate |
From: Nathan Y. <na...@yo...> - 2002-10-27 16:10:23
|
> Whoops, I should have seen this earlier. Of course this list > is not in order of the clients as they are forked, it is in the > order of clients as they finish! So you should always see better > timings for the first ones! :) Doh! Good catch... sometimes its the simple things ;-) Perhaps we should have each fork also output its relative position to the others (via a counter), or perhaps its token or something - just so we can identify trends (if there are any) relating to order of connection etc. Nate |
From: David W. <wo...@pl...> - 2002-10-26 23:00:58
|
>> >> Forking 21 clients. >> 0.101624 sec/message, 9729.83 bytes/sec >> 0.107163 sec/message, 9226.97 bytes/sec >> 0.113180 sec/message, 8736.43 bytes/sec >> 0.112972 sec/message, 8752.53 bytes/sec >> 0.121449 sec/message, 8141.61 bytes/sec >> 0.123179 sec/message, 8027.26 bytes/sec >> ... Whoops, I should have seen this earlier. Of course this list is not in order of the clients as they are forked, it is in the order of clients as they finish! So you should always see better timings for the first ones! :) -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
From: David W. <wo...@pl...> - 2002-10-26 22:57:32
|
Nathan Yocom wrote: > Ahhh - much cleaner - I was wondering about that still ;-) I did a bit > of looking, but you beat me too it.. there is also a clock_t and clock() > function that do the same thing (no more/less accurate) with clock > ticks, thereby allowing us to measure CPU time vs wall clock time, but i > think we are really only interested in wallclock. > Yeah, I think the gettimeofday routine is working fine for what we want (wall clock time). I can't imagine how CPU time will be of interest to us. > Interesting to note, my speeds seem to show that the first clients > connected get slightly higher average transfers: > > > Forking 21 clients. > 0.101624 sec/message, 9729.83 bytes/sec > 0.107163 sec/message, 9226.97 bytes/sec > 0.113180 sec/message, 8736.43 bytes/sec > 0.112972 sec/message, 8752.53 bytes/sec > 0.121449 sec/message, 8141.61 bytes/sec > 0.123179 sec/message, 8027.26 bytes/sec > ... Hmmm... Do you find these numbers to be repeatable? I'd guess that that small of a difference is probably "within the noise." The good thing is that all clients seem to be getting about the same response rates (within 2%). > etc.. However, does 9729.83 bytes/sec = ~9.7K/sec? I am not up to > speed on my K/k/B/b etc notation/math. Is this a good speed? it seems > respectable on a per message (less than a second) basis.. but overall? > Yes, I believe that 9729 ~ 9.5K. However, there are 21 clients that are sharing the same "pipe" so that is actually 9.5K * 21 bytes/sec, or about 200K/sec. Now, this is assuming that they all start and end at the same time which is not exactly true, but hopefully close. Do you agree with that logic? > I also get different sec/message rates depending on the # of clients. ~ > 0.001 with < 10, 0.01 10-15, 0.1 15-20, but that makes sense, as each > must share bandwidth with the others. > Yes, I get that too, and that makes perfect sense. The important thing is that they share the load equally. My results show that all timings are consistent for all clients (seem to be sharing the load equally). Good news! Dave ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
From: Nathan Y. <na...@yo...> - 2002-10-26 22:34:22
|
Ahhh - much cleaner - I was wondering about that still ;-) I did a bit of looking, but you beat me too it.. there is also a clock_t and clock() function that do the same thing (no more/less accurate) with clock ticks, thereby allowing us to measure CPU time vs wall clock time, but i think we are really only interested in wallclock. Interesting to note, my speeds seem to show that the first clients connected get slightly higher average transfers: Forking 21 clients. 0.101624 sec/message, 9729.83 bytes/sec 0.107163 sec/message, 9226.97 bytes/sec 0.113180 sec/message, 8736.43 bytes/sec 0.112972 sec/message, 8752.53 bytes/sec 0.121449 sec/message, 8141.61 bytes/sec 0.123179 sec/message, 8027.26 bytes/sec ... etc.. However, does 9729.83 bytes/sec = ~9.7K/sec? I am not up to speed on my K/k/B/b etc notation/math. Is this a good speed? it seems respectable on a per message (less than a second) basis.. but overall? I also get different sec/message rates depending on the # of clients. ~ 0.001 with < 10, 0.01 10-15, 0.1 15-20, but that makes sense, as each must share bandwidth with the others. Nate Nate On Sat, 2002-10-26 at 13:23, David Wolff wrote: > > It turns out that I was using gettimeofday incorrectly. I've > fixed that and now the results look much more reasonable. Take > a look. > > Dave > > > -- > ---------------------------------------------------------------- > I encourage correspondence using GnuPG/OpenPGP encryption. > My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ApacheCon, November 18-21 in > Las Vegas (supported by COMDEX), the only Apache event to be > fully supported by the ASF. http://www.apachecon.com > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel > |
From: David W. <wo...@pl...> - 2002-10-26 20:23:41
|
It turns out that I was using gettimeofday incorrectly. I've fixed that and now the results look much more reasonable. Take a look. Dave -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
From: <na...@yo...> - 2002-10-25 05:49:58
|
Well, I don't know about changes in 2.5 (3.0??) but, thought you guys would find this interesting: http://www.kerneli.org/index.php Looks like we are still stuck doin stuff through a user-level program - probably not a huge deal though... Nate |
From: Nathan Y. <na...@yo...> - 2002-10-24 03:41:39
|
"mental" note for future - found an example of getting password in pam: /* Get the password */ retval = pam_get_item(pamh, PAM_AUTHTOK, (const void **)&password); if (retval != PAM_SUCCESS) { _pam_log(LOG_ERR, "Could not retrive user's password"); return -2; } where password is defined as: const char *password; |
From: Nathan Y. <na...@yo...> - 2002-10-24 01:23:15
|
Sounds fine to me. cya then On Wed, 2002-10-23 at 17:49, David Wolff wrote: > > Sorry folks, I said 12:30 without thinking. I have a meeting > with some students at 1:00. So can we instead have an early > lunch, say 11:30? > > > > > Bryce Bockman wrote: > > Zound good to me. > > > > Bryce > > David Wolff wrote: > > > >> > >> How about we get together for lunch, say 12:30 PM at > >> From the Bayou? We'll make sure to get a booth so we can > >> have table space. > >> > >> Dave > >> > >> > >> Nathan Yocom wrote: > >> > >>> Then the only question is what time? > >> > >> > >> > >> > > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: Influence the future of Java(TM) > > technology. Join the Java Community Process(SM) (JCP(SM)) program now. > > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > > > > _______________________________________________ > > securenfs-devel mailing list > > sec...@li... > > https://lists.sourceforge.net/lists/listinfo/securenfs-devel > > > > -- > ---------------------------------------------------------------- > I encourage correspondence using GnuPG/OpenPGP encryption. > My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel > |
From: Bryce B. <boc...@pl...> - 2002-10-24 00:54:32
|
Sure. --Bryce David Wolff wrote: > > Sorry folks, I said 12:30 without thinking. I have a meeting > with some students at 1:00. So can we instead have an early > lunch, say 11:30? > > > > > Bryce Bockman wrote: > >> Zound good to me. >> >> Bryce >> David Wolff wrote: >> >>> >>> How about we get together for lunch, say 12:30 PM at >>> From the Bayou? We'll make sure to get a booth so we can >>> have table space. >>> >>> Dave >>> >>> >>> Nathan Yocom wrote: >>> >>>> Then the only question is what time? >>> >>> >>> >>> >>> >> >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: Influence the future of Java(TM) >> technology. Join the Java Community Process(SM) (JCP(SM)) program >> now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en >> >> _______________________________________________ >> securenfs-devel mailing list >> sec...@li... >> https://lists.sourceforge.net/lists/listinfo/securenfs-devel > > > > |
From: David W. <wo...@pl...> - 2002-10-24 00:49:42
|
Sorry folks, I said 12:30 without thinking. I have a meeting with some students at 1:00. So can we instead have an early lunch, say 11:30? Bryce Bockman wrote: > Zound good to me. > > Bryce > David Wolff wrote: > >> >> How about we get together for lunch, say 12:30 PM at >> From the Bayou? We'll make sure to get a booth so we can >> have table space. >> >> Dave >> >> >> Nathan Yocom wrote: >> >>> Then the only question is what time? >> >> >> >> > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future of Java(TM) > technology. Join the Java Community Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
From: Bryce B. <boc...@pl...> - 2002-10-23 23:55:23
|
Zound good to me. Bryce David Wolff wrote: > > How about we get together for lunch, say 12:30 PM at > From the Bayou? We'll make sure to get a booth so we can > have table space. > > Dave > > > Nathan Yocom wrote: > >> Then the only question is what time? > > > |
From: Nathan Y. <na...@yo...> - 2002-10-23 21:46:50
|
Sounds like a plan... mmmm - jalapeno bread... On Wed, 2002-10-23 at 14:09, David Wolff wrote: > > How about we get together for lunch, say 12:30 PM at > From the Bayou? We'll make sure to get a booth so we can > have table space. > > Dave > > > Nathan Yocom wrote: > > Then the only question is what time? > > > > > -- > ---------------------------------------------------------------- > I encourage correspondence using GnuPG/OpenPGP encryption. > My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel > |
From: David W. <wo...@pl...> - 2002-10-23 21:09:38
|
How about we get together for lunch, say 12:30 PM at From the Bayou? We'll make sure to get a booth so we can have table space. Dave Nathan Yocom wrote: > Then the only question is what time? > -- ---------------------------------------------------------------- I encourage correspondence using GnuPG/OpenPGP encryption. My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt |
From: Nathan Y. <na...@yo...> - 2002-10-23 07:00:36
|
Then the only question is what time? On Tue, 2002-10-22 at 23:58, Bryce Bockman wrote: > Thursday should be good for me. > > B > > Nathan Yocom wrote: > > >Oh yeah... I keep forgettin. > > > >Cool! That gives me all day thursday AND friday to code! :-) > > > >Bryce? > > > >On Tue, 2002-10-22 at 23:36, wolffda wrote: > > > >>Thursday works well for me this week because no > >>classes on Friday! > >> > >>Dave > >> > >> > >> > >>>===== Original Message From Nathan Yocom <na...@yo...> ==== > >>> > >>= > >> > >>>Can we? I think we should discuss statistic and information to be > >>>gathered in our thread-test module, and design those tests. > >>> > >>>Anytime is good for me... You guys? > >>> > >>> > >>> > >>> > >>> > >>>------------------------------------------------------- > >>>This sf.net emial is sponsored by: Influence the future > >>>of Java(TM) technology. Join the Java Community > >>>Process(SM) (JCP(SM)) program now. > >>>http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/ > >>> > >>javavote > >> > >>>_______________________________________________ > >>>securenfs-devel mailing list > >>>sec...@li... > >>>https://lists.sourceforge.net/lists/listinfo/securenfs-devel > >>> > >> > >> > >>------------------------------------------------------- > >>This sf.net emial is sponsored by: Influence the future > >>of Java(TM) technology. Join the Java Community > >>Process(SM) (JCP(SM)) program now. > >>http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > >>_______________________________________________ > >>securenfs-devel mailing list > >>sec...@li... > >>https://lists.sourceforge.net/lists/listinfo/securenfs-devel > >> > > > > > > > > > >------------------------------------------------------- > >This sf.net emial is sponsored by: Influence the future > >of Java(TM) technology. Join the Java Community > >Process(SM) (JCP(SM)) program now. > >http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > >_______________________________________________ > >securenfs-devel mailing list > >sec...@li... > >https://lists.sourceforge.net/lists/listinfo/securenfs-devel > > > > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel > |
From: Bryce B. <boc...@pl...> - 2002-10-23 06:58:05
|
Thursday should be good for me. B Nathan Yocom wrote: >Oh yeah... I keep forgettin. > >Cool! That gives me all day thursday AND friday to code! :-) > >Bryce? > >On Tue, 2002-10-22 at 23:36, wolffda wrote: > >>Thursday works well for me this week because no >>classes on Friday! >> >>Dave >> >> >> >>>===== Original Message From Nathan Yocom <na...@yo...> ==== >>> >>= >> >>>Can we? I think we should discuss statistic and information to be >>>gathered in our thread-test module, and design those tests. >>> >>>Anytime is good for me... You guys? >>> >>> >>> >>> >>> >>>------------------------------------------------------- >>>This sf.net emial is sponsored by: Influence the future >>>of Java(TM) technology. Join the Java Community >>>Process(SM) (JCP(SM)) program now. >>>http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/ >>> >>javavote >> >>>_______________________________________________ >>>securenfs-devel mailing list >>>sec...@li... >>>https://lists.sourceforge.net/lists/listinfo/securenfs-devel >>> >> >> >>------------------------------------------------------- >>This sf.net emial is sponsored by: Influence the future >>of Java(TM) technology. Join the Java Community >>Process(SM) (JCP(SM)) program now. >>http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en >>_______________________________________________ >>securenfs-devel mailing list >>sec...@li... >>https://lists.sourceforge.net/lists/listinfo/securenfs-devel >> > > > > >------------------------------------------------------- >This sf.net emial is sponsored by: Influence the future >of Java(TM) technology. Join the Java Community >Process(SM) (JCP(SM)) program now. >http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en >_______________________________________________ >securenfs-devel mailing list >sec...@li... >https://lists.sourceforge.net/lists/listinfo/securenfs-devel > |
From: Nathan Y. <na...@yo...> - 2002-10-23 06:43:46
|
Oh yeah... I keep forgettin. Cool! That gives me all day thursday AND friday to code! :-) Bryce? On Tue, 2002-10-22 at 23:36, wolffda wrote: > Thursday works well for me this week because no > classes on Friday! > > Dave > > > > >===== Original Message From Nathan Yocom <na...@yo...> ==== > = > >Can we? I think we should discuss statistic and information to be > >gathered in our thread-test module, and design those tests. > > > >Anytime is good for me... You guys? > > > > > > > > > > > >------------------------------------------------------- > >This sf.net emial is sponsored by: Influence the future > >of Java(TM) technology. Join the Java Community > >Process(SM) (JCP(SM)) program now. > >http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/ > javavote > >_______________________________________________ > >securenfs-devel mailing list > >sec...@li... > >https://lists.sourceforge.net/lists/listinfo/securenfs-devel > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel > |
From: wolffda <wo...@pl...> - 2002-10-23 06:36:25
|
Thursday works well for me this week because no classes on Friday! Dave >===== Original Message From Nathan Yocom <na...@yo...> ==== = >Can we? I think we should discuss statistic and information to be >gathered in our thread-test module, and design those tests. > >Anytime is good for me... You guys? > > > > > >------------------------------------------------------- >This sf.net emial is sponsored by: Influence the future >of Java(TM) technology. Join the Java Community >Process(SM) (JCP(SM)) program now. >http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/ javavote >_______________________________________________ >securenfs-devel mailing list >sec...@li... >https://lists.sourceforge.net/lists/listinfo/securenfs-devel |
From: Nathan Y. <na...@yo...> - 2002-10-23 04:05:35
|
Can we? I think we should discuss statistic and information to be gathered in our thread-test module, and design those tests. Anytime is good for me... You guys? |
From: Nathan Y. <na...@yo...> - 2002-10-12 20:16:45
|
Compiles without any warnings or errors ;-) Thanks Dave! Nate On Sat, 2002-10-12 at 13:03, David Wolff wrote: > > I just committed a version of snfsd that compiles for me. Nate, > check to make sure that this compiles in gcc 3.1. > > Just for future reference, make sure all .h files have multiple > inclusion checks, for example for file foo.h: > > #ifndef FOO_H > #define FOO_H > > ... all of the header file goes here ... > > #endif > > This avoids multiple inclusions of a single header file. > > Dave > > > -- > ---------------------------------------------------------------- > I encourage correspondence using GnuPG/OpenPGP encryption. > My public key: http://www.cs.plu.edu/~dwolff/pgpkey.txt > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > securenfs-devel mailing list > sec...@li... > https://lists.sourceforge.net/lists/listinfo/securenfs-devel > |
From: Nathan Y. <na...@yo...> - 2002-10-12 20:15:00
|
There is now a private forum called "Developers" on sourceforge - its not the prettiest thing, but it is functional and should work for us. You have to be logged into sourceforge, goto the project page, then click on Forums in the line of options along the top (Summary, Files, ...Forums, etc) - the link toward the bottom is Public forums only. Nate |