|
|
| Author |
Message |
| 25 new of 547 responses total. |
asddsa
|
|
response 471 of 547:
| 
Oct 20 03:01 UTC 2003 |
We sure will.
|
janc
|
|
response 472 of 547:
|
Oct 20 03:02 UTC 2003 |
I did a lot of work on NextGrex for a while. After a while I lost momentum.
Now I'm also short on time, having a lot of work to do. There are still
things I ought to do, but I don't think anything is actually blocked on me.
I don't think Picospan is a problem. Ask Marcus, and he'll deliver. An
OpenBSD version already exists. Installing it would require very little of
his time. He hasn't done it because he's thinking Grex isn't coming up right
away anyway.
If you want to move away from Picospan to something we can get a source
license to, then that's a more significant project. I'm inclined to
discourage Yapp. I've worked with it on Spring and M-Net and in both places
it much flakier than Picospan. There seems to be something where it deletes
hunks of the following response when a response is censored, and other
flakiness. The Spring especially seems to be riddled with mangled item
files that can't be correctly parsed any more.
Fronttalk is buggier still, but the bugs are all in the user interface. Some
of the search things don't work right, I think. It doesn't mung up the item
files, because that part is done by Backtalk, which is pretty solid at that
level. I do about 75% of my conferencing on Grex with the Fronttalk running
on Grex. (Type "ft" at the shell prompt to run it - start up is slow but
after that it's fine. Type "help differences" to see how it differs from
Picospan. Mostly in good ways.)
But I don't think it will be necessary to replace Picospan.
Mail, not picospan, is the biggest single blocker. It would be good to have
Marcus involved in that, at least in a spec-writing mode.
Mostly there are a lot of smallish tasks that need doing. Some people need
to put in some serious time. I don't have it right now. I'd be delighted
if someone else did.
|
asddsa
|
|
response 473 of 547:
|
Oct 20 03:06 UTC 2003 |
We should officially change the name to "NextGreX". It's a lot more
symmetrical.
|
cross
|
|
response 474 of 547:
|
Oct 20 03:27 UTC 2003 |
Several points. I'm starting to get really leery of major software
components that only one or two staffers can fix, install, whatever.
This is certainly the case with PicoSpan, and for legal reasons; it's
not even a question of technical knowledge (which could presumably
be transferred)! Surely that's bad. What's more, it's not at all
clear to me that we have a legal license for it.
But let me ask this: why is PicoSpan still `closed source'? I don't
think there are too many people running it. Would it be possible to
ask the holders of the intellectual property to release it under an
open source style license? Or under a dual-license so that non-profits
can use it for free? That would eliminate the problem once and
for all.
But even then, I'm not sure that's going in the right direction.
Something like frontalk, which works across machines, is in my
opinion where we should be directing our efforts.
Mail isn't a big deal. Give me a day and I'll have it set up. But
the time for elaborate spec writing and endless back and forth has
passed: we've used up our time trying to create a system that
satisfies everyone, and in the end, we've satisfied no one. Let's
just start from a few basic guiding principles, a reasonable design,
and go from there. If some aspect or other of the system isn't to
someone's liking, too bad; at least we'll have a place to start
addressing that person's concerns from.
|
aruba
|
|
response 475 of 547:
|
Oct 20 13:27 UTC 2003 |
I agree wholeheartedly with the last paragraph. I have never understood why
Grex needs to have a mail system that's much more hacked than anyone else's.
Why can't we use a (mostly) off-the-shelf solution for mail? (I'd be happy
to be enlightened.)
|
remmers
|
|
response 476 of 547:
|
Oct 20 16:02 UTC 2003 |
I agree with Jan that Picospan probably isn't the holdup here,
especially since an OpenBSD version already exists. As one can
see by reading Dan's summary, quite a bit of work on NextGrex has
already been done and some critical issues have been resolved; it's
mostly been reported in the Garage conference, not Coop. I'm glad
to see that Dan doesn't think mail will be a big issue, because
that had been worrying me.
Even if NextGrex comes up initally running Picospan for conferencing,
which it probably will, I do believe that we should think in terms
of moving away from it in the long run and towards something that
is open source, non-proprietary, and is a bit more modern in its
underlying architecture (that the user doesn't see). This rules out
YAPP, of course, which on balance I'd have to say that I don't like
as well as Picospan anyway (I've used both extensively). The most
promising effort in this direction that I've seen is Jan's FrontTalk,
which I hope he (or somebody) puts some more effort into getting
ready for primetime. Fronttalk is essentially a Picospan-like
front end to Backtalk, so users would continue to have a familiar
interface, but the technical hassles involved in getting text-based
conferencing to play well with web-based conferencing that one has
with both Picospan and YAPP would basically disappear. Because of
its client-server architecture, FrontTalk can also handle distributed
conferencing, i.e. can access conferences on more than one machine.
FrontTalk is slower than Picospan, but I think that once we're on
the new machine, speed differences won't be particularly noticeable.
|
jp2
|
|
response 477 of 547:
|
Oct 20 18:02 UTC 2003 |
This response has been erased.
|
jep
|
|
response 478 of 547:
|
Oct 20 19:00 UTC 2003 |
I'd like to think we aren't waiting for new software to be developed
for NextGrex, because that would appear to me to be an indication of
major further delays. Why were we in such a hurry to buy the hardware
if we're so far away from using it?
My expectation, when I saw we were buying new hardware, is that "we"
(the staff) knew how it was going to be used, or thought they would
know soon and had reason to believe they could begin using it. If we
know we're using Picospan and that it's going to be ready in small
amounts of time, that's terrific; it doesn't need to be worried about.
Resp:474 implies the holdup is designing a mail system. Folks, this is
not the right time to be designing a new mail system! The right time
was before the hardware was bought. Maybe Next^2Grex can have the
perfect mail system, after a few years of development. I'd like to
respectfully request you quit screwing around with garbage like that,
at least quit allowing it to hold up the new Grex machine, and install
something available now.
|
cross
|
|
response 479 of 547:
|
Oct 20 19:07 UTC 2003 |
Regarding #477; If you can get it done in the next three months, we'll
consider it. We'll consider anything. However, the priority now should
be doing whatever will take the least amount of time.
Regarding #478; That's what I said. I plan on just building a mail system
and moving on. If it's imperfect, we can fix it later. But right now,
the goal *has* to be getting something reasonable up in short order.
The only thing it would be silly not to do is wait for OpenBSD 3.4 to
come out. That's less than two weeks ago, though, so won't be a huge
deal. On that, we're hamstrung by a megalomaniac in Canada, though.
|
jep
|
|
response 480 of 547:
|
Oct 20 21:48 UTC 2003 |
re resp:479: Dan, it's my impression you need buy-infrom the rest of
the staff for the new mail system and that you don't have it. I think
I was speaking to the staff as a whole rather than to you, indicating
that, in my opinion, we have to go ahead.
If my impressions are wrong, you have enough freedom to go ahead with
implementing a standard mail system, have committed to doing so, and
that that major roadblock (as described earlier in this item) is not
going to be a hold-up... that's terrific. Congratulations to you and
to all of us.
But it still leaves open the question, which I raised on Friday...
what's the next hold-up? What's going to be done about it?
Finally, in the end... when do we, the non-staff users, get to be on
the new hardware? However pointedly, brusquely (or other euphemisms
for rudely) I've asked it, I think it's a valid question to be asking,
and I don't feel like I have received an answer yet.
|
cross
|
|
response 481 of 547:
|
Oct 20 22:32 UTC 2003 |
You're right, I do need buy-in from the rest of staff. But what I
think we need buy-in for is to just *do* things without a huge amount
of debate and public discussion. Something needs to be done, let's just
do it instead of trying to appease everyone. That can come later.
Like I said, I think three months is a reasonable timeline. But again,
that's dependent on staff buying into it, and on us agreeing to just do
the work.
|
gull
|
|
response 482 of 547:
|
Oct 21 13:27 UTC 2003 |
For those who are worried the new hardware will be obsolete before we
get onto it:
I don't see this as a concern. We're not building a system to play the
latest shoot 'em up game here. It doesn't matter if our hardware is
obsolete as long as it's fast enough to do what we need it to. Grex has
been running on obsolete hardware for as long as I've been using it.
There are reasons to be unhappy about the delays, but fear of
obsolescence is not one of them.
It's important that we get this system up and running soon. But it's
also vitally important that it be set up right, and documented
thoroughly. Thorough documentation is our only way out of the "we need
to wait for person X to fix it, because only they know how that works"
syndrome that curses us right now. That's worth spending extra time on,
and I'm willing to wait for it.
|
cross
|
|
response 483 of 547:
|
Oct 21 14:54 UTC 2003 |
There's a difference between doing a thorough, but *speedy* job, and
continuing to do what we have been, which is nothing, while we make
noises about needing more time to do it right. Remember, it doesn't
matter whether we do it right or wrong if we don't do it at all!
|
jep
|
|
response 484 of 547:
|
Oct 21 16:25 UTC 2003 |
We bought brand new equipment with the idea of running Grex on hardware
that *wasn't* several years old. That brand new equipment will have
passed it's warranty period before NextGrex is anywhere close to being
up and running.
|
other
|
|
response 485 of 547:
|
Oct 21 16:32 UTC 2003 |
The idea was to make a significant infrastructure improvement, and of the
ways to do that, the best investment was in new hardware.
The relative age of the Grex hardware versus the current standard has *
never* been an issue of concern (except as it relates to the ability of
Grex to provide even the basic services for which it exists), and very
likely never will be.
|
cross
|
|
response 486 of 547:
|
Oct 21 17:14 UTC 2003 |
Now, now, let's not mince our position. We *did* buy top of the line
new hardware, with the intention of moving to the newer machine sooner
than later. I will agree it wasn't our primary goal to have a super-
computer to run grex on, but that doesn't excuse us being this slow.
We really do have to do better.
I'm going to suggest that, if staff agrees to move to nextgrex within
three months, we end this thread of discussion. Pointing fingers and
complaining about what we didn't do isn't going to help us achieve the
goal of moving to the new machine sooner than later. Let's not lose
sight of what's important here: getting nextgrex running.
That said, I think we have a limited amount of time available until
OpenBSD 3.4 comes out. Let's make profitable use of that time by trying
to hash out some of the remaining technical issues before we have to
start slinging away with configuring and documenting the new machine.
Let's just get this thing done and move on to other issues.
|
aruba
|
|
response 487 of 547:
|
Oct 21 23:26 UTC 2003 |
John - ifit's any consolation, NextGrex has been up and running since not
long after we got the hardware. So most waranteeable problems would have
showed up by now.
|
jep
|
|
response 488 of 547:
|
Oct 24 03:55 UTC 2003 |
Let me clarify my position a little bit.
It's my intention to ask questions and to get the answers. I just
wanted to find out why NextGrex isn't being used yet, and when it will
be used. I still don't know either of those things. Dan Cross is
certainly stepping forward and setting expectations, but I don't know
if the staff as a whole is going to accept and meet those expectations.
It's not my intention to bash anyone. I don't think the NextGrex
implementation needs to be about personal feelings. If person A isn't
going to get the job done -- for *whatever* reasons; I haven't asked
for the reasons and no one has volunteered them -- then if there is a
person B, that person should allowed to give it a shot.
There are "person B" people available, by the way. Grex is lucky that
it doesn't have to be dependent on one individual for it's survival
and future direction.
re resp:485: I apologize for any of my comments which may seem to
stretch a point or two. Grex could have bought a 3.0 GHz machine in
February, instead of a 2.2 GHz machine, so in that sense it's new
hardware is not "state of the art". And I don't care if it's state of
the art in that sense; that wasn't my point.
It *was* new then, and is not new now. If we had waited a year to
buy, we'd be better off. That's what probably should and would have
happened, had we known there was no commitment to put Grex on the new
hardware last winter and spring. Having the NextGrex hardware sitting
unused is hurting Grex. *That* was my point.
re resp:487: Yeah, the warranty remark was a stretch. A hardware
warranty isn't of that much relevance.
|
gelinas
|
|
response 489 of 547:
|
Oct 24 04:03 UTC 2003 |
I don't think the current state is "hurting" grex, but I do agree it's not
really helping. And waiting a year to buy the hardware wouldn't have helped,
either.
We are setting up a checklist of things to be done. The next step is to
install OpenBSD 3.4, which janc agreed to do.
|
gull
|
|
response 490 of 547:
|
Oct 24 13:22 UTC 2003 |
Re #488:
> It *was* new then, and is not new now. If we had waited a year to
> buy, we'd be better off. That's what probably should and would have
> happened, had we known there was no commitment to put Grex on the new
> hardware last winter and spring.
Honestly, I think this is a bit of a catch-22. You're not going to get
people to commit time and effort until they know there's a will to spend
money on the hardware.
|
cmcgee
|
|
response 491 of 547:
|
Oct 24 21:40 UTC 2003 |
I disagree that we should have waited to buy. As I understand the process,
you have to make sure the software runs correctly on a specific hardware
configuration, not a hypothetical one.
While we might have moved faster if we weren't a volunteer organization, or
if more people had more time, I just don't see that we should have waited on
the software.
|
aruba
|
|
response 492 of 547:
|
Oct 25 01:10 UTC 2003 |
Well we tried waiting, for over a year, with the idea that we would install
the OS on two different types of hardware and then pick one. Nothing
happened. Last winter the consensus was that we should commit to Intel
hardware and buy what we need, because then staff would be more likely to do
something. So we bought it. We made some progress at first, but now we're
stalled. I'm glad cross is trying to jumpstart the process.
|
asddsa
|
|
response 493 of 547:
|
Oct 25 05:46 UTC 2003 |
Oh boy...time drags on...
re 489 There are dozens of reasons that show the current state is hurting
GreX.
|
cmcgee
|
|
response 494 of 547:
|
Oct 25 12:50 UTC 2003 |
Errr, last line 491 software=hardware.
|
jep
|
|
response 495 of 547:
|
Oct 25 23:26 UTC 2003 |
I agree with moving ahead if we were ready. I'm piqued that we spent
the money then stopped.
I'll raise another point, too. For years, there have been two people
who have been most adamantly against switching from Sun to Intel
hardware; Marcus and STeve. These are the two people who were most
needed to do anything new with Grex. I am on the outside; I'm not
involved with the process, but... these are the two people who have
stalled the move. Right?
|
