response 35 of 56:

Jan 5 00:05 UTC 2009

resp:33 Needed or wanted....

response 39 of 56:

Jan 5 15:07 UTC 2009

Could it have?  What was the recent multi-day outage all about?

response 41 of 56:

Jan 6 00:55 UTC 2009

I hadn't yet read agora when I posted that.  I see Joe (gelinas) was the
one who called.  Thanks, Joe.

response 43 of 56:

Jan 6 11:41 UTC 2009

Nights, weekends and holidays would be the difference.

response 45 of 56:

Jan 6 16:33 UTC 2009

I'm not so sure about that.

The fundamental problem isn't access, but getting someone to notice
and use whatever access is available.  It's still not clear to me
that anyone who could have done anything about it noticed right
away.  At that point, whether the vector to bring the system back
online is a phone call or a virtual console is irrelevant, because
there isn't anyone to do the job.

Besides, if we ran some sort of virtualization solution on our own
hardware, we could have reaped the benefit of virtual consoles and
etc.  It doesn't require that a third party runs it for us.

I'll restate my specific objections to the idea of hosting Grex on
a virtualization hosting provider at this point in time:

1. Modems.  No one has even bothered to address this one yet.
2. Maturity.  These solutions are relatively new, and they're just
   not mature enough for our use.  There's a strong possibility
   that they will be in a year or two, but we're not there yet.
3. Privacy.  If we host our data on someone else's server, how do
   we know who looks at it?  I'm not sure this matters, but it has
   in the past.
4. Solving the wrong problem.  This isn't about hardware reliability,
   it's about staff availability.  A virtual solution with
   net-accessable virtual consoles isn't going to solve that, and
   as I stated above, we could realize the same benefits on our own
   hardware.
5. Quality of service (in the performance sense).  With a virtualized
   solution, we lose some of this, as we no longer control what
   happens on our hardware.  Another user of the virtualization
   service that happens to be using the same *physical* computer
   as our virtualized server could send our performance spiraling
   by running some job that sucks up some resource, thus starving
   us.  Disk and network capacity come immediately to mind, and
   even if other services are rate-limited going out, nothing can
   stop the network interface from being overwhelmed with incoming
   traffic.

I'm not in principle opposed to a virtualized solution, but I'd
rather us do another round of Grex on our own hardware to let the
commercial virtualization offerings mature and address the above
issues than jump ship before the infrastructure is really ready.
For example, it's highly probable that in four years or so, modems
just won't be an issue or that we can force them not to be even if
they still are.

response 47 of 56:

Jan 7 01:57 UTC 2009

resp:46

1. I'm not sure that's the point.  I've suggested in lesser or more
subtle ways that we need to start thinking about getting rid of
modem access over the last few months, but met with resistance.
There are a few very well established users who use the modems.
It's part of Grex's philanthropic charter.  It may even be related
to our status as a non-profit organization.  Can all of these things
been fixed?  Yeah, given time, but Grex just isn't ready for that
change yet.

2. Not really.  There's a big difference between what most of the
rest of the Internet does and what John is describing.

3. In principle I'd agree with you.  But not everyone would.  Have
you discussed your thoughts on this with Steve Andre?  He believes
one of the benefits of Grex is that it allows people to do things
"under the radar" of certain repressive regimes around the world;
that's one of his arguments for fixing mail as a viable service to
draw new users.  He has a compelling vision there.  My own perspective
is that we shouldn't guarantee privacy, but we shouldn't give access
to our data to outside organizations either.  That's exactly what
we'd be doing with a virtualized solution.

4. Who says it's the current hardware that's not reliable?  I see
no indications of that.  If you have data to the contrary, I'd love
to see it.  What I'm seeing is that it's the software (particularly
OpenBSD) that isn't reliable.  Virtualization won't solve that if
we stick with OpenBSD.  If we switch to FreeBSD, we'd get the benefit
of (possibly) greater reliability on our own hardware, too.  Cause
and effect aren't correlated here.

As for new hardware, ship it to me in New York; I'll set it up and
ship it to Ann Arbor for physical placement at Provide.net.

You assume too much in assuming that, at present, those commercial
entities (a) want a stake in keeping us up and running (think about
what we do and what most companies do and how they differ), (b) the
virtualization technology is mature enough to support us yet, (c)
that it would be any more relabile than what we currently run, (d)
we couldn't reap most of the benefits of virtualization on our own
hardware, without the drawbacks.

5. Note that I said QoS with respect to performance, not availability
of the service.  If we run a virtualized service on physical hardware
that supports multiple services, some of which are presumably beyond
our control, how do we prevent their workloads from interfering
with our own?  The sad truth is that we cannot.  If you disagree
post data to back yourself up.

I did a financial analysis earlier in this thread showing that we'd
about break even over a four year anticipated lifespan of new
equipment (that's assuming there aren't hidden costs associated
with a virtualized solution that we haven't considered yet).  By
then, the virtual provider offerings will have matured enough to
make this viable.  Right now, I'm just not seeing a compelling
argument for it.  Hope isn't a strategy, and right now, the argument
*for* VPS is predicated on the hope that it would solve lots of our
problems, but no data to back that up.  I'd be willing to do some
experiments to get some of that data (which is what you elluded to)
but I am unwilling to jump to a radically different, virtualized
server unless I see data strongly indicating a net positive benefit.

The bottom line is this: without some hard data, I'm just not seeing
the benefit here.  Next step: get the data.  Taking off my staff
hat and putting on my board hat for a moment, I'm 100% behind you
and John getting some of the data and presenting it to the board.

response 49 of 56:

Jan 12 00:19 UTC 2009

COGNRANTUG:LATIONS< TS> FOR WINNING THE BOARD SEAT>

ARE YOU GOING TO BE TYP:ING UP THE MINUTES ? I THINK THEY REALLY SHOULD MAKE
YOU SEDCRETARY

MJAYBE THE IRS WILL TAKE A QUCICK LOOK AT THOSE FUNKY MINUTES<> REEZEF> AND
THEN SEND SOE P{OELICE OFFICIERS TO BREAK UP THE NEXT BOARD MEETING NBECAUSE
WHO KNOWS< YUOU GUYS MIGHT BE ON ACID< JUDGING BY THAT TYPING AND THE USE OF
PSYCHEDELIC WORDS SUCH AS "EPISTOLICALLY EPISTEMOLOGICALLY SOUND< DUDE"


JUST FOOD FOR THOUGHT< YOU KNOW

response 51 of 56:

Jan 25 23:42 UTC 2009

newuser is still not up?

response 53 of 56:

Jan 28 07:11 UTC 2009

i was asking about the psuedo-site remmers established ... well, it;ls
a real site .... sorry .... but the maintainers mighrt object to
our newuser and unix experiments.

response 55 of 56:

Mar 23 03:47 UTC 2009

i don;t do minuets - canr;t tpey w.a.s.