sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) (05/23/88)
The following are my replys to WRONGLY stated comments: > The messages are in a non-standard format with all messages stuffed into > one huge file. The messages are limited to a compile time maximum length. Firstly, what is a standard message???? The message base is INDEXED for rapid retrieval. Secondly, the writter stated that the messages are limited to a compile time maximum length. The message length is limited to 20 lines of 72 characters per line. This was intentionally done to limit the amount of disk space. > | 16) Message of the day (pre-selected) > This is a hardcoded filename (the date) whose contents get printed out. This happens to be a VERY efficient way of doing it!!!!!! This way, you can make up your messages for the future and they will be listed on the appropriate days. BTW, since you don't like the file name as being made up of the date, what would you like, with the idea that the software has to find it on the proper date????? | 18) The following file protocols are available for downloading: sliding windows/standard kermit, zmodem, ymodem, batch-ymodem, crc-xmodem, | checksum-xmodem, ascii, SEAlink, and type. | 19) The following file protocols are available for uploading: | (Same as downloading except for "type") > All the file transfer protocols are external programs - you must have them > on your system to be able to use them. The file protocols are available on my system. Even the ones thast AREN'T included in the over compressed tar file! You see, the ONLY ones that aren't in the tar file are kermit and rzsz, which most users already have! Why make the file file larger than necessary???? | 20) List the contents of an archive file ( .arc, .tar, or .tar.Z ) > This requires that you have a working copy of ARC on your system... The source code is available on my system and has been sent MANY times through the net. | 21) File directory summary > Simply a "ls -l directory > file ; cat file > modemport ; rm file" sequence I hate to use profanity on the net, but you are COMPLETLEY wrong! The file summary option, for your information, lists the file statistics within the directory. This option lists, according to date groups, how namy files have been accessed, modified, or changed. Then it lists, according to size groups, how many files fall within this limit. Next time, I suggest you KNOW what you are talking about! | 22) List all, new, or matched files > See 21 with a few additions I wish I could write out what I am thinking now; however, I do not want to disobey the net rules! Firstly, the output format is nearly the same as Fido and Opus ( if that is an ls -l, I'll eat my hat! ). The list all format, lists all of the files that are mentioned in the file, files.bbs, along with the "canned" description for each file. The output, as stated before, is nearly the same as Fido and Opus. The new list is basically the same as the previous list; however, it only outputs the files that are NEW for the user. This is something that Opus and Fido can't do. The matched file list, again, is nearly the same but only outputs the file list that matches the user supplied substring. | 40) 100% "C" code using SysV termio >But not all of the code is supplied - you must find your own source for kermit, > arc, ...... (see above) As stated before, IT IS SUPPLIED is additional files!! | P.S. The full source code can be retrived from my system (750K uncompressed) > Before you rush out and download it, be warned: > 1) The code is *VERY* unstructured. It looks as if the code was > written over a long period of time without any thought to > combining similar features - there are several places where > the code prints out the contents of a file (Message areas, > file areas, ...) and the routines are bulk copies of each other > with one or two quoted strings changed. Even the (wrong) comments > are the same! It's funny, you are the ONLY one that has said that the code is unstructured! There are 134 VERY happy users of the code to code. As a matter of a fact, MANY large computer companies have praised me for how well structured it is! There may be some code that is duplicated; however, each subroutine is unique! > 2) The code makes extensive use of the system() call to do even > the easiest of things. The code is quite slow when it comes to > these sections! I really wish you knew what you were talking about! The protocols are called via system calls and the raw listing. > 3) The message base, file handling, and bulletins (motd and others) > use non-standard layouts and fixed length record formats. They are MY format; therefore they are standard for xbbs! > 4) The code consists of one HUGE source file (107K) and about a > dozen small (< 5K) additions. Many of the parts share the > same comments - indicating that they all began life as the > same source file - (e.g., many claim to be "file area" listers > in the comments, even though the code prints out things like > "Message Areas".) Well, here goes proof of another bunch of garbage! file size file size bbsc1.c 67158 bbsc2.c 38111 bbscadds.c 3734 bbscarea.c 3591 bbscbult.c 5029 bbsconf.c 5431 bbscfile.c 15675 bbscio.c 2298 bbsclist.c 3012 bbscclock.c 2259 bbscmisc.c 1410 bbscmsga.c 7555 bbscport.c 7701 bbscqust.c 3219 bbsczip.c 4101 > If you are interested in doing a lot of work, his code isn't too bad > a starting place, but instead of hawking its new features he should > be cleaning up what he has. This code is definitely not "comp.sources.unix" > quality - it just squeaks by as being something that comp.sources.misc would > appreciate. (Sorry Brandon... :-) My lawyer will be VERY interested in the above comments along with previous comments! > I tried to talk to Sandy about this stuff (voice, my dime) and he implied > that he wasn't interested in anything I had to say. So be warned that things > don't look like they will get any better in the future... I don't even know who you are! MY COMMENTS ___________ I have NO idea why you would make my code sound so bad on the net. I only wish that you can sleep well at night after liabling me as much as you did. I am sure you will NOT hear the end of this. Sanford 'Sandy' Zelkovitz > -John > -- > Comp.Unix.Microport is now unmoderated! Use at your own risk :-)
dewey@execu.EXECU (dewey henize) (05/25/88)
Oh boy, does this mean we get to watch a liable case on the net? It should be a BLAST! (But perhaps it should be in alt.flame? :-))
pcm@iwarpv.intel.com (Phil C. Miller) (05/26/88)
In article <190@execu.EXECU> dewey@execu.UUCP (dewey henize) writes: >Oh boy, does this mean we get to watch a liable case on the net? It should ^libel >be a BLAST! (But perhaps it should be in alt.flame? :-)) Phil Miller
allbery@ncoast.UUCP (Brandon S. Allbery) (06/01/88)
Sandy: I suspect that your "attacker" has got us confused -- although where
he got a copy of UNaXcess 0.2 (aka UBBS) I'll never know, as it was ncoast
internal and not available for distribution.
I admit that some things are "block copied" (although file area maintenance
was not, it started out as an external program and needs more than a simple
"collapsing" of duplicate code to integrate). I've been cleaning them up
steadily (you, no doubt, wondered where 1.1 is? That's where -- that, and
a badly needed linting), and 1.1 will be modular.
"Non-standard file formats": some people praise me for using MH-style
messages, some flame me for it. I'm sticking with separate ASCII files.
You just have to expect flames from someone. (I expect I'll get MASSIVELY
flamed when 1.2 converts all the ASCII control files to hashed binary.)
Make your own choice -- and if someone else doesn't like those choices, they
can bloody well write their *own* BBS!
Yours in BBS authorship,
++Brandon
--
Brandon S. Allbery, moderator of comp.sources.misc
{well!hoptoad,uunet!marque,cbosgd,sun!mandrill}!ncoast!allbery
Delphi: ALLBERY MCI Mail: BALLBERYpeter@ficc.UUCP (Peter da Silva) (06/01/88)
Note: newsgroups line coalesced... The following are my nosey-parker comments about what I think (from context) must be some sort of UNIX-based BBS. I am currently running a UNIX-based BBS of my own devising, so... In article ... sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) writes: > The following are my replys to WRONGLY stated comments: > > The messages are in a non-standard format with all messages stuffed into > > one huge file. The messages are limited to a compile time maximum length. > Firstly, what is a standard message???? Either 1 message per file, a-la news, or <n> messages per file, a-la mail. In either case the files should be normal UNIX text files with no message length limits. > > 3) The message base, file handling, and bulletins (motd and others) > > use non-standard layouts and fixed length record formats. > They are MY format; therefore they are standard for xbbs! Fixed length record files are very rarely appropriate for a UNIX system. Certainly a low-performance application like a BBS doesn't need them. The downside obvious: you can't use an editor on them... -- -- Peter da Silva, Ferranti International Controls Corporation. -- Phone: 713-274-5180. Remote UUCP: uunet!nuchat!sugar!peter.
donegan@stanton.TCC.COM (Steven P. Donegan) (06/04/88)
In article <837@.UUCP>, peter@ficc.UUCP (Peter da Silva) writes: > > > > 3) The message base, file handling, and bulletins (motd and others) > > > use non-standard layouts and fixed length record formats. > > > They are MY format; therefore they are standard for xbbs! > > Fixed length record files are very rarely appropriate for a UNIX system. > Certainly a low-performance application like a BBS doesn't need them. > The downside obvious: you can't use an editor on them... > -- > -- Peter da Silva, Ferranti International Controls Corporation. > -- Phone: 713-274-5180. Remote UUCP: uunet!nuchat!sugar!peter. Gosh Peter (FLAMES ON), I have been using vi on my XBBS bulletins, control files and motd's for ages. You tell me that it's obvious that I can't do what I've been doing for about 2 years? I am getting rather sick of the totally unfounded and obviously uninformed comments of quite a few different individuals on Sandy's XBBS system. Most downside comments I've seen here so far prove that the individuals making the comments have never actually installed/operated/managed an XBBS system. I also take exception to the 'low-performance application' comment. XBBS is a very efficient, fast, responsive system that hides system load well. Users of the XBBS system note very little response degradation on a heavily loaded system, much less than a shell user on the same system. Come on folks, before flaming someones efforts to provide FREE software of any variety at least: Try it before bitching. Bitch constructively. Make sure of your FACTS. -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (06/07/88)
In article <51@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes: | Gosh Peter (FLAMES ON), I have been using vi on my XBBS bulletins, control | files and motd's for ages. You tell me that it's obvious that I can't do | what I've been doing for about 2 years? I suspect he mistyped that one. I'm sure what he meant was that the message file (note singular) is fixed length records. If you have a way to edit it with vi PLEASE let me know how you did it. | I am getting rather sick of the totally unfounded and obviously uninformed | comments of quite a few different individuals on Sandy's XBBS system. Most | downside comments I've seen here so far prove that the individuals making | the comments have never actually installed/operated/managed an XBBS system. Good hit 'n'instead of 'f', then. If I'm one of the individuals you mean, I've been running XBBS for months now (since before Christmas) and I agreed with a few of the original remarks, and still do. | I also take exception to the 'low-performance application' comment. XBBS is | a very efficient, fast, responsive system that hides system load well. Users | of the XBBS system note very little response degradation on a heavily loaded | system, much less than a shell user on the same system. Excuse me? I didn't say anything for or against the performance, but if you look at the accounting files for XBBS, it does use quite a bit of memory, CPU, and forks. I'm not sure anyone really said anything bad about it, but I think calling it efficient and fast is pushing the issue (as it calling it a pig). Let's look at some usage figures from the last few days... procname UID u-cpu s-cpu realtime avg-K line iochar ioblk ends bbsc1 xbbs 15.1 80.4 531.84 129.8 tty2A 313984 215 14:22:05 bbsc1 xbbs 3.3 27.0 233.12 144.2 tty2A 77376 85 22:10:34 bbsc1 xbbs 4.1 30.1 216.32 129.6 tty2A 67712 32 23:21:58 procname UID u-cpu s-cpu realtime avg-K line iochar ioblk ends bbsc1 xbbs 2.0 15.6 129.42 137.2 tty2A 49456 79 8:19:00 bbsc1 xbbs 3.3 25.8 259.04 127.1 tty2A 51208 91 12:05:47 bbsc1 xbbs 3.9 36.1 294.72 131.4 tty2A 116032 66 12:49:10 bbsc1 xbbs 8.7 73.7 1004.16 131.6 tty2A 181760 111 13:29:11 bbsc1 xbbs 2.3 23.6 352.00 140.8 tty1A 65376 86 13:39:12 bbsc1 xbbs 1.9 13.4 168.96 154.4 tty2A 53928 37 13:59:08 Note that the CPU is about 10% of the real time, and that the system time is a lot higher than the user time. This is a moderately large program. This is one a 386 system with lots of memory and fast disk. If you extrapolate to a 286 I can see that the performance might be a bit sluggish. On a loaded machine it might be pretty bad. All of these figures are from times when the load average was <0.3, so they represent mostly load from XBBS. Let's stop this "is too" "is not" stuff. I think a number of people will thell you that Sandy has not been responsive even to the point of responding to fixes for existing bugs. I said before that's his privilege, but don't expect support. The quality of the code is not debateable, let anyone who cares pull the latest version and see what they think. Nobody cares in the least about your opinion (or mine, the original poster's, or Sandy's for that matter). I think both XBBS and UNaXcess represent sharing of a great deal of work with the public, and both should be taken as "unsupported." Since I offer both of them, I have some perspective on the comparisons, and I agree that XBBS is quite hard to maintain, both in the code sense and the sense of day to day system operation. It's comparable to some DOS based systems in that respect, requiring renumbering messages, etc. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) (06/08/88)
In article <11115@steinmetz.ge.com>, davidsen@steinmetz.ge.com (William E. Davidsen Jr) writes: > In article <51@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes: > Let's stop this "is too" "is not" stuff. I think a number of people > will thell you that Sandy has not been responsive even to the point of > responding to fixes for existing bugs. I said before that's his > privilege, but don't expect support. The quality of the code is not > debateable, let anyone who cares pull the latest version and see what > they think. Nobody cares in the least about your opinion (or mine, the > original poster's, or Sandy's for that matter). > Bill, I think your comment about not being too responsive about bugs and support is a little unfair. I have spent MANY hours on the telephone with people about code problems ( mostly ports to other operating systems ) and, yes, bugs in the code. I try to fix them as soon as I am able to do so. You see, I do have to earn a living to support my family so I can't devote all of the time that I would like to on the cod. If I were able to do so, I definately would. Many of the "bugs" that are reported may be bugs on other ports of Unix; however, because I don't have the equipment to check it out on their hardware/software, I have to rely on other inputs as fixes. If I have not supported the code as much as others would like me to do so, I am sorry. Many of the "support calls" are long distance and, to be honest with you, I really do not want to pay for the call. Sandy
peter@ficc.UUCP (Peter da Silva) (06/16/88)
Let's see if we can avoid the flames, boys and girls... In article ... donegan@stanton.TCC.COM (Steven P. Donegan) writes: > In article <837@.UUCP>, peter@ficc.UUCP (Peter da Silva) (that's me) writes: > > > Someone wrote: > > > > 3) The message base, file handling, and bulletins (motd and others) > > > > use non-standard layouts and fixed length record formats. > > Someone else (presumably the author of xbbs) replied with a flip > > response to the effect: > > > They are MY format; therefore they are standard for xbbs! > So I took it upon myself to point out: > > Fixed length record files are very rarely appropriate for a UNIX system. > > Certainly a low-performance application like a BBS doesn't need them. > > The downside obvious: you can't use an editor on them... > Gosh Peter (FLAMES ON), I have been using vi on my XBBS bulletins, control > files and motd's for ages. You tell me that it's obvious that I can't do > what I've been doing for about 2 years? And the message base? Now then, I haven't used xbbs myself: my own unix based BBS is quite good enough for my purposes. However, based on the statements above it's not unreasonable to assume that "the message base, file handling, ... [of xbbs] use ... fixed length record formats". The author of the program didn't deny that, so I assumed that it was true. I thought it worthwhile to point out that fixed length record files have certain disadvantages. Now then, based on *your* reply I must assume that at least the bulletins, control files, and motds are not a fixed record format. You didn't mention the message base and (I presume) user files and mailboxes, so might I assume that these are really fixed-length record files? OK, let's go on... > I am getting rather sick of the totally unfounded and obviously uninformed > comments of quite a few different individuals on Sandy's XBBS system. Most > downside comments I've seen here so far prove that the individuals making > the comments have never actually installed/operated/managed an XBBS system. No, but I have installed, operated, and managed several other BBS systems of my own and others devising. I have used systems (and to my shame written one) that have fixed length record files, as well as systems that use standard UNIX-style text files. I must say that it was *much* more pleasant to work on the latter. > I also take exception to the 'low-performance application' comment. XBBS is > a very efficient, fast, responsive system that hides system load well. Users > of the XBBS system note very little response degradation on a heavily loaded > system, much less than a shell user on the same system. A bulletin board is a low performance application. It does not require fast response time, nor does it require a lot of number crunching. In general, a bulletin board system is limited by the physical I/O speed of the disk drives more than anything else -- including parsing message headers and responding to keystrokes. You might very well have a fast bulletin board, but I really doubt that fixed-length record files should be given the credit. > Come on folks, before flaming someones efforts to provide FREE software of > any variety at least: Here is where I would definitely flame on if I were the type to do so. I did not flame the author of XBBS. I merely pointed out a well-established fact about unix-based systems, to wit that all the tools are oriented towards text files. > Try it before bitching. I have. > Bitch constructively. I though I was. > Make sure of your FACTS. No-one can ever be 100% sure of their facts. One can only operate on the best information available to them. The best information I have, based on messages from the author of the software, among other people, is that it does not use text files to store user messages. I believe this is a mistake. I have explained why. Next time, before flaming, go check out news.announce.newusers. -- -- Peter da Silva, Ferranti International Controls Corporation. -- Phone: 713-274-5180. Remote UUCP: hoptoad!academ!uhnix1!sugar!peter.