valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 2004 Valerie Mates valerie Jan 8 05:10:55 2004 Val valerie Jan 8 05:10:55 200454 responses total.
This response has been erased.
If you want more excitment, find a way to stick people into interesting conferences when they join. That why I fought hard on m-net, & to some extent here, to have "general" or "agora" be the default. What I think would be even more interesting, and something I've always wanted to try, is to have newuser read through what people say interests them, and generate a .cflist file of conferences. Generating more publicity, and getting grex better known, could mean a *lot* more people, and a lot more demand for the system. How do people feel about having 200 people on at a time on grex? Are we ready to think about issues such as running out of UID space, kerberos, Solaris 2.6, DFS, etc?
What I'd like to see most is more conferencers. I think that will result in more members, which is what I would like to see second-most. In order to pay for a lot of things Grex would like, we need more members. Period. (Oh, I suppose we could search for alternate forms of income, but I hope we don't do that, because if we become dependent on such sources, then we become beholden to them.) The way to get more members is to have more content, in my opinon, though perhaps we can make more of an effort to get regular Grexers to become members.
Let's get the new Sun up and running. Since this obviously isn't going to happen "short-term," I assume it fits under "medium-term." Once we do that (or even sooner), I would *really* like to restrict all the folks who use us as a remote mailer somehow. There is no easy way to do this, I know.
With Valerie, I would very much like to see mail limited on Grex, so that it doesn't hog all the resources, especially the link.
Re:valerie's issue #4: I know next to nothing about computers, and have very little money, but I *would* like to help out somehow. In the past, I've felt kind of guilty about using grex so much and not becoming a member, but I really can't afford it. What can I do to help out that doesn't require a high degree of computer literacy?
How about talking about Grex to people, when you think you might have found a kindred soul who might like us? That would be very useful if everyone could find just one or two people and get them into the Grex community. So, for social issues I agree with Mark. On the technical side, Dave is right.
Well, if you can't afford to buy a membership, you'll just have to be interesting enough in the conferences so that *other* people will want to join. Think of it as a form of "sweat equity." (1/2 :) ) I think getting conferencing speed up is important -- cutting out the net link lag and the CPU lag so that conferencers don't get bored and go away. I think that Grex's concept of "open-everything-for-everybody" is going to need some reformulating, and there are going to be some political struggles with that. (Hi, Mary!) I think there are two problems: 1) As has been discussed at great lengths, many of us believe that free-email-to-the-world is becoming a black hole which will grow to consume all of the resources Grex will let it consume. E-mail chews up lots of the link; it chews up lots of staff time, from what I hear. 2) Regarding the minutes of the last Board meeting, where Steve Andre' reports that Grex is under heavy pressure from vandals: I am starting to suspect that offering open shell access to the world just makes us too tempting a target to the malevolent. Again, here I suspect the issue is staff time. Every hour Steve and others spend coping with system attacks is an hour not spent on getting the new Sun up. So I would lay out an argument like this: From this item, and other discussions, I feel a strong consensus that conferencing, and probably party and e-mail within Grex, are Grex's most important functions -- these are the community-building activities. But we have not been willing to act on this consensus: to direct our scarcest resources, the link and staff time, in support of this community-building. Such a redirection of resources would imply some significant shake-up in how Grex operates, and what it offers to the wide world.
The risks associated with an open system such as Grex are real, but a couple of things need to be remembered. The first is that some largeish number of root-explotiable bugs in commonly available software these days comes from complicated user programs like elm, or lower-level things like sendmail which are still accessable by people. The second part is that more and more attacks are from the "outside", ie off-grex but still attacking the system. Thus a lot of #1's problems aren't solved by closing down the openness, and none of #2's are. The worst part of Grex's openness is that we've become something of a "magnet" amongst the vandal community. I'm not sure that we'd be better off in this regard if we shut shells down, or not. Unforunately, probably not. You are right however Ken, that this activity does take away from working on the Sun. And yes, at some point we are going to have to come up with a new way to do some things.
(Hi, Ken!)
I, for one, would very very much like to see Grex keep open shells. You can't get shell access easily any more. Most ISP's don't offer it. Universities do, but only to students and staff. So, grex is one of a few places to get shell access, and one of even fewer that are free. I very much like that about Grex. The shell access that Grex offers has been very important in deciding my career choice, and I'd like to offer that to others.
People have been saying since 1983 that it was "not possible to run an open access Unix system". I think first m-net, and now grex, show that this is just not true. It does take some percentage of staff time, & more importantly, "the right perspective", to do it. This was known from the start on grex. Going to a more closed system would not reduce, in the slightest, the amount of work that would be necessary here, nor, to any substantial degree, would it increase security. In the short run, it would actually considerably *increase* staff work, because considerable extra effort would have to be devoted to finding replacements or workarounds for programs that inherently offer shell access. For instance, programs such as mail, party, vi, and picospan all offer this facility, and derive part of their power and usefulness from including this facility. In the long run, since clever users with socialization problems would persist, the potential for misuse would still exit. Since also grex doesn't have the budget that NASA has for exhaustive proactive custom "bug-free" design methodology and code development, it is inevitable that there will sometimes be bugs to be found. One need only look at the typical freenet to find an example of a system that is considerably less open, yet probably has just as many if not more problems from vandals.
Heh. Thats an excellent point marcus, about various freenets problems.
I agree about the desirability of keeping open shell access. Another reason to throw into the pot is that it's in line with Grex's charitable mission. I can think of various people who have benefitted education- and career-wise from the open shell access on M-Net and Grex. From a practical point of view, it's an avenue for recruiting new staff members. Folks like Ed Anselmo, Marc Unangst, Mark Bobak, and Steve Gibbard come to mind.
By all means, keep open shell access. I would like to institute some scheme that would limit the preportion of our total bandwidth that is consumed by mail.
This response has been erased.
I'm certainly not invested in the idea of restricting shell access if it won't buy anything. Let me rephrase my goal: We need to examine what ongoing tasks are devouring staff time; if these tasks are not central to Grex's community building purpose, we need to find ways to streamline or eliminate this drudgework. We need to be able to redirect more staff energy from "maintenance" to "development." The "fake POP server" is an excellent implementation of this idea; we need to find more and bigger ones.
Heh. Can't argue with that.
I am currently thinking of several changes to newuser that may help in this area, both to "discourage" not so good uses of grex, and to "encourage" conferencing. The first change I'm contemplating is to teach newuser to generate a cflist based on people's interest. This way, instead of seeing one "introductory" cf, which may not be intrinsically interesting to all, and which isn't really a "home", people will instead see real live conferences right off, that are hopefully discussing things that will be of interest to that person. The second change I'm contemplating is to make newuser more nosy about what people are going to use grex for. One thing I want to catch is people hoping to run "eggdrop" on grex. This is definitely a big waste of time, both for us and them, and I'm hoping by nipping it in the bud, so to speak, that we can just avoid the whole mess. Another thing I'm interested in is catching people who are interested in mail. What I want to do there is basically a bit of "social engineering". I want to describe grex's mail in the least favorable terms possible (no modern gui, slow, doesn't work to every system, etc.) and then to have pointers to as many other mail systems as we can possibly find (hotmail, juno, etc.) I also hope to deal with mailing lists, web pages, gif files, and so forth in a similar way. It'll probably take a bit of work to get the wording in all of this phrased right, but I'm hoping that the result will be a higher quality of user who makes it through newuser, the users who basically *want* to become part of our community, and aren't just looking for free pine. I don't know when I'll get time to work on either of these. I'm hoping, though, that it will be soon.
I worry about adding more stuff to newuser without also taking some stuff away. Newuser already makes people go through a huge amount of stuff, and it seems like while people are often willing to add something to it, people are rarely willing to see anything taken out (kind of like the Federal budget).
Yeah.. I wrote a very shortened version of newuser for nether.net awhile back to make it much easier to get on the system, which took out lots of weird little quirks that I did not think were very worthwhile, and also had it do stuff like check the passsword against a wordlist, and verious other things.. it's by no means perfect, but making it easier to initally register, and later change the information is good. I've got the eggdrop/bot problem also, but on a different scale since people can compile it and make it owrk on my system, but I go and delete their accounts.. there's stuff in the newuser text, /etc/motd, people are just plain stupid. Putting more text in there isn't going to be worthwhile.. they're already doing it and there's sufficent docs in the ftpd motd to get the folks that are actually interested in caring.
This response has been erased.
whenever I see .cflist I get hurt. guess why? :)
(Some of use acutally *like* to use strange things like vi for our .cflist and .login, etc. :) (Then again, some of us are total geeks...)
Let's have some more dreams about what Grex should be in 1-3 years.
This response has been erased.
#26 thanx :)
This response has been erased.
one ignored medium range action would have beenfor the cfadm in atrining and also new coop fw, void to have had the opportunity and experience of changing the conferences and aslo changing the fws. but, noooooooooooooooooooo, the gun was jumped. so now you have had the chance to train someone new ---adn stiffed her. ...and ALSO install the WRONG fws for coop.cf. don't we feel just so proud? where the hell did 'respect go'?
This response has been erased.
I'd like to see the dialup users have the (additional, optional) ability to access some of the services that only our internet users can access. This would require that we allow PPP connections upon dialup. We could make these non-routed connections, so that users would not be able to access services this way except those provided on our own subnet. Advantages: (1) Dialup users could see our web pages, and use Backtalk if they preferred. (2) It would be much easier for us to provide distributed services that way. (3) We could add POP mail service for these users. It is still arguable whether it is a good idea to provide POP over the internet, but if we had implemented a mail bandwidth limiter, we could conceivably do that as well. Users would thus have access to much better interfaces than they do now, providing that they have computers which can support PPP. Only really old computers can't do this.
I would very much like to see this too. I prefer greatly to use backtalk to do my cfing, but I can't as I dial up to Grexes modems all the time.
The Chase IOLan terminal server we have supports PPP connections. That could be set up fairly easily, I think.
Interesting idea. Of course, dialup users can access backtalk and grex's web pages now via lynx, but that ain't the same as accessing them via their own browser, which PPP would make possible. How annoying would a restriction to grex's subnet be, though? Dialup users wouldn't be able to follow any of the hyperlinks that show up in backtalk and grex's or users' web pages. Would they be able to see the graphics on the web pages (Grex logo, buttons in the pistachio interface, etc.) if they continue to be served from elsewhere?
We'd have to set things up so that dialup users get their button images served from Grex. At some point I hope to make this configurable, so that regular backtalk users can unpack a collection of images on their home computers and serve them from their own machine.
This response has been erased.
This response has been erased.
I agree that the restriction is necessary. Without it, we'd become something we can't afford to be and don't want to be. This is the "medium-range planning" item, so maybe this next it a little off-topic, but I just want to remark that the claim made in #33 that Backtalk is a "nicer interface" than the standard tty- based interface to Picospan is debatable. Without disparaging the tremendous job Steve and Jan did in creating Backtalk, the fact remains that there are things that I and others like to do in Picospan that just aren't possible via Backtalk with the current interfaces, e.g. various kinds of browsing (the equivalents of "browse new", "browse since -1", etc.), doing a "!" escape to run a Unix command (!tel, !mail, !pwho, !who, etc.), and piping Picospan output through filters (I tend to do "browse all | 'grep string" fairly often). The lack of Backtalk equivalents to various useful Picospan commands is remediable, since Backtalk has a very flexible mechanism for creating new interfaces. The lack of connection to the "rest of Grex" seems harder to address.
That's what your telnet window is for. :) Afterall, if you can run your browser through the link, you can telnet too. I have no objection to telnetting into Grex as long as I don't have to go through the link.
I can think of a number of DNS or routing based hacks that would make BackTalk's images come from different places depending on whether people were dialed into Grex's local terminal server or coming in over the Net, which wouldn't require any modifications to BackTalk at all (and could also apply equaly well to other graphics on Grex's web pages). Everything I can think of for that sounds pretty ugly, though. As far as BackTalk goes, it might be better for BackTalk to look at where a user is coming from and give different image tags accordingly.
Re #39: You're right of course, and that addresses the "doing Unix commands" part of things, although not the "integration of Unix functionality with Backtalk" part. (That could be an interesting exercise in interface design...)
This response has been erased.
At some point in time, we'd like to go over the functionality missing from Backtalk that our most sophisticated picospan users (like John) take advantage of. Ideally, we don't want Backtalk to be giving up many features. The backtalk's config file defines a symbol, /imghost, which is used as a base URL for the images. That symbol is set up in /usr/local/lib/backtalk/backtalk.conf. It is currently set up to point to hvcn unconditionally. It could be defined conditionally. It does make more sense for backtalk to make this distinction than to put in a DNS hack or some other kludge. I think there are other benefits that will accrue to local users besides accessing Grex web pages and backtalk, btw. I'd like to see us support POP so that local users can use local interfaces available for their mail, too.
Hello, I have suggestion to offload the giant e-mail problems.
IMO the staff can put info about various info about free e-mail
service such as Juno, Hotmail, Bigfoot etc.
There are several free faster Lynx text browser service
accessible using telnet. You can download files using Kermit (77 cps).
You can send e-nmail using the service ("mailto:....)
Have we already mentioned that?
Has it been done?
Staff routinely points people to hotmail, juno, etc. for email only service.
... as do helpers... fwiw.
Good to see planning has been alive and well for ht elast two and a half months. *ironic grin*
I think we're too overwhelmed with work to do any planning. Once we et the 670 up, and the terminal servers are usable, we should really do some planning. The first thing I'd like to plan is distributed function. But that would be premature right now.
by that do you mean, say using the old machine for mail processes, and the new machine for home directories and conferences?
I just meant that we ought to get ourselves in the position where we can have several machines doing several different functions. *Some* machine could handle mail delivery, but it might not be grex, and it might not be the old machine. Other things besides mail could be offloaded to different processors too. One of the things that would make all of this easier is a distributed authentication system. This requires a little planning, and more staff time than we have free right now. There is progress being made on the 670, but there is more ground to cover there before it will be visible.
I wish I could help with that, but I lack both expertise and proximity. <:-T
You have several choices: