98 new of 109 responses total.
I wouldn't be too excited about getting rid of Picospan or Backtalk/Fronttalk as it is what has attracted most of us here. If new interfaces can be made which let the existing users continue to use the system as we're accustomed to using it, that would be interesting. I kind of like the idea of separate communities. It has been possible for a long time to have multiple Picospan type BBSes on the same computer. A couple of users, including Jared Mauch, installed their own copy of YAPP on M-Net back in the 1990s. We discouraged it then because of space limitations but it was possible. I expect it should still be possible now for Backtalk/Fronttalk though it would take a root some manual work to set it up. There'd be no technical problem with other software packages pointing to different communities as far as I know. I too like the new WWW interface.
I got a "The page cannot be found" for www.dmine.com/dialbbs/dialbbs.html
I approve of modernizing the website to use current standards. In particular, I'm happy to see that the homepage Dan set up uses CSS and is "real" XHTML (i.e. MIME type "application/xhtml+xml"). I'm not all that fond of the appearance (tiny fonts, dull colors, Grex logo missing) but those are things that are easy enough to tweak. For comparison purposes, the old homepage can be viewed at http://grex.org/index.html.no-wnu . I actually think the old one wins on readability and attractiveness; YMMV. Whatever website design we decide that we like, we'd want it to be consistent throughout the site. I'm thinking that a good move would be to use a full-blown content management system (CMS). Of course, we'd want one that's free, open-source, and facilitates easy modification of content as well as tailoring the appearance to what we want (i.e. something with a "Grexish" look, whatever that is). I've not worked with any CMSs, so I'm not familiar with what's available, or with the advantages and disadvantages of different products. Drupal seems to be getting a lot of buzz nowadays; maybe that would meet our needs. Once a CMS is in place, folks could go to work bringing the content up-to-date. Using a popular CMS project might also encourage new folks familiar with the product to get involved in maintaining the website. Hence I suggest the following PROJECT: Make Grex's website CMS-based.
resp:11; Huh. That could work. Or maybe we could just host the grexergallery on Grex itself. Personally, I'm getting to the point where I think we need to change the access structure so that only our "community validated" users can resp:12 Well, the idea isn't to do away with conferencing as we know it, but rather to replace the picospan program itself with something compatible and open source. If YAPP were open source, that would be the obvious choice, but it is not and it doesn't appear that the Thaler's are going to open it up any time soon (though if someone asked them, that'd be nice). There are certainly no plans to replace the backtalk/fronttalk combination any time soon, though it may be feasible to replace picospan with fronttalk. resp:14 I'm sorry you don't like the color scheme; actually, I didn't change it at all from the submitted website. I confess I rather like it, but then, asthetic tastes vary. Well, maybe "like" is too strong of a word. I do think that it looks nice, though. I am not, in principle, opposed to using a CMS, though I do not want to become hamstrung in by waiting on the "right" technical solution when what we need *right now* is a major update. I think this is a potentially useful long-term project, but right now, let's focus on getting what we have into the 21st century and reflecting reality. Btw: John, does this mean that you are volunteering to work on the website? :-)
resp:15 (First paragraph; neglectfully unfinished....) ...only our "community validated" users can create web sites. Concurrently, we should just allow images. We have always feared we would be either a) overutilized in terms of disk, bandwidth, etc if we allowed images, or b) be overrun with phishing and porn sites. I don't think we have any evidence to assume either is true, though.
Re resp:15 - I was aware that the color choices were not yours. I wasn't all that fond of them the first time I saw them either. In any case, they're easy to change. I'm thinking that installing a CMS like Drupal might represent a day's work for somebody, and then everything would be in place for people to start contributing content through a well-defined process that would not require extensive technical skills and that would ensure everything would have a uniform appearance. Not having worked with CMSs, I can't say for certain that it would be that simple, though. Developing standard "Grexian" CSS and then requiring that all pages use it might be a simpler way to get to the 21st century. Maybe somebody who's reading this and has had CMS experience could provide useful input regarding what a CMS would buy us and how much work would be involved in setting it up. No, I'm not volunteering to work on the website.
I dont mind working on the website but my web skills are somewhat lacking.
What I am getting good at though is testing things. I do a lot of the quality control for the web designers at work
What's that involve? Viewing the same page with five different browsers? Proofreading for typos?
In Grex's case, since it is pretty simple, that is pretty much what it entails. That and checking every link. At work, it is somewhat more complex because we have massive databases feeding data to the site and all kinds of weird filters and stuff.
resp:17 Cool. If we can find someone to do the work, we can make it happen. It does sound interesting. While you have said that you haven't worked with the software yourself, do you know of anyone close to Grex who has a proof of concept site running? resp:21 The big things I think we need to work on right now are content (and frankly, anyone can do that) and utilizing current web standards. The latter isn't so hard; we can use tools like HTML tidy to automate most of it. The former is where we need people who are sufficiently familiar with Grex that they can describe it reasonably well and, more importantly, good at writing and with something of an eye for design. Actually, we only need one person who's decently good at design to do the CSS part, and then the rest of the pages more or less inherit that, so mostly we need people who are good at word-smithing and working on the content part. And we also need people to advertise and cheerlead for Grex.
Not until my name is on the front page.
RE:13 Oops, I mistyped the URL its www.dmine.com/dialbbs/dialbbs.htm not html sorry for the screw up
I generally am not very relevant in this discussion but I'm posting this anyway. CMSs are "certainly" not the way for Grex to go. Their functions only slightly overlap with those of Grex's and despite what remmers says they are far from being "easy to maintain." They are almost invitations for disaster because they're too complex, often involve many "moving parts," and mostly hinge on "shiny new technology" instead of "proven old ways." A simple CMS package will need heavy server-side (e.g. PHP, Perl) and client-side scripting, some sort of database (e.g., MySQL, PostgreSQL), and "mods" for the web server (e.g. mod_php for Apache). These are obvious performance drains and security threats. Grex is known (and loved for) being simple and "old-skool." Some Grex users delibrately use very minimal setups and view these same pages through lynx (or through bbs), with those "frills" they'll be deterred. I like it when pagefuls of good talk is loaded over my dial-up connection in under 15 seconds. On the functional aspect, Grex offers a bundle: shell access, email, webhosting, "and" community interaction. CMSs are focused only on collaborative content creation which is not the sort of community interaction Grexers are involved in. Grex isn't hosting some sort of "project" that needs "collaboration," i.e. modification of the "same" content. Its community interaction paradigm is very well described by the title it already has: bbs. The refurbishment it needs in that respect is probably some new "light" bulletin board software but I'd be skeptic to even deploy phpBB and the like because all of them, like CMSs, depend on server-side scripting and DBMSs. As for "standards compliance," as far as I know most "recent versions" of standards have been specifically designed to be supersets of their previous versions. So Grex is not non-standard if it still presents content in old HTML instead of some blasted XHTML/DTHML 4.1-bloody-transitional. In fact, one has to be proud to present a functional Grex using the smallest possible subset of the pertinent standards. That's good minimalism. I believe on a "frills-mostly-with-a-bit-of-content" Internet a good ol' system's mission should be to keep up the good ol' ways. In case of Grex, that could be accomplished by enriching the shell/remote access experience (for me that boils down to port forwarding and running httptunnel ;-), expanding (or total abandoning) of email services (to include IMAP, for example), relaxing webhosting practice so that people can make diverse websites within reason (I don't think people should be able to put up sites written in PHP on Grex, though), and a more capable but still "text-oriented" bbs (a "multi-level forum" structure instead of conferences, and a proper linkable archive). Good luck to [put the hero's name here] who will revive Grex. Seriously though, I'll be happy to help if there's something I can do for Grex over some thousands of kilometers and a dial-up connection.
Perhaps fronttalk could be changed so that you can click on a link posted in bbs, and use lynx or links to view it (no graphics).
Re resp:25 - Hmm. I'll need to educate myself better on CMS's before I can agree or disagree with what you say. As far as the underlying plumbing is concerned - Perl and MySQL we already have, and intelligent use of CSS and PHP could substantially improve the website. I've found that adding some light-weight CSS and PHP to my personal website has significantly simplified maintenance tasks. I'm in favor of reasonable minimalism and avoiding technological overkill, but not to the point of rejecting technologies that could be useful and make our jobs easier. Re resp:26 - Adding mouse support to a tty interface is an interesting concept, but probably not feasible (although xterm has limited support for it, I think). On the other hand, implementing a web interface that looks and acts substantially like the tty interface, but also supports "clicking", might have some appeal to the old guard. Not that I'm seriously suggesting that it be done.
You don't need a mouse to click on a link. Pine lets you go to URLs already (Enter key). Why not fronttalk also letting you invoke lynx or links or even w3m?
Ah, gotcha - "selecting" might be a less confusing term than "clicking", which suggested to me that you meant a real point-and-click device (mouse). Well, it's definitely feasible technically; stumbling block would be, as usual, persuading someone with the necessary programming skills to implement it.
My Enter key clicks.
resp:28 I'm not sure what the point would be.... Grex already has fronttalk that works with a TTY interface. One of the ideas is to make the web interface more TTY like, but that's a separate issue.
The point would be to make it easier in Fronttalk to follow web links that people post, similar to a mechanism that already exists in Pine. That would actually be a nice facility to add, if somebody gets inspired to do it, and underscores why Grex really needs to be running open source conferencing software.
I wouldn't mind a web interface to BBS which supports cellphone users.
resp:32 Aha. Okay. It strikes me that both picospan and fronttalk pipe conference data (read: responses) through an external pager program; I wonder if less or most of any of those can be made to recognize URLs and do something similar to what pine does. If that were the case, we could just set the pager and get the same functionality for free.
The new page looks nice. A couple of typos: "frequently" needs an "l." "Our home, Ann Arbor" needs a space.
Thank you! I corrected both typos; please let us know if you see any more!
Re #27: I'm rather bewildered to hear Grex runs a SQL server. Are there any Grex applications depdendent on it? Has it ever been load tested? Or is it just "educational?" As for Perl, mere availability of the interpreter is not enough. PerlCGI modules must be added to both Perl and Apache (assuming Grex is served on Apache) to provide the required CGI hooks. These hooks and the "possibility" of remotely running malicious code through a misconfigured or buggy CGI interface will make Grex vulnerable to a host of attacks. On the other hand, cgi-bin is already there so perhaps there won't be much added vulnerability. I've heard computer security experts have a saying that goes, "usability is inversely proportional to security." I wonder if Grex isn't already "useful" enough?.
The front page is too cool. But the same theme is not followed in all pages. It should be consistent in all pages as remmers mentioned. I would like to help you in always I can. I can read/write HTML, CSS, little PHP and Perl. Thanks Noorul
resp:37 I've found it's not always true that security and usability are inversely proportional. For instance, many networks become *more* usable when moving to, e.g., Kerberos for authentication because it suddenly becomes transparent to most users: instead of entering a password/passphrase for a variety of different services, the library just pulls it out of your credentials cache on your behalf. Similarly with SSH public-key authentication. Btw: Grex runs MySQL for a few different, administrative types of things. We also already run mod_perl. resp:38 Thanks! That'd be great! All of the HTML is in /var/www/htdocs; feel free to copy that to your directory and go to town making changes that you see fit. I agree that the pages should have a consistent look and feel, but haven't had time to update most of them myself. I *did* convert the HTML in the main directory to XHTML using tidy, but it's being servied up by Apache as text/html instead of the XML+XHTML combo that all the kids love. That's largely a matter of fixing links.
I seem to remember that IE6 has problems with the application/xml+xhtml MIME type.
It does. Which is why I modified the Apache configuration to rewrite the MIME type to text/html for .xhtml documents if it detects that it is serving to Internet Explorer. Similarly for Lynx. For other browsers, we still want to serve as application/xml+xhtml.
I still hate the colors.
And what happens when STeve finally logs in realizes things have changed? Will he / can he revert back to the old and lock cross out? Only 1/2 joking..
I say we give cross root and lock steve out. It would probally be months before he noticed anyway.
Change the fucking colors!! It looks like diarrhea.....like someone hershey-squirted all over the screen.
resp:32 Once again, we mention the need for open source conferencing tools. I think we need to push strongly on this; maybe we should get with the M-Net people and collaborate on something new.
Shortest path to something useable would probably be Backtalk + Fronttalk. Backtalk works well, and fixing up Fronttalk would be a lot less work than developing something new.
Well, I think the absolute shortest path would be getting either Marcus
or the Thalers to open up the source for either Picospan or YAPP,
respectively. However, I'm not really sure what either partys' positions on
the matter are. At the minimum, with respect to Picospan, it sounds like it
would require a lawyer to figure out the ownership of the source code. If
Marcus were interested, I wonder if someone like Dave Cahill might be
willing to look into that on a pro-bono basis for Grex.
But, history is usually a strong indicator of the future, and it seems
extremely unlikely that either YAPP or Picospan will be open sourced any
time soon. Given that, we need to move to plan B.
And on that front, I absolutely agree that backtalk + fronttalk is the
path of shortest resistance to getting an open source replacement for
picospan on Grex. The problem now shifts to finding the resources to get
fronttalk cleaned up to the extent that it will make a credible replacement.
Fronttalk is ... not a small program. It's not *big*, but it's not
trivial by any measure. And it's not well understood except by Jan, who's
mostly not around these days. And we don't have enough people testing it.
What to do?
Well, it's open source, so if we can get some more peopple who are
decently familiar with Perl and how Backtalk works together, we can work
through the bugs easily enough. I mean, nothing here is particularly
complex; there are no deep mysteries of computer science. It's just
maintenance on a decently sized program. But where are those people going
to come from?
Another option is to try and persuade Jan to work on it again; I suspect
we'd have to pay him (as I suspect part of the reason he hasn't done it
already is that he's busy doing things that make enough money to help him
support his family). Purely to get some information, I sent him an email to
ask him if he'd be willing to do some work if we paid him. However, he
hasn't gotten back to me (or, if he did, it got flagged as spam by GMail and
I never saw it). I suspect, however, that we haven't really got enough
money to make it worth his time.
So we are back to doing the work ourselves. So who is willing to take
up the challenge of working on fronttalk to turn it into a suitable
replacement for Picospan? Note, you don't have to be staff to do this, you
just have to know some Perl.
And who is willing to help out testing it? We *really* need people
to *use* it and tell us where the problems are. And if we decided to make
this change, it's likely that people might have to change some of their
.cfonce files and maybe some minor usage patterns. Are people going to
accept this? Will they work with us to get everyone converted over to the
new software, even if it's slightly incompatible with Picospan?
I'd be willing to help but I'm not literate in computer technology...
Well, we need people to test out fronttalk; you run it by running "ft" instead of "bbs". However, until we can have a group of people to work on it, all we can get is data.
from an ssh connection? ummmmmm.....
Yup.
Yes indeedy. Fronttalk is a web client that runs on a terminal (sorta like lynx, but more specialized).
i'll try it out ...
runin g ft now ... seems mostly the same .. las doesn't work, but hte -X command does ( not a quibble, just an observation). and twit filter works JustFine (tm) as well. you can tell, my typing has improved ....
(What does the "las" command do?)
Whatever .zshrc tells it to?
resp:58 is totally empty.
> resp:58 is totally empty. If you look closely it's the executable for /bin/true
Close, but no /bin/sh.... :-)
You can make a "true" executable from the empty file, too, not just from the empty shell script. e.g.: > bash$ touch truetest; chmod +x truetest; ./truetest && echo "true" &&\ rm truetest > true
(That wasn't what I meant.)
58 was the start of an explanation of las (as well as -xxx) but there were too many variables as to when each/either works/doesn;t work between ft adn bbs but it got WAY messy so i thought i cancelled it by having an empty reponse (no chars) but it seems that ft and bbs handle empty differently as well. no biggie, just quirks all aorund.
Well, so what is las?
LAS is the acronym for the Las Vegas airport.
in bbs - but not ft - the las command at the rfp prompte displays the last response. there are quirks with it but in general that is how it works.
Oh, okay. That actually sounds kind of useful.
Note that it's really the "last" command. It just accepts shortened versions, including "las" or even "l", but if you try to talk about "the l command" nobody will know wtf you are talking about, and if you change it to "the l word" things get even worse.
that L word again ... /sigh ... how right you are.
What's wrong with lpstat?
Huh?
("l" word... Unix commands... never mind.)
(I got it after the fact. I was like, "WTF? We don't use SysV style printing....")
See, I thought you were going for "WTF? SysV style print commands suck -- everyone knows that!"
(That's a given.)
So I made some changes to fronttalk today.... 1) I incorporated bellstar's changes to add a 'respond' command at the Ok: prompt. 2) I made 'l' work as a synonym for "last" at the RFP prompt. So, "l", "la", "las", "last" and "$" all do the same thing there.
tnx. ,
Ain't no thang.
umm, i did find a preserve command, spelled out entirely. howse about shortinge it to pre ? is that possible?
Maybe. What's it do, and what prompt is it used at?
I believe it's at the "Respond or pass" prompt and suppresses updating the participation file.
I'll look into it. Jan hasn't responded about any of the patches I've sent him; I'm not quite sure what to make of that.
use the telephone ... the preserve command sets 'where bbs starts reading' the next tme bbs is engaged. for example ... 237 responses, 126 new ... read new .. ok fine. if ther eis bs in some resps but an importent response in 222, then 'preserve 222' will read froem 222 sted 111.
It looks like that's already abbreviated to "pre".
correct .. change was made ... tnx.
RE #25 >>CMSs are "certainly" not the way for Grex to go. Here!Here! I cringe at the mention of CMS in the context of GREX. I have developed sites using both XOOPs and JOOMLA solutions and have found both to be an insult to knowledgeable web design. They are certainly capable of producing professional results but they strike me as very 'Rube Goldburg' in nature. The XOOPs site I did only to test the software. But the JOOMLA site is a current project. I did a bunch of research on CMS software and decided to go with JOOMLA mainly due to it's massive following (translating that to mean a greater support community.) I had always wanted to try a serious CMS site when my son came up with a website idea he wanted to try. He has no web skills at all and I set this up for him because at least the administrative functions are logically presented and well documented. The thing is so overbuilt yet convoluted. Everything was included in the basic setup except what you need. I added a "Simple Machines Forum" (SMF) forums module which is very slick but It is so much like everything else on the internet. If all you want is a forum site this is really a nice solution. (Bridging Modules? - OMG!) What GREX would do with any of this stuff is beyond me. But trust me on this incorporating a CMS into the current setup would be a programming nightmare! It would be far easier to rewrite GREX in PHP from scratch to do "whatever" than to try to customize a CMS. I like the new GREX website. The clean cut CSS design fits in well with the true GREX tradition (Telnet + ASCII.) I was NEVER fond of the old web front. It just never felt like it was promoting the place I had known as cyberspace.org. Back talk is VERY NICE in that it makes the conferences so easy to navigate and contribute to. However, on the telnet side the conferences where always just tricky enough to limit posters to folks that I felt have paid some sort of dues to participate. I think some of that is lost with BackTalk but so much is gained in ease of use, it is hard to argue against it. One thing I really miss from my old bulleten board days is ANSI support. We used to have a blast goofin' around with the graphics and sounds. I know they where just toys but we could really do some fancy screens and menus. We segregated ourselves into SIGs (Special Intrest Groups). I always thought the various conferences here where the next best thing but there has never seemed to be much purpose to contributing to many (most) of those available. Here's an idea: What about getting active groups to collaberate on webpages to promote their special intrest and having their conferences only visible to logged in members. Keep agora publicly readable, of course. But the "I Like Gardening" conference takes place 'behind closed doors.' For instance the "I Like Gardening" conference would have a webpage to promote itself and invite folks to come join the fun. Perhaps allow a 500K limit on graphics for use on the page. This would reguire some limited graphics handling (for reviews and what-not) maybe give each participating conference/group 5meg or so of storage to cull their page from. Not only would this sort of thing attract attention from the surf- by visitor it would encourage GREXers to develop their web design skills or at least bring to the group an individual with such tendencies. If we could evolve into a GREX of Website Designers as well as UNIX users we would find we could maintain GREX and build it ourselves into anything we wish it to be.
Can I read ft code? Where can I find it?
resp:87 Hmm, interesting idea. We've been thinking about "fishbowl" conferences for some time now; YAPP had the ability to have finer-grained access controls for conferences which would, I think, provide a starting point for the sort of things you are talking about (accessible from the command line, not accessible from the web; up to the conference's administration to decide which way to go). The problem with enabling that sort of support in backtalk was, of course, legacy support for Picospan. Since we're moving away from Picospan, however, we might be able to rethink these sorts of things (fronttalk, the "new" terminal-based interface for BBS, is just a frontend to backtalk). Anyway, the point is that it's technically possible, provided it's something that the community wants to do. With respect to the web site, I think the thing to do is keep most of it static, with some cron scripts and resp:88 Certainly! Read /usr/local/bin/fronttalk, and the libraries are in /usr/local/lib/fronttalk-0.9.2. Feel free to read whatever you like; if you see bugs, or want to make a change, just send email or post here, or (for changes) copy the files in question to your home directory, make a change, and email or post a patch (diff -u format works best). Provided the changes are reasonable, I've got no problems incorporating them into the running version here on Grex and sending an email to Jan. For that matter, there are a number of things that need to be incorporated into the current code to make it compatible with Picospan.
I thought of making some changes to web pages. 1. Creating common header html which can be included in all the html files. 2. Creating common footer 3. Creating common sidebar html file In order to do this I tried copying all the files from /var/www/htdocs to my home directory. But it looks like I dont have enough disk quota. Is there any way I can copy this entire folder to my local machine?
Do you have wget? Can you work in /tmp at grex?
To download the htdocs folder is to attempt to get way more files than you need or would even want. There are subfolders to htdocs that are actually links to folders elswhere in the system and those probably contain symbolic links to other folders as well. It is entirely possible you are meeting yourself coming and going - downloading files more than once in some cases. Some folders and contents are permission based and cannot be accessed. Much of what you can download is no-doubt irrelevent to your project but may shed some light on the structure of the grex website. I have downloaded what I could. I have ommitted the GREX minutes documents but admit they would probably be in interesting (& dry) read. I've also pruned the stats folder (almost 50MB in itself.) I have made these files available for downloading in a compressed ZIP file at the following link. check here http://www.cyberspace.org/~madmike/GREX/ I was hoping this might ease bandwith demands on grex in case anyone else was curious as to these files and their contents. I havent yet checked what all is included but I'm sure you will find what you are looking for. When I get the time I'll prune this down to the bare essentials. But for now I think I'll have a look myself. STAFF: If you would rather I did not do this let me know.
resp: 92 Even if I work in /tmp it wont help because I should be able to see the result in a browser. resp: 93 I am on a very narrow bandwidth. It looks like the size of the zip file is 3.2 MB.
Oops I tried downloading. But I am not able to do the same.
perhaps this will get it... http://infinitelyremote.dyndns.org/members/madmike/GREX/htdocs.zip It is possible that the firewall may be blocking you. I do have several large IP blocks filtered. sorry, but if you email me your IP address I will be happy to poke a hole in the wall for ya.
resp:93 I don't have a problem with it; the stuff can be easily retrieved by a web browser; I'm sure lots of it is already stored in various archives and caches automatically (like most of the web's content). The Grex web pages (the ones that we actually edit, anyway; not the meeting minutes, Apache manual, stats, etc) are now in CVS: /var/ncvs/grex/web is the location of the repository.
madmike is a madasswipe!!! nyah! nyah! HE can't hear me!!! I'll bet he has sex with geese and wipes his ass with his finger and then sticks it in cyklown's mouth.
Twit Filters are a beautiful thing!
(Mary gives madmike the secret handshake.) ;-)
Okay then... I have moved the file to a bigtime server for hosting. Should be World accessable now. See this page for the updated link. ==== http://www.grex.org/~madmike/GREX/ ==== I've included most of the following folder /var/ncvs/grex/web/htdocs in the htdocsII.zip file the /var/www/htdocs is still available in the htdocs.zip file re# 100 ;o)
It stikes me that we do allow people to mirror the Grex CVS repositories using cvsync; it might be easier to just suck those down than getting the RCS file from the CVSROOT subtree (those don't give you much, really).
Sounded like a good idea... Am I doing something wrong? ================================= [root@myserver grex]# cvsync cvsync://grex.org:80 Connecting to grex.org port 80 Connected to 216.86.77.194 port 80 Socket Error: recv: 2 residue 2 Recv: protocol version length ================================= (takes about 5 minutes to do above cycle)
I know what I'm doing wrong... Trying to do something I have no idea what I am doing. I'll read the docs and get edgamacated. (this'll be fun) thanx cross
Idiot. I'm losing nothing by him filtering me. hah!
cvsync -v cvsync://grex.org/grexcvs/rcs/?prefix=/grex ******************************* Done (collection grexcvs/rcs) Finished successfully Total time: 465.256 sec now to figure out what to do with these ;)
I have found two things that is different from picospan. 1) Initially when we get into front-talk it displays help messages which says that typing "help conf" will display the available conferences. But this command is not working. I think it should be "help conference". 2) I tried "help conference" and it worked. But there is no pagination for this command so the list runs out of the screen. Don't you think changing the initial message and adding pagination will help?
I do; remind me to put it on my list of things to do!
Today I can see (type "help conf" for a list of conferences) above the Ok: prompt. :) And "help confe" works and "help conf" doesn't. And there is no pagination.
You have several choices: