Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.banyan-l
Date:         Tue, 10 Nov 1992 19:11:57 ADS
From:         Ian.Brabham@CC.MONASH.EDU.AU
Subject: Re: Banyan versus Novell

Dear all,

>> As with any namespace management if it is not thoughtfully layed out then
>> it can be a real pig to use.
>For most students, even computer literate ones, e:\apps\bcpp is bad enough,
>"BCPP@APPS" if worse, and the more normal Banyan-ite
>"Borland C++@Applications@MathCS" is ridiculous.

My my what a totally twisted and crippled way of viewing the world.  This
must be a real pig to use.  None of our users, Banyan or Novell, ever need to
know a streettalk name or server/volume name (apart from their own account
name).  Much less the Dos pathname to an application.  They can use them if
they wish but we provide batch files, default paths and default names so a
users need never see all the nasty mechanics of how things really work.

>Couple that with the lack of a reasonable method for adding to the path,
>e.g., the Novell MAP INS S1:= construct, and StreetTalk is a royal pain
>in the butt for most users.

The MAP INS S1:= construct would have to be one of the most confusing and
time wasting constructs anybody ever half implemented.  The number of times
people, who should know better, try to use this from a spawned Command.Com and
get so totally confused and befuddled I can just not believe.  There are at
least half a dozen public domain path manipulating programs available, all
of which do an infinitly less butcherous job than MAP INS does.  MAP INS
appears to be a nifty concept but it just encourages the weak minded to make
an even bigger mess of there batch files.

Besides what has MAP INS got to do with StreetTalk.  StreetTalk has nothing
to do with Dos paths.

>>>Banyan's greatest weakness is StreetTalk.  It is a performance hog.
>>Generally StreetTalk access within a local group is on a par with Netware
>>bindary access.  ...........        If Novell have done
>>rev 4 properly this will become a new variable Netware 4.0 administrators
>>may have to come to terms with.
>Absolutely false.  Every review that has ever been done has shown that there
>is a very large overhead to StreetTalk, and the overhead is geometrically
>proportional to the largest group that resides on a given server.  There
>is no case in which StreetTalk overhead and Novell bindery overhead are
>even remotely comparable.

Richard I am starting to suspect you really don't have any idea what
StreetTalk really is or how Vines services use it.  StreetTalk like the
Novell bindary is just a simple database, you feed them a key (ST name or
property ID) and they return you some data simple as that.  It is really
quite efficient at doing that.

Ever seen what happens to SYSCON when you put 2000 usernames into the
Bindary I have had tried it and it is not a pleasent sight.  To be fair
MUSER was not to flash when asked to select the whole 2000 but at least
you could ask for a subset.  There is definitly no geometric degradation
in StreetTalk performance with large groups it is in fact very close to
the ideal n*log(n) rule.  Rev 4 ARL processing is a differnet matter.

>>>InfoWorld's review of VINES 5.0 (the Banyan product that can take
>>>a Mac add-on) found that VINES performance (throughput) was 1/3 that
>>>of a similar Netware 3.11 network with 24 simultaneous users,
>>The default tuning parameters Banyan set for Vines are frequently not
>>very appropriate.  This is almost certain for ultimate load testing.

>Banyan assisted InfoWorld in tuning the server.  There was still a 3X
>difference with 24 users - a very lightly loaded server.

I sort of doubt this, maybe someone from Banyan Technical support has
some comments on the subject.  I live in Australia and haven't seen the
InfoWorld review so for all I know you are comparing apples to grapefruit.

>>>          Banyan also has a nasty habit of making you upgrade to a new
>>>version to get new features.
>> I cannot think of any vendor (software of other) who does not do this, it
>> is a commercial reality if you give things away you go broke.
>What about Source Routing support.  Novell supplied it with 2.15C, but
>made the parts available so that anyone with 2.1x could add it.

Yes they supplied the parts.  With Netware you get to roll your own for
better or for worse.  With Vines it's preassembled so you don't get to bolt
on a new carby or add fuel injection yourself.  It's a pity in some ways
but it also protects you from your own worst enemy, yourself.

>What about Windows client support; Novell supplied it for every version
>later than 2.10, even though it came out when 2.15C was shipping.

They provided lots of versions of NET3/4/X many of which crashed your server
and/or exhausted your Dynamic 1 memory pool.  We still have occasional
difficulties due to IPX/NETX revision incompatibilies.

>Banyan required an upgrade to 4.10 (and did not provide it until >2 years
>after Windows 3.0 came out).  Same with OS/2 support.  Banyan requires an
>upgrade for every new little piece of software/hardware that is released!

It's a price you pay for having the luxury of a NEWREV mechanism.  All of
a given rev of Vines goes together and works together.  Sure I can patch the
4.11 drivers onto rev 5.00 and mostly they work but I loose all that nice
secure newrev protection and knowing when I get a user problem it is not
going to be some clown using a 2.01 ipx with a 3.20 netx.

>If I want OS/2 2.0 support I will need to do YAU - Yet Another Upgrade.

You could alway apply to be put on the restricted release program and you
could alway pay for software subscription and get it as a matter of course
just like we do with Digital and Pyramid and Unisys and Banyan.

>+-----------------------+-------------------------------------+
>|   Richard M. Warner   |   Internet:  rick@sjsumcs.sjsu.edu  |
>|                       | CompuServe:  71121,2257             |
>+-----------------------+-------------------------------------+
>|  ** DISCLAIMER:  All opinions are strictly my own.  I work  |
>|                  hard enough at forming them!               |
>+-------------------------------------------------------------+

Ian Brabham                 email: ian@banyan.cc.monash.edu.au
Micro Support Group         phone: +61 3 565 4742
Monash University           fax:   +61 3 565 4746
Melbourne Australia
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU