response 1 of 196:

Jul 11 18:28 UTC 1996

I actually like the idea, it just needs to be worked on. I tried all night
last night to get on, the waiting didn't bother me, it was that all the ports
weren't being used. I understand that was one of the problems with the
program. I am in favor of this program, once it is working fairly. I believe
I read something about this in the minutes of the board meeting. So it was
disscussed wasn't it?

response 3 of 196:

Jul 11 18:59 UTC 1996

  This wasn't a surprise change.  It was described in the April board
minutes, and has been mentioned several times in Agora and Co-op (see
co-op items 61 and 66).  It just didn't raise much controversy.
 
  As for the issue itself, I think it's a great idea.  It sounds like
the programming needs a little fine-tuning, but I welcome the change.
I only wish a similar approach could be applied to modems dialers!

response 5 of 196:

Jul 11 19:22 UTC 1996

Couple notes:  Attack telnetting does significantly load down Grex.  The
waiting list should reduce the load on the system, and shouldn't make the
average wait to get in any longer, though it should make it more predicatable.

There are other reasons that we want to do this, including making it possible
to reserve some tty ports for the terminal servers and screen sessions.

response 7 of 196:

Jul 12 01:21 UTC 1996

A very *nice* change!!
        Would Grex be willing to give this to M-Net?  I hope?

response 9 of 196:

Jul 12 05:03 UTC 1996

Indeed. this was not a surprise change. Marcus began working on this a while
ago, and had a number of things occur that caused it to be put on the back
burner. It was a bit of a (pleasant) surprise to most of us staffers when he
installed it. 

Of course, much of its problems were because the code was quite experimental.
There were some problems that caused it to tie up an excessive number of ptys
in a fruitless attempt to log in disconnected users. As a result, it performed
badly and was deinstalled for the time being.

These problems will be fixed and it will reappear. I hope soon.
When it is working properly we suspect that the average queue lengths will
never be astronomical, and that the average waits to get connected will be
manageably small, but no one can really know for sure until we do it.

Consider this all experimental. If we can't make it work to our satisfaction,
then we will try something else. The current experiment in queuing has one 
huge advantage in that it puts everyone on an equal footing. It is designed to 
eliminate the advantage currently available to those who can attack-telnet.

Imagine walking into a bank with only a small number of tellers and a lobby
full of customers who want service. Would you rather see a single line with
everyone waiting peacefully in order to get to the next available teller, 
or would you rather see all of the customers race each other to the first 
teller who calls out "Next!"? 

We have been experiencing the second kind of line, and I think it sucks.

response 11 of 196:

Jul 12 09:43 UTC 1996

guess it's good that the telnet queue went back for repairs. 
  
and ,yes, there was discussion a while back about creating somethnig 
like that  - but ... there was NO notification that the implementation
was gonna happen ..... 
  
here again, a reasonable and good idea "suddenly appeared" affecting
85% or more of the login sessions.
  
maybe there just *has* to be a "rule" that, if some change (aside from
a root-hack/security-breach) will affect a whole lotta ppl, then the
earliest implementation will take place *only after* 7 days announcement
in the motd. after that 7 days notice, adn only after that notice, the
change will be implemented, and not before. [april first excepted, of course]
  

response 13 of 196:

Jul 12 14:39 UTC 1996

Yeah, I guess it would have been nice if there had been some notice that the
queue was going to come in soon, but that's minor.  I'll be glad when it's
running.  As for the objection of tying up your line while waiting for the
countdown, isn't there anything else you can use your Internet connection for
while waiting?  You could look at the grex web site while you're waiting to
log in!

response 15 of 196:

Jul 12 16:25 UTC 1996

Okay I can see the benefits of this if it works right.  The real issue is 
why Marcus didnt ask the Board for permission to do this.  Even if this wa
discussed, there should have been a board vote.  If the Board does not exert
its authority over coding decisions, it is a puppet board with no real power.

The rule should be that no major coding/software changes that do not involve
root/security issues should be implemented with out a board vote of approval
AND proper notification.  These decisions should always go through the board
and should never occur unless the board is on record about it.

I mentioned this when popcorn installed her idle time zapper.  That should hve 
been proposed to the board and approved first too.

response 17 of 196:

Jul 12 17:33 UTC 1996

We have plenty of discussion in coop.  The board also discusses policy
plenty.  We do *not* need staff having everyone look over their shoulder every
time a minor sortware enhancement - which this one is - is being contemplated.
(Um, it may not have been minor in what it took Marcus - I mean minor in terms
of the overall function of Grex.)  Who wants hundreds of items in coop
discussing, endlessly, whether to upgrade from one version of (say) figlet
to another?  or even from one version of sendmail to another?  That sounds
like a *really* good way to drive out everyone except the true techies & the
totally clueless who like to talk.  Who wants the marathon board meetings that
could result if every staff action requires prior board approval?  Who wants
to see the staff resign en masse rather than put up with that kind of thing?

Listen, folks, I've had the opportunity to see the staff in action.  They do
in fact go to a lot of effort to think things through, & to a lot of effort
to see that policy issues get discussed & decided in coop & by the board. 
Sometimes they call things wrong (but *this is not one of those times*). 
Sometimes they fail to forsee consequences of things they do - this is
arguably one, but I'd say it's not.  Let's see.  I telnet in and get an "all
network ports in use" message.  My only option is to close (possibly by
waiting for a timeout, possibly by interrupting & closing), & then trying at
a later time (immediately or whenever).  Alternatively, I'm put in a queue
& given info on my position.  *I can still close the session* - though not
just by waiting a few minutes.  For crying out loud, what are we arguing
about?  Some notice might have been nice, but I can't see it as a really big
deal.  There were bugs, so maybe it should have been tested more, but for
heaven's sake no one is saying *that*.

For the record, when policy issues (should we have .yeswrite & .nowrite, for
example) are discussed here, people then complain that they're discussed to
death without action.  Bah, humbug.

response 19 of 196:

Jul 12 22:36 UTC 1996

A change in figlet might be a big deal to a figler user who dials in directly.
 
I don't think we should get into deciding what is and isn't an important
change, just so the board can "exert authority".  Ick.

response 21 of 196:

Jul 13 01:23 UTC 1996

In the best of all possible worlds, there would be advance notice of these
things.

This is not the best of all possible worlds.  Marcus is very busy.  He is able
to grab time to work on things at odd hours, as time is available.  If he were
required to get board approval a month in advance, I think his answer would
be "Goodbye".  I don't think mine would be much different.

Having a volunteer staff saves Grex at least $50,000 a year.  Since our annual
budget is about $6,000, this is important to us.  It does have some minuses
for the organization.  Volunteers don't jump when you say "frog."  The board
does have to give us some measure of control, and since the board is supposed
to speak for the members, some measure of democracy is lost too.  In general,
volunteer organizations aren't as "professional" in their style of operations
as those with paid employees.

I've seen what happens when boards try to manage volunteers as if they were
paid employees.  The volunteers go away.  See M-Net.  All these calls for
"greater professionalism" on the part of staff are exactly the kind of thing
that started M-Net on the road to where they are now.  If you try to bully
your volunteers into doing things "the company way" then you'll rather quickly
find yourself with no volunteers.

There are only two alternatives in staff/board relations that I can see:

(1) find the money to hire at least one staff member (note that having a
    paid staff person around tends to discourage volunteers, so it had better
    be a full time person).

(2) live with a fair degree of staff autonomy.

I'm not claiming that staff autonomy is a good thing, I'm claiming that we
cannot afford the only effective alternative.  I think all of those calling
for more "professional" behavior from staff, need to figure out a story for
how this is supposed to work that doesn't require staff members who saints,
selflessly willing to subjugate all their own desires so they can serve the
holy will of the almighty board.

Personally, you couldn't pay me to work at that kind of job in that kind of
organization.  However, if you'll give me a bit of space, I may do some of
it for free.

response 23 of 196:

Jul 13 05:31 UTC 1996

Somewhere up there someone said that Marcus implemented this wthout
permission. That's not true. Once he started on this project, he found other
things had to take higher priority, so he stopped working on it. 
In fact a number of grex staffers were trying to get a hold of the project
so that they could take it over, as we thought Marcus would not finish it.

Fortunately, he found some time one night last week and worked on it.
This spares us from having to go learn the code and do it instead.
The whole staff has strongly favored wait queues for technical reasons
for quite some time, and had been a bit disappointed in the time it took to
get here, quite frankly.

I don't see any way we could have scheduled it as tsty suggests.
Had we tried it wouldn't have happened. And that would have been worse.
Staff generally makes recommendations on technical matters to the board.
Fortunately, our board generally listens to the staff about these things. They
have the power to override such a recommendation, but would only do so (at
least with the current boaqrd, I believe) if they felt staff was trying to
pull a "fast one". It is good for the board to have this power, as they
represent the members, but it is also good that the board llistens to the
staff, because the staff genberally knows what it is talking about, and has
the best interests of Grex at heart.

If the members are unhappy with the board because they believe that it gives
too much autonomy to  staff, then they should elect a board that feels
differently. Certainly they should elect fewer staff members to the board.

(OK, I'll stop now, but I could go on.)