VOTE PROPOSAL: Remove the idle daemon.

Feb 20 06:44 UTC 2006

I propose that a vote be put to the membership, as suggested by mcnally in
agora, to remove the idle daemon.  The reason being that the idle daemon
serves no purpose anymore, since (a) grex is not resource constrained for
pty's or CPU/memory capacity, and (b) the benefit it has of preventing
preventing obnoxious behavior is easily subverted, and (c) there is no
evidence that it stops anybody from doing anything anyway.

response 2 of 88:

Feb 20 15:37 UTC 2006

i vote yes

response 4 of 88:

Feb 20 16:24 UTC 2006

Well, some of us like to sit in party waiting for someone to come along
to talk to. It becomes annoying when you have to re-login every 15
minutes or so.

response 6 of 88:

Feb 20 16:39 UTC 2006

Grex should only restrict things insomuch as they are necessary to
keeping Grex safe. IMHO.

response 8 of 88:

Feb 20 18:38 UTC 2006

Another resource that the idle daemon helps conserve is network bandwidth, at
least for users who come in over the net. I've noticed at least once in the
past week a time of definite slowdown, which may come from CPU or network load,
so I think we're not totally past the days of limited resources. 

(One point: I believe it's actually twenty (20) minutes: fifteen (15) before
the first warning, and then disconnect after five more.)

response 10 of 88:

Feb 20 18:55 UTC 2006

re #8:  Bandwidth and CPU utilization from idle users is so negligible
it wouldn't be noticable if you had 1000 users with idle sessions open.

response 12 of 88:

Feb 20 20:33 UTC 2006

 I don't know.  How many idle users would we have if we turned the daemon
 off?  There's no real way to tell except by trying it.

 It's not like one has to make an irrevocable decision on the issue.  
 It could be turned off with an understanding that in a month or two
 if people aren't happy with the results it could be put to another
 vote..  If people are really concerned that it will really hurt the
 system direction can be given to staff to turn it back on if problems
 start developing. 

 In my opinion, however, the thing to keep in mind, is that ideally
 direction on policy changes should come from the board or from the
 members, not from staff, and that continuing to do something the way
 we've done it just because we've always done it that way and don't
 know what the alternative would be like isn't a sound strategy for
 directing system policy.

response 14 of 88:

Feb 20 21:34 UTC 2006

 I'm not sure to what extent that's controlled by "robocop" and to
 what extent by "idled"

response 16 of 88:

Feb 21 00:03 UTC 2006

Mcnally addressed the resource usage issue.  I don't think that kicking off
idle users is really keeping grex safe in anyway, though I concur with nharmon
that grex should have the authority to do what it feels necessary to keep the
system ``safe'' (though by what metric you judge safety is an open question).

As for `bots' and the like; (a) You need network access to, well, talk to the
network, which is only something members have (other users have very limited
network access; but that's not at issue here). (b) m-net turned off its idle
daemon, and doesn't seem to have much of a problem. (c) those users likely to
run annoying bots on grex that are targeted at grex can already circumvent
idled.  Therefore, idled doesn't really buy one much.

response 18 of 88:

Feb 21 02:01 UTC 2006

Re #16: You need network access to talk to the network, but that doesn't stop
them from building the thing, starting it up, testing it (it can talk to
localhost, after all), and then going away.

response 20 of 88:

Feb 21 04:01 UTC 2006

(What Nate said.)

response 22 of 88:

Feb 21 14:06 UTC 2006

I have an opinion on this issue, but before I give I think I should
point out that this is not a "vote proposal" in the strict sense because
according to the bylaws, vote proposals have to be entered by members
and unless there's been a recent change in his status that hasn't been
recorded yet, Dan Cross isn't one.  The bylaws specify timelines such as
a two-week discussion period for proposals, but since this isn't a vote
proposal, the clock hasn't started ticking yet.  (See
http://cyberspace.org/local/grex/bylaws.html and particular "Article 5:
Voting Procedures".  (The copy of the bylaws posted in this conference
isn't up-to-date, so please refer to the web version.))  

In the meantime, this is a discussion item, not a vote proposal.  Which
is fine -  the idle daemon is certainly an issue that's appropriate to
discuss in Coop.

That said, I think this issue is a bit of a silly candidate for a member
vote, as there's no data for members to make an informed choice.  If
even the technical staff can't agree, how can members be expected to
have a reasonable grasp of the consequences of their decision?

So I propose an experiment:  Let's turn off the idle daemon for a trial
period (two weeks? a month?) and see what the effects are.  If serious
problems emerge, we turn it back on.  In any case, after the trial
people will have an idea of the consequences and can cast an informed
vote.  Or the situation might be so clear-cut that there's no need for a
vote.

What do you think?  Let's keep on discussing, but unless somebody comes
up with some really show-stopper reasons for not trying this, I think
I'll turn the daemon off myself two days from now and we can have our trial.

response 24 of 88:

Feb 21 14:28 UTC 2006

You're calling this a discussion item, and yet you say there's "no data for
members to make an informed choice." ??

i think there's lots of data in this fine item, sir.

Also, i like the trial IDea