Discuss Jan's explanation of Nextgrex here.112 responses total.
Jan, thanks for a very clear and helpful explanation of what to expect from the next grex. I think Marcus told me recently that he had compiled Picospan for Nextgrex, but maybe he meant that he was still working on it. Anyway, the new features of Fronttalk sound really helpful. I have often wanted to mark some item 'new' without having to reread the parts of I that I already went through (such as mcnally's extensive Alaska postings, which I wanted to read at leisure the next day). Will Fronttalk let me mark some item as 'new' without it showing up when I do 'b n' or should I use postpone for that? How does lynx deal with sites that have no secure certificate? Lynx 2.8.5 complains when I hit a site for which I do not have the certificate, but what must I do to stop it from complaining? I hope Nextgrex will have 2.8.5. If I type lynx grex - does this automatically bring up the https version?
re #1...if Marcus has in fact compiled Picospan for NextGrex, should the decision to use Fronttalk be reconsidered? Or is it possible to give users the option of whether they want to use Fronttalk or Picospan?
Using Picospan on NextGrex would be like renting a phone from AT&T to use on your SBC landline. You can't make any changes to it, it worked fine in its day but the way the system is used now makes it obsolete from a feature standpoint, and just because we've been using it up 'til now is not a good reason to keep using it when the environment changes.
I think we should continue to offer Picospan. No-one would disagree with that.
I was out of the loop on that decision. There was a board meeting, Marcus was there (as a member of the board, I think) and the decision came out not to use Picospan. I think most of the Picospan users won't notice that they are running Fronttalk instead. I think a few bugs will be found, reported, and fixed, and then it'll be fine. I think the motivation of the decision was that Grex doesn't really want to be dependent on software it cannot modifiy. It is beyond Marcus's legal capability to give Grex that power over Picospan. I had understood that there was an OpenBSd version of Picospan, but it has never been installed on NextGrex.
Marcus hasn't been seen at a board meeting for a while.
This response has been erased.
The decision to go with FrontTalk was taken because FrontTalk was available to be installed and Picospan is not. (Note the switch in tense; 'tis significant.)
Picospan is available to be installed. (Note the lack of a witch in tense; 'tis significant.)
Note that the bitch is tense; 'tis very significant
'Its.
Indeed, mfp; indeed.
Even if it turns out that there are a few glitches in FrontTalk that need to be fixed, I think that the decision to move to it is a sound one. Even if PicoSpan had been ready to go on NextGrex, I'd favor switching to FrontTalk. PicoSpan has served conferencing well, but it's old architecture and we can't modify it. Time to move on. With software we can modify, we can experiment with improving the conferencing environment. I think that even Backtalk was hampered in that regard due to the requirement of compatibility with PicoSpan.
re #13, picospan-- surely Marcus has the source code and can modify it. I realize he doesn't "own" it anymore, but it is so old that why would whoever does own it even care? I mean who, besides grex, even uses picospan anymore?
Re. 13: Don't forget that change is not a prerequisite of activity; indeed, activity is a prerequisite of change.
But don't mistake activity for progress...
I wouldn't dare do that, KA.
This response has been erased.
I hope youstill have your rotary phone, ryan
re #18...how can grex get legal permission to use picospan if the company that owns it no longer exists? It seems to me that since it is not possible to get permission, the requirement to get it is moot. I mean doesnt a company have to maintain itself as a company in order to maintain the copyrights it owns as a company? I would argue that nobody owns picospan now, it is for all intents and purposes in the public domain, since the old owner no longer exists
Richard we don't need to -get- permission, we have permission to use Picospan, just the way it is. You would have to trace the disposition of the assets of the company to find out who "owns" Picospan at the moment. I doubt that anything with value was missed by the lawyers for the creditors of the company. You do not have to maintain a company, you only have to dispose of its assets, one of which is a copyright. Just because it is difficult to figure out who owns the copyright, does not mean that we can ignore copyright law.
you are assuming that something was done with the copyright. maybe nothing was done with the copyright and at some point in the future it is simply going to expire, and until then its own by a defunct company and nobody cares whether it is modified or not
As long as political winds blow the way they do today, copyrights will never expire; they will be good forever.
I've heard rumors that NETI assigned it's copyrights to some other company before it croaked. I don't know if that is the case though. If anyone would like to set out on a mission to figure out who owns Picospan, you certainly have my permission.
Do we NEED your permission, jan? ;-)
Yes. Without it any answer you find will be unauthorized. Marcus hasn't logged onto Grex for six weeks. I don't know what his status is, but I don't think we should be letting Next Grex wait for him to do something. Not that the general velocity of progress is so great that there isn't plenty of time for him to jump in if he takes a mind to.
I talked to Marcus at the recent memorial services (which STeve and Glenda
and other grexers also attended) and I am pretty sure he told me he had
compiled PicoSpan for Nextgrex but to make sure I wrote him.
Date: Thu, 14 Oct 2004 22:34:48 -0400
From: Marcus Watts <mdw@umich.edu>
To: Sindi Keesan <keesan@cyberspace.org>
Cc: Marcus D Watts <mdw@grex.cyberspace.org>, andres@msu.edu
Subject: Re: picospan
> There is a discussion going on in coop about whether you have compiled
> Picospan for Nextgrex and why you have not logged on for six weeks. Jan
> is planning to use Fronttalk instead unless he hears from you before
> Nextgrex is ready.
>
> Sindi Keesan
I built a copy of PicoSpan for nextgrex; STeve Andre has it
and I presume plans to install it post haste.
I've been way busy at UM for a while - and I've got several
other activities that have temporarily got most of the rest
of my free time. Never fear, I'll be back.
-Marcus
Cool. That's not the decision I thought I'd been told about, but I'm fine either way. One mode in which Fronttalk has not been fully tested is when used as a login shell. I did a little testing with that configuration yesterday, but not a whole lot.
I would like it if at some point (no particular hurry) someone made a final decision about Picospan. So far backtalk/frontalk on nextGrex is configured in the same 100% Picospan compatible mode as it is here on Grex. But if Picospan is not coming, then I'd like to be free to diverge from Picospan compatibility.
I'll make the final decision: We'll use Picospan on NeXtGreX.
STeve says he will be installing Picospan on NextGrex tomorrow.
Good to hear it.
Ugh. Why? Now we need to maintain compatibility with Picospan.
It's because I said it should be!
Why do we need 100% compatibility? Can't people just choose? Type bbs for picospan and something else for fronttalk. bbsf.
The problem is that backtalk (and therefore fronttalk as well) must now remain compatible with picospan. Fronttalk is already a nearly 100% faithful substitute from picospan; since we have that, why be constrained by the past?
That, of course, is a bad piece of rhetoric. We're not being constrained by the past. We're being guided by the present.
Would it be boorish / stupid to create a member vote about whether or not to break with picospan for NextGrex? If not, if it's reasonable to consider leaving picospan behind with oldgrex, then I'll create the vote item.
I don't think it's stupid. Why not let the user population decide?
Here's what I see as the plus and minus. If Picospan is installed on nextGrex, it will be the only piece of proprietary software on the system. We have complete source to everything else on the system, and the legal right to modify it as we wish. The only person who can see or modify the source code to Picospan is Marcus. Picospan is not under active development. I don't believe there has been any change to it's functionality in over a decade. Nor is there ever likely to be. Picospan is thoroughly tested and debugged. There is some tiny chance that some bugs will appear in the OpenBSD port, but I doubt it. Fronttalk is open source. In practice, the only person likely to be making changes to it is me, but in theory anyone at all could do so. The code is all available on the web for anyone to download. It is well documented with both internal comments and separate documents. Fronttalk does implement virtually everything that Picospan does. Just about every Picospan command you have heard of, and many you have not is implemented by Fronttalk. It reads the same .cfonce and .cfrc files. If you modified your iseps and rseps, they will work with Fronttalk. Fronttalk is a bit slower. The difference is mostly only noticable during startup on Grex, and should not be noticable at all on nextGrex. Fronttalk has a rather strange architecture. It actually consists of two completely separate programs - a client that reads commands from the user and formats output for display, and a server that manages the conference data files and controls access to them. The Fronttalk server is just Backtalk. Backtalk has been running on Grex for eight years, and hasn't mangled a single item file yet. This part of Fronttalk is well-tested and dependable. There is little chance that a bug in Fronttalk will result in something catastrophic, like deleting all the item files or letting users censor each other's posts. The Fronttalk client is a perl program. It has been running on Grex for two years, but so far as I know, I am the only person who routinely uses it. It has never been heavily used by a large set of people. I'm sure it has bugs. I even know of some that I haven't fixed yet (I've been pretty busy with installing other stuff on nextGrex). The "read since" command doesn't seem to work right. Prp recently reported a bug where if you join a conference that changes it's command prompt and then join another, the command prompt doesn't get reset right. I'm sure there will be other bugs similar to this. You just don't find all these bugs until you get a large set of users beating on it for a while. So if we switch to Fronttalk, there will definitely be a teething period. Bugs will be reported, and I will fix them in due course. Part of what Fronttalk offers/threatens is the potential to evolve the software. If Picospan is kept, it will not change. Backtalk and Fronttalk might change, but the need to remain compatible with Picospan will severely limit the kinds of changes that can be made to them. Backtalk already contains some very complex pieces of code that would be very simple if Picospan didn't exist. The more I have to maintain compatibility with Picospan, the slower continued development will be. It also has a few features that are turned off here on Grex because they would not be compatible with Picospan. It is likely to develo more. For example, one of my ongoing Backtalk projects is teaching it to mail out responses. The idea is that a user could choose to have new posts to selected items and/or conferences emailed to him. You'd be able to choose either to have a copy of each new response to an item mailed to you immediately after it is posted, or you could have periodic digests of the conference sent out to you. (I do not plan to allow people to post by sending email - instead each message would have a link back to backtalk that you could click on to put you back in the item so you can respond to it normally.) Part of the coding for this has already been done. Backtalk already has a very nice mail sending system built in. It can send either plain text messages or mime messages with both HTML and plain text versions of the same post. The mode where copies of responses are sent instantly when they are posted would be quite easy to finish off at this point - I need to maintain a database for each item listing what users want copies of responses sent, and everytime a new message is posted we just send copies out to all users who want them. Except this won't work if Picospan is still being used. Any message posted from Picospan would not be sent out. So instead I'd have to have a daemon process running in background periodically scanning the sum files for all the conferences to see when new messages have been posted, so it can send them out. Certainly this is doable, but it's much more complex. Backtalk already has the capability to handle items and responses with attachments. That means you can attach any random kind of file to any response - a text file, a Word document, an image, a sound file, whatever. Readers can see these by clicking on them. I'm not at all sure that this would be a desirable feature for Backtalk (the feature was added for another organization that uses Backtalk). At least I'd have to finish implementing quotas that would limit how much data people could post to the conferences. This feature is not compatible with Picospan because it requires changes to the format to the item files which Picospan would choke on, and even if I found a way to keep the file format compatible with Picospan (which certainly could be done at the cost of some extra complexity) Picospan would not show the attachments. These are just two examples that happen to already be mostly implemented. Get rid of Picospan, and many things become possible. This is, of course, not an unmitigated advantage. Not all change is good. It has to be done thoughtfully and carefully. But some changes are certainly good. I think the email thing would be great for Grex. It has several advantages. First, it would help us retain users. Right now, a user can get busy for a few months, forget all about his Grex account, and never come back. If that user has requested to be emailed new responses on an item they entered, then their attention is going to get drawn back to Grex each time someone responds. Chances are good that they'll be sucked back in again. Second, it can restore life to dead conferences. There are many conferences on Grex that get responses less than once every month. People stop checking in, even though they are interested in the topic of the conference, just because there is never anything there. So when someone new comes in and makes a posting, nobody sees it for weeks. The new person wanders off, and the confernece remains dead. But what if that new post were emailed out to a bunch of people interested in the topic? They'd likely come streaming back, and that new post would trigger a wave of activity. A dead conference comes alive. So the email feature is likely to improve Grex's ability to retain conference users, and thus increase the conferencing population, and it is likely to bring life to many old conferences, helping to reverse the trend for everything to happen in the 'agora' conference. Might even improve Grex's income. Or it might not. I'm only guessing. And I don't even know when I'll have time to finish implementing it. I do need to take time off now and then to change little diapers and earn a living. Picospan is a wonderful thing, but it is 20 years old and not going to change. It's an anchor. Anchors are very useful at times. But is this such a time?
I didn't know you could use a .cfonce file for fronttalk. Thanks, janc! I can't believe some people will talk about getting rid of picospan and RetroGreX in the next breath. it's just illogical.
How about using both Fronttalk and Picospan for a while (a few months?) until the bugs in Fronttalk are mostly caught?
Besides improved speed going with Fronttalk/Backtalk is the best part about making this transition. Pico is stagnant. It worked well for us for a long time but I'd really like to see what can be done with Grex on new software. I'd hope to give Jan's programs a few months and then, if folks are really unhappy, talk about going backwards, to Pico. But I doubt that will happen.
Sindi's suggestion is fine, but note that we've been running both Fronttalk and Picospan on Grex for two years. I use regularly. I'm using it now. (Actually, I'm not logged onto Grex - I'm running the fronttalk client on nextGrex to communicate with the fronttalk server on Grex.) Not many other users use it though, so I'm not getting many bug reports. Recently prp spent some time testing it and turned up some good bug reports. I'll have those fixed by the time we get NextGrex up. I can live with Picospan continuing to be here. I've been programming around it for years and I can keep doing it. But I do need to know what the plan is going to be. Once I get nextGrex off my lap, I hope to return to doing Fronttalk/Backtalk development, and the strategies I use depend heavily on whether I need to continue to maintain compatibility with Picospan.
I think that a vote would be premature; for folks to be able to make an informed decision, Fronttalk and Picospan need to run side-by-side for a while on NextGrex so that people can try them both out. If you haven't tried Fronttalk, something to keep in mind is that it looks almost exactly like Picospan and accepts practically the same command set. People wouldn't have to change their conferencing habits much, if at all, in switching from Picospan to Fronttalk. On OldGrex, the big downside to Fronttalk is its slower speed, but I suspect that this will be much less an issue on NextGrex. In any event, a side-by-side comparision on NextGrex would settle that issue. My personal view: We need a conferencing program to which we can add new functionality. Jan mentioned email notification for new responses as one such enhancement; I'd add RSS notification as well. I'm sure there are others.
How does one go about using FrontTalk right now, on the current grex?
I'd like to see us move on from Picospan as well. It's been a great program, for a long time. But it would be terrific if Grex could try new things.
At the moment, do picospan, fronttalk, & backtalk all manipulate the conferencing files in the exact same way, such that there is total data consistency? If so, the real question is whether to bother to try out the OpenBSD recompiled picospan on NextGrex or not. If it's all ready to go, then it need not be an either/or proposition. However, if there is a good possibility of bugs in OpenBSD-picospan, bugs that might not be fixable, then that is one good reason not to bother with it. Would a determination that picospan will not be used or supported on NextGrex materially help get NextGrex launched and foster improved support?
Re #46: To run Fronttalk on the current Grex, type ft or !ft, depending on your shell. I'm running Fronttalk right now and am using it to enter this response. First time I've tried Fronttalk in quite a while, and I was pleasantly surprised by the speed - it feels fast now. Maybe Jan made some code improvements since the last time I ran it? I notice some differences with Picospan - some of my customizations (e.g. prompts and response headers) work, and some (e.g. my twit filter) don't. Also, Fronttalk doesn't understand "l" as an abbrevation for "last"; that's easily fixable, I'm sure.
RSS is something I want to do, but Picospan isn't in the way of that one. All I need to do for RSS is respond to an HTTP request with a list of items presented in a specific format. Backtalk can do that easily. The hard part is the semantics. Which items should I list? How long do I continue listing items? None of this is terribly clear. However, Picospan is not in the way of doing RSS. Backtalk can handle it. It should be noted that the Fronttalk on oldGrex is an older version than the Fronttalk on nextGrex. It has some bugs that the current version does not have, but the ones John reports are new to me. But fixable. I'm fairly confident that Picospan will not be buggy under OpenBSD. Backtalk as configured on Grex has complete data consistancy with Picospan. Backtalk on M-Net has complete data consistancy with Yapp. Backtalk in other places is compatible with neither. Fronttalk doesn't access most of the data - it accesses Backtalk which accesses the data. It does interpret ".cfonce" and ".cfrc" files, which it strives to do in a Picospan compatible manner, but there are still bugs in this. As long as Picospan is running on Grex, I'll keep Fronttalk/Backtalk compatible with it. If it goes away, I'll keep a look and feel closely compatible with traditional Picospan for those who prefer that interface. But development of new features will become much easier.
Since Fronttalk is on grex now (that is, on the old Sun), why not do something radical and make it the *default* BBS program? Ie, when one types `bbs' one gets fronttalk. If someone wants to run picospan, then just invoke it via another name (eg, `picospan' is pretty obvious). We get the benefit of catching the major bugs now, perhaps fixing them, and the user population can get used to the new software (I suspect that for most that's going to be a nop) before we even switch to it. Comments?
STeve and I installed picospan today. It is currently what you get when you run 'bbs'. It wasn't entirely configured Grexishly - wrong path name for the /bbs directory, but that was fixable with a symlink. I'm slightly worried that there might be other configuration changes. I should probably spend some time figuring out what kind of file locking it is configured for so I can be sure Backtalk is still compatible.
I agree with John that a user vote on picospan versus fronttalk/backtalk would be premature: not enough of us have any experience on which to base a vate. My personal inclination would be to make the switch to fronttalk on grex, right now. However, I had a few problems with it a few minutes ago (which I've notified Jan of), so I can't in conscience recommend such a switch. I _would_ like to see us do so before migrating to the new machine.
Too late. We're locked into the 1970's forever now. :-(
No, we're not. If we can update the version of fronttalk on the current machine, I'd recommend disabling picospan on the new one. It shouldn't be more than resetting a few permission bits, after all.
Will the new Grex have the following: elm, lynx, pico, and pine ? Thanks. Ahmet Toprak
It will have all those things and more, Turkish Radio Hour.
Re #50: Hmmm... I can envision some things that one might want to do with RSS that could be difficult if you have to maintain Picospan capability. For example, a user might want to be notified whenever a particular item gets a new response. The obvious way to do that would be to associate an RSS "feed" (XML file in a particular format) with the item, the user would subscribe to this feed in their news aggregator, and the feed would be updated whenever a response is added to the item. I'd think this would be a fairly easy feature to add to Backtalk, but impossible to add to Picospan since we can't modify it. The result would be that the feed would be updated only when responses are added through Backtalk, not when a response is added via Picospan -- an unsatisfactory situation. Besides updating an RSS feed, there might be other "events" that we'd want to associate with the posting of an item or response - e.g. updating a search index, a database entry, things like that. As long as we support a response entry method that we can't modify, we're effectively prevented from doing that, and I see that as a big problem in the long run.
(Side note: If it's possible to have a process receive notification whenever a particular file changes, then RSS feed (or other) updating could be handled by a separate daemon program, and it wouldn't matter whether the file change was done by Backtalk, Picospan, or Aunt Fanny's Home-Grown Response Appender. But I don't know if OpenBSD supports that capability.)
The 'feed' doesn't have to be a static XML file. It can be generated by a
CGI. If backtalk is that CGI, it would have no problem generating a current
response list for that item in RSS format. including any Picospan responses.
Of course, RSS works by polling, so if lots of people are polling, this can
add up to a lot of computation. A static file would be more efficient, and
would not be possible while Picospan exists.
John mentions the idea of updating a database entry when a new posting is
made. This is another one that Backtalk already partially implements.
Backtalk is already capable of talking to an SQL server - it can work with
either MySQL or PostgreSQL. Code to keep conference sum files in an SQL
database already works and is being used at http://www.greatgreenroom.com .
Code to keep item indexes in SQL is partially implemented. Someday I may
have an option to move all the conference data into SQL. The advantage of
having indexes in SQL is that it becomes posible to make much richer kinds
of queries aganst the database. Like this would be a nice one:
Show me the 10 items on the system which have had the most responses
in the last 2 days from people who are not on my twit list.
Still, this could all be done while Picospan is around. When a new post
is made via Backtalk it would write to both the SQL database that it uses
and the sum file that Picospan needs. We'd have a background process
babysitting Picospan - it periodically polls all sum files to watch for
new items or responses appearing, and checks that they are in the SQL
database. If not, it runs whatever processes you want to have run when
a new posting is made. It's a little more complex than that, but it's
do-able.
The other area where Picospan is a problem is in item formats. If I
ever want to store more data than Picospan does, then I can't put it
in any of Picospan's files without making Picospan croak on it. I usually
solve this with parallel files. You you are a regular Backtalk user, you'll
find that you have two kinds of participation files - .agora45.cf is the
Picospan participation file. .agora45.cfx is the Backtalk participation
file, that contains additional data that would make Picospan choke. On
systems where there is no Picospan or Yapp, Backtalk uses just a single
file in it's native format.
So, I can always work around Picospan - but it requires substantially
more difficult programming and significant cost in efficiency.
As a supporter of Open Source, I'm all for switching to FT. We all know the problems of dealing with propriatory software, switching to FT will eliminate those problems, as Jan discussed. Those wanting to stick with PicoSpan, I'm guessing, are doing so not because they don't like Fronttalk (odds are, most haven't tryed it yet, myself included), but because it's familiar...comfortable. But like the saying goes, "familiarity breeds contempt," and in the fast- pace world of software development, that's something you don't want to happen. But because FT is so similar to PicoSpan, the learning curve should be pretty small, and the benefits are great. I remember when Apple announced their plans to drop ties to OS9 in favor of OSX. Everyone was up in arms for awhile. But once they got to know OSX, they not only settled down, but started singing the praises of Apple's decision. I think Grex should follow Apple's example: Let's start with FT on NextGrex, endure the "teething process" as Jan called it, and in the end Grex'll have a system that's stable, flexible and free of propriatary hooks.
Re #60: Performance issues aside, generating the RSS feed dynamically by a CGI (or PHP, some sites do that) might be the better strategy. That way you don't have to build an RSS "hook" into every piece of code that affects item status (responding, scribbling, retiring, etc.)
One does have to ask, though, if the extra programming effort and performance costs involved in maintaining Picospan compatibility are worth the gain. That's really the central question.
I'd say no. You'll notice that for every work-around Jan came up with, there was the issue of "complexity" or "significant time" it'd take to do these tasks. And again, history shows that maintaining compatibility with older softwere only drags things down. Apple realized this and only now is Microsloth catching on.
Re #56 (trh): Yes, NextGrex will have elm, lynx, pico, and pine.
What of MH?
It will have MH. Re. 65: Why'd you answer with an answer that was LESS informative than the one I had already given?
Regarding #59; For the record, OpenBSD *does* support the kqueue mechanism, which allows a process to monitor events such as you describe.
kqueue isn't so k-cool, though.
Thanks. I had glanced at the manpage for kqueue() but wasn't sure if it could monitor such things as file status changes.
Is ft current on m-net ?
I have no idea of the status of ft on M-Net. At this point, thanks to various helpful users, I have a decent sized list of bugs to fix in Fronttalk. But right now I am not working on things that I don't think are important to getting nextGrex up. With Picospan installed, Fronttalk ceases to be on that list. I'll be returning to work on Fronttalk after nextGrex is up. I think if I used kqueue(), I'd have to set up an event filter on every sum file on the system. It might be better than polling them, but it still isn't great. At least it is probably unnecessary to monitor every item file on the system. There isn't that much that Picospan does to an item that doesn't also result in a modification of the sum file. mfp is right again. NMH version 1.0.4 is installing as I type. There, it's done.
I don't even know what NMH is! Oh well.
An open source version of MH.
(MH being the Rand Mail Handler.)
(Message Handler, actually, as it has some facility for news and stuff broader than e-mail, mostly from the pre-NNTP days if I recall.)
re 72 If the current version of ft were installed on m-net, you could recieve infinitely more bug reports!
When was the equipment for NextGrex purchased?
May, 2003, IIRC.
May is the date when we had all the hardware assembled. Most of the purchasing was in March and April, 2003.
Hm. So it's been a year and a half and we still can't get the thing up.
Yep. Is this news to you, Dave? Maybe you haven't been around Grex much the last year or two? Mostly, after you've gotten over the shock of the situation, I'm anxious to hear what you'd like to do the address the problem. I bet our unpaid volunteer staff is looking forward to your suggestions too.
I would like to see a clear list of remaining tasks, with a rough idea of the staff time needed to do each one, and the order in which they should be done. The Board should then set deadlines for the staff to accomplish each one. If the deadlines are not met, then the Board should pay outside people to finish the tasks. Right now we have plenty of money and no NextGrex. I would much prefer slightly less money and having NextGrex up. Otherwise, if the downward spiral in memberships continues, we will have no money and no Grex at all.
We don't have the kind of money people charge commercially for doing this kind of thing.
Grex does not have the financial leverage to assure any sort of longevity for itself, and trying to force it, or wish that leverage into existence will only alienate the human resources (in lieu of financial ones) on which Grex's continued existence and functionality depend, and thereby shorten its lifespan.
I must point out that our present human resources have not been able, so far, to insure Grex's continued existence by getting NextGrex up. Since the human resources haven't done the trick, I think we should consider using our financial resources. We have a large pile of bucks in the bank. We should use a few of them. John, how much money would you think is needed to finish what needs to be finished on NextGrex?
I just tiptoed through the minutes. In April, 2003, we spent over $1500 on the basic hardware for NextGrex. Most of this was raised in a special fundraiser. As of October 31 of this year, we have $3403.50 in the bank, with $3146.96 of that in the general fund. I think we should spend some of that. Otherwise, the money that people raised (and spent) for the hardware will not result in any benefits for the users, for the foreseeable future.
Dave, I think you responded to #85 WITHOUT READING IT. Grex has a little money socked away, and using it to get done properly just about any of what is needed to get NextGrex up would be financially irresponsible, in a very M-Net sort of way. [Commenting on past history, not personality.]
Our best hope for achieving progress is to encourage our volunteer staff, to publicly and sincerely appreciate their efforts, and not to denigrate them for having lives which demand that Grex be a lower priority for them than other things.
I agree with Dave about this. I think Eric misses the point that M-Net is a reliable system with plenty of human resource keeping it running. Grex isn't in such an agreeable condition. For whatever reason, Grex is lacking any sort of dedicated staff beyond Jan in regards to NextGrex. It would be irresponsible to NOT get some assistance via capital, imo. Why is Jan given the burden (and at the same time the liability if the old Grex were to die)?
old GreX is dying with its competent staff.
I think we should separate two different staff functions. One is the normal maintenance, which our staff can handle. The other is the once-in-a-decade job of setting up a totally new system, which our staff has not been able to handle. So I suggest that if we have to, we "open the sock" and use some of the money we have squirreled away to finish the NextGrex job.
At any time when you're thinking about our "sock" you need to consider what is really available for use. Whatever funds we'd need to close Grex and pay off existing obligations (lease and DSL contracts come to mind) should be subtracted and not be considered spendable. That's a considerable chunk of change. Then you have to consider keeping some funds available for hardware emergencies. Even NextGrex doesn't come with a warranty anymore. Something doesn't work, we'd need to fix or replace it. If the problem means we can't get online then fundraising gets mighty tricky. Let's be responsible and not go there. What's left you may be able to spend toward NextGrex technical support. All three hours of time if we could get it cheap.
Jan said he'd be back and finish up the project. He isn't obligated to do this. He probably isn't even motivated to do this. But he said he would and I'll take him at his word. I think Grex is going through some changes right now and there are some not so subtle signs of it all around. Not sure how it will end up. But I do know that whatever corrective measure we take should be pretty well thought out and not simply venting or we could end up making it a whole lot worse.
I don't think there are a straightforward set of tasks which could be given to a software contractor, who could then set a price, perform those tasks, and have NextGrex up and running and ready to replace the old Grex. I also think that, once the new system is running, there's an amount of maintenance which will remain -- tweaks, adjustments, fixes, reverses of direction, and so forth. I don't know what dpc expects it would cost to hire someone to "finish the job". I work for a software company, who charges $1000 per day (and maybe it's $2000) for contracting for the software we built and sell and maintain full time as our livelihood. If Grex could hire an individual for $200 per hour, and that person could do NextGrex in 6 weeks, it'd probably be quick work. That'd be what, $48,000? Maybe dpc is thinking there are college students who could do it for $10 per hour. College students with a vision of Grex, who are trusted enough, and have the programming ability and system knowledge and commitment to do this kind of work -- well, if they're out there, it'd be great were they to speak up.
I bet there are some folks on Arbornet's staff that could be outsourced to Cyberspace Communications. How much money you got in that sock? >:)
I did some back-of-the-envelope calcuations today. I charge $60/hour. I think it took Jan something over 50 hours to get where we are, and there are probably close to that many hours' work left to be done. (The list is a response referenced in the most recent "BoD Agenda" item.) 50x60=3000, which is what we have. BEFORE subtracting out the obligations Mary listed.
If it will take a while to get NextGrex up, then it will take a while.
DOing so is some serious skullsweat, and the amount of effort expended so far
is Deeply appreciated, at least by me. You do understand that FUnctioning,
and rock solid stable are completely different things right? We've got PLENTY
in the way of existing SKILLED man-hours in Grex-as-it-is, and there's
likely to be significant software issues in the shakedown, initial public
usage phase of NEXTGREX.
If you know wherwe you are, it's at least slightly easier to figure
out where to go next...
Item 105, Response 277 gives Jan's description of what is left to be done.
Whoa. The fact that someone as IGNORANT about system administration as gelinas charges SIXTY DOLLARS AN HOUR is outrageous.
re #97 That's a great point. I wonder how many people on Grex staff "write off" their volunteer time?
Whoa. The fact that someone as IGNORANT about how to function as a human being as is the author of #100 STILL BREATHES is outrageous.
60 bucks an hour is outrageous, yes.
Yeah - way too cheap. Being in business is expensive. $100/hr is more realistic.
You're obviously talking about people who have services to offer.
My standard rate is $120/hour. I consider myself a bargain. I should be charging more. Lots of people do similar work for lower rates. I'm pretty often hired to fix their messes. What I am expert at, however, is software design and development, not system configuration or system administration. I come to tasks like configuring exim on nextGrex with *NO* experience, *NO* special knowledge, and virtually *NO* interest. I do it by reading the manuals and figuring things out from scratch. It's a mystery to me why anyone thinks I'm the only person who can do this. It bothers me that I'm even being trusted to do this - it'd be nice if someone with some experience were looking at what I was doing. I think I'm doing OK, but I'm well outside my domain of expertize here. Not only don't I really have any expertize at this stuff, but I don't really like doing it. I do just enough work on my own systems to keep them barely functional. I'd rather be designing and developing new software. There is a lot about the way the Grex community and the Grex system work these days that I don't like. I have about eight ideas for software changes to Grex that I think could make Grex a better place. I feel like I have to get all this nasty system configuration junk out of the way before I can do any of it. It's a big hunk of work. And I'm just not sure how much I care about Grex these days. How much effort do I want to put into this place? Why am I putting so much effort into something of such dubious relevance to anything? Wouldn't it have been more worthwhile to say, work on the Kerry campaign instead of nextGrex? Once Grex was an idea we thought had a future. Now it's just the trailing edge and the future is happening someplace else. I used to care a lot about the community, but I'm finding the level of incivility around here has risen quite a lot, and my willingness to endulge it is has fallen quite a lot. The fallout from Valerie's departure has also had an impact. At this point, any mention of my personal life on Grex is going to be greeted by all sorts of self-rightous jibes aimed at Valerie, which I am not interested in hearing. I get enough of those even when I don't mention Valerie. So I no longer say anything about my personal life on Grex. If I had another child, I would not announce the birth on Grex. That means Grex is just not a central part of my life any more. I've been moved to the fringes of the Grex community, if there still is anything you'd call a community on Grex. So from what well do I draw motivation to work on this system? I did the backtalk RSS stuff because I was interested in figuring how to do RSS stuff, and Grex made an convenient arena to try things out on. I was happy to see the board's decision to move to co-location. Seeing other people make an effort on Grex's behalf does help inspire me to do the same. The general lack of anyone doing anything rather saps my energy. I'll try to get some more work done. There isn't really that much left to do. Just all those "last few things" that always seem to pile up at the end of any project.
Thank you janc for your candor. On the assumption that you were one of the pillar's of grex's inception, it's sad that you have lost your warm feelings for grex. But things change, I guess. Thanks for putting the effort into nextgrex when we'd be hard-pressed to understand why you'd make the effort. Others who still have "that loving feeling" for grex who are able to carry out nextgrex should pick up the mantle from janc.
Thanks Jan, for all your work. I still care about Grex, even though I haven't been abole to muster the energy to do much lately.
I wasn't a pillar of either Grex's inception or M-Net's inception. I have had quite a lot to do with the development of both.
Stallagtite, then. ;-)
Stalactite? Stalagmite?
TROGG IS DAVID BLAINE
You have several choices: