|
|
| Author |
Message |
| 25 new of 125 responses total. |
scg
|
|
response 60 of 125:
| 
Oct 18 00:38 UTC 1998 |
Right, we're likely not there yet, but we're also not to the point where our
usage doesn't entirely fit over the ISDN link. The modem link won't be useful
to us until we are, and at that point I'm guessing we'll have too much mail
traffic for it to be useful to us.
|
scott
|
|
response 61 of 125:
|
Oct 18 12:36 UTC 1998 |
Or perhaps we won't have enough CPU or staff time to handle enough users to
saturate the ISDN link.
|
steve
|
|
response 62 of 125:
|
Oct 18 18:00 UTC 1998 |
Do not think that, Scott. Grex usage is growing every month. Unless
we take forceful actions to stop that growth, we're going to hit a point
where the ISDN link is going to saturate.
However, ISDN saturation is not the only reason why the IC-Net link
should stay. We need that link to carry mail on the mail machine: having
a seperate link for that will be a large win. Yes, putting mail machine
on the current ISDN link will win too, but having a seperate link lets
us process mail when the ISDN link is down.
|
scg
|
|
response 63 of 125:
|
Oct 18 18:36 UTC 1998 |
Which so far has been a once every six months occurrance. Having a separate
link for the mail machine while the ISDN connection is working only helps us
if the ISDN link is full. Otherwise, it doesn't make a difference. So that
leaves us with the 33.6 link being marginally useful maybe for a few days
every six months, based on current experience with one of our ISDN lines.
The board was well aware of that when making the decision to cut the link,
and there was a pretty clear consensus that that kind of marginal usefulness
wasn't worth $480 per year, given Grex's budget constraints.
|
scg
|
|
response 64 of 125:
|
Oct 18 18:40 UTC 1998 |
It's also worth pointing out that the 33.6 link was considerably less reliable
than the ISDN link, so having mail only going over the 33.6 link would reduce,
not enhance, the reliability of the mail system.
|
steve
|
|
response 65 of 125:
|
Oct 19 00:22 UTC 1998 |
Look at the logs, Steve. There was a time when the PPP link was
crashing every day. Two things changed, however: Marcus made a new
kernel for it which got rid of the serial port bug, and moving to
the Pumpkin changed the line noise picture very much. But, look
at the logs.
|
scg
|
|
response 66 of 125:
|
Oct 19 01:11 UTC 1998 |
And after that, the reliability still wasn't perfect. No, it certianly wasn't
developing problems every day, or every week, or maybe even every month. It
had problems more than once every six months, though. That's not a lot, but
it's certianly no better than the ISDN line.
|
steve
|
|
response 67 of 125:
|
Oct 19 03:49 UTC 1998 |
True, but given that the mail machine is a Open BSD box I expect it
to work as good as the quality of the phone line. I've seen OB regularly
keep 10 day at a time ppp connections.
Again, it isn't that the PPP link is as good as an ISDN line, becuase
it isn't. But it's also cheaper.
|
scg
|
|
response 68 of 125:
|
Oct 19 04:10 UTC 1998 |
Not if we already have the ISDN connection.
|
valerie
|
|
response 69 of 125:
|
Oct 19 15:43 UTC 1998 |
This response has been erased.
|
valerie
|
|
response 70 of 125:
|
Oct 19 15:47 UTC 1998 |
This response has been erased.
|
aruba
|
|
response 71 of 125:
|
Oct 19 17:24 UTC 1998 |
Valerie, it's fine to say "aruba began pulling the plug" instead of "the board
began pulling the plug". I take responsibility for my own actions.
I am unrepentant. I'd already waited longer than I felt comfortable with,
and I am tired of being strung along.
I am a little sorry we didn't specifically designate a time and place for
STeve to state his opinions on the matter before we voted on it, for the
sake of everyone feeling better about the decision. But we knew his
opinion at the time we voted; we just disagreed with it. I will grant,
though, that we could have accomplished the same thing more smoothly than
we did.
The mood at the board meeting last month was one of frustration that it
had taken so long to do anything about cutting costs, and we really wanted
to do *something*. We probably should have just entered an item about
cutting the ICNET link, let everyone discuss it for a month, and then
voted the next month. So I guess I will concede STeve's point that the
process was, if not flawed, than at least not stellar.
But STeve did get his specific discussion, in this item, and it hasn't
changed the minds of any of the board members. I am nearly certain that a
staff meeting won't change any minds either, and I really doubt that it's
going to make STeve feel any better to wait until after it. (Correct me
if I'm wrong, STeve.)
If the board allows one staff member to blackball its decisions, then we are
not doing the job we were elected to do, and we have only ourselves to blame
for it.
|
jep
|
|
response 72 of 125:
|
Oct 19 18:32 UTC 1998 |
Only a phone line was turned off, right? No one has cancelled the
connection on IC-Net's side as of yet. The Board is going to discuss
turning off some phone lines, and it seems likely they'll decide to turn
off at least one. That connection could easily be used to re-connect to
IC-Net, if that path were desired.
In short, though this was a decision, it wasn't irrevocable, or even
expensive to revoke (given the assumptions I made). I would hope, and
have every reason to expect, that no disrespect for STeve, nor for the
staff, was intended.
It's pretty likely this change saved some money, even if it's just the
advance turning off of a phone line that will be turned off anyway. The
only way it can cause any harm is if a rift develops between (some
of) the staff and (some of) the Board. That can only happen if you guys
let it happen.
|
dpc
|
|
response 73 of 125:
|
Oct 19 19:57 UTC 1998 |
I sure hope the Board sticks to its unanimous decision. Things like
cutting IC-Net can be argued forever. It is plain that the Board
decided to cut the Gordian knot and *make* a decision.
This is good.
|
scg
|
|
response 74 of 125:
|
Oct 19 22:02 UTC 1998 |
STeve hasn't raised any arguments here that the board wasn't already aware
of when deciding to cut the link, as far as I know. So perhaps we've got more
stuff on the record here, but I woudln't expect this discussion to change
anybody's vote. Also, like Mark, I'm not at all comfortable with a non-board
member being given veto power over the actions of the board, which seems, if
nothing else, procedurally bad.
|
other
|
|
response 75 of 125:
|
Oct 19 22:23 UTC 1998 |
if you look at it from the standpooint of a non-board member vetoing the
board, then it seems a bad things, but if you look at it as a staff
membermaking a very strong recommendation to the board on the basis of his
experience and knowledge, and the board responding by delaying action until
other alternatives are discovered or a set deadline has passed, then it take
on a different aspect...
|
jared
|
|
response 76 of 125:
|
Oct 19 23:06 UTC 1998 |
Folks.
1) Ditch the ICNet link
2) Get ready for Solaris before y2k. SunOS does not work
w/ y2k well at all. Sun doesn't support SunOS 4.x anymore
I'm never on anymore, and am just wandering about old places
fora few minutes.
The vote is done. Ditch it. Picking up a mail server
and dropping it someplace with internet connectivity while
grex has a major outage isn't that hard. it's called
"low dns ttl".
As far as routing the mail over another link, yeah, it would
be cool. oh yay for us. It would be nice. But
last I checked nobody has time to jump into and
after this.
If the net link is down, and you have this new mail server
up, it will handle the mail load just fine.
There is fancy router queueing that can be done
to give precedence to telnet rather than http/smtp, etc.
sigh.
Comments, send them in e-mail, as i'm never online
anymore.
|
lilmo
|
|
response 77 of 125:
|
Oct 20 15:42 UTC 1998 |
Are the assumptions of #72 correct?
|
dpc
|
|
response 78 of 125:
|
Oct 20 15:55 UTC 1998 |
Could someone take the IC-Net message out of the MOTD? It would shorten
the MOTD by two line and help fight "bloat."
|
aruba
|
|
response 79 of 125:
|
Oct 20 16:37 UTC 1998 |
Re #77: I cancelled the line on Grex's end of the connection, but Valerie is
going to wait for the staff meeting, I believe, before calling ICNET to cancel
the other end.
|
mta
|
|
response 80 of 125:
|
Oct 20 20:02 UTC 1998 |
I'd suggest waiting until a final decision is made and the deed is done/not
done before removing the ICNet message from the MOTD. It is only two lines
after all, and a few more days of thanking ICNet for all they've done for us
isn't too much to ask.
|
richard
|
|
response 81 of 125:
|
Oct 22 22:35 UTC 1998 |
Y2K is going to cause major problems with SUN and grex should switch
to Solaris? Interesting...I guess its better not to take chances
|
mdw
|
|
response 82 of 125:
|
Oct 23 00:34 UTC 1998 |
Actually, we don't know that's so. Sun has released quite a few y2k
patches for sunos, most of which we've installed (some, such as the
patch for passwd, don't apply to us). The basic data structures used by
Unix and most unix utilities shouldn't be affected by y2k, so there's no
reason to expect that sunos will turn belly-up on jan 1. The most
likely effects of y2k on sunos would be a few utilities might produce
weird output; this is not necessarily all that big a disaster. One
thing we haven't done (but should have) was to do some y2k testing
before switching onto the 670. That's a shame.
Solaris has its own interesting problems, some of which are a
significant problem for us. The kernel blocks we have would be
non-trivial to install in solaris, which has a completely different
tcp/ip architecture. While Sun does distribute a C compiler with
solaris, it is not free; you have to purchase a license from sun and run
the license manager to use it. The vandals have found quite a few
security holes in various versions of solaris. We'd probably need to
get the latest stable solaris release, and do quite a bit of research to
make sure we have the right set of patches for it, that fix all the
holes found by the vandals. Doing this right means finding a 2nd
machine to run in parallel with grex, which we don't have. On the
bright side of things, solaris would fix the uid overflow problem, which
may be a more serious problem for us than y2k.
|
steve
|
|
response 83 of 125:
|
Oct 27 04:06 UTC 1998 |
I'm getting comments that others have taken SunOS 4.1.4. to 2000
and back, without problems.
We're going to need to do some testing, I think. But the picture
looks pretty good.
Solaris, with it's every-other-week root exploit courtesy of
the vandal community would be a real horror for Grex to switch to.
|
lilmo
|
|
response 84 of 125:
|
Nov 2 03:18 UTC 1998 |
So, I take it staff is not chomping at the bit to get their hands on solaris,
eh? :-)
|