NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/alt/bbs/7139

Internet Message Format | 1992-11-22 | 3.8 KB

Path: sparky!uunet!mcsun!sun4nl!hacktic!utopia!global!peter
From: [e-mail] (Peter Busser)
Newsgroups: alt.bbs
Subject: Re: TBBS versus RA/Netware
Message-ID: <[e-mail]>
Date: Sun, 22 Nov 1992 12:55:29 GMT
References: <[e-mail]> <[e-mail]>
Organization: Global Village 1
Lines: 63

[e-mail] (Chris Blaise) writes:

>> Aren't that enough reasons (besides that it is expen$$$$$ive?)???

>    I don't think they're enough, no.  I think TBBS's strength's
>lie in it's speed and incredible customization ability.

Other BBS systems are also incredible customizable. Maximus for instance. I
don't know about the speed of a multi-node Maximus BBS system (I'd prefer OS/2
as multi-tasker in such a case and definetly not DOS+DV or Windows).

>  It's also
>fairly easy to setup, the complexity based on how complex you want to
>make the system *grin*

So is Maximus. Install it and you already have a complete BBS system. Including
built-in multi-line chat. Furthermore, you don't need a mailer on each line to
pick up the phone as Maximus can do that (you still need a mailer for the
FidoNet stuff). Squish puts the messages either in an old fashioned .MSG message
base or in a Squish message base. You can either use DOS utilities or OS/2
utilities under OS/2. And under OS/2 you don't need to worry about future
compatibility of the message utilities; they use a dynamic loadable library
and don't mess with the messages themselve. The DLL also handles locking so
that concurrent access to the message base is okay. Okay, I guess it isn't
possible to run MS-DOS door games under OS/2, but what the heck, TBBS can't
do it either! ;-) OS/2 needs more memory than TBBS, that's for sure, but not
buying TBBS save so much money that buying extra memory isn't a problem... ;-)

>cheaper for the performance you get.  I know of no DOS BBS program
>(thinking of RA, QuickBBS, PCBoard, etc.) that will run this many lines
>on a single CPU without any loss of performance for the other users
>on the other lines without going the multi-machine/for/multi-node
>route.

(Insisting that it should run under DOS is silly since you can't use it from
within TBBS anyway. If you insist on comparing TBBS with other DOS systems,
then I insist that you pull out the smart serial board(s) and run TBBS on
normal 8250/16450 serial chips! Read on...)

Well, the real reason isn't that systems like RA, QBBS, PCBoard, Wildcat,
Maximus, Opus, Magpie, Telegard, SBBS, and all the others are more ineficient
than TBBS. Okay, they take more memory but the difference in price can easily
compensate that. The real reason is that TBBS supports smart multi-port boards
and the others don't. These boards do the real work. TBBS just supervises these
boards and only needs to send a block of bytes to such a board once in a
while. On a system with 16 lines, all actively downloading at high speed, you
should see only a few percent CPU usage. If TBBS had to do all the character
I/O to and from the serial ports, then there wouldn't be such a difference in
performance between TBBS and any other DOS BBS program. Not even though DV
has probably more overhead than TBBS.

This means in short that it isn't TBBS that is responsible for the speed, it's
the hardware. Fortunately, supporting smart hardware isn't a unique TBBS
feature. An OS/2 or UNIX system which had drivers that could use the same
boards as TBBS would be as fast if not faster (probably better file system and
*less* (that's no typo) OS overhead) than DOS+TBBS. The same kind of boards
exist for UNIX. They might exist for OS/2 too. Any BBS system that can support
a UNIX tty device or an OS/2 COMxx: device can use these boards and get the
same or better speed as TBBS.

THERE IS NO ADVANTAGE IN RUNNING TBBS. There *WAS* maybe a reason, but there is
none anymore.