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 :-)
wtr@moss.ATT.COM (05/24/88)
In article <208@turnkey.TCC.COM> sandy@turnkey.UUCP writes: >The following are my replys to WRONGLY stated comments: [bundles of stuff deleted about xbbs] sandy, please dont delete the "In article..." line, i would have liked to do this by e-mail, but i don't know whom the previous poster was, thanx. >> 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 [...] >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 and i'm sure we won't either..... sandy, before you get your feathers all ruffled, realize that john has the right to review your product and post a summary of his opinion to the net, just as YOU initially did. his opinions are not always going to be complimentory (more on this later). you have to face the fact that not everybody is going to drop what they are using and praise your product. they are going to see their own 'flaws' in what you may consider to be perfectly decent code. hell, i hate it here at work when somebody critiques my code, but it has to be done, and in general it improves the product. (well, sometimes, but i'll never admit it to them ;-) and while we're on the discussion, let's just DUMP all this lawyer talk. it's bullsh*t and reminds me of when i was a five year old: "well my uncles a lawyer, and if you take my toy he'll SUE you!" i thought we'd learned better after flaming apple for two consistant months. your product is public domain, and like-wise draws public domain criticism, no warantee implied, original author not responsible for result of the use of this product, nor any damages incured as a result. you've had your ego pretty bruised, but you'll live. JOHN- now that i've pointed out a few things to sandy, it's time to point out a few things in your article. first of all, your review was about as subtle and impartial as a charging hippo. you tore apart sandy's code with very little eye for any nice features, nor any appreciation for the effort that went into the untaking. you judged the code based upon the assumption that your tastes and personal judgements were the apparent word of god, or at least a major representative thereof. some of the flames that you made were about features that i found useful and even desirable. furthermore, apparently you did not bother to checkout a few fact before flaming on (module size comes initially to mind) overall, i think your review pointed out some good things to look out for in the code, but i certainly would NEVER base my own judgement on your review. lastly, this software is public domain (as i have already reminded sandy.) you little quip about not being comp.sources.unix quality was a real snide remark, and definitely not appropriate. sandy's code is not POSTED! he was pointing out it's availibility on his system. you are not one to judge the effort it took to program this monster, nor judge it's utility to others. i'm sure that sandy would more than welcome suggestions about improvements, cleanups, and fixes. posting a software 'offering' to the net is one of the best ways to solicit these things. you offered NONE of these in you article. okay, let's finish this up: i'm only posting to unix.microport and unix.questions, followup to unix.questions, in case there is any. you two NEED to get together and work this out, as two potential adults, between yourselves. use email or the phone, i don't care. but get it OFF the net. if you wish to flame me, or at least discuss it, see the signature below. GET A GRIP PEOPLE! ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...![ ihnp4 ulysses cbosgd allegra ]!moss!wtr ...![ ihnp4 cbosgd akgua watmath ]!clyde!wtr =====================================================================
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: BALLBERY