If (when?) Grex goes down again, where should we continue the discussion
of grex's future?  We could also use the chosen venue to discuss the
status of grex while it is down.

During the recent unpleasantness, some folks were discussing the matter
on m-net, while others were using a web-based system called "posterous."
There were also some exchanges in e-mail.  However, e-mail is not a good
solution for a conversation between many people.

So, where do we go when we can't go here?

30 responses total.

  
both ...
  

I think "both" is a bad choice.  We need a place _everyone_ will go to.
 Remember, "An interpreter is someone who tells you what would be best
for him if the other guy said it."

I was hoping enough people had yahoo or google accounts that a 
google.group or yahoo.group would be an easy place to meet.  There would 
be a learning curve but it's slight and it's dead easy to customize how 
you receive new posts.  I'm kinda fond of both for conferencing.

A yahoo group would work. Google could too, though I'm not familiar with
 google groups yet.

I'd say M-Net.  "Both" is the wrong answer.

  
yeh, both might nowt be 'the singular best' but it;s not wrong, ok?
  
hte m-b0x takes tolearation of dirt pigs. 
  
posterous, fwiw, as soone as you singe up, sends email to your respective
address with an opprotunity to reply into hte braided conv and everone
receives that as weell. 
  
it;s not as familiare as bbs but it has its benefits ... again, not
;teh singular best' but not wroing wither.
  
a third idea ... jusat had the brain-bulb light ... woeuld be a
standby  mini-grex housed somewhere with a decent intenernet connectoin.
  
wold just run one, maybe two .cfs with what everone is familiar with.
  
a stanby, mini-grex mighte not even be 'the singuarl best' but it;s
not wroing either.
  

at one point I ran 'down.arbornet.org' with a small instance of backtalk
that did something similar.  if there's interest, it could be done for
grex too.

I think that's a good way to go - a small virtual machine running
backtalk, with a copy of Grex's password info so that Grex users
could log into it.  Backtalk access only (no shell access),
accessible when (only when?) Grex is down.  I'm assuming that
syncing of password info is feasible.

I set up the posterous thing as a stopgap measure.  It's certainly
not ideal.  Neither is hosting on a non-grex-controlled site like
M-Net.  Grex should have its own site for this purpose.

well, the site I was running had it's own database of users (and created
via the backtalk newuser program).  Syncing of the passwords might be
feasable, but I'm not going to sync grex's accounts to my password file,
so I'm not sure it'd be exactly straightforward.

re #3
 It's certainly
 not ideal.  Neither is hosting on a non-grex-controlled site like
 M-Net.  Grex should have its own site for this purpose.
 
Define: non-grex-controlled

The systems are almost identical in purpose and have shared staff.

Very different in culture, regardless what mission statements & such
might say.  Have been for years.

By grex-controlled I mean operated by Cyberspace Communications, Inc.

Does anyone know if M-Net and Grex could run on VMWare instances on one
box?  Would a physical sharing still be a deal breaker for Cyberspace Comm?
(Curious why)

there is no reason why they could not both run on separate vmware
instances on the same physical hardware, aside from the previous
arguments put forth that such a thing is blasphemous.

It's more who owns the hardware not who Grex is next to on that disk.  I'd 
like to see Grex stay as autonomous as possible. On one end of that 
autonomy scale would be living on a machine that could be shut down on a 
benefactor's whim and where we'd have no recourse.  The other end would be 
our being housed on a well-established, for profit enterprise system where 
we'd have a contract and pay for service.

I agree with resp:15.  Physical sharing of virtual instances (e.g.
VMWare, Xen, or some other virtualization technology) certainly
wouldn't be adeal-breaker to me.  If you're running as a virtual
instance, the other instances you're sharing the hardware with are
essentially invisible to you, so why should anyone care if Grex is
sharing physical hardware with M-Net, StupidNet, LimbaughNet, or
whatever?

I actually suggested running Grex as a virtual machine on a
commercial hosting service some time ago, as a way of unloading
responsibility for the hardware, which has proven to be a serious
bottleneck (as the recent 5-week downtime clearly shows).  See
item:248 for discussion of this.  There are arguments for and
against, of course.  Dan Cross and STeve Andre are very much
opposed to the idea.

I think the reasons against the hosting of grex at a commercial provider
are good ones.  They're very expensive for what you actually get, and
there are potential security risks with it which Dan has outlined pretty
clearly.

The idea of having both MNet and Grex as VM instances is fairly simple:
M-Net hardware works.  ISP doesn't charge for bandwidth.  Staff crossover.

I still really don't understand the problem with hosting two separate BBS
instances on the same physical hardware.  Could someone please address that?

  
here it is ... again, imo:
  
 Tue, Dec  1, 2009 (17:10):

 grex was set up, officially, socially, technically, emotionally and
 structurally to be  NOT-m-b0x.  the water and the oil were separated
 by the birth of grex and it just ain't a-gonna fuse again even if enough
 pressure can make diamonds from carbon.

 ann arbor is a VerySmallTown (tm).

I don't care about Ann Arbor or how big it is.  And what does that have to
do with anything?

If people don't object to the systems being on the same (virtualized)
hardware, then who cares whether they share the same running kernel?

it seems like there are objections to both.  aside from that, m-net has
source to backtalk and could techncially recompile and install a
separate instance of bbs for grex if it ever came to be required.  I'm
unsure of picospan, but I'm assuming it's possible to do the same so I
would think it could be done if picospan and yapp were to run
concurrently.  That is to say that it's likely TECHNICALLY possible, if
it ever came to the implementation stage.

Yes, that is all true...  Picospan has been deprecated for a while now,
though, so I'm really not concerned about it.

re #22
Implementation would be nice.  Other than emotional intelligence barriers,
I don't see why it couldn't happen.

Me neither.  And frankly, I don't care about the emotional barriers.
Whatever happened 19 years ago in some dinky midwest college town is
irrelevant to me sitting in New York, Afghanistan, or California in
2010.  Caving the the ghosts of Grex's past is what's keeping it back
more than anything.

Grexing from Jalalabad or Kabul? Whoa, haha, nice!  I've got NY and CA in
2010, too..and some EU places mostly.  A2 drama only taints the whole
experience with Green Acres episodic comedy not worth reading.

imho an m-net based solution is far from _outside the box_. seems a bit
insestuous in fact. the problems that seem to hinder the growth of grex are
not avoided by moving to that box. the further away from M-Net cyberspace gets
the more I -for one - would like it. 
when your engine blows a gasket you could fix it with a used motor - sure your
could even drop in a NEW motor. the important thing is if you blow your gasket
you are not treating your motor properly. 
the problem as I see it has less to do with hardware and more to do with
process. 
I really wish I had more time to get involved here but for now its just 2
cents from the peanut gallery. 

re #27
There's a handful of users on either system.  M-Net has no hosting costs.
I don't see how Grex would be in harm's way by converging on hardware.
Split virtual systems would be a piece of cake.

Another possibility would be running both in a FreeBSD jail.

To swerve back to topic...
If the answer to the hosting issue gets us to sharing a box with M-Net then
I imagine if Grex goes down then M-Net likely has as well :\

Having a location to hook-up that is disconnected from that hub is only
logical (in much the same way as hosting via M-Net piggyback seems logical)

Putting all the eggs in one basket is seldom the wisest couse of action.
-call that cent 3 ;)

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss