|
|
| Author |
Message |
| 25 new of 547 responses total. |
gelinas
|
|
response 461 of 547:
| 
Oct 19 05:50 UTC 2003 |
There is a change in object file format with the next release, if I've
properly understood the discussion. We (staff) have been discussing
when to make the switch, with most wanting to wait for the release that
includes/requires it. So November 1 sounds like a good starting point
to me.
I expect this to be a significant part of the agenda of Wednesday's
staff meeting.
|
gelinas
|
|
response 462 of 547:
|
Oct 19 06:24 UTC 2003 |
On expiring passwords: ssh does not work well with expired passwords.
Blanket expiration of all passwords would cause a lot of trouble.
|
mary
|
|
response 463 of 547:
|
Oct 19 12:05 UTC 2003 |
I'd like to respond to the earlier thread, of how we've gotten to the
point that the move to New Grex has stalled. Because I'm going to name
names and be pretty straightforward here, I'm going to be very clear this
is my opinion and I could be dead wrong on a lot of it.
One of the things that makes Grex so cool is that we are the sum of
volunteer effort. It's also a problem as there really isn't anyone to
call on the carpet when project goals slide. And not only are we
dependent on volunteers but a very few pretty much call the shots for how
anything goes. Partly this is out of respect for their opinions, partly
it's because if the wrong decision is made they are the ones who will have
to clean up the mess. But there is something else working there too, that
I can't quite put into kind words, but it's working against the system as
a whole right now. It can be seen in the difficulty our staff seems to
have working as a team.
We are all at fault for allowing one or two people to be so central to
Grex's future. It's my understanding that Marcus is under a lot of stress
at the moment, dealing with family issues. Been there, done that, but I
was fortunate not to have a community of thousands breathing down my neck
to simultaneously keep their project growing. If Marcus is holding things
up right now it's not Marcus' fault. It's our fault for letting *any one
person* be in the position of being that necessary.
So, where I'm going, is toward a shift in philosophy. We need to not only
move Grex to new hardware but to a way of working that fosters teamwork,
uses software that is team customizable, and where any one person could
walk away and the rest of staff could pick up and carry on. It's way time
this should happen.
I don't think Picospan is going to fit that goal. I'd like to take a
serious look at software that would. It's scary, for sure. It probably
would mean we'd not be too happy until we'd had a chance to mold it to our
specific needs. But the point is we could mold it and the staff and users
would get to decide how. And we'd be far far less dependent on one
person. A win/win after the agony of working though the change.
I'd also like to applaud Jan and other staff, who are working hard to
document exactly what they are doing with New Grex, and looking to
standardize as much of the hardware and software as possible. They are
looking out for us.
|
jep
|
|
response 464 of 547:
|
Oct 19 13:23 UTC 2003 |
Mary, in my opinion, that came off as both tactful and straight. I
don't think I've ever managed to do both at the same time. Nice job.
|
aruba
|
|
response 465 of 547:
|
Oct 19 14:29 UTC 2003 |
I basically agree with Mary here, and like everyone I am frustrated that we
haven't moved forward. I'd like to see some input from more staffers.
|
cross
|
|
response 466 of 547:
|
Oct 19 15:05 UTC 2003 |
Well, there is another issue at play. Replacing Picospan is fine with
me, but what are we going to replace it with? An old version of YAPP is
available in source form, but even mnet doesn't run that, and there are
no indications that it's completely free (as in not paying for it), or
that the new version is available in source form, free, or that we have
any chance of getting a license for it without paying many thousands
of dollars. What alternatives do we have? Is frontalk there yet?
That's the *only* reasonable alternative if getting YAPP doesn't pan out.
|
jp2
|
|
response 467 of 547:
|
Oct 19 21:17 UTC 2003 |
This response has been erased.
|
cross
|
|
response 468 of 547:
|
Oct 19 22:30 UTC 2003 |
What's the email address? I'll send a message asking, but I'm not
convinced it's the right direction.
|
jp2
|
|
response 469 of 547:
|
Oct 19 23:49 UTC 2003 |
This response has been erased.
|
cross
|
|
response 470 of 547:
|
Oct 20 01:09 UTC 2003 |
Okay, I sent an email to that address. We'll see what comes back.
|
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.
|
