From list2rado at gmx.de Sat Feb 2 10:51:50 2008 From: list2rado at gmx.de (Rado S) Date: Sat, 2 Feb 2008 17:51:50 +0100 Subject: [netrek-dev] metaserver on orion.netrek.org not responding Message-ID: <20080202165150.GD21654@sun36.math.uni-hamburg.de> Moin moin, telnet metaserver.netrek.org 3521 Trying 65.193.17.240... telnet: connect to address 65.193.17.240: Connection refused Trying 199.233.98.170... Connected to metaserver.netrek.org. Escape character is '^]'. The failover metaservers are up, but maybe somebody cares for orion to get back anyway. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From carlos at jpl.nasa.gov Sat Feb 2 13:23:53 2008 From: carlos at jpl.nasa.gov (Carlos Y. Villalpando) Date: Sat, 02 Feb 2008 11:23:53 -0800 Subject: [netrek-dev] metaserver on orion.netrek.org not responding In-Reply-To: <20080202165150.GD21654@sun36.math.uni-hamburg.de> References: <20080202165150.GD21654@sun36.math.uni-hamburg.de> Message-ID: <20080202112353.onmtdsb28004gs0k@webmail.jpl.nasa.gov> Quoting Rado S : > > The failover metaservers are up, but maybe somebody cares for orion > to get back anyway. Apparently orion has been rebooted a couple of times this week, and again this morning. I have a cron job that checks to see if the metaserver is still alive, and restarts it if it doesn't, but somebody edited my crontab from running it every 5 minutes to only running it at the top of the hour. It started up again within 9 minutes of your original message. --Carlos V. From quozl at us.netrek.org Tue Feb 5 17:52:04 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 6 Feb 2008 10:52:04 +1100 Subject: [netrek-dev] Bad Vibes, Expired Linux Client Message-ID: <20080205235204.GC8295@us.netrek.org> G'day, We have a community perception issue. We've been slashdotted, and I note the following comment from a contributor: "So, just to see if anyone's still playing Netrek today, I immediately followed the link in the FA, went to netrek.org, and downloaded what their webpage had as the latest Linux client. Attempting to run it, I got "sorry, but this client has expired; you need to download a current one from ftp.netrek.org." I guess that's a clue as to the vitality of the community . . . ." I'd like the following to happen: 1. remove the expired client from the web site, 2. in future script the web site to not provide an expired client if the date is nearing or exceeding the expiry date, 3. no longer set expiry dates in clients, 4. release a client without an expiry date for Linux. Reference: http://yro.slashdot.org/article.pl?sid=08/02/05/1425252 -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From netrek at gmail.com Tue Feb 5 21:53:48 2008 From: netrek at gmail.com (Zach) Date: Tue, 5 Feb 2008 22:53:48 -0500 Subject: [netrek-dev] Bad Vibes, Expired Linux Client In-Reply-To: <20080205235204.GC8295@us.netrek.org> References: <20080205235204.GC8295@us.netrek.org> Message-ID: Yes that is a negative pereption. There is still the Paradise 2.99 Final binary for Linux which doesn't expire. Karth's 2.5 release of BRMH does have an expiration date IIRC. Perhaps Trent could be convinced now to finally open source his client - assuming one can get a hold of him somehow. ;-) I emailed him a month or so about the p2k expiration and got no reply, no bounced mail either so who knows. Zach On Feb 5, 2008 6:52 PM, James Cameron wrote: > G'day, > > We have a community perception issue. > > We've been slashdotted, and I note the following comment from a > contributor: > > "So, just to see if anyone's still playing Netrek today, I immediately > followed the link in the FA, went to netrek.org, and downloaded what > their webpage had as the latest Linux client. Attempting to run it, I > got "sorry, but this client has expired; you need to download a current > one from ftp.netrek.org." I guess that's a clue as to the vitality of > the community . . . ." > > I'd like the following to happen: > > 1. remove the expired client from the web site, > > 2. in future script the web site to not provide an expired client if > the date is nearing or exceeding the expiry date, > > 3. no longer set expiry dates in clients, > > 4. release a client without an expiry date for Linux. > > Reference: > > http://yro.slashdot.org/article.pl?sid=08/02/05/1425252 > > -- > James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From akb+lists.netrek-dev at mirror.to Wed Feb 6 15:00:05 2008 From: akb+lists.netrek-dev at mirror.to (Andrew K. Bressen) Date: Wed, 06 Feb 2008 16:00:05 -0500 Subject: [netrek-dev] Bad Vibes, Expired Linux Client In-Reply-To: (Zach's message of "Tue, 5 Feb 2008 22:53:48 -0500") References: <20080205235204.GC8295@us.netrek.org> Message-ID: <0qbq6tztpm.fsf@lanconius.mirror.to> Zach writes: > Yes that is a negative pereption. There is still the Paradise 2.99 > Final binary for Linux which doesn't expire. Karth's 2.5 release of The dynamic linked version of it still works! The static doesn't. It's packaged as just a raw binary; no .rc file, but shouldn't really need one to play with default keymap, options, etc. Shall we put it up on the sidebar and downloads pages? --akb From akb+lists.netrek-dev at mirror.to Wed Feb 6 15:01:12 2008 From: akb+lists.netrek-dev at mirror.to (Andrew K. Bressen) Date: Wed, 06 Feb 2008 16:01:12 -0500 Subject: [netrek-dev] Bad Vibes, Expired Linux Client In-Reply-To: <20080205235204.GC8295@us.netrek.org> (James Cameron's message of "Wed, 6 Feb 2008 10:52:04 +1100") References: <20080205235204.GC8295@us.netrek.org> Message-ID: <0qabmdztnr.fsf@lanconius.mirror.to> Sorry I didn't check mail yesterday, guys. (Dave and Joe, remember ya can always phone me if we get slashdotted!) Thanks to Joe for handling the site updates! Paradise 2000 has been taken off of the sidebar and basic clients download page, remains on the full clients page for archival purposes. It is still useable with authentication turned off. > 2. in future script the web site to not provide an expired client if > the date is nearing or exceeding the expiry date, > > 3. no longer set expiry dates in clients, I think 3 would take care of 2. I think P2K was the only client set to expire, so I think 3 is largely addressed. > 4. release a client without an expiry date for Linux. I've been asking for this for a while... as Zach noted, the Paradise 2.99 dynamic build for Linux still plays; I hadn't know that, or I would have had it listed more prominently. --akb From akb+lists.netrek-dev at mirror.to Wed Feb 6 18:27:35 2008 From: akb+lists.netrek-dev at mirror.to (Andrew K. Bressen) Date: Wed, 06 Feb 2008 19:27:35 -0500 Subject: [netrek-dev] Bad Vibes, Expired Linux Client In-Reply-To: <0qabmdztnr.fsf@lanconius.mirror.to> (Andrew K. Bressen's message of "Wed, 06 Feb 2008 16:01:12 -0500") References: <20080205235204.GC8295@us.netrek.org> <0qabmdztnr.fsf@lanconius.mirror.to> Message-ID: <0qejbpy5jc.fsf@lanconius.mirror.to> I've created a new rc file and tarball for linux Paradise 2.99 nd put sidebar and download page links in. If people with linux systems could test this out, it'd be good; it seems to work on my box... I'll try to check back here tonight for replies... --akb From netrek at gmail.com Mon Feb 11 18:02:20 2008 From: netrek at gmail.com (Zach) Date: Mon, 11 Feb 2008 19:02:20 -0500 Subject: [netrek-dev] players - no responses Message-ID: I've noticed with some netrek players you can't get certain information such as when you send @ to their slot it does not return a hostmask or ip, it just gives a blank line, the other case is when pinging someone (!) it will say that it could not ping them. I am curious exactly what is occuring on the player's end to cause these 2 behaviors? If they had a firewall it must be allowing UDP through. Zach From jrd at gerdesas.com Mon Feb 11 18:14:17 2008 From: jrd at gerdesas.com (John R. Dennison) Date: Mon, 11 Feb 2008 18:14:17 -0600 Subject: [netrek-dev] players - no responses In-Reply-To: References: Message-ID: <20080212001417.GA4992@mail.beanhq.com> On Mon, Feb 11, 2008 at 07:02:20PM -0500, Zach wrote: > I've noticed with some netrek players you can't get certain > information such as when you send @ to their slot it does not return a > hostmask or ip, it just gives a blank line, the other case is when > pinging someone (!) it will say that it could not ping them. > > I am curious exactly what is occuring on the player's end to cause > these 2 behaviors? If they had a firewall it must be allowing UDP > through. These are client side issues. The clients in question (older paradise clients I believe, mactrek, possibly others) do not respond to the inquiry commands you are sending them. John -- "I'm sorry but our engineers do not have phones." As stated by a Network Solutions Customer Service representative when asked to be put through to an engineer. "My other computer is your windows box." Ralf Hildebrandt trying to play sturgeon while it's under attack is apparently not fun. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080211/37a72ab5/attachment.pgp From quozl at us.netrek.org Mon Feb 11 18:14:40 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 12 Feb 2008 11:14:40 +1100 Subject: [netrek-dev] players - no responses In-Reply-To: References: Message-ID: <20080212001440.GK5390@us.netrek.org> These responses are generated by ntserv for the player, not by their client, so you can exclude what is happening on the player's end. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From netrek at gmail.com Mon Feb 11 18:27:58 2008 From: netrek at gmail.com (Zach) Date: Mon, 11 Feb 2008 19:27:58 -0500 Subject: [netrek-dev] players - no responses In-Reply-To: <20080212001440.GK5390@us.netrek.org> References: <20080212001440.GK5390@us.netrek.org> Message-ID: Ah ok but I'm still curious exactly what is happening on their end to cause ntserv to generate these 2 cases. I want to see if I can reproduce the behaviour. Zach On Feb 11, 2008 7:14 PM, James Cameron wrote: > These responses are generated by ntserv for the player, not by their > client, so you can exclude what is happening on the player's end. > > -- > James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From netrek at gmail.com Mon Feb 11 18:33:00 2008 From: netrek at gmail.com (Zach) Date: Mon, 11 Feb 2008 19:33:00 -0500 Subject: [netrek-dev] players - no responses In-Reply-To: <20080212001417.GA4992@mail.beanhq.com> References: <20080212001417.GA4992@mail.beanhq.com> Message-ID: Oh, thanks. Zach On Feb 11, 2008 7:14 PM, John R. Dennison wrote: > These are client side issues. The clients in question (older > paradise clients I believe, mactrek, possibly others) do not > respond to the inquiry commands you are sending them. > From jrd at gerdesas.com Mon Feb 11 18:36:39 2008 From: jrd at gerdesas.com (John R. Dennison) Date: Mon, 11 Feb 2008 18:36:39 -0600 Subject: [netrek-dev] players - no responses In-Reply-To: <20080212001440.GK5390@us.netrek.org> References: <20080212001440.GK5390@us.netrek.org> Message-ID: <20080212003639.GB4992@mail.beanhq.com> On Tue, Feb 12, 2008 at 11:14:40AM +1100, James Cameron wrote: > These responses are generated by ntserv for the player, not by their > client, so you can exclude what is happening on the player's end. Hmm - then why does it only happen with a very specific subset of clients, including the 2 that I mentioned? Slots with older mactrek clients and older paradise clients don't reply. John -- "I'm sorry but our engineers do not have phones." As stated by a Network Solutions Customer Service representative when asked to be put through to an engineer. "My other computer is your windows box." Ralf Hildebrandt trying to play sturgeon while it's under attack is apparently not fun. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080211/b573bafd/attachment.pgp From quozl at us.netrek.org Mon Feb 11 19:11:47 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 12 Feb 2008 12:11:47 +1100 Subject: [netrek-dev] players - no responses In-Reply-To: <20080212003639.GB4992@mail.beanhq.com> References: <20080212001440.GK5390@us.netrek.org> <20080212003639.GB4992@mail.beanhq.com> Message-ID: <20080212011147.GN5390@us.netrek.org> On Mon, Feb 11, 2008 at 06:36:39PM -0600, John R. Dennison wrote: > Hmm - then why does it only happen with a very specific subset > of clients, including the 2 that I mentioned? Good question. Sounds like a mystery worth exploring. I'm a bit busy today responding to media enquiries though to do this. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From narcis at luky.nl Tue Feb 12 13:20:05 2008 From: narcis at luky.nl (Narcis) Date: Tue, 12 Feb 2008 20:20:05 +0100 Subject: [netrek-dev] responses In-Reply-To: References: Message-ID: > On Tue, Feb 12, 2008 at 11:14:40AM +1100, James Cameron wrote: >> These responses are generated by ntserv for the player, not by their >> client, so you can exclude what is happening on the player's end. > > Hmm - then why does it only happen with a very specific subset > of clients, including the 2 that I mentioned? > > Slots with older mactrek clients and older paradise clients > don't reply. indeed, i guess to find a description of these queries i would need to read the source code of ntserv? hog call (5 spaces) is supported, i was not aware of other requests. Anyone has a list handy? regards Chris From karthik at karthik.com Tue Feb 12 13:37:49 2008 From: karthik at karthik.com (Karthik Arumugham) Date: Tue, 12 Feb 2008 14:37:49 -0500 Subject: [netrek-dev] players - no responses In-Reply-To: References: Message-ID: On Feb 11, 2008, at 7:02 PM, Zach wrote: > I've noticed with some netrek players you can't get certain > information such as when you send @ to their slot it does not return a > hostmask or ip, it just gives a blank line, the other case is when > pinging someone (!) it will say that it could not ping them. > > I am curious exactly what is occuring on the player's end to cause > these 2 behaviors? If they had a firewall it must be allowing UDP > through. If you send someone @ or !, it should always return SOMETHING unless the player is busted. I am fairly certain that it will block if the player is dead as well, until they are back in the game. If you can replicate a case of either one not working on a non-busted ship that is in the game, please let me know. I have never seen these commands fail, except on a busted ship, and be delayed on a dead ship until re- entry. The "no ping stats available" output is caused by a client having ping stats disabled. (E.g. "dontPing: on" in your rc file, for BRMH at least.) By the way, MacTrek doesn't even support UDP, and it isn't required for ping stats. If you ping a MacTrek player, you will see -1%/-1% for the loss, which means TCP-only. From gfleming at buffalo.edu Tue Feb 12 13:57:11 2008 From: gfleming at buffalo.edu (Fleming, Gregory) Date: Tue, 12 Feb 2008 14:57:11 -0500 Subject: [netrek-dev] Any Help on getting a server running In-Reply-To: References: Message-ID: <9BBCCB11C6B66E409F8BC1B98A28CDA001428E@ubitmb-cc2.itorg.ad.buffalo.edu> I have the hardware, software, ip address, etc. I just need some docs on how to configure and install the server. Any help from yall is really appericated. Love the game! Newbie! Fizz From karthik at karthik.com Tue Feb 12 14:17:46 2008 From: karthik at karthik.com (Karthik Arumugham) Date: Tue, 12 Feb 2008 15:17:46 -0500 Subject: [netrek-dev] responses In-Reply-To: References: Message-ID: On Feb 12, 2008, at 2:20 PM, Narcis wrote: >> indeed, i guess to find a description of these queries i would need >> to > read the source code of ntserv? hog call (5 spaces) is supported, > i was not aware of other requests. Anyone has a list handy? Pig call (the 5 spaces, supported by most clients, notably not by BRMH) is confusing to me. There are two types. You can send it to yourself, and it tells you of "possible cyborgs". The second type is where you send 5 spaces to ALL, to a team, or to a specific slot, and everyone got your message and supports the pig call replies with a version string, as well as you being informed of "possible cyborgs". The "possible cyborgs" message is generated by the server as a list of slots with ST_CYBORG set. I'm confused about how this is set, as a quick glance at the code shows that it's either on RSA failure or on the host being in the bypass file. At the moment, I am neither (though I am in the whitelist directory), yet I show up as a possible cyborg. I'm assuming it's related to BRMH not supporting the pig call, but do not have time to investigate at the moment. Other messages you can send to slots: Ping/"!" requires the client have ping stats enabled to work properly, but the reply is generated by the server and is a "no ping stats" reply when the client has it off. Client/"#" requires the client have RSA enabled to work properly, but the reply is generated by the server is is an empty "Client: " reply when the client has it off. Stats/"?" is a server side-only command. Whois/"@" is a server side-only command. Sbstats/"^" is a server side-only command. From netrek at gmail.com Tue Feb 12 14:36:43 2008 From: netrek at gmail.com (Zach) Date: Tue, 12 Feb 2008 15:36:43 -0500 Subject: [netrek-dev] responses In-Reply-To: References: Message-ID: I recall it telling me I was a possible cyborg when I connected with my un-blessed version of COW. Zach On Feb 12, 2008 3:17 PM, Karthik Arumugham wrote: > On Feb 12, 2008, at 2:20 PM, Narcis wrote: > > >> indeed, i guess to find a description of these queries i would need > >> to > > read the source code of ntserv? hog call (5 spaces) is supported, > > i was not aware of other requests. Anyone has a list handy? > > Pig call (the 5 spaces, supported by most clients, notably not by > BRMH) is confusing to me. There are two types. You can send it to > yourself, and it tells you of "possible cyborgs". The second type is > where you send 5 spaces to ALL, to a team, or to a specific slot, and > everyone got your message and supports the pig call replies with a > version string, as well as you being informed of "possible cyborgs". > > The "possible cyborgs" message is generated by the server as a list of > slots with ST_CYBORG set. I'm confused about how this is set, as a > quick glance at the code shows that it's either on RSA failure or on > the host being in the bypass file. At the moment, I am neither (though > I am in the whitelist directory), yet I show up as a possible cyborg. > I'm assuming it's related to BRMH not supporting the pig call, but do > not have time to investigate at the moment. > > Other messages you can send to slots: > > Ping/"!" requires the client have ping stats enabled to work properly, > but the reply is generated by the server and is a "no ping stats" > reply when the client has it off. > Client/"#" requires the client have RSA enabled to work properly, but > the reply is generated by the server is is an empty "Client: " reply > when the client has it off. > Stats/"?" is a server side-only command. > Whois/"@" is a server side-only command. > Sbstats/"^" is a server side-only command. > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From quozl at us.netrek.org Tue Feb 12 16:42:26 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 13 Feb 2008 09:42:26 +1100 Subject: [netrek-dev] Any Help on getting a server running In-Reply-To: <9BBCCB11C6B66E409F8BC1B98A28CDA001428E@ubitmb-cc2.itorg.ad.buffalo.edu> References: <9BBCCB11C6B66E409F8BC1B98A28CDA001428E@ubitmb-cc2.itorg.ad.buffalo.edu> Message-ID: <20080212224226.GC7305@us.netrek.org> On Tue, Feb 12, 2008 at 02:57:11PM -0500, Fleming, Gregory wrote: > I have the hardware, software, ip address, etc. I just need some docs > on how to configure and install the server. Read INSTALL in the source. Let me know if it does not explain something, so we can fix it. On the other hand, we don't want it to explain something that some other document adequately explains. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From msucka0xff at programmer.net Tue Feb 12 18:38:37 2008 From: msucka0xff at programmer.net (. .) Date: Tue, 12 Feb 2008 16:38:37 -0800 Subject: [netrek-dev] client inclusion of supervisor key Message-ID: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> Folks, The "supervisor key" is an assigned key, e.g. 'F1' that previously would replace the game system screen with a dos command prompt, 'C:> ', and blinking cursor. If anything but 'exit' was typed into the terminal it would accept the input without error and present a further command prompt. Gamers would use the supervisor key to escape out of their current gaming system and AFAIK the supervisor key was implemented previously in dos based games like rogue, but never caught on to netrek. However I think that it would be useful to have such a feature in case the woman in charge passes by at an in opportune time. I would be availabe for testing this feature. Thanks, -bd -- Want an e-mail address like mine? Get a free e-mail account today at www.mail.com! From quozl at us.netrek.org Tue Feb 12 18:55:09 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 13 Feb 2008 11:55:09 +1100 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> Message-ID: <20080213005509.GI7305@us.netrek.org> There is software already for this, I don't see why Netrek need to anything. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From netrek at gmail.com Wed Feb 13 01:27:15 2008 From: netrek at gmail.com (Zach) Date: Wed, 13 Feb 2008 02:27:15 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> Message-ID: Most window managers allow you to bind a function such as "minimize window" to a key. So you could do something like that. Zach On Feb 12, 2008 7:38 PM, . . wrote: > Folks, > > The "supervisor key" is an assigned key, e.g. 'F1' that previously would replace the game system screen with a dos command prompt, 'C:> ', and blinking cursor. If anything but 'exit' was typed into the terminal it would accept the input without error and present a further command prompt. Gamers would use the supervisor key to escape out of their current gaming system and AFAIK the supervisor key was implemented previously in dos based games like rogue, but never caught on to netrek. However I think that it would be useful to have such a feature in case the woman in charge passes by at an in opportune time. I would be availabe for testing this feature. > > Thanks, > -bd > > -- > Want an e-mail address like mine? > Get a free e-mail account today at www.mail.com! > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From jrd at gerdesas.com Wed Feb 13 01:33:43 2008 From: jrd at gerdesas.com (John R. Dennison) Date: Wed, 13 Feb 2008 01:33:43 -0600 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> Message-ID: <20080213073343.GA7318@mail.beanhq.com> On Wed, Feb 13, 2008 at 02:27:15AM -0500, Zach wrote: > Most window managers allow you to bind a function such as "minimize > window" to a key. So you could do something like that. Even better. Don't game at work if your company has an anti-gaming policy. John -- "I'm sorry but our engineers do not have phones." As stated by a Network Solutions Customer Service representative when asked to be put through to an engineer. "My other computer is your windows box." Ralf Hildebrandt trying to play sturgeon while it's under attack is apparently not fun. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080213/8b474339/attachment-0001.pgp From mark at mark.mielke.cc Wed Feb 13 07:09:06 2008 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed, 13 Feb 2008 08:09:06 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <20080213073343.GA7318@mail.beanhq.com> References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> <20080213073343.GA7318@mail.beanhq.com> Message-ID: <47B2EBF2.1050009@mark.mielke.cc> John R. Dennison wrote: > On Wed, Feb 13, 2008 at 02:27:15AM -0500, Zach wrote: > >> Most window managers allow you to bind a function such as "minimize >> window" to a key. So you could do something like that. >> > > Even better. Don't game at work if your company has an > anti-gaming policy. > Haha - that's a huge part of Netrek history that you are speaking about influencing! :-) mark P.S. I somewhat fondly remembers the days when I was 13 or so, and I would visit my father's work to play Netrek on his Sun 4. It was a work-only Netrek server, and outsiders did not have firewall access in. It was busy non-stop throughout the day for at least a year before they finally restricted hours to 12pm-1pm and 4pm->8am. It was then VERY busy at those times, with a wait queue of 20+. Hahaha.... -- Mark Mielke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080213/2f3df837/attachment.htm From netrek at gmail.com Wed Feb 13 07:28:40 2008 From: netrek at gmail.com (Zach) Date: Wed, 13 Feb 2008 08:28:40 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <47B2EBF2.1050009@mark.mielke.cc> References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> <20080213073343.GA7318@mail.beanhq.com> <47B2EBF2.1050009@mark.mielke.cc> Message-ID: wow! i wonder how many private intranet netrek servers there are still active out there :) where did your father work btw? zach On Feb 13, 2008 8:09 AM, Mark Mielke wrote: > > John R. Dennison wrote: > On Wed, Feb 13, 2008 at 02:27:15AM -0500, Zach wrote: > > > Most window managers allow you to bind a function such as "minimize > window" to a key. So you could do something like that. > > Even better. Don't game at work if your company has an > anti-gaming policy. > > > Haha - that's a huge part of Netrek history that you are speaking about > influencing! :-) > > mark > > P.S. I somewhat fondly remembers the days when I was 13 or so, and I would > visit my father's work to play Netrek on his Sun 4. It was a work-only > Netrek server, and outsiders did not have firewall access in. It was busy > non-stop throughout the day for at least a year before they finally > restricted hours to 12pm-1pm and 4pm->8am. It was then VERY busy at those > times, with a wait queue of 20+. Hahaha.... > > -- > Mark Mielke > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > > From msucka0xff at programmer.net Wed Feb 13 12:14:39 2008 From: msucka0xff at programmer.net (. .) Date: Wed, 13 Feb 2008 10:14:39 -0800 Subject: [netrek-dev] client inclusion of supervisor key Message-ID: <20080213181439.4A22711581F@ws1-7.us4.outblaze.com> you've never got busted for playing games when you should have been working?? punishment is sometimes severe. which s/w does this already? ----- Original Message ----- From: "James Cameron" To: "Netrek Development Mailing List" Subject: Re: [netrek-dev] client inclusion of supervisor key Date: Wed, 13 Feb 2008 11:55:09 +1100 There is software already for this, I don't see why Netrek need to anything. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ _______________________________________________ netrek-dev mailing list netrek-dev at us.netrek.org http://mailman.us.netrek.org/mailman/listinfo/netrek-dev -- Want an e-mail address like mine? Get a free e-mail account today at www.mail.com! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080213/3a07c5c1/attachment.htm From jrd at gerdesas.com Wed Feb 13 12:19:11 2008 From: jrd at gerdesas.com (John R. Dennison) Date: Wed, 13 Feb 2008 12:19:11 -0600 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <20080213181439.4A22711581F@ws1-7.us4.outblaze.com> References: <20080213181439.4A22711581F@ws1-7.us4.outblaze.com> Message-ID: <20080213181911.GB7318@mail.beanhq.com> On Wed, Feb 13, 2008 at 10:14:39AM -0800, . . wrote: > you've never got busted for playing games when you should have been > working?? punishment is sometimes severe. which s/w does this already? No, I haven't. Policies are policies. I follow policies, whether I am setting said policies or not. They exist for a reason. John -- "I'm sorry but our engineers do not have phones." As stated by a Network Solutions Customer Service representative when asked to be put through to an engineer. "My other computer is your windows box." Ralf Hildebrandt trying to play sturgeon while it's under attack is apparently not fun. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080213/d9ff8e39/attachment.pgp From narcis at luky.nl Wed Feb 13 12:37:04 2008 From: narcis at luky.nl (Narcis) Date: Wed, 13 Feb 2008 19:37:04 +0100 Subject: [netrek-dev] netrek-dev Digest, Vol 36, Issue 8 In-Reply-To: References: Message-ID: <6CAA0F38-8DFD-486F-8B14-775D9F7BE932@luky.nl> >> >> > > Haha - that's a huge part of Netrek history that you are speaking > about > influencing! :-) > > mark > > P.S. I somewhat fondly remembers the days when I was 13 or so, and I > would visit my father's work to play Netrek on his Sun 4. It was a > work-only Netrek server, and outsiders did not have firewall access > in. > It was busy non-stop throughout the day for at least a year before > they > finally restricted hours to 12pm-1pm and 4pm->8am. It was then VERY > busy > at those times, with a wait queue of 20+. Hahaha.... > I remember the sysadmins bursting in my office when the backbone started to crumble under 40% load caused by my harmless series of clients that were running. I managed to convince them it was a load test that went out of control, i even came up with explanation of the word netrek in relation to network, tracking and something else :-) those were the days! regards C From mark at mark.mielke.cc Wed Feb 13 15:08:56 2008 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed, 13 Feb 2008 16:08:56 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <20080213181911.GB7318@mail.beanhq.com> References: <20080213181439.4A22711581F@ws1-7.us4.outblaze.com> <20080213181911.GB7318@mail.beanhq.com> Message-ID: <47B35C68.30803@mark.mielke.cc> John R. Dennison wrote: > On Wed, Feb 13, 2008 at 10:14:39AM -0800, . . wrote: > >> you've never got busted for playing games when you should have been >> working?? punishment is sometimes severe. which s/w does this already? >> > > No, I haven't. Policies are policies. I follow policies, > whether I am setting said policies or not. They exist for a > reason. > > Imagine - a company expecting their employees to work on the clock... :-) What is this world coming to??? I think one of the other posters though said significant other - not employer. My wife lets me play games or work late, so I don't need to hide. I know many, though, who are in unfair relationships to the other extreme where anything "computer related" or "game related" must be unimportant, but a spa treatment, reading a book, or shopping, is definately important. For such a person, I can totally see how the "if she doesn't know it won't hurt her" comes into play. :-) Cheers, mark -- Mark Mielke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080213/7cfdd18d/attachment.htm From mark at mark.mielke.cc Wed Feb 13 15:14:58 2008 From: mark at mark.mielke.cc (Mark Mielke) Date: Wed, 13 Feb 2008 16:14:58 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> <20080213073343.GA7318@mail.beanhq.com> <47B2EBF2.1050009@mark.mielke.cc> Message-ID: <47B35DD2.6030403@mark.mielke.cc> Zach wrote: > wow! i wonder how many private intranet netrek servers there are still > active out there :) > where did your father work btw? > It was around 1991 - 1992 @ Bell Northern Research now recognized as Nortel. It's not too popular any more - and once they figured it out, the server was locked down and eventually barred. I don't think there has been a server here in ~15 years. (After Netrek was shut down, I ended up getting a job and working here since :-) ) Cheers, mark -- Mark Mielke From netrek at gmail.com Wed Feb 13 16:51:55 2008 From: netrek at gmail.com (Zach) Date: Wed, 13 Feb 2008 17:51:55 -0500 Subject: [netrek-dev] netrek-dev Digest, Vol 36, Issue 8 In-Reply-To: <6CAA0F38-8DFD-486F-8B14-775D9F7BE932@luky.nl> References: <6CAA0F38-8DFD-486F-8B14-775D9F7BE932@luky.nl> Message-ID: haha sometimes the ccons would make us leave if students wanted to do actual work, imagine that! lol or if a class needed the room. but after say 11pm you could play without being bothered. zach On Feb 13, 2008 1:37 PM, Narcis wrote: > >> > >> > > > > Haha - that's a huge part of Netrek history that you are speaking > > about > > influencing! :-) > > > > mark > > > > P.S. I somewhat fondly remembers the days when I was 13 or so, and I > > would visit my father's work to play Netrek on his Sun 4. It was a > > work-only Netrek server, and outsiders did not have firewall access > > in. > > It was busy non-stop throughout the day for at least a year before > > they > > finally restricted hours to 12pm-1pm and 4pm->8am. It was then VERY > > busy > > at those times, with a wait queue of 20+. Hahaha.... > > > > I remember the sysadmins bursting in my office when the backbone > started to > crumble under 40% load caused by my harmless series of clients that > were running. > > I managed to convince them it was a load test that went out of > control, i even came > up with explanation of the word netrek in relation to network, > tracking and something else :-) > those were the days! > > regards > > C > > > _______________________________________________ > netrek-dev mailing list > netrek-dev at us.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/netrek-dev > From netrek at gmail.com Wed Feb 13 16:53:39 2008 From: netrek at gmail.com (Zach) Date: Wed, 13 Feb 2008 17:53:39 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <47B35DD2.6030403@mark.mielke.cc> References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> <20080213073343.GA7318@mail.beanhq.com> <47B2EBF2.1050009@mark.mielke.cc> <47B35DD2.6030403@mark.mielke.cc> Message-ID: On Feb 13, 2008 4:14 PM, Mark Mielke wrote: > > It was around 1991 - 1992 @ Bell Northern Research now recognized as Nortel. Ah. > It's not too popular any more - and once they figured it out, the server > was locked down and eventually barred. I don't think there has been a > server here in ~15 years. (After Netrek was shut down, I ended up > getting a job and working here since :-) ) Cool. What type of work you do? Zach From netrek at gmail.com Wed Feb 13 16:54:41 2008 From: netrek at gmail.com (Zach) Date: Wed, 13 Feb 2008 17:54:41 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <47B35C68.30803@mark.mielke.cc> References: <20080213181439.4A22711581F@ws1-7.us4.outblaze.com> <20080213181911.GB7318@mail.beanhq.com> <47B35C68.30803@mark.mielke.cc> Message-ID: On Feb 13, 2008 4:08 PM, Mark Mielke wrote: > >. > I know many, though, who are in unfair relationships to the other extreme > where anything "computer related" or "game related" must be unimportant, but > a spa treatment, reading a book, or shopping, is definately important. For > such a person, I can totally see how the "if she doesn't know it won't hurt > her" comes into play. :-) That is a shame, how unfair and selfish. Is netrek grounds for divorce? ;-) Zach From mark at mark.mielke.cc Thu Feb 14 12:03:35 2008 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 14 Feb 2008 13:03:35 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> <20080213073343.GA7318@mail.beanhq.com> <47B2EBF2.1050009@mark.mielke.cc> <47B35DD2.6030403@mark.mielke.cc> Message-ID: <47B48277.2040601@mark.mielke.cc> Zach wrote: > On Feb 13, 2008 4:14 PM, Mark Mielke wrote: > >> It's not too popular any more - and once they figured it out, the server >> was locked down and eventually barred. I don't think there has been a >> server here in ~15 years. (After Netrek was shut down, I ended up >> getting a job and working here since :-) ) >> > > Cool. What type of work you do? > Configuration management customization. I've been the software architect for a few of the products we use on top of things such as ClearCase. These products are supposed to work out of the box - but they really do not. Cheers, mark -- Mark Mielke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080214/bc328cac/attachment.htm From netrek at gmail.com Thu Feb 14 16:51:24 2008 From: netrek at gmail.com (Zach) Date: Thu, 14 Feb 2008 17:51:24 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <47B48277.2040601@mark.mielke.cc> References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> <20080213073343.GA7318@mail.beanhq.com> <47B2EBF2.1050009@mark.mielke.cc> <47B35DD2.6030403@mark.mielke.cc> <47B48277.2040601@mark.mielke.cc> Message-ID: On Thu, Feb 14, 2008 at 1:03 PM, Mark Mielke wrote: > > Configuration management customization. I've been the software architect > for a few of the products we use on top of things such as ClearCase. These > products are supposed to work out of the box - but they really do not. Heh. Neat work. Zach From karthik at karthik.com Thu Feb 14 19:19:35 2008 From: karthik at karthik.com (Karthik Arumugham) Date: Thu, 14 Feb 2008 20:19:35 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> <20080213073343.GA7318@mail.beanhq.com> <47B2EBF2.1050009@mark.mielke.cc> <47B35DD2.6030403@mark.mielke.cc> <47B48277.2040601@mark.mielke.cc> Message-ID: <87F4E9A7-4D63-4415-A37E-A38083034586@karthik.com> On Feb 14, 2008, at 5:51 PM, Zach wrote: > On Thu, Feb 14, 2008 at 1:03 PM, Mark Mielke > wrote: >> >> Configuration management customization. I've been the software >> architect >> for a few of the products we use on top of things such as >> ClearCase. These >> products are supposed to work out of the box - but they really do >> not. > > Heh. Neat work. Can you please keep your personal discussions off-list? This list is for Netrek-related things. Thank you. From mark at mark.mielke.cc Thu Feb 14 19:34:12 2008 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 14 Feb 2008 20:34:12 -0500 Subject: [netrek-dev] client inclusion of supervisor key In-Reply-To: <87F4E9A7-4D63-4415-A37E-A38083034586@karthik.com> References: <20080213003837.A056D1BF2A3@ws1-1.us4.outblaze.com> <20080213073343.GA7318@mail.beanhq.com> <47B2EBF2.1050009@mark.mielke.cc> <47B35DD2.6030403@mark.mielke.cc> <47B48277.2040601@mark.mielke.cc> <87F4E9A7-4D63-4415-A37E-A38083034586@karthik.com> Message-ID: <47B4EC14.3010704@mark.mielke.cc> Karthik Arumugham wrote: > Can you please keep your personal discussions off-list? This list is > for Netrek-related things. Thank you. > How about keeping your criticisms off list and honouring your own request? This list is dead. A little bit of life doesn't hurt. Or did something said offend you in some way? Cheers, mark -- Mark Mielke From list2rado at gmx.de Mon Feb 18 11:28:33 2008 From: list2rado at gmx.de (Rado S) Date: Mon, 18 Feb 2008 18:28:33 +0100 Subject: [netrek-dev] metaserver solicitation usage Message-ID: <20080218172833.GB15145@sun36.math.uni-hamburg.de> Moin moin everyone, finally I've got around to apply the solicitation patch, it works with Paradise now, too. However, before I commit it to the public, I want to see some issues addressed which Psychosis has brought up. I agree with him that polluting the metaservers is undesired. Polluting in the sense of weakly connected or maintained servers, or too many servers misconfigured (either for testing or intended to remain local). I learned from Psychosis that servers listed via solicitation remain persistent on the metas even after shutting down for good. That's ... bad. :( (the remains after my experiments are still there, even though I stopped the server to clean up, since it's not meant to be a permanent server at all) Can you please remove the current entries for "sun36" on all metas now once manually, please? Then, can the metas drop servers which haven't reconnected for some time period, like 1h? If so, please enable it. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Mon Feb 18 15:50:30 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 19 Feb 2008 08:50:30 +1100 Subject: [netrek-dev] metaserver solicitation usage In-Reply-To: <20080218172833.GB15145@sun36.math.uni-hamburg.de> References: <20080218172833.GB15145@sun36.math.uni-hamburg.de> Message-ID: <20080218215030.GA5640@us.netrek.org> On Mon, Feb 18, 2008 at 06:28:33PM +0100, Rado S wrote: > I agree with him that polluting the metaservers is undesired. Agreed. Please don't do it. It is also an attack vector, and fixes are welcome. Such as closing metaserver to new servers, only allowing solicitation from authorised servers. > I learned from Psychosis that servers listed via solicitation remain > persistent on the metas even after shutting down for good. > That's ... bad. :( They will drop off the list within a day or so, assuming that there is no server listening on the host. During that time clients won't be able to connect, and players should assume that the server is unavailable. If there is a client that is not handling this correctly and gracefully, please let us know so we can get it fixed. > Can you please remove the current entries for "sun36" on all metas > now once manually, please? I've restarted the one that I run. > Then, can the metas drop servers which haven't reconnected for some > time period, like 1h? The metaserver source is in a darcs repository: http://james.tooraweenah.com/darcs/netrek-metaserver/ -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From list2rado at gmx.de Tue Feb 19 13:08:38 2008 From: list2rado at gmx.de (Rado S) Date: Tue, 19 Feb 2008 20:08:38 +0100 Subject: [netrek-dev] metaserver solicitation usage In-Reply-To: <20080218215030.GA5640@us.netrek.org> References: <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> Message-ID: <20080219190838.GB29597@sun36.math.uni-hamburg.de> =- James Cameron wrote on Tue 19.Feb'08 at 8:50:30 +1100 -= > It is also an attack vector, and fixes are welcome. Such as > closing metaserver to new servers, only allowing solicitation from > authorised servers. Hum, but what advantage would solicitation have over the old workflow of signing up with the metaserver admins, if it required manual admission again? > > Can you please remove the current entries for "sun36" on all > > metas now once manually, please? > > I've restarted the one that I run. On 208.20.202.42 there is also hockey.tamu.edu down all the time I checked, but the timer for refresh gets reset after 30 ("down"). With solicitation, wouldn't it make more sense to drop those "down" noted servers and let them re-register once they're back up? > > I learned from Psychosis that servers listed via solicitation > > remain persistent on the metas even after shutting down for > > good. That's ... bad. :( > > They will drop off the list within a day or so, assuming that > there is no server listening on the host. That's what I assumed, too, based on the comment in the "howto"... but orion is still listing it even after a full day and more now. > > Then, can the metas drop servers which haven't reconnected for > > some time period, like 1h? > > The metaserver source is in a darcs repository: > http://james.tooraweenah.com/darcs/netrek-metaserver/ As far as I understand, it's already in there. So it must be something specific to orion. Maybe orion has different code or configuration besides: policy.c: if (sp->player_count == 0 && age > (60*60*6)) return 0; BTW, it reported "Nobody playing" while my server actually was completely out of business. Wouldn't "no connection" be more appropriate? Does the "Status" indicate host or server status? Is there a distinction possible between "host unreachable" and "server down"? -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Tue Feb 19 16:08:46 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 20 Feb 2008 09:08:46 +1100 Subject: [netrek-dev] metaserver solicitation usage In-Reply-To: <20080219190838.GB29597@sun36.math.uni-hamburg.de> References: <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> Message-ID: <20080219220846.GC5731@us.netrek.org> On Tue, Feb 19, 2008 at 08:08:38PM +0100, Rado S wrote: > Hum, but what advantage would solicitation have over the old > workflow of signing up with the metaserver admins, if it required > manual admission again? Lower age of information, and less packets for each update. > On 208.20.202.42 there is also hockey.tamu.edu down all the time I > checked, but the timer for refresh gets reset after 30 ("down"). hockey.tamu.edu is in the metarc file of 208.20.202.42 and so it is listed statically, not because of solicitation. > With solicitation, wouldn't it make more sense to drop those "down" > noted servers and let them re-register once they're back up? Yes. > As far as I understand, it's already in there. > So it must be something specific to orion. > Maybe orion has different code or configuration besides: > policy.c: if (sp->player_count == 0 && age > (60*60*6)) return 0; Yes, that seems likely. > BTW, it reported "Nobody playing" while my server actually was > completely out of business. Wouldn't "no connection" be more > appropriate? Yes. Would you be able to fix it? > Does the "Status" indicate host or server status? Yes. > Is there a distinction possible between "host unreachable" and > "server down"? I don't know, it has been a while since I worked in the metaserver code. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From billbalcerski at gmail.com Tue Feb 19 18:10:04 2008 From: billbalcerski at gmail.com (Bill Balcerski) Date: Tue, 19 Feb 2008 19:10:04 -0500 Subject: [netrek-dev] metaserver solicitation usage In-Reply-To: <20080219220846.GC5731@us.netrek.org> References: <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> Message-ID: <45ab86180802191610u43d04842ue771e5fd8b31a142@mail.gmail.com> On Feb 19, 2008 5:08 PM, James Cameron wrote: > On Tue, Feb 19, 2008 at 08:08:38PM +0100, Rado S wrote: > > Is there a distinction possible between "host unreachable" and > > "server down"? > > I don't know, it has been a while since I worked in the metaserver code. > I can't speak for how the metaserver sorts these cases, but on the client end (for the Windows clients) our users can parse their metaserver listing to only show server types they want. Relevant snippet from netrekrc.txt is as follows: # What servers to get from metaserver # 0 - with players # 1 - as above + with queue # 2 - as above + with nobody playing (default) # 3 - as above + timed out servers # 4 - as above + servers that metaserver could not connect to metaStatusLevel: 2 So by default, XP 2006 doesn't list servers that couldn't be connected to, or timed out servers. If at one point a server was able to be connected to, but on the next client session it is no longer available, the server will remain in the metacache for 5 metaserver connect attempts, then fall out of the cache. Bill Bill From list2rado at gmx.de Wed Feb 20 14:04:09 2008 From: list2rado at gmx.de (Rado S) Date: Wed, 20 Feb 2008 21:04:09 +0100 Subject: [netrek-dev] metaserver solicitation usage In-Reply-To: <20080219220846.GC5731@us.netrek.org> References: <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> Message-ID: <20080220200409.GB11852@sun36.math.uni-hamburg.de> =- James Cameron wrote on Wed 20.Feb'08 at 9:08:46 +1100 -= > > On 208.20.202.42 there is also hockey.tamu.edu down all the time I > > checked, but the timer for refresh gets reset after 30 ("down"). > > hockey.tamu.edu is in the metarc file of 208.20.202.42 and so it is > listed statically, not because of solicitation. > > > With solicitation, wouldn't it make more sense to drop those "down" > > noted servers and let them re-register once they're back up? > > Yes. Why do you still keep it (or any server) static then? Functionally I see no difference for a player between being listed as "unreachable" and not listed at all, while the former distracts more. > > Maybe orion has different code or configuration besides: > > policy.c: if (sp->player_count == 0 && age > (60*60*6)) return 0; > > Yes, that seems likely. I couldn't verify since I gave up after 1h and next day it was gone: was "sun36" removed from the other metaserver automatically? Knowing that they indeed get removed automatically would allow for testing without having to bother anyone to clean up manually. > > BTW, it reported "Nobody playing" while my server actually was > > completely out of business. Wouldn't "no connection" be more > > appropriate? > > Yes. Would you be able to fix it? If I knew where to start looking... maybe. Does the metaserver re-check on its own at all when solitications from a server stop? If that's the case, then judging from scan.c:796++ nuke_server(), my server wasn't considered soliciting, even though it was... strange. No idea why the "solicit" flag got lost for my server. Or does meta rely exclusively on the servers to send info on their own? In that case we'd need a timeout to actively probe a regularly soliciting server to notice status changes. > > Is there a distinction possible between "host unreachable" and > > "server down"? > > I don't know, it has been a while since I worked in the metaserver > code. Maybe somebody else then? -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From list2rado at gmx.de Wed Feb 20 14:11:07 2008 From: list2rado at gmx.de (Rado S) Date: Wed, 20 Feb 2008 21:11:07 +0100 Subject: [netrek-dev] metaserver solicitation usage In-Reply-To: <45ab86180802191610u43d04842ue771e5fd8b31a142@mail.gmail.com> References: <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <45ab86180802191610u43d04842ue771e5fd8b31a142@mail.gmail.com> Message-ID: <20080220201107.GC11852@sun36.math.uni-hamburg.de> =- Bill Balcerski wrote on Tue 19.Feb'08 at 19:10:04 -0500 -= > > > Is there a distinction possible between "host unreachable" and > > > "server down"? > > > > I don't know, it has been a while since I worked in the > > metaserver code. > > I can't speak for how the metaserver sorts these cases, ... well, now I can, after I had a closer look at the code (which I had unfortunately after I fired my previous reply to James). > but on the client end (for the Windows clients) our users can > parse their metaserver listing to only show server types they > want. Relevant snippet from netrekrc.txt is as follows: > > So by default, XP 2006 doesn't list servers that couldn't be > connected to, or timed out servers. Since the client only reacts to all possible given output, that would have answered my question if I hadn't looked myself in the meantime, thanks. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Wed Feb 20 16:27:08 2008 From: quozl at us.netrek.org (James Cameron) Date: Thu, 21 Feb 2008 09:27:08 +1100 Subject: [netrek-dev] metaserver solicitation usage In-Reply-To: <20080220201107.GC11852@sun36.math.uni-hamburg.de> <20080220200409.GB11852@sun36.math.uni-hamburg.de> References: <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <45ab86180802191610u43d04842ue771e5fd8b31a142@mail.gmail.com> <20080220201107.GC11852@sun36.math.uni-hamburg.de> <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> Message-ID: <20080220222708.GB4168@us.netrek.org> On Wed, Feb 20, 2008 at 09:04:09PM +0100, Rado S wrote: > Why do you still keep it (or any server) static then? The reasons for keeping a server static are: 1. solicitation may not be working, because it was not implemented, or because of network path problems, ... from memory that is why hockey.tamu.edu is on my metaserver, 2. solicitation may work fine, but by placing the server in the static list it is shown to clients as soon as the metaserver restarts, rather than waiting for players to join that server ... from memory that is why pickled.netrek.org and continuum.us.netrek.org are on my metaserver, 3. the metaserver has an undesired feature that prevents it from working unless there is at least one static server. > I couldn't verify since I gave up after 1h and next day it was gone: > was "sun36" removed from the other metaserver automatically? I don't know, however the metaserver that Carlos runs was restarted on 19th February. Did you check Karthik's metaserver too? > Does the metaserver re-check on its own at all when solitications > from a server stop? Indeed that is the question. I remember coding it so that it would, but I can't remember if it was removed. > Maybe somebody else then? Last burst of active development was by me in 2007-08, then before that in 2007-05. I've received no other contributions since. If anyone has any, please send me patches. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From list2rado at gmx.de Thu Feb 21 10:54:38 2008 From: list2rado at gmx.de (Rado S) Date: Thu, 21 Feb 2008 17:54:38 +0100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080220222708.GB4168@us.netrek.org> References: <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <45ab86180802191610u43d04842ue771e5fd8b31a142@mail.gmail.com> <20080220201107.GC11852@sun36.math.uni-hamburg.de> <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> Message-ID: <20080221165437.GF26653@sun36.math.uni-hamburg.de> =- James Cameron wrote on Thu 21.Feb'08 at 9:27:08 +1100 -= > On Wed, Feb 20, 2008 at 09:04:09PM +0100, Rado S wrote: > > Why do you still keep it (or any server) static then? > > 1. solicitation may not be working, because it was not > implemented, or because of network path problems, ... from memory > that is why hockey.tamu.edu is on my metaserver, - network path problems: well, again, what's the gain for anyone to see it listed as unreachable rather then not listed at all? Admins / regular players know what servers are supposed to exist from their experience when the server was OK. If it's missing, they know something is wrong. Casual players have no gain, only a zombie entry in their list. - not implemented: isn't the goal to have all servers work with solicitation? Anyone tried contacting the server's admin for a status update or perhaps to aid implementing solicitation? If it's dead for good, then it needs no "in memory of" note on the metas, put it on a history page. ;) > 2. solicitation may work fine, but by placing the server in the > static list it is shown to clients as soon as the metaserver > restarts, rather than waiting for players to join that server ... You mean "waiting for the server to report to the metas"? If yes, then it's just a matter of moments per server-cfg. If not, why is joining the server relevant for its solicitation? And how could they be joined before being listed on the metas? (chicken-egg problem, unless you assume people keep local lists and/or caches, but then this isn't an issue at all) > 3. the metaserver has an undesired feature that prevents it from > working unless there is at least one static server. This can't be overcome? Or it isn't wanted to be overcome? > > Does the metaserver re-check on its own at all when > > solitications from a server stop? > > Indeed that is the question. I remember coding it so that it > would, but I can't remember if it was removed. Ok, I think I found a place to jump in: scan.c:917 if (servers[i].next_update <= now && !servers[i].solicit) { Maybe it should be expanded like this: if (( !servers[i].solicit && servers[i].next_update <= now) || ( servers[i].solicit && (servers[i].last_update + SOLICIT_TIMEOUT) <= now)) { With some sane value for SOLICIT_TIMEOUT, maybe 1h? -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From list2rado at gmx.de Thu Feb 21 11:05:28 2008 From: list2rado at gmx.de (Rado S) Date: Thu, 21 Feb 2008 18:05:28 +0100 Subject: [netrek-dev] metaserver solicitation usage: filtering empty servers by time In-Reply-To: <20080220222708.GB4168@us.netrek.org> References: <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <45ab86180802191610u43d04842ue771e5fd8b31a142@mail.gmail.com> <20080220201107.GC11852@sun36.math.uni-hamburg.de> <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> Message-ID: <20080221170527.GG26653@sun36.math.uni-hamburg.de> =- James Cameron wrote on Thu 21.Feb'08 at 9:27:08 +1100 -= > > I couldn't verify since I gave up after 1h and next day it was > > gone: was "sun36" removed from the other metaserver > > automatically? > > I don't know, however the metaserver that Carlos runs was > restarted on 19th February. Did you check Karthik's metaserver > too? I checked all 3. Next day (before 24h limit) it was removed from yours and Karthik's, while it was on Carlos' for more than 1-2 days. That's why I assumed Carlos' had no auto-clean feature and the other 2 removed it manually. So I still don't know whether or when all metaservers remove unreachable servers automatically. Apropos, the policy, which I quoted last time not to show servers which are empty for 6h, why is this good? When a server is not shown, how could it ever change its status when nobody knows how to get there to fill it up? When is "last_udapte" updated? Can "age" ever become > 6h purposefully (unlike dead solicitation servers as in my broken case [soon to be fixed])? -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Thu Feb 21 16:10:38 2008 From: quozl at us.netrek.org (James Cameron) Date: Fri, 22 Feb 2008 09:10:38 +1100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080221170527.GG26653@sun36.math.uni-hamburg.de> <20080221165437.GF26653@sun36.math.uni-hamburg.de> References: <20080219220846.GC5731@us.netrek.org> <45ab86180802191610u43d04842ue771e5fd8b31a142@mail.gmail.com> <20080220201107.GC11852@sun36.math.uni-hamburg.de> <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> Message-ID: <20080221221038.GA4941@us.netrek.org> On Thu, Feb 21, 2008 at 05:54:38PM +0100, Rado S wrote: > - network path problems: well, again, what's the gain for anyone to > see it listed as unreachable rather then not listed at all? I suspect you misunderstand. I mean network path problems that prevent solicitation packets from the server to a metaserver, yet permit play. We have had such servers in the past, and we may yet again, which is why I mentioned it as a reason. > - not implemented: isn't the goal to have all servers work with > solicitation? Anyone tried contacting the server's admin for a > status update or perhaps to aid implementing solicitation? > If it's dead for good, then it needs no "in memory of" note on the > metas, put it on a history page. ;) Whether a server uses solicitation or not is up to the server admin. I don't think it is a "goal" as such. Yes, we have frequently contacted server admins to encourage them to use solicitation, but as it isn't a critical feature there's no reason to block them if they don't use it. > > 2. solicitation may work fine, but by placing the server in the > > static list it is shown to clients as soon as the metaserver > > restarts, rather than waiting for players to join that server ... > > You mean "waiting for the server to report to the metas"? > If yes, then it's just a matter of moments per server-cfg. No, that's not how it works. The server does not send any packet to the metaserver until it has players join. > And how could they be joined before being listed on the metas? > (chicken-egg problem, unless you assume people keep local lists > and/or caches, but then this isn't an issue at all) Exactly ... and that by the way is an argument for why a server that sends a solicitation should continue to be listed for some days, so that players will join it, thus generating further solicitation. > > 3. the metaserver has an undesired feature that prevents it from > > working unless there is at least one static server. > > This can't be overcome? > Or it isn't wanted to be overcome? This can be overcome. This has not yet been overcome. Nobody has fixed it yet. If you care enough to, please do so. I'm not aware of any plans to fix it. On Thu, Feb 21, 2008 at 06:05:28PM +0100, Rado S wrote: > Apropos, the policy, which I quoted last time not to show > servers which are empty for 6h, why is this good? > When a server is not shown, how could it ever change its status when > nobody knows how to get there to fill it up? > When is "last_udapte" updated? > Can "age" ever become > 6h purposefully (unlike dead solicitation > servers as in my broken case [soon to be fixed])? You raise important design points. What do you propose as the solution? To me the simplest extension is to add an identifying token to the solicitation packet, and permit the original server to delist itself when it shuts down. Another potential extension is for a server to send a solicitation every hour regardless of being empty, and code the metaserver to remove entries from list that exceed three hours age. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From jrd at gerdesas.com Thu Feb 21 21:59:19 2008 From: jrd at gerdesas.com (John R. Dennison) Date: Thu, 21 Feb 2008 21:59:19 -0600 Subject: [netrek-dev] [xyzzy@speakeasy.org: Re: [paradise-workers] Prepare servers for metaserver listing: clients work with all servers] Message-ID: <20080222035919.GI22493@mail.beanhq.com> Copied from the paradise-workers list as an FYI. John ----- Forwarded message from Trent Piepho ----- > Date: Thu, 21 Feb 2008 19:51:07 -0800 (PST) > From: Trent Piepho > To: Dave Ahn > Cc: paradise-workers at lists.netrek.org > Subject: Re: [paradise-workers] Prepare servers for metaserver listing: > clients work with all servers > > On Thu, 21 Feb 2008, Dave Ahn wrote: > > > On Thu, Feb 21, 2008 at 03:29:35PM -0800, Trent Piepho wrote: > > > Was added by me for paradise 2000. > > > > Do you plan to release an unexpired or non-expiring client? Your client > > was taken off netrek.org downloads page when RC6 expired, and you never > > returned my emails. > > I've been busy with a new job and haven't been following this stuff. I was > under the impression that blessed clients had to expire, in case they have > a borg feature. Maybe that's changed. > > I'll probably try to compile a new client soon. Every time I change to a > new glibc version compiling a static binary becomes a bigger pain in the > ass. > > _______________________________________________ > Paradise-Workers mailing list > Paradise-Workers at lists.netrek.org > http://mailman.us.netrek.org/mailman/listinfo/paradise-workers > ----- End forwarded message ----- -- "I'm sorry but our engineers do not have phones." As stated by a Network Solutions Customer Service representative when asked to be put through to an engineer. "My other computer is your windows box." Ralf Hildebrandt trying to play sturgeon while it's under attack is apparently not fun. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080221/8ee88cbc/attachment.pgp From list2rado at gmx.de Fri Feb 22 13:06:38 2008 From: list2rado at gmx.de (Rado S) Date: Fri, 22 Feb 2008 20:06:38 +0100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080221221038.GA4941@us.netrek.org> References: <45ab86180802191610u43d04842ue771e5fd8b31a142@mail.gmail.com> <20080220201107.GC11852@sun36.math.uni-hamburg.de> <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> Message-ID: <20080222190638.GB15371@sun36.math.uni-hamburg.de> =- James Cameron wrote on Fri 22.Feb'08 at 9:10:38 +1100 -= > On Thu, Feb 21, 2008 at 05:54:38PM +0100, Rado S wrote: > > - network path problems: well, again, what's the gain for anyone > > to see it listed as unreachable rather then not listed at all? > > I mean network path problems that prevent solicitation packets > from the server to a metaserver, yet permit play. We have had such > servers in the past, and we may yet again, which is why I > mentioned it as a reason. Got it. Is this a systematic problem for some conditions? If it's only a temporary issue, then either it's short and doesn't matter anyhow or it takes long to notice and people should take care of it in general. Addressing the cause is better than working around symptoms. > Yes, we have frequently contacted server admins to encourage them > to use solicitation, but as it isn't a critical feature there's no > reason to block them if they don't use it. It's not about blocking "disobedience", but the lack of usefulness (or even harm) of keeping a permanently dead server listed statically. > No, that's not how it works. The server does not send any packet > to the metaserver until it has players join. Uh... why is _that_? How should an empty server get players in the first place then? > > And how could they be joined before being listed on the metas? > > (chicken-egg problem, unless you assume people keep local lists > > and/or caches, but then this isn't an issue at all) > > Exactly ... To what, being a problem? Or not an issue at all? > and that by the way is an argument for why a server that sends a > solicitation should continue to be listed for some days, so that > players will join it, thus generating further solicitation. Ok, now you lost me. How does keeping an outdated entry on the list help the player? Especially "empty" servers aren't attractive to join in the first place. And then by the policy empty ones aren't shown after 6h anyway. This sounds just wrong: hide before start, lie after its death, hide again when idle too long. Why is _this_ operation preferable over listing even empty servers from the start so that they get a chance to attract players, and at the same time stop being listed with wrong state as soon as they stop updating? > > > 3. the metaserver has an undesired feature that prevents it > > > from working unless there is at least one static server. > > > > This can't be overcome? > > Or it isn't wanted to be overcome? > > This can be overcome. > If you care enough to, please do so. Well, it makes only sense if it got used. If the metaserver admins want to keep statically listed servers, then that's useless. > On Thu, Feb 21, 2008 at 06:05:28PM +0100, Rado S wrote: > > Apropos, the policy, which I quoted last time not to show > > servers which are empty for 6h, why is this good? > > When a server is not shown, how could it ever change its status when > > nobody knows how to get there to fill it up? > > When is "last_udapte" updated? > > Can "age" ever become > 6h purposefully (unlike dead solicitation > > servers as in my broken case [soon to be fixed])? > > You raise important design points. What do you propose as the > solution? It would help thinking about if I knew what the purpose of this policy is/ was. Solving a problem by breaking another is no progress. > To me the simplest extension is to add an identifying token to the > solicitation packet, and permit the original server to delist > itself when it shuts down. What about crashes, net-loss? Result would be the same as in my case: phantom entries. > Another potential extension is for a server to send a solicitation > every hour regardless of being empty, and code the metaserver to > remove entries from list that exceed three hours age. I see you joined 2 mails, yet you cut off what's more interesting: whether my suggestion to fix the "drop dead servers" problem is adequate. My suggestion was to let metaserver update solicitors proactively when they haven't updated for a timelimit, then depending on the forced check let things update, potentially delisting the server, see "nuke_server" checking for solicitation servers to remove them when disconnected. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From billbalcerski at gmail.com Fri Feb 22 23:53:13 2008 From: billbalcerski at gmail.com (Bill Balcerski) Date: Sat, 23 Feb 2008 00:53:13 -0500 Subject: [netrek-dev] Change to refit conditions Message-ID: <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> Hi all, I was pulling the latest server patches, and I was concerned about a change to hull damage refit conditions that seems to have been slipped in with no discussion. Here's the patch description: /* Start patch description */ * lame refit Historically ships have been allowed to refit either on their homeworld or while docked to their base with the following criteria: shields >= 75%, fuel >= 75%, damage <= 75%. I do not believe that this was the original authors intent, as damage is the only of the three critera that increases on a scale of good to bad; I believe the original intent was damage <= 25%. It is the status quo for non-base ships to be able to refit while docked to a base in clue games when heavily damaged. But to allow a base to do so while on home world is disruptive to the game. The base is the most expensive of all ship classes and the only one with a 'regeneration' period between base death and the availability of the next base. The current refit criteria is currently being abused on pickled to allow core bases to refit on homeworld with significant amounts of damage, disrupting the game and making bases virtually indestructable as a result of knowing how to split damage to exploit this 'feature' of the code. This patch has 2 configuration options to give server admins the ability of 'fixing' the refit criteria and limit refits to those with <= 25% damage individually for both bases (LAME_BASE_REFIT=0/1) and non-bases (LAME_REFIT=0/1). The patch defaults to the classical criteria to maintain the status quo. /* End patch description */ I know that it's a SYSDEF option, so no servers are forced to change refitting. But I don't think that the argument that "the original server developers made a mistake" holds any merit. Changing game design because you don't like the way it is, and saying it was a mistake to ever be that way, is highly presumptious. I would strongly urge community review of this patch and would like to know the opinions of the Bronco server operators as to whether they support this change to refit. On a minor note, clients with a repair/refit timer will be broken if there is a server configurable refit time without a feature packet to tell the client about the refit criteria, as refit conditions are hard coded into some clients. Bill From karthik at karthik.com Sat Feb 23 00:37:54 2008 From: karthik at karthik.com (Karthik Arumugham) Date: Sat, 23 Feb 2008 01:37:54 -0500 Subject: [netrek-dev] Change to refit conditions In-Reply-To: <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> References: <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> Message-ID: On Feb 23, 2008, at 12:53 AM, Bill Balcerski wrote: > * lame refit > Historically ships have been allowed to refit either on their > homeworld or > while docked to their base with the following criteria: shields >= > 75%, > fuel >= 75%, damage <= 75%. I do not believe that this was the > original > authors intent, as damage is the only of the three critera that > increases > on a scale of good to bad; I believe the original intent was damage > <= 25%. > I know that it's a SYSDEF option, so no servers are forced to change > refitting. But I don't think that the argument that "the original > server developers made a mistake" holds any merit. Changing game > design because you don't like the way it is, and saying it was a > mistake to ever be that way, is highly presumptious. I would strongly > urge community review of this patch and would like to know the > opinions of the Bronco server operators as to whether they support > this change to refit. On a minor note, clients with a repair/refit > timer will be broken if there is a server configurable refit time > without a feature packet to tell the client about the refit criteria, > as refit conditions are hard coded into some clients. It's a non-default SYSDEF option, so I don't see the problem with adding it to the codebase. That said, I have enabled it for bases only on pickled, and not for other ships. The reason for doing this is the proliferation of bases that sit on their homeworld, take heavy damage, and just refit before the next wave. Invulnerable bases sitting on their homeworld on a cored team are no good for the game in my opinion. Nobody has been opposed to this, of the dozen or so people I have polled. (And I do generally poll a cross-section of both clued players and not-so-clued players before making game-modifying decisions like this.) What clients have a refit condition coded into them? The refit TIMER is not modified, simply the requirements to refit. I am fairly certain that no clients will break simply based on the criteria for refitting being changed. Honestly, I would have to ask the same questions about XP 2006 having un-featurepacketed one-key no-lock-requirement twarp (surely the game designers intended you to actually have to lock onto a base before twarping to it), un-featurepacketed zoom, and possibly other "borg" features that don't come to mind at the moment. I would urge community review of these as well, since they are activated by default without having to be enabled by the server. I would have no problems with these changes if they were featurepacketed. I appreciate the other improvements you have made in the client, but really do wish that game- altering behavior was not simply dropped in by default with no external review. It would be nice if the current key maintainer would review the features being added to clients instead of simply blindly issuing keys, as well. (No offense intended, Carlos; I know you don't really have too much extra time to spend on Netrek, but we DO need reviews of things like this before issuing keys.) From billbalcerski at gmail.com Sat Feb 23 06:16:19 2008 From: billbalcerski at gmail.com (Bill Balcerski) Date: Sat, 23 Feb 2008 07:16:19 -0500 Subject: [netrek-dev] Change to refit conditions In-Reply-To: References: <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> Message-ID: <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> On Sat, Feb 23, 2008 at 1:37 AM, Karthik Arumugham wrote: > It's a non-default SYSDEF option, so I don't see the problem with > adding it to the codebase. That said, I have enabled it for bases only > on pickled, and not for other ships. The reason for doing this is the > proliferation of bases that sit on their homeworld, take heavy damage, > and just refit before the next wave. Invulnerable bases sitting on > their homeworld on a cored team are no good for the game in my > opinion. Nobody has been opposed to this, of the dozen or so people I > have polled. (And I do generally poll a cross-section of both clued > players and not-so-clued players before making game-modifying > decisions like this.) > What I object to is that there are certain numeric gameplay values that are ingrained into clue players, and affect how we play. For example, knowing the range at which enemies can see you, cloaked or uncloaked. When we log in, the server options tells us what the conditions are for Hidden Mode, or what the visibility rules are - the de facto setting being Tournament only. In this case, knowing how to alter damage splitting depending on if a refit station is available, whether at homeworld or near your team's base. At the very least, the refit rules should be in the server options so a player doesn't have to guess as to the refit rules every time the play. > What clients have a refit condition coded into them? The refit TIMER > is not modified, simply the requirements to refit. I am fairly certain > that no clients will break simply based on the criteria for refitting > being changed. > From list2rado at gmx.de Sat Feb 23 07:30:29 2008 From: list2rado at gmx.de (Rado S) Date: Sat, 23 Feb 2008 14:30:29 +0100 Subject: [netrek-dev] Change to refit conditions In-Reply-To: <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> References: <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> Message-ID: <20080223133029.GA20773@sun36.math.uni-hamburg.de> =- Bill Balcerski wrote on Sat 23.Feb'08 at 7:16:19 -0500 -= > At the very least, the refit rules should be in the server options > so a player doesn't have to guess as to the refit rules every time > the play. This applies to so many features that could be changed by sysdef or code hacks... but there is only limited space to display it all. What's important to list first until the space runs out? > From Paradise 2000 README: Please, can we focus on replacing that with a more useful standard P-client rather than using this as a reference for anything? Avoid any reference to it in the future, thank you. > On Sat, Feb 23, 2008 at 1:37 AM, Karthik Arumugham wrote: > > It would be nice if the current key maintainer would review the > > features being added to clients instead of simply blindly > > issuing keys, as well. (No offense intended, Carlos; I know you > > don't really have too much extra time to spend on Netrek, but we > > DO need reviews of things like this before issuing keys.) Why does this sound so familiar to me? I guess because I raised this issue some months ago. Is there _now_ enough need for a change? > Those two features you mentioned existed in other clients first > before I added them, mactrek for zoom, and paradise 2000 for one > key twarp. > {...} > For things existing in a blessed client already, I didn't see the > need to feature packet it. Still, others doing bad is no requirement or permission to do bad oneself. Lead by good example. Make it optional, leave it up to the server admin to activate, the community to test and judge it's acceptance. Then we still can separate between fun and sports configuration. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Sun Feb 24 04:55:59 2008 From: quozl at us.netrek.org (James Cameron) Date: Sun, 24 Feb 2008 21:55:59 +1100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080222190638.GB15371@sun36.math.uni-hamburg.de> References: <20080220201107.GC11852@sun36.math.uni-hamburg.de> <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> Message-ID: <20080224105559.GB22440@us.netrek.org> On Fri, Feb 22, 2008 at 08:06:38PM +0100, Rado S wrote: > =- James Cameron wrote on Fri 22.Feb'08 at 9:10:38 +1100 -= > > > On Thu, Feb 21, 2008 at 05:54:38PM +0100, Rado S wrote: > > > - network path problems: well, again, what's the gain for anyone > > > to see it listed as unreachable rather then not listed at all? > > > > I mean network path problems that prevent solicitation packets > > from the server to a metaserver, yet permit play. We have had such > > servers in the past, and we may yet again, which is why I > > mentioned it as a reason. > > Got it. > Is this a systematic problem for some conditions? I don't think it is important to go into details, but this has happened ... we have had people run servers in locations that prevent the solicitation packet from reaching the metaservers. > Addressing the cause is better than working around symptoms. The cause is not always in our control, so it is better to be flexible. > > Yes, we have frequently contacted server admins to encourage them > > to use solicitation, but as it isn't a critical feature there's no > > reason to block them if they don't use it. > > It's not about blocking "disobedience", but the lack of usefulness > (or even harm) of keeping a permanently dead server listed > statically. You've lost me. What is not about blocking disobedience? Why is disobedience mentioned? > > No, that's not how it works. The server does not send any packet > > to the metaserver until it has players join. > > Uh... why is _that_? Defective design or implementation. > How should an empty server get players in the first place then? It can only get players if someone logs into it manually first. This should change. Please care enough to change it rather than keep a mail thread alive. > > > And how could they be joined before being listed on the metas? > > > (chicken-egg problem, unless you assume people keep local lists > > > and/or caches, but then this isn't an issue at all) > > > > Exactly ... > > To what, being a problem? > Or not an issue at all? I was agreeing with you. > > and that by the way is an argument for why a server that sends a > > solicitation should continue to be listed for some days, so that > > players will join it, thus generating further solicitation. > > Ok, now you lost me. > How does keeping an outdated entry on the list help the player? It provides history. (Remember, I'm answering factually, not from a policy perspective. I'm not saying that history is more important than keeping an outdated entry.) > Especially "empty" servers aren't attractive to join in the first > place. And then by the policy empty ones aren't shown after 6h > anyway. > > This sounds just wrong: hide before start, lie after its death, hide > again when idle too long. > Why is _this_ operation preferable over listing even empty servers > from the start so that they get a chance to attract players, and at > the same time stop being listed with wrong state as soon as they stop > updating? This operation is not preferable, I never said it was, I was only describing it. Fix it. > > > > 3. the metaserver has an undesired feature that prevents it > > > > from working unless there is at least one static server. > > > > > > This can't be overcome? > > > Or it isn't wanted to be overcome? > > > > This can be overcome. > > If you care enough to, please do so. > > Well, it makes only sense if it got used. > If the metaserver admins want to keep statically listed servers, > then that's useless. Again, note that I was describing implementation, not policy. > > On Thu, Feb 21, 2008 at 06:05:28PM +0100, Rado S wrote: > > > Apropos, the policy, which I quoted last time not to show > > > servers which are empty for 6h, why is this good? > > > When a server is not shown, how could it ever change its status when > > > nobody knows how to get there to fill it up? > > > When is "last_udapte" updated? > > > Can "age" ever become > 6h purposefully (unlike dead solicitation > > > servers as in my broken case [soon to be fixed])? > > > > You raise important design points. What do you propose as the > > solution? > > It would help thinking about if I knew what the purpose of this > policy is/ was. Solving a problem by breaking another is no progress. I was not describing policy. I imagine the current implementation is defective by design. > > To me the simplest extension is to add an identifying token to the > > solicitation packet, and permit the original server to delist > > itself when it shuts down. > > What about crashes, net-loss? > Result would be the same as in my case: phantom entries. Yes, I know. I would expect the token to be stored locally by the server. Loss of filesystem would cause phantom entries. Yet how can we implement a way to delist that cannot be easily abused by attackers? Source IP address is trivially forged. > > Another potential extension is for a server to send a solicitation > > every hour regardless of being empty, and code the metaserver to > > remove entries from list that exceed three hours age. > > I see you joined 2 mails, yet you cut off what's more interesting: > whether my suggestion to fix the "drop dead servers" problem is > adequate. Yes, I cut it off, because it didn't apply, it wasn't in a format recognised by patch(1), try again. > My suggestion was to let metaserver update solicitors proactively > when they haven't updated for a timelimit, then depending on the > forced check let things update, potentially delisting the server, > see "nuke_server" checking for solicitation servers to remove them > when disconnected. Sounds good, but I'd need to see a patch, thanks. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Sun Feb 24 05:15:21 2008 From: quozl at us.netrek.org (James Cameron) Date: Sun, 24 Feb 2008 22:15:21 +1100 Subject: [netrek-dev] Change to refit conditions In-Reply-To: <20080223133029.GA20773@sun36.math.uni-hamburg.de> <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> References: <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> <20080223133029.GA20773@sun36.math.uni-hamburg.de> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> Message-ID: <20080224111521.GC22440@us.netrek.org> On Sat, Feb 23, 2008 at 12:53:13AM -0500, Bill Balcerski wrote: > /* Start patch description */ > * lame refit [...] > /* End patch description */ > > I would strongly > urge community review of this patch and would like to know the > opinions of the Bronco server operators as to whether they support > this change to refit. I support the change as a SYSDEF option, and so I accepted the patch. I don't have any need for the option on the two servers that I'm operating. I agree that the original code was probably a mistake, having reviewed the earliest sources that my research assistant could uncover. I've also researched xtrek 1.2, which already had p_shield and p_damage, and p_damage increased with damage done, same as with Netrek. It does seem possible that the implementation of refit restrictions was done wrongly. Either way, I could not find anything conclusive as to how it was to be designed. > On a minor note, clients with a repair/refit > timer will be broken if there is a server configurable refit time > without a feature packet to tell the client about the refit criteria, > as refit conditions are hard coded into some clients. Please fix this. We can't have these clients misbehave as a result of a server side policy change. On Sat, Feb 23, 2008 at 01:37:54AM -0500, Karthik Arumugham wrote: > What clients have a refit condition coded into them? Ideally refit timer support should be supplied by the server, so that this situation need not occur again with the next change. On Sat, Feb 23, 2008 at 07:16:19AM -0500, Bill Balcerski wrote: > What I object to is that there are certain numeric gameplay values > that are ingrained into clue players, and affect how we play. [...] Yes, but they can change, or they wouldn't be clue. > At the very least, the > refit rules should be in the server options so a player doesn't have > to guess as to the refit rules every time the play. The client should display the refit rules at the time of refit opportunity. > For things existing in a blessed client > already, I didn't see the need to feature packet it. I'd like to see those other clients have feature packets added, or if they cannot comply with current development schedules remove their key. On Sat, Feb 23, 2008 at 02:30:29PM +0100, Rado S wrote: > This applies to so many features that could be changed by sysdef or > code hacks... but there is only limited space to display it all. > What's important to list first until the space runs out? Yes, that's a challenge. How not to make some things appear more important just because some developer was concerned about them. Not you, Rado. > > From Paradise 2000 README: > Please, can we focus on replacing that with a more useful standard > P-client rather than using this as a reference for anything? > Avoid any reference to it in the future, thank you. While the key is present and people use it, I think we need to continue to refer to it as necessary. > > On Sat, Feb 23, 2008 at 1:37 AM, Karthik Arumugham wrote: > > > It would be nice if the current key maintainer would review the > > > features being added to clients instead of simply blindly > > > issuing keys, as well. (No offense intended, Carlos; I know you > > > don't really have too much extra time to spend on Netrek, but we > > > DO need reviews of things like this before issuing keys.) > > Why does this sound so familiar to me? > I guess because I raised this issue some months ago. > Is there _now_ enough need for a change? Nothing has changed in the situation, except a few people have made patches and some others have noticed them. If you can out-do the current key maintainer and convince all server operators to follow your key list, go ahead. I don't see that as likely. Carlos at least has our trust. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From list2rado at gmx.de Sun Feb 24 08:18:43 2008 From: list2rado at gmx.de (Rado S) Date: Sun, 24 Feb 2008 15:18:43 +0100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080224105559.GB22440@us.netrek.org> References: <20080218172833.GB15145@sun36.math.uni-hamburg.de> <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> <20080224105559.GB22440@us.netrek.org> Message-ID: <20080224141842.GA13672@sun36.math.uni-hamburg.de> =- James Cameron wrote on Sun 24.Feb'08 at 21:55:59 +1100 -= > You've lost me. What is not about blocking disobedience? Why is > disobedience mentioned? "there's no reason to block them if they don't use {solicitation}." The reason for my inquiry is to get rid of permanently downed servers once identified as such, solicitors or not, and I'd like to know what reasons speak against it. You've put it as if anyone wanted (or believed this about others) to block those not obedient to the request to switch to solicitation. That's not true. If there indeed were the intention to make all switch, I'd have expected those asking for it to support those candidates to accelerate the transition and then get rid of static lists. That was before I learned there were persistent problems requiring exceptions. If solicitation were so uncritical, why were Paradise servers urged to implement it rather than just getting relisted as before? > > > No, that's not how it works. The server does not send any > > > packet to the metaserver until it has players join. > > > > Uh... why is _that_? > > Defective design or implementation. > > > How should an empty server get players in the first place then? > > It can only get players if someone logs into it manually first. > This should change. Please care enough to change it rather than > keep a mail thread alive. Well, you could contribute your part to it by not simply publicating what you know in the for you most minimalistic possible way, but consider what's helpful, given the direction I was asking. A mere comment that "this works this way but it's not intended behaviour" would have saved both our times. Given the past of requests and decisions about acceptance and denials I had reason to believe that only what is approved is let in and kept for some reason. Before breaking that with a change to _my_ liking I want to know what there is more than I could think about why things are as they are. For the record if you still haven't noticed: I care for change. But I can't change all by myself, because of lack of time or knowledge. I can not afford reading all code lines to get the big picture and _guess_ intentions or reasons. > Yet how can we implement a way to delist that cannot be easily > abused by attackers? Source IP address is trivially forged. By listing only those soliciting continuously and responding when checked after a timeout. > > I see you joined 2 mails, yet you cut off what's more > > interesting: whether my suggestion to fix the "drop dead > > servers" problem is adequate. > > Yes, I cut it off, because it didn't apply, it wasn't in a format > recognised by patch(1), try again. > > > My suggestion was to let metaserver update solicitors > > proactively when they haven't updated for a timelimit, then > > depending on the forced check let things update, potentially > > delisting the server, see "nuke_server" checking for > > solicitation servers to remove them when disconnected. > > Sounds good, but I'd need to see a patch, thanks. I gave it. A "patch(1)"-able format wouldn't give you any more information than I gave you already. You act like an unflexible robot -> not helpful for change. Facts alone don't help, but reasoning behind it and consideration of context. If you don't want to give that, then save both our times. Facts of how things are can be figured out, but background on how things came to be are not always recorded next to the facts. You like to keep it simple for yourself, but you overdo it at times, and then blame me for catching up with what you missed to add. Discussion is not a contest about the shortest answer, but a desire to proceed together. Nobody is perfect, everyone can improve. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From list2rado at gmx.de Sun Feb 24 08:47:36 2008 From: list2rado at gmx.de (Rado S) Date: Sun, 24 Feb 2008 15:47:36 +0100 Subject: [netrek-dev] Change to refit conditions In-Reply-To: <20080224111521.GC22440@us.netrek.org> References: <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> <20080223133029.GA20773@sun36.math.uni-hamburg.de> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <20080224111521.GC22440@us.netrek.org> Message-ID: <20080224144736.GB13672@sun36.math.uni-hamburg.de> =- James Cameron wrote on Sun 24.Feb'08 at 22:15:21 +1100 -= > > > From Paradise 2000 README: > > > > Please, can we focus on replacing that with a more useful > > standard P-client rather than using this as a reference for > > anything? Avoid any reference to it in the future, thank you. > > While the key is present and people use it, I think we need to > continue to refer to it as necessary. But the presence is questioned, not just by me, but some netrek authority, too. Maybe the whole issue could be solved faster if the presence issue were solved first. > Nothing has changed in the situation, except a few people have > made patches and some others have noticed them. Sometimes this is enough to cross the critical threshold. > If you can out-do the current key maintainer and convince all > server operators to follow your key list, go ahead. I don't see > that as likely. Carlos at least has our trust. I never asked for takeover and following _my_ leadership. I just asked for _some_ _more_ active leadership. But nobody felt like doing it nor following anyone else even if he/ they stood up to serve. So netrek as a whole has the mess it deserves. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Sun Feb 24 16:35:17 2008 From: quozl at us.netrek.org (James Cameron) Date: Mon, 25 Feb 2008 09:35:17 +1100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080224141842.GA13672@sun36.math.uni-hamburg.de> References: <20080218215030.GA5640@us.netrek.org> <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> <20080224105559.GB22440@us.netrek.org> <20080224141842.GA13672@sun36.math.uni-hamburg.de> Message-ID: <20080224223517.GA5286@us.netrek.org> On Sun, Feb 24, 2008 at 03:18:43PM +0100, Rado S wrote: > =- James Cameron wrote on Sun 24.Feb'08 at 21:55:59 +1100 -= > > > You've lost me. What is not about blocking disobedience? Why is > > disobedience mentioned? > > "there's no reason to block them if they don't use {solicitation}." > > The reason for my inquiry is to get rid of permanently downed > servers once identified as such, solicitors or not, and I'd like to > know what reasons speak against it. > > You've put it as if anyone wanted (or believed this about others) to > block those not obedient to the request to switch to solicitation. > That's not true. > If there indeed were the intention to make all switch, I'd have > expected those asking for it to support those candidates to > accelerate the transition and then get rid of static lists. > That was before I learned there were persistent problems requiring > exceptions. > > If solicitation were so uncritical, why were Paradise servers urged > to implement it rather than just getting relisted as before? I do not recall my reasons for urging this in April 1998, and they may no longer be relevant, but there are some possible reasons that I can think of now: 1. information about Paradise servers would be as up to date as Bronco servers, thus creating a level playing field, (Bronco servers would not have had the advantage of accuracy on metaserver listing as they have had for ten years now), 2. once all servers have converted to solicitation we may be able to deprecate the older mechanism (metaserver connecting to server), 3. remove the need for the player list port on servers, especially those in an environment where each port needs to be explicitly listed in system or network security configuration, > > > > > No, that's not how it works. The server does not send any > > > > packet to the metaserver until it has players join. > > > > > > Uh... why is _that_? > > > > Defective design or implementation. > > > > > How should an empty server get players in the first place then? > > > > It can only get players if someone logs into it manually first. > > This should change. Please care enough to change it rather than > > keep a mail thread alive. > > Well, you could contribute your part to it by not simply publicating > what you know in the for you most minimalistic possible way, but > consider what's helpful, given the direction I was asking. I didn't understand the direction you were asking. I still don't understand why you don't just fix it and give me a patch. > A mere comment that "this works this way but it's not intended > behaviour" would have saved both our times. I thought you would have known this already from our previous discussions on other subjects. > > Given the past of requests and decisions about acceptance and > denials I had reason to believe that only what is approved is let in > and kept for some reason. Before breaking that with a change to _my_ > liking I want to know what there is more than I could think about > why things are as they are. It won't help though ... even if you just provide a patch to match your understanding of what should happen, there may be some who would fight you over it. I'm more likely to accept a patch if it has a simple explanation of what it fixes. In this case, something like "with this patch, servers will initially list on the metaserver without having to wait for a player to connect to them first, eliminating a catch-22 situation." > For the record if you still haven't noticed: I care for change. > But I can't change all by myself, because of lack of time or > knowledge. I can not afford reading all code lines to get the big > picture and _guess_ intentions or reasons. Intentions or reasons rarely matter to me. I'm more interested in the code, and the future. > > Yet how can we implement a way to delist that cannot be easily > > abused by attackers? Source IP address is trivially forged. > > By listing only those soliciting continuously and responding when > checked after a timeout. That is almost what is currently implemented, except that servers are not contacted after a timeout. > > > I see you joined 2 mails, yet you cut off what's more > > > interesting: whether my suggestion to fix the "drop dead > > > servers" problem is adequate. > > > > Yes, I cut it off, because it didn't apply, it wasn't in a format > > recognised by patch(1), try again. > > > > > My suggestion was to let metaserver update solicitors > > > proactively when they haven't updated for a timelimit, then > > > depending on the forced check let things update, potentially > > > delisting the server, see "nuke_server" checking for > > > solicitation servers to remove them when disconnected. > > > > Sounds good, but I'd need to see a patch, thanks. > > I gave it. > A "patch(1)"-able format wouldn't give you any more information than > I gave you already. It would give the information I need to apply the patch. > You act like an unflexible robot -> not helpful for change. > Facts alone don't help, but reasoning behind it and consideration of > context. > If you don't want to give that, then save both our times. I will take a patch if I understand it and agree with it. > Facts of how things are can be figured out, but background on how > things came to be are not always recorded next to the facts. > > You like to keep it simple for yourself, but you overdo it at times, > and then blame me for catching up with what you missed to add. > Discussion is not a contest about the shortest answer, but a desire > to proceed together. > Nobody is perfect, everyone can improve. Interesting, but not relevant. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From list2rado at gmx.de Mon Feb 25 06:40:12 2008 From: list2rado at gmx.de (Rado S) Date: Mon, 25 Feb 2008 13:40:12 +0100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080224223517.GA5286@us.netrek.org> References: <20080219190838.GB29597@sun36.math.uni-hamburg.de> <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> <20080224105559.GB22440@us.netrek.org> <20080224141842.GA13672@sun36.math.uni-hamburg.de> <20080224223517.GA5286@us.netrek.org> Message-ID: <20080225124012.GA16991@sun36.math.uni-hamburg.de> =- James Cameron wrote on Mon 25.Feb'08 at 9:35:17 +1100 -= > 2. once all servers have converted to solicitation we may be able > to deprecate the older mechanism (metaserver connecting to > server), Fine, looking forward for it. > I didn't understand the direction you were asking. I still don't > understand why you don't just fix it and give me a patch. *sigh* If the current behaviour were intentional, I wouldn't need to fix anything since it is already as it should be. Just because I see an improvement it doesn't mean I've considered all side effects. > > A mere comment that "this works this way but it's not intended > > behaviour" would have saved both our times. > > I thought you would have known this already from our previous > discussions on other subjects. Generally speaking: no, see explanation in eMail before (or below). If you mean something specific, please point it out. > > Before breaking {what's supposed to be as it is} with a change > > to _my_ liking I want to know what there is more than I could > > think about why things are as they are. > > It won't help though ... even if you just provide a patch to match > your understanding of what should happen, there may be some who > would fight you over it. Exactly, that's why I ask in advance, to avoid fighting and/ or wasting time by hacking unfamiliar code. I rather spend the little time I can afford on things I can handle or learn just enough to make a problem go away, not all the code. > I'm more likely to accept a patch if it has a simple explanation > of what it fixes. I don't expect immediate acceptance, but a discussion (at least about things unknown to me), so I better understand the current state and how to think about solutions. Despite being subscribed to the various netrek-places, I'm not aware of all technical (in-)decisions of the past. As said, I supposed that what is there and how it is were for a good reason. It's news to me that it isn't, and I'll keep in mind to question intention before arguing about it. Why is conceptually broken code kept and -- worse -- used? Both filtering/ starting empty servers and dropping dead solicitors doesn't sound like a big problem. > Intentions or reasons rarely matter to me. I'm more interested in > the code, and the future. You're aware that you're contradicting yourself? Future == intention/ reasons. > > > Yet how can we implement a way to delist that cannot be easily > > > abused by attackers? Source IP address is trivially forged. > > > > By listing only those soliciting continuously and responding > > when checked after a timeout. > > That is almost what is currently implemented, except that servers > are not contacted after a timeout. Exactly, that's what I hoped to have patched with the simple code change suggested. > > I gave it. > > A "patch(1)"-able format wouldn't give you any more information > > than I gave you already. > > It would give the information I need to apply the patch. You can't replace 1 single line of code (by copy&paste)? > I will take a patch if I understand it and agree with it. So, what's the problem understanding with 1 instruction replaced by another and its location? > > You like to keep it simple for yourself, but you overdo it at times, > > and then blame me for catching up with what you missed to add. > > Discussion is not a contest about the shortest answer, but a desire > > to proceed together. > > Interesting, but not relevant. *sigh* Ok, if you say so. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Mon Feb 25 17:08:17 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 26 Feb 2008 10:08:17 +1100 Subject: [netrek-dev] Change to refit conditions In-Reply-To: <20080224144736.GB13672@sun36.math.uni-hamburg.de> References: <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> <20080223133029.GA20773@sun36.math.uni-hamburg.de> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <20080224111521.GC22440@us.netrek.org> <20080224144736.GB13672@sun36.math.uni-hamburg.de> Message-ID: <20080225230817.GA4883@us.netrek.org> On Sun, Feb 24, 2008 at 03:47:36PM +0100, Rado S wrote: > =- James Cameron wrote on Sun 24.Feb'08 at 22:15:21 +1100 -= > > > > > From Paradise 2000 README: > > > > > > Please, can we focus on replacing that with a more useful > > > standard P-client rather than using this as a reference for > > > anything? Avoid any reference to it in the future, thank you. > > > > While the key is present and people use it, I think we need to > > continue to refer to it as necessary. > > But the presence is questioned, not just by me, but some netrek > authority, too. Maybe the whole issue could be solved faster if the > presence issue were solved first. I agree. > > Nothing has changed in the situation, except a few people have > > made patches and some others have noticed them. > > Sometimes this is enough to cross the critical threshold. It was for you, yes. > > If you can out-do the current key maintainer and convince all > > server operators to follow your key list, go ahead. I don't see > > that as likely. Carlos at least has our trust. > > I never asked for takeover and following _my_ leadership. > I just asked for _some_ _more_ active leadership. > But nobody felt like doing it nor following anyone else even if he/ > they stood up to serve. > So netrek as a whole has the mess it deserves. It is fascinating how you presume there should be community and leadership. Good luck. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Mon Feb 25 17:23:15 2008 From: quozl at us.netrek.org (James Cameron) Date: Tue, 26 Feb 2008 10:23:15 +1100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080225124012.GA16991@sun36.math.uni-hamburg.de> References: <20080219220846.GC5731@us.netrek.org> <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> <20080224105559.GB22440@us.netrek.org> <20080224141842.GA13672@sun36.math.uni-hamburg.de> <20080224223517.GA5286@us.netrek.org> <20080225124012.GA16991@sun36.math.uni-hamburg.de> Message-ID: <20080225232315.GB4883@us.netrek.org> On Mon, Feb 25, 2008 at 01:40:12PM +0100, Rado S wrote: > =- James Cameron wrote on Mon 25.Feb'08 at 9:35:17 +1100 -= > [...] > > > > Before breaking {what's supposed to be as it is} with a change > > > to _my_ liking I want to know what there is more than I could > > > think about why things are as they are. > > > > It won't help though ... even if you just provide a patch to match > > your understanding of what should happen, there may be some who > > would fight you over it. > > Exactly, that's why I ask in advance, to avoid fighting and/ or > wasting time by hacking unfamiliar code. > I rather spend the little time I can afford on things I can handle > or learn just enough to make a problem go away, not all the code. On the other hand, once you have invested the time in learning the code, you will be able to argue more soundly and successfully. The only expert status I have comes from understanding or writing the code. Even Bill gets patches accepted, once he understands the code. > > I'm more likely to accept a patch if it has a simple explanation > > of what it fixes. > > I don't expect immediate acceptance, but a discussion (at least > about things unknown to me), so I better understand the current > state and how to think about solutions. The trouble I have is that I don't know exactly what you are proposing, because it hasn't hit my mental model of the current situation. My mental model is integrated with the source code. > Despite being subscribed to the various netrek-places, I'm not aware > of all technical (in-)decisions of the past. > > As said, I supposed that what is there and how it is were for a good > reason. It's news to me that it isn't, and I'll keep in mind to > question intention before arguing about it. > > Why is conceptually broken code kept and -- worse -- used? > Both filtering/ starting empty servers and dropping dead solicitors > doesn't sound like a big problem. > > > Intentions or reasons rarely matter to me. I'm more interested in > > the code, and the future. > > You're aware that you're contradicting yourself? > Future == intention/ reasons. That's an interesting viewpoint. I didn't see a contradiction. > > > > Yet how can we implement a way to delist that cannot be easily > > > > abused by attackers? Source IP address is trivially forged. > > > > > > By listing only those soliciting continuously and responding > > > when checked after a timeout. > > > > That is almost what is currently implemented, except that servers > > are not contacted after a timeout. > > Exactly, that's what I hoped to have patched with the simple code > change suggested. > > > > I gave it. > > > A "patch(1)"-able format wouldn't give you any more information > > > than I gave you already. > > > > It would give the information I need to apply the patch. > > You can't replace 1 single line of code (by copy&paste)? > > > I will take a patch if I understand it and agree with it. > > So, what's the problem understanding with 1 instruction replaced by > another and its location? Can't you use diff(1) yet? It isn't difficult. darcs even makes it easier ... "darcs diff > proposed.patch" Let me tell you what happens if you send a patch ... 1. my mail reader flags it as a patch and places it ahead of every other mail I've got to read, 2. my mail reader extracts the patch and discovers which source code repository (of 65) it relates to, 3. on command, the patch is applied to a copied repository, to verify the patch can be applied without error, 4. on command, the patch is displayed in emacs, with hyperlinks from each patch line to the source code in the old or new version of the repository, 5. any questions about side-effects or usage are resolved using the emacs etags cross-referencer, 6. compilation is tested by hitting a key, 7. any stylistic changes can be made, and a new review patch written to cover them, 8. a decision is made on whether to accept the patch as is, augment it, or reject it, 9. the patch from you and any review patch from me are then pushed to the external repository for others to use. Steps 1 and 2 are replaced by a "darcs pull" for the developers who have repositories available already. > > > You like to keep it simple for yourself, but you overdo it at times, > > > and then blame me for catching up with what you missed to add. > > > Discussion is not a contest about the shortest answer, but a desire > > > to proceed together. > > > > Interesting, but not relevant. > > *sigh* > Ok, if you say so. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From list2rado at gmx.de Tue Feb 26 10:55:39 2008 From: list2rado at gmx.de (Rado S) Date: Tue, 26 Feb 2008 17:55:39 +0100 Subject: [netrek-dev] Change to refit conditions In-Reply-To: <20080225230817.GA4883@us.netrek.org> References: <20080223133029.GA20773@sun36.math.uni-hamburg.de> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802230416l60d720e9mcde34deae5f619b6@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <45ab86180802222153i3c9cf4dfga4274280378bde52@mail.gmail.com> <20080224111521.GC22440@us.netrek.org> <20080224144736.GB13672@sun36.math.uni-hamburg.de> <20080225230817.GA4883@us.netrek.org> Message-ID: <20080226165539.GA14691@sun36.math.uni-hamburg.de> =- James Cameron wrote on Tue 26.Feb'08 at 10:08:17 +1100 -= > > I never asked for takeover and following _my_ leadership. > > I just asked for _some_ _more_ active leadership. > > But nobody felt like doing it nor following anyone else even if he/ > > they stood up to serve. > > So netrek as a whole has the mess it deserves. > > It is fascinating how you presume there should be community and > leadership. Good luck. Now I know I was mistaken, I didn't before asking. Apparently I wasn't and am not the only one with such desires. What's fascinating is why among those even those with enough power in resources and trust don't make it work but once in a while still complain about it. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From list2rado at gmx.de Tue Feb 26 11:47:13 2008 From: list2rado at gmx.de (Rado S) Date: Tue, 26 Feb 2008 18:47:13 +0100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080225232315.GB4883@us.netrek.org> References: <20080220200409.GB11852@sun36.math.uni-hamburg.de> <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> <20080224105559.GB22440@us.netrek.org> <20080224141842.GA13672@sun36.math.uni-hamburg.de> <20080224223517.GA5286@us.netrek.org> <20080225124012.GA16991@sun36.math.uni-hamburg.de> <20080225232315.GB4883@us.netrek.org> Message-ID: <20080226174713.GB14691@sun36.math.uni-hamburg.de> =- James Cameron wrote on Tue 26.Feb'08 at 10:23:15 +1100 -= > > Exactly, that's why I ask in advance, to avoid fighting and/ or > > wasting time by hacking unfamiliar code. > > I rather spend the little time I can afford on things I can handle > > or learn just enough to make a problem go away, not all the code. > > On the other hand, once you have invested the time in learning the > code, you will be able to argue more soundly and successfully. The > only expert status I have comes from understanding or writing the > code. Even Bill gets patches accepted, once he understands the > code. So did I. I didn't suggest the change out of thin air. Based on what I know I wanted another opinion on whether that's the right direction to go. I guess neither of you studied each and every single line of the whole code, but what matters to a problem at hand. Otherwise you are more expert. > The trouble I have is that I don't know exactly what you are > proposing, because it hasn't hit my mental model of the current > situation. My mental model is integrated with the source code. I gave you source code. > > Future == intention/ reasons. > > That's an interesting viewpoint. I didn't see a contradiction. Fine, enlighten me then what you mean with "I'm more interested in {...} the future". > > > It would give the information I need to apply the patch. > > > > You can't replace 1 single line of code (by copy&paste)? > > > > > I will take a patch if I understand it and agree with it. > > > > So, what's the problem understanding with 1 instruction replaced > > by another and its location? > > Can't you use diff(1) yet? It isn't difficult. darcs even makes it > easier ... "darcs diff > proposed.patch" I can, but it takes more time to do that for such a simple patch. (no darcs here) > Let me tell you what happens if you send a patch ... > > 1. my mail reader flags it as a patch and places it ahead of every > other mail I've got to read, If you like it that way, fine. > 2. > 3. > 4. > 5. > 6. > 7. Awesome overhead for specialized automation to give you a convenient life. My observation of robot-like acting isn't too far off. I'm sorry for being just an average human trying to talk to another average human. Maybe there are still some humans left who care enough. > 8. a decision is made on whether to accept the patch as is, > augment it, or reject it, > > 9. the patch from you and any review patch from me are then pushed > to the external repository for others to use. So de-facto you lead the crowd, just reject any official responsibility to go all the way. -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Tue Feb 26 16:46:45 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 27 Feb 2008 09:46:45 +1100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080226174713.GB14691@sun36.math.uni-hamburg.de> References: <20080220222708.GB4168@us.netrek.org> <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> <20080224105559.GB22440@us.netrek.org> <20080224141842.GA13672@sun36.math.uni-hamburg.de> <20080224223517.GA5286@us.netrek.org> <20080225124012.GA16991@sun36.math.uni-hamburg.de> <20080225232315.GB4883@us.netrek.org> <20080226174713.GB14691@sun36.math.uni-hamburg.de> Message-ID: <20080226224645.GB4739@us.netrek.org> On Tue, Feb 26, 2008 at 06:47:13PM +0100, Rado S wrote: > =- James Cameron wrote on Tue 26.Feb'08 at 10:23:15 +1100 -= > > > The trouble I have is that I don't know exactly what you are > > proposing, because it hasn't hit my mental model of the current > > situation. My mental model is integrated with the source code. > > I gave you source code. I repeat, because it wasn't in the form of a patch, it didn't hit my mental model. You have to compete against all the other patches I get. > > > Future == intention/ reasons. > > > > That's an interesting viewpoint. I didn't see a contradiction. > > Fine, enlighten me then what you mean with "I'm more interested > in {...} the future". Sorry, I can't remember what I meant now. I see no need to post-justify what I said. > > > > It would give the information I need to apply the patch. > > > > > > You can't replace 1 single line of code (by copy&paste)? > > > > > > > I will take a patch if I understand it and agree with it. > > > > > > So, what's the problem understanding with 1 instruction replaced > > > by another and its location? > > > > Can't you use diff(1) yet? It isn't difficult. darcs even makes it > > easier ... "darcs diff > proposed.patch" > > I can, but it takes more time to do that for such a simple patch. > (no darcs here) So what do you have in the way of information technology assets and operating system software? If I knew that I could recommend actions to remedy your lack of darcs. > > 9. the patch from you and any review patch from me are then pushed > > to the external repository for others to use. > > So de-facto you lead the crowd, just reject any official > responsibility to go all the way. Official? Responsibility? I'm not elected. Nobody gives me any responsibility. I merely out-do the others. A social meritocracy. Part of why I out-do the others is that I process patches and review code really fast. Makes it harder for new participants though, I see. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ From quozl at us.netrek.org Tue Feb 26 18:30:41 2008 From: quozl at us.netrek.org (James Cameron) Date: Wed, 27 Feb 2008 11:30:41 +1100 Subject: [netrek-dev] netrek-server-vanilla-2.14.0 released Message-ID: <20080227003041.GA5449@us.netrek.org> netrek-server-vanilla 2.14.0 was released. http://quozl.linux.org.au/netrek/ 1b200a5dc2341a33f0b640201e22b015 netrek-server-vanilla-2.14.0.tar.gz -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20080227/95577654/attachment.pgp From list2rado at gmx.de Wed Feb 27 12:24:03 2008 From: list2rado at gmx.de (Rado S) Date: Wed, 27 Feb 2008 19:24:03 +0100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080226224645.GB4739@us.netrek.org> References: <20080221165437.GF26653@sun36.math.uni-hamburg.de> <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> <20080224105559.GB22440@us.netrek.org> <20080224141842.GA13672@sun36.math.uni-hamburg.de> <20080224223517.GA5286@us.netrek.org> <20080225124012.GA16991@sun36.math.uni-hamburg.de> <20080225232315.GB4883@us.netrek.org> <20080226174713.GB14691@sun36.math.uni-hamburg.de> <20080226224645.GB4739@us.netrek.org> Message-ID: <20080227182403.GA29506@sun36.math.uni-hamburg.de> =- James Cameron wrote on Wed 27.Feb'08 at 9:46:45 +1100 -= > > I gave you source code. > > I repeat, because it wasn't in the form of a patch, it didn't hit > my mental model. I've grasped your explanation of your perfect world already before, but you obviously don't realize that there is not only your way of conveying and discussing source code (or anything for that matter). > You have to compete against all the other patches I get. You described your personal ideal way of dealing with it. Fine, for you. I don't depend on keeping up with your standards, it was an offer for the common good. If you don't like my contribution below your ideal form, ignore it. I hoped there were some more parties interested in this matter than just the 2 of us. Apparently I was wrong. Are you the only person that I have to convince? If so, then because you're the only one who decides? Or because you're the only interested? (besides me) > So what do you have in the way of information technology assets > and operating system software? If I knew that I could recommend > actions to remedy your lack of darcs. Whatever it is, it (and all noise around it) takes more than it took pasting the simple change. You're focused so much on formalities, that you miss the progress in the matter of code. I guess the same applies to me for the matter of organisation. I've reduced my desires about my ideal and would be happy about any progress, maybe once you can, too. > > So de-facto you lead the crowd, just reject any official > > responsibility to go all the way. > > Official? Responsibility? I'm not elected. Nobody gives me any > responsibility. I merely out-do the others. A social meritocracy. meritocracy: "a system in which the talented are chosen and moved ahead on the basis of their achievement 2 : leadership selected on the basis of intellectual criteria" I'm sorry for my insecurity, does your explanation match or miss this definition? It sounds like contradiction to me. > Part of why I out-do the others is that I process patches and > review code really fast. Makes it harder for new participants > though, I see. This might be a problem: you quickly pick up any issue, solve it your way, and nobody else feels the need to participate. So it often ends up not only at your sole mercy, but also on your workload. You probably can handle it, while others can't. Could you handle key-management (i.e. client approval) with the same efficiency, since it's basically about code control, given how well you're organized for code review? > > > > Future == intention/ reasons. > > > > > > That's an interesting viewpoint. I didn't see a contradiction. > > > > Fine, enlighten me then what you mean with "I'm more interested > > in {...} the future". > > Sorry, I can't remember what I meant now. I see no need to > post-justify what I said. Nobody asked for justification, I was just curious how our perceptions differ with regard to "future". -- ? Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give. From quozl at us.netrek.org Thu Feb 28 16:05:27 2008 From: quozl at us.netrek.org (James Cameron) Date: Fri, 29 Feb 2008 09:05:27 +1100 Subject: [netrek-dev] metaserver solicitation usage: drop/ update lost servers In-Reply-To: <20080227182403.GA29506@sun36.math.uni-hamburg.de> References: <20080221221038.GA4941@us.netrek.org> <20080222190638.GB15371@sun36.math.uni-hamburg.de> <20080224105559.GB22440@us.netrek.org> <20080224141842.GA13672@sun36.math.uni-hamburg.de> <20080224223517.GA5286@us.netrek.org> <20080225124012.GA16991@sun36.math.uni-hamburg.de> <20080225232315.GB4883@us.netrek.org> <20080226174713.GB14691@sun36.math.uni-hamburg.de> <20080226224645.GB4739@us.netrek.org> <20080227182403.GA29506@sun36.math.uni-hamburg.de> Message-ID: <20080228220527.GA8205@us.netrek.org> On Wed, Feb 27, 2008 at 07:24:03PM +0100, Rado S wrote: > Are you the only person that I have to convince? > If so, then because you're the only one who decides? > Or because you're the only interested? > (besides me) I checked with some others via IRC, and the impression I get is that we're talking about a corner case, a trivial issue, that they don't believe they need to spend time on. > This might be a problem: you quickly pick up any issue, solve it > your way, and nobody else feels the need to participate. Good point, I'll try to stay quiet for a couple of weeks hoping for others to solve issues. > Could you handle key-management (i.e. client approval) with the same > efficiency, since it's basically about code control, given how well > you're organized for code review? No. It isn't about code control alone, the job would also require running clients on various operating systems. I'm just not set up for that. -- James Cameron mailto:quozl at us.netrek.org http://quozl.netrek.org/