With no great particular pleasure, but in hopes that it might make for a "better" or "more efficient" NextGrex, this particular member proposal is put forth: Picospan will be neither ported to nor supported on (nor even allowed to run on, if necessary) NextGrex (OpenBSD). Fronttalk will be used instead. When possible, an as-close-to-Picospan interface to Fronttalk can be provided, if users so desired. Discuss, suggest wordsmithing, etc. Also note that in order for this proposal to be brought to a vote at the appointed time, it must receive "support" from at least 10% of the members.105 responses total.
I support this proposal, with some sadness, since Picospan is such a wonderful program, and has really allowed Grex to become a community.
So, if this proposal fails, does that mean staff is compelled to make it work, or what?
No. The failure of a proposal doesn't imply anything.
The phrase "as-close-to-Picospan interface to Fronttalk" doesn't make sense -- Fronttalk *is* a Picospan-like interface, by definition. What it's an interface to is Backtalk. If I remember what Jan said elsewhere, Picospan has already been installed on NextGrex, so the first point of the proposal is moot.
As I said elsewhere, I think a vote on this issue is premature. I'm also a little uncomfortable on principle with dictating the use (or non-use) of particular named software products via member vote. It smacks of micromanagement. I'd prefer to trust the staff to (1) be on top of the technical issues, and (2) maintain open dialog in this conference and be sensitive to what the users (not just the members) want.
That said, I think I could support a proposal stating that it's the sense of the membership that Grex should continue to support a Picospan-like text-based conferencing interface and that the supported conferencing software should be open-source. (Three responses in a row from me, so I'll shut up now.)
Slip.
I'm with remmers on this. I'd endorse a proposal to move NextGrex to open source software wherever technically feasible, unless users provide compelling reasons why the proprietary software should continue to be supported. In those cases, I'd support a decision to do whatever the staff feel is best within the limitations of their willingness and ability to support it.
That's not what remmers supports. You're not with him.
I guess what I don't like is for years to have heard "that's the way Picospan works, and we can't change Picospan". I will post a modified proposal.
"Picospan will not be used/supported as the text-based conferencing software on NextGrex (OpenBSD). Fronttalk will be used instead, already having the functionality and "look and feel" of Picospan, but also with the ability to be extended to provide new functionality in the future."
I can't support that one, for the reasons stated above.
Open Source: Yea! Propriatory: Nah!
aruba/remmers: What is the magic number these days required to allow this to come to a vote?
Kevin, why are you rushing people to vote for something before they have even had the chance to see it in action? Back off, let's see how New Grex works as Jan sets it up, and go from there.
It sounds like janc is putting a lot of work into NextGrex right at the moment, and deciding this may (or may not) help. I asked, didn't seem to make a difference. *You* back off. You don't like the proposal, now or later, don't vote for it.
The rule is that for a proposal to come to a vote, 10% of the membership must (in this item) endorse bringing it to a vote. The proposal expires if the necessary endorsements are not retained within 30 days. According to the !members command, there are 70 current members, so the magic number of endorsements is 7. I'm not sure if the !members command reflects all recent changes in membership, so Mark should supply the authoratative figure. The minimum time frame for member proposals is: minimum of two weeks for discussion, followed by voting over a ten-day period. Hence the earliest this could be decided is a bit over three weeks from now.
(That should be "obtained", not "retained", in the third line above.)
I think it's an interesting proposal, certainly not a nuisance proposal. I probably won't vote for it... but I will endorse bringing it to a vote.
The members group is up to date.
Froom what I've heard from Jan, we are likely to be on the new machine before this comes to a vote. I would like to see us move from picospan, much as I like it. I'm not sure this proposal is the way to accomplish that transition, but I prefer this proposal to one requiring picospan. I am not ready to formally endorse this proposal.
For technical and support reasons I prefer front talk become the primary, officially-supported conferencing technology and I am somewhat sympathetic to what I believe is Kevin's intent in proposing this That said, I do not support this proposal. The implied premise that picospan has been the roadblock to nextgrex going live has nothing to do with reality. It was the other 99.9999% of the systems work, lack of staff time and motivation that have been the principal factors hampering progress. I also think it unnecessary legislate that a picospan like interface be provided when it already exists in front talk (along with a web interface and perhaps in future, others such as rss). What urgent problem are we trying to address by "requiring" a state affairs that aleady exists? I also don't like the precident of legislating specific technical implementations to staff which to my mind should be a determined on the basis of technical merit and/or support costs. To my knowledge we have limited formal policies about technology to those that have a direct, negative legal, economic or security impact on the system. Beyond these specific areas, we avoid creating too many rules that might otherwise interfere with our educational mission encouraging grex to be a place where folks can learn and play with unix and programming. Specifically forbidding picospan or down the line some other alternative interface to the conferencing system for no particularly good reason goes against the spirit of that mission.
(Joe slipped-in...)
Ah, but this is not strictly about technology, as you well know, so please don't trot out any slippery slope notions. This is not an ignorant member trying to decide by vote OpenBSD versus Linux. This is a clear case of a primary piece of software which is the window into what is supposed to be core to grex's mission, conferencing in support of a cyber community. And we have a situation where one version of the software that enables conferencing is stagnant, trapped in time, never to emerge (Picospan). NextGrex may be the perfect opportunity (or may not) to formally go in another direction, since there is an available equivalent alternative. I didn't dream up this notion, or have it come to me serendipitously. janc's notes about his work on NextGrex brought this issue into clear light at this time.
i'm curious if anyone can explain how switching to fronttalk is in any way likely to bolster the quality of bbs's content.
Shouldn't this decision be put off until we hear from Marcus on this? It is his program and Grex may not have existed without him or it in the form that we know it. I'd think that if he wants to update the source code and put it on the new system, grex ought to use it. Which doesn't mean that fronttalk couldn't be used as well. But grex just tossing picospan out the back door like a piece of garbage doens't seem right.
I think staff should organise a counter-strike move that goes against the member's wishes.
Grex is turning into a nanny-state. Just put both on and, if no-one uses picospan, delete it later.
I don't care if picospan is on the machine as long as it's *not* the default, and as long as plans are in place to either (a) get it open sourced (I can't believe that'd be terribly difficult at this point) or (b) get rid of it. Regarding #26; Marcus has been largely MIA on NextGrex work. Despite the fact that he's made major contributions in the past, his is not the only voice that counts. I object to the idea that we have to do whatever Marcus says just because he wrote PicoSpan.
I concur. I just don't want NextGrex to continue to be fettered the way oldgrex has been because it needed to restrict new development or innovations to always be compatible with Picospan, which couldn't/can't be changed.
It's not going to happen.
Ya wanna elaborate on what that "It" is?
I do feel it is best for Grex to transistion to Fronttalk, or another non-proprietary picospan-like interface. (No other non-proprietary Picospan-like interfaces now exists, but it would certainly be possible to build one. Fronttalk's architecture is a bit weird. With open-source Backtalk code available for use as a reference or cannibalization, it wouldn't actually be awfully hard to build an open-source picospan clone with a more traditional architecture.) However, given that Picospan arrived, I think it best to stick with it for the time being. All the major tasks for getting nextGrex have been done. All that's left is a few smaller tasks and some more testing and debugging. Having Picospan on hand now means I don't have to put any time into Fronttalk debugging. This gets us to nextGrex faster, and ensures greater stability in at least one essential piece of software. After we are up on nextGrex, I'll fix everything on my current fronttalk bug list, and I'll ask people to "take the fronttalk challenge" - alias "bbs" to "ft" and see how it goes. If I can get a decent population of test users, we can get fronttalk a bit more stable and get it into a state where nobody will regret the change when we do eventually drop Picospan. That's what I see right now as the ideal scenario. Decouple the Picospan question from the nextGrex project. Get more people into Fronttalk to test it out more thoroughly. Don't switch until Fronttalk is ready.
Sounds sensible.
#33, sounds logical enough. This will give people a chance to compare the two programs, and then there could be a vote, using the !vote program, on which to use. So when is the grand opening day for NextGrex going to be, theoretically, since you won't need immediate time to debug fronttalk>?
I predict we're now stuck with picospan forever.
I hope not. I too wish Picospan had not made it onto the new machine. But I'm so greatful for what Jan has done to this point, and, quite frankly, amazed he has been able to dedicate the needed time, that I feel greedy asking for FrontTalk to be ready for prime time on NewGrex launch. Whatever he can give us is more than we would have had. A huge thanks, Jan.
Until I read Jan's #33, I was about to change my mind and endorse bringing this proposal to a vote, despite my reservations about the particulars of the wording. Perhaps now it's moot, and from #34 it sounds like Kevin is withdrawing the proposal. I agree strongly with Jan that for our primary mission of computer conferencing, we need to replace the current proprietary software, which we cannont modify, with software whose source we control. In my view, it is indefensible that *for our primary application*, we are running software that we cannot modify, or at best can be modified by one particular person. In another item, Jan has laid out very clearly how this creates a problem by complicating software development. I'll go one step farther and say that it stifles innovation. I'll note that several staff members - Jan, Dan Cross, and myself - have presented arguments for dropping Picospan in favor of non-proprietary software. *NO* staff member has presented any arguments on the other side. If there are staff members who feel that staying with Picospan is the best course for Grex, I would greatly appreciate it if they would share their reasoning here, in the conference. I hope that when NextGrex is up, the course of action proposed by Jan in #33 is diligently pursued.
I predict that it won't happen. Once the machine is up, Picospan will be ``good enough,'' and there won't be any incentive to replace it. Yeah, sure we can do all this high speed stuff with the fronttalk/backtalk combo, but we could have done that now, on the Sun4, and didn't.
I haven't withdrawn this proposal - yet. But let me ask this: What will it take to decide and carry out the decommissioning/removal of Picospan from NextGrex in the (not so distant?) future? Can staff just do it, if they agree? Baff? Da board? Or must users - members - approve the action? The answer to this policy/procedure matter will dictate what I do with this particular proposal.
I think Dan's prediction will not come true. Yes, there is always reluctance to change from a known piece of software to an unknown one. I not only expect resistance to change, but respect it. However, I strongly believe that Grex's conferencing software must evolve, and will continue to press for that. I've sold bigger changes than this to the Grex users, and I can do it again. I would never simply go out and replace Picospan with Fronttalk. I would always discuss it first, listen to reactions, see what I can do to accomodate people. Heck, that's 90% of what Fronttalk is. I didn't really have a burning desire to write a clone of a 1980's conferencing system - I'd much rather be designing a conferencing system for the 21st century. But I recognize that people want to keep their familiar interfaces. Fronttalk has the potential of preserving the familiar interface while enabling new development. It's all about keeping people who like Picospan happy, and if it doesn't do that, then it needs fixing, and I'll fix it. (The other 10% of the reason for writing Fronttalk was the fun of the design - hiding a client/server architecture under the skin of a old monolithic program, transmitting Backtalk into a server for something other than web-browsers, and even the way rseps and iseps are handled by translating them into Perl functions at load time and just calling the functions each time we need to print them. I couldn't get into cloning Picospan until I thought of a way to make it semi-cool under the hood.) If it comes to a vote, I'm OK with that. But I don't want to switch to Fronttalk just because a majority want it. I'd really like to get it to a state where virtually nobody really objects to it.
Can anyone name a single advantage of using Fronttalk?
Since we are going to be re-building the new grex machine at regular intervals, it seems likely to me that at one of those rebuilds, in the not too distant future, we'll simply eliminate picospan. By that time, it's possible that almost everyone will already have migrated to fronttalk. One way to facilitate that migration is to configure newuser to default to ft instead of bbs. Or maybe for everyone, by adding an alias to the system-wide cshrc file (as, I think, has already been suggested).
Can anyone name a single advantage using Fronttalk has over using Picospan?
Yes: It avoids the telnet queue.
That advantage is present even when it's with Picospan, though. I'm looking for reasons for getting rid of Picospan and replacing it with Fronttalk.
Why would anyone want to be on Grex if they aren't running BBS in text mode with a terminal?
Re #46: For reasons to get rid of Picospan, see item 201, response 40.
Re: #47
Tod, of course it's 'party' - run in text-mode monitor
(which should be amber or green).
Hmm, or lynx? or pine? - nah, it must be party.
the question is whether it should be a staff decision when the time comes to get rid of picospan, or whether it should be a member decision. I think that given how long grex has used picospan, it should not be a staff decision alone
It's been proven that the staff can't control their own actions when it comes to the text the members write; so how are we supposed to trust them with the SOFTWARE that the USerS usE to WRITE the text; in the 1ere; 1st place ?
Because you are already trusting staff with the software the users use to write the text. Picospan and Backtalk are both written by Grex staff members.
nonononon, janc. PICOspan, although it was written by a GreX staffer long since lapsed, has been tried and true; and therefore trusted. However, fronttalk has not gone through such rigorous testing; and we cannot be sure that it may find the need to delete text that certain users write. How often, janc, have you left your computer running to go get your daily cup of Earl Grey tea with lemon, with the potential fact that Valerie might just be tempted to inset some code on her own? Frankly, albaugh (esq.) has not foundthe need to be concerned about such matters, but the rest of the GreX public MUST make a decision for themselves, and this item is where it's at. Please let the word bespoken.
I think Jan should stop drinking Earl grey tea wtih lemon.
Until/unless someone answers my inquiry of how Picospan would be retired in absense of a member vote, I'm pressing forward with this proposal.
Not according to janc's website, you aren't. The matter has been decided for you.
I prefer my Earl Grey with with dose of gasoline, preferably lead-free. I ignite it just before drinking. Clears the sinuses. It's great. Trust me. And if you don't trust me, then who you gonna trust?
Point.
I'm not sure I understand your comment in #55, Kevin. What, exactly are you looking for? Personally, I'd prefer a general concensus, preferably expressed by measured diminishing use, that it were time to move away from picospan. I fully expect such concensus to be reached, and implemented, in the first eighteen months after the migration to the new machine.
re 57 It's VALERIE that I don't trust, jan; your dear wife.
I say go with the open source stuff with the most support since staff support is obviously the biggest hinge around here on the old stuff.
Does russ cage fit into the Old Stuff category ?
!telnet grease.cyberspace.org Trying 216.93.104.38 ... Connected to grease.cyberspace.org. Escape character is '^]'. OpenBSD/i386 (grex.cyberspace.org) (ttyp2) User not authenticated. Using plaintext username and password
grease it up
The "grease" name is actually a leftover from the previous machine that used that IP address. We had another sun set up as a clone of Grex to do software development on for a while. It was called "grease". That machine died years ago and nobody cared enough to fix it. NextGrex inherited it's IP address, and thus the name too. I guess it's not wholely inappropriate.
Updated proposal wording: ----------------------------------------------------------------------------- Regarding the NextGrex (OpenBSD) text-based conferencing software: Picospan will be phased out and made unavailable as soon as practical. Fronttalk will be used instead, already having the functionality and "look and feel" of Picospan, but also with the ability to be extended to provide new functionality in the future. ----------------------------------------------------------------------------- And if it wouldn't be seen as overly prescriptive, I could add the following: To aid in the rapid transition to Fronttalk, the new default conferencing shell will become Fronttalk, and using the "bbs" command will cause Fronttalk to be invoked.
What's wrong with NextGreX.cyberspace.org ?
SLIP
Point.
Nothing, really, but traditionally, our machines have been given names that begin with "g".
Point.
How about grease.nextgrex.cyberspace.org ? There's just no Point in calling it NextGreX if it's really called "Grease"
Point.
The old interface to bbs would be picospan?
Point.
Point.
Point.
Point.
Point.
No point
Well, there have been 2+ weeks of discussion about this item. Have 10% of members supported it going forward to a vote?
I only count 3 endorsements in this item - albaugh, aruba, and scott. It needs 4 more to come to a vote.
Why bother?
I endorse.
So, whatever happened with this? Not enough people endorsed it? Now, apparantly, a decision has been made.
I'd really like to see us get away from Picospan. But you know what? In this case I think the ONE and ONLY person doing ALL the work gets a really strong say in how it goes, at least for the next chunk of time. If Jan says Fronttalk isn't ready, and he is going to focus on getting NextGrex up first, that's just fine by me. But hey, don't let that stop you from complaining about HIS effort. It's the Grex way.
This response has been erased.
mary, if you would really like to see us get away from picospan, express your support for this motion, and get a few other members to do so, then it can be brought up for a vote, and maybe the membership will descide "out with picospan".
Mary, you really have a way with words.
This response has been erased.
If you ask John nicely, he'll tell you about some other things she really has a way with.
I cannot in good conscience endorse this proposal in its current form. I would endorse a proposal to switch to fronttalk as the default interface keeping picospan available until such time as there was consensus that the fronttalk interface was as robust and stable as the picospan interface and then disabling picospan, but I feel that the current proposal is too abrupt given the current state (according to its author) of fronttalk.
I agree.
It's a bit late now.
Right - the proposal passed the 30-day expiration limit some time ago. Anyway, Picospan on NextGrex is now a fait accompli.
I translate this item (205) and item (105) as: Janc is doing all the work so tough shit if there are other volunteers or other preferences from members. Too bad the governance of Grex (despite claims of an online democracy) obviously hasn't changed any in over a decade. With that, I say, nice work Jan. The system runs very fast.
Am I being cast as the villian who is preventing Grex from moving to Fronttalk by exercising my defacto monopoly on system configuration decisions? Impressive what you can see through the power of the Force, even with the blast sheild down.
It was efficient and painless. I applaud the entire process. I could see the migration being bogged down at the cost of continued debates. On the contrary, I see the villains as the folks that can't appreciate that Grex got here in short order with minimal cooks in the kitchen. M-Net has sort of a similar philosphy in "monopoly on system configuration" by giving Rex the sysadmin keys to the kingdom.
Jan, thanks for making a few decisions needed to get the new grex running this week. Hopefully the more important bugs will all be squashed in the next few days by you and other helpful staff and non-staff. I really appreciate the quick fix of procmail.
Regarding #97; I don't think so. I think tod was blasting Mary a bit for being snappish. Regardless, what's done is done. Now is the time to work on remaining problems and new functionality, not focus on dead debates. I think we all had our biases and preferences with making this move. I know I debated mine heatedly because they were what I believed were the best way to do things. But, that's rather a moot point at this stage in the game; we've got the system we've got, and it's a good one for the effort that you primarily and others put into it; I know I'm happy and excited, and I assume others are as well.
I'm elated at the response time from the system. Lag is absent.
It's almost as fast as m-net, right , tod?
Let's not get ahead of ourselves!
Indeed, let's keep 'em slow and steady.
TROGG IS DAVID BLAINE
You have several choices: