cschenk@daitc.daitc.mil (Cliff Schenk) (11/16/88)
Has anyone had any experience with Banyon VINES (Virtual Networking System). How does it stack up against NetWare 2.1? I am impressed with some of Banyon's design strategies and guidelines. It appears to be a nice implementation of the seven-layer ISO model and the fact that it was developed and runs on a real operating system (UNIX), is favorable (no flames please). Future ports are planned for DEC's VAX using VMS, and IBM's 9370 running under VM. They reportedly have a version running internally on a VAX running BSD 4.3. Of intrest are its asynchronous remote bridging capabilities and customer service. How do the security features compare with NetWare 2.1. Comments from anyone who uses VINES would be very helpful. Thanks in advance, Cliff -- Disclaimer: These views are my own and in no way represent that of CDC or The Defense Applied Information Center (DAITC). Cliff Schenk DOMAIN cschenk@daitc.daitc.mil Control Data Corporation PATH ..!uunet!daitc!cschenk Defense Applied Information Technology Center Phone 703/998-3481
john@stiatl.UUCP (John DeArmond) (11/16/88)
In article <238@daitc.daitc.mil> cschenk@daitc.daitc.mil (Cliff Schenk) writes: >Has anyone had any experience with Banyon VINES (Virtual Networking System). >How does it stack up against NetWare 2.1? > >I am impressed with some of Banyon's design strategies and guidelines. >It appears to be a nice implementation of the seven-layer ISO model and >the fact that it was developed and runs on a real operating system (UNIX), >is favorable (no flames please). Future ports are planned for DEC's VAX >using VMS, and IBM's 9370 running under VM. They reportedly have a >version running internally on a VAX running BSD 4.3. > >Of intrest are its asynchronous remote bridging capabilities and customer >service. How do the security features compare with NetWare 2.1. > >Comments from anyone who uses VINES would be very helpful. > >Thanks in advance, >Cliff > >-- >Disclaimer: These views are my own and in no way represent that of CDC or > The Defense Applied Information Center (DAITC). > >Cliff Schenk DOMAIN cschenk@daitc.daitc.mil >Control Data Corporation PATH ..!uunet!daitc!cschenk >Defense Applied Information Technology Center Phone 703/998-3481 Newsgroups: comp.dcom.lans Subject: Re: NETWARE 2.1 vs. VINES Summary: Expires: References: <238@daitc.daitc.mil> Sender: Reply-To: john@stiatl.UUCP (John DeArmond) Followup-To: Distribution: Organization: Sales Technologies Inc., Atlanta, GA Keywords: LAN WAN Networking Unix In article <238@daitc.daitc.mil> cschenk@daitc.daitc.mil (Cliff Schenk) writes: >Has anyone had any experience with Banyon VINES (Virtual Networking System). >How does it stack up against NetWare 2.1? > I have an extensive amount of experience with Novell as a user and as a developer and a significant amount of experience with Vines. From my vantagepoint, Vines is not even in the same league with Novell. I'm afraid that the fact that Vines uses a unix system as a server blinds many people. The fact of the matter is, it does not really matter what hardware platform is used for a server as long as it's performance is adequate and it is reliable. I've found that an 8 mhz AT is more than fast enough to handle a single port (by that i mean one network port on the server) LAN and a 386 class box is more than enough to handle multiport LANS with bridges (novell). Lets look at a few differences between Vines and Novell. PC memory usage: Vines needs about 150k (>200k with their terminal emulator) Novell needs about 40k. Spooler control. Vines pipes to the unix lp server which means that only the superuser can kill a job once it's spooled. Novell has a nice full screen queue manager that any user can access. if the user has supervisor security, he can manipulate any user's queue. Access control. vines uses the unix file system pretty well intact so it is open to all the known (and unknown) methods of hacking. I consider it very insecure from this point of view. Novell uses a proprietary server disk format. DOS cannot access it. If additional security is needed, remove the floppy drive from the server. There are utilities that will allow dos to access the novell file system but they must be run from the server which requires physical access - a pretty good security barrier. File security Vines provides standard DOS file security (I make this statement with some hesitation because I'm not real sure. The docs are so poor I have not found much of anything on the subject.) Novell provides much finer granularity and detailed security including write only read only create (does not imply read or write) search directory overwrite delete parental rights (do these priviledges apply to subdirectories.) The supervisor supplies a default mask that determines how a file is created using DOS calls. These can be changed either by a Novell utility or by an extended Novell system call. Network Media support Banyon runs on Ethernet (and not all adaptor cards) Novell supports all network hardware available for the PC including dialup asynch services. Up to 4 network adaptors can be placed in a server. Mix or match. Stability Vines (at least the version we have here) is very unstable. It "looses" files on the pc drive. These magically reappear when the network server is stopped and restarted but it interrupts all network activity. Happens a couple of times a day around here. In any event, the file system is subject to all the known unix weaknesses. I have never personally seen a Novell server malfunction, though I know others that have. It is a VERY rare occasion. The system has many safeguards such as cache flushing which provide a reasonable probability that the system will survive even an arbitrary powerdown. Fault tolerant Vines has none I'm aware of. Novell SFT (system fault tolerant) provides a fault tolerant transaction based system that is extremely secure. You can mirror the file system on 2 drives or across 2 servers. There is full transaction control facilities including integrety checks and backouts. There is an interface to a UPS so the system can auto shutdown when the UPS low battery alarm goes off. Novell had some teething problems with this product and there are some bugs still but it's a good product. Support Vines has minimal that I've seen. (these comments are strictly from a user viewpoint not an administrator). Last summer Banyon sent us an update tape that had some kind of copy protection on it. When the tape was installed, it took the server down. It stayed down for 2 WEEKS. I'm not particularly aware of the dirty details but neither did I see many frantically waving arms belonging to Banyon people as I would expect under such disaster condx. The novell bunch are somewhat a bunch of pricks to deal with but when you do get support, it is excellent. As an enduser, you must pay 50 bux per 15 minutes of support. A dealer or ISV gets good, free support. Novell has dropped the hardware copy protection scheme for it's server software so the system should have no copy-protection related problems. Documentation The Vines documentation I've seen around here is sparse and obscure. They are caught up in using cutsie names like StreeTalk for services instead of naming them for what they do. Novell comes with about 10 pounds of relativly good docs PLUS a "guide to documentation" book that servers as kinda a dispatch table to other manuals. Nice. Market share (important because it is an indicator of 3rd party support) Novell claims about 70% of the PC networking market. I have no idea about Banyon. Cost Novell software costs in the vicinity of $2,000 or so depending on how you get it and what options you get. A fast AT-based server platform can be configured for less than $3,000. There are no restrictions on number of users other than a server limit of 100 per subnet. I don't know the pricing of Vines but I'd expect the software to be more expensive - Unix software almost always is. Then consider that you must have a fast Unix box to run it on (at least if you want the unix side to remain useful) so figure maybe 20 grand for that. I have no facts but I've heard that there are user restrictions on Vines. Summary Vines DOES provide a couple of functions that are nice, such as a fairly poor terminal emulator for Unix but on the whole, Novell has it beat on all fronts. Just to bare my biases . I've sold Novell for many years as a network consultant. I arrived at Novell after looking at what's out there. I have to remain fairly current in others' products in order to justify Novell. I do like other networks such as TCP/IP or ViaNet but I promote Novell when the service is severe and reliability is paramount. I particularly do not like Vines. It's been interesting comming into a Vines environment and working here for the last 6 months. I have been able to look at Vines with a background of knowing the features of competitors' products. From this point of view, Vines is very lacking. Please also note that these are personal opinions totally separate from my work here at Sales Technologies. John John De Armond Sales Technologies, Inc. Atlanta, GA ...!gatech!stiatl!john
dab@ftp.COM (Dave Bridgham) (11/17/88)
I've not used either Banyan or Novell enough to comment on most of John's message, but I do know that Vines is not limited to ethernet. It also runs over 802.5 rings, ProNet-10 rings, starlan, arcnet, and omninet. There may be others; there were some cards in the list that I didn't recognize. David Bridgham
tim@j.cc.purdue.edu (Timothy Lange) (11/18/88)
Following up John's message. Novell does NOT do server mirroring, just disk mirroring. Server mirroring would be much better, disks are not the only failure point. Cost wise, setting up equivalent Banyan and Novell networks, Banyan will be about twice as much. When you start to add in options like TCP/IP service, Async comm service, they are about the same. Again, you really need specifics to compare the two. We are setting up a lab with 30 machines, the Banyan dealer said we should buy the CNS server ($29,000!!), to support that many. I am using Zenith 248 (8Mhz 80286) to support 23 machines with Novell, so I think the dealer was pushing a little. Tim. -- Timothy Lange / Purdue University Computing Center / Mathematical Sciences Bldg West Lafayette, IN 47907 / 317-494-1787 / tim@j.cc.purdue.edu / CIS 75410,525
johnk@banyan.UUCP (John Krawczyk) (11/18/88)
Cliff Schenk of Control Data Corporation asked for comments from VINES users. He was particularly interested in how VINES stacks up to NETWARE 2.1. John De Armond of Sales Technologies, Inc., responded with a comparison of VINES and NETWARE features. As an employee of Banyan Systems (note the spelling), I would normally just sit back and read this discussion (Mr. Schenk did ask for users' opinions, not the vendors), but Mr. De Armond's response was so riddled with inaccurate statements about VINES and a strong bias toward Novell that I feel I must respond. Please note that these are my opinions and this is not an official statement from Banyan Systems, Inc. > [Mr. De Armond's text] > Spooler control. > Vines pipes to the unix lp server which means that only the superuser can > kill a job once it's spooled. VINES has no concept of a Super-User. System Administrators can be created as needed and are not necessarily tied to a specific server. Users on a VINES system (including Sys Admins) are not UNIX-type users. The SETPRINT command (executable from the PC) allows spooled jobs in a print queue to be cancelled, held, or reprinted. Of course, if you are just an ordinary user, you can only affect your own jobs, whereas System Administrators have more control. > Access control. > vines uses the unix file system pretty well intact so it is open to all the > known (and unknown) methods of hacking. I consider it very insecure from > this point of view. The UNIX file system on the server is not visible from the PC clients. Also, the server box is not a general purpose UNIX machine. It runs a modified version of UNIX tuned to maximize network performance. The machine is not used for traditional UNIX access. Because of this, it is extremely difficult to get at the UNIX file system. > File security > Vines provides standard DOS file security (I make this statement with some > hesitation because I'm not real sure. The docs are so poor I have not found > much of anything on the subject.) VANGuard, which has been available since early 1988, combines user passwords and ARLs (access rights lists) to provide comprehensive security across a VINES network. This service has been exceptionally well received by users, who compare it to mainframe security packages, such as IBM's RACF and Computer Associates' Top Secret. ARLs have long been a feature of VINES. They protect every network resource. From the SETARL (set access rights list) help screen: SETARL allows you to determine which users can access a directory on a network volume, and what type of access they have, as follows: C or control - change access rights, plus read and write files. M or modify - read and write files. R or read - read files. N or none - no access. > Network Media support > Banyon runs on Ethernet (and not all adaptor cards) Banyan VINES does run on Ethernet. It also supports several versions of Token-Ring, PC-NET, Pronet-10, ARCNET, VistaLAN, StarLAN, OMNINET, and Northern Telecom's LANSTAR. IBM's 16-Mb Token-Ring is coming soon. In addition, wide-area networking (async and X.25) is supported in the same servers concurrently. The number of cards per server depends on which box you are using (non-proprietary: 286, 386; proprietary: CNS, BNS, DTS). > Stability > Vines (at least the version we have here) is very unstable. It > "looses" files on the pc drive. These magically reappear when the > network server is stopped and restarted but it interrupts all network > activity. Happens a couple of times a day around here. In any event, > the file system is subject to all the known unix weaknesses. A dissenting point of view from another user, as it appeared in PC Week, September 26, 1988: "... the Banyan hardware has proven very reliable. We run our servers 24 hours a day, seven days a week. We've only had one server crash, and that was due to a hard-disk problem on the LAN." > Documentation > The Vines documentation I've seen around here is sparse and obscure. > ... Novell comes with about 10 pounds of relativly good docs I am reminded of a TV commercial a few years ago that showed an IBM system delivered with a pile of documentation and an Apple with one small manual. The major VINES features are self-documenting. Pressing F1 within an application displays the help documentation. > They are caught up in using cutsie names like StreeTalk for services > instead of naming them for what they do. StreetTalk is the VINES global naming mechanism for network resources. This includes users, file services, and print services. The mechanism is truly virtual; it does not tie a resource to a physical location on a complex net. If I decide to move a server from my local Ethernet to the other side of the country and connect it via HDLC, all of the services on that server can still be accessed by the same name. More than a cute idea, I think. Patricia B. Seybold, in the Jan. 1988 issue of Computer and Communications Decisions, claimed, "The only LAN operating system that offers this degree of transparency is Vines from Banyan Systems, Inc." Mr. De Armond claims: > I have an extensive amount of experience with Novell as a user and as a > developer and a significant amount of experience with Vines. I do not doubt his extensive Novell experience. But when he makes statements like: > I make this statement with some hesitation because I'm not real sure. > Banyon runs on Ethernet (and not all adaptor cards) > Market share ... I have no idea about Banyon. > I don't know the pricing of Vines but I'd expect the software to be more > expensive - Unix software almost always is. > I have no facts but I've heard that there are user restrictions on Vines. I seriously doubt that he has "significant experience" with VINES. His response especially displays a lack of understanding of how Banyan uses UNIX and what platforms we use for servers. Mr. Schenk, I'd encourage you to seek out the opinions of many users (don't trust everything I say either ;-) ). Finally, (I'll make this short, really), check out the June, 1988 edition of Data Communications for the article "Users rate their LANs". The first page shows a graphic of the vendors that rated "above average" in the survey. Banyan scored a 3.5/4.0 to top the list. Novell is missing... ------------------------------------------------------------ John J. Krawczyk Banyan Systems, Inc. ...buita!banyan!johnk 115 Flanders Road Westboro, MA 01581
max@claris.com (Max Rochlin) (11/18/88)
At my previous workplace I worked with Banyan systems for about two years. Rather than get ing the crossfire between a vendor and a manufacturer, I'd like to share my experience. I do not have first hand knowledge of Novell. Banyan is very easy for an end user, if he has enough memory. Of all the networks ( PC-LAN, IBM Token-Ring, Novell, etc) Banyan requires the most memory. Connectivity: If you have a PC with one of the supported network cards you should have no problem..Banyan _is_ very pickey about 3COM/ethernet card version, but then again, so is 3COM. Banyan was kind enough to ship a server to my company for testing with an unsupported network card. If you want to connect your Mac to the network you have a while to wait, and when you'll be able to connect a Mac to the network Banyan has not announce Mail support for the Macs on their net. So, initally their Mac support will be limited. Speed: Banyan used to be _very_ slow. Version 2.15 of the software upgraded the speed of the network and server to just plain slow. There are odd spped quirks with Banyan and the numbers of users using specific program. Our network was ether based, swtiched to twised pair thru a David Switch. That may have impacted the network speed. I sure made it cost more ( > $1500 a connection, server price not included) Security: The ARL security system is a blessing and a curse. It is very secure from and enduser viewpoint. Problems arise when you realize that your companies naming conventions is limited and you have to rename groups. There is no mass way to change access rights and your system admin will be spending DAYS in the ARL menu changing files and/or subdirectories one by one. UNIX: The UNIX is well hidden, and you can only get to it from a console and only if you know the right incantations. UNIX is neither a plus or a minus in this case with the one exception of that since all the Banyan services are UNIX services if you run out of disk space the server crashes. The system will attempt an orderly shutdown of sorts, but if you open a file and keep writting out to the server it will die. Printing: Printing services are pretty good. Problems arise when custom page size names and created by the system admin. Jobs just sit in the print queue. This is very similar to mainframe forms selection and isn't a big problem. One big problem IMHO is that you can't re-assign jobs to a different printer queue. If a printer goes down you can hold all the print jobs in a particular queue or cancel them but you can't send them to a printer that is OK. Distributed services: If you have three servers ( called Sales, Marketing, and Finance) and someone from Marketing attempts to sign on if the Sales server sees the log-on attempt it will provide the routing services. There is no way to limit routong services. This creates confusion. IF I'm in Finance and I am being routed thru the Marketing server and the Marketing server crashes I'm going to wonder why I got blown away. Support: Spotty. You'll get great response if server sales are pending and Banyan knows the answer to your problem. I am told it really depends on your sales office, but I guess that's true of Novell, too. BACKUP: Backing up a BNS server is a Pain ( or so I was told by our system admin). They do not support 9-track tape. Many fun hours were spent putting DC-600 tapes into the servers to back up gigabyte servers. I hope that by now Banyan supports 9Track or 8mm tape backup. If your server is bothersome to backup it won't be. COST: Expensive. The servers are expensive. They can't be used for anything else. Great marketing scheme. My summary: If you have lots of money, PCs with 640K of ram, and need a network that is easy to use with lots of menu systems, Banyan is OK. If I were interested in UNIX based file servers for DOS that are less expensive, just as esy to use, and not as memory hungry I'd look in to AT&T Starlan. . --------------------------------------------------------------------------- The opinions expressed above are mine. Your actual mileage may vary. /---------------------------------------------------------------------\ |UUCP: {ames,apple,portal,sun,voder}!claris!max Applelink: Rochlin1 | | {ames,apple,portal,sun,voder}!claris!madmax!max [home system] | |Internet: claris!max@ames.arc.nasa.gov Phone: 415-960-4052 \---------------------------------------------------------------------/
john@stiatl.UUCP (John DeArmond) (11/18/88)
In article <339@banyan.UUCP> johnk@banyan.UUCP (John Krawczyk) writes: >Cliff Schenk of Control Data Corporation asked for comments from VINES >users. He was particularly interested in how VINES stacks up to >NETWARE 2.1. John De Armond of Sales Technologies, Inc., responded >with a comparison of VINES and NETWARE features. As an employee of >Banyan Systems (note the spelling), I would normally just sit back and >read this discussion (Mr. Schenk did ask for users' opinions, not the >vendors), but Mr. De Armond's response was so riddled with inaccurate >statements about VINES and a strong bias toward Novell that I feel I >must respond. > >Please note that these are my opinions and this is not an official >statement from Banyan Systems, Inc. Well, I guess JohnK is talking about a european version of Vines or vaporware or something? :-) The system we have bears little resemblance to what he describes .. read on dear reader. > >> [Mr. De Armond's text] >> Spooler control. >> Vines pipes to the unix lp server which means that only the superuser can >> kill a job once it's spooled. > >VINES has no concept of a Super-User. System Administrators can be >created as needed and are not necessarily tied to a specific server. >Users on a VINES system (including Sys Admins) are not UNIX-type >users. > >The SETPRINT command (executable from the PC) allows spooled jobs in a >print queue to be cancelled, held, or reprinted. Of course, if you >are just an ordinary user, you can only affect your own jobs, whereas >System Administrators have more control. I guess he's right for the few seconds the print job stays in the VINES spooler. The Vines spooler hands the job off to Unix lp just as soon as it can. THEN you gotta be a superuser to kill it. Witness the following from the que command on our system: scheduler is running system default destination: fort device for fort: /dev/tty017 device for proprt: /dev/tty016 device for hplaser: /dev/tty014 hplaser-3348 banps 4000 Nov 18 10:08 on hplaser ^^^^^^^^^^^^^^^^^^^^^^^^^ This is the print job created on unix by my issuing the command "copy doc prn" from dos while logged in. (ps: The network went down while I was trying to create this job :-) ). It took about 3 seconds for Vines to hand off to lp. > >> Access control. >> vines uses the unix file system pretty well intact so it is open to all the >> known (and unknown) methods of hacking. I consider it very insecure from >> this point of view. > >The UNIX file system on the server is not visible from the PC clients. >Also, the server box is not a general purpose UNIX machine. It runs a >modified version of UNIX tuned to maximize network performance. The >machine is not used for traditional UNIX access. Because of this, it >is extremely difficult to get at the UNIX file system. Our system runs on a plain 'ole Convergent MightyFrame which is a 68020-based Unix sVr2 box. I'm running vi on it right now. > >> File security >> Vines provides standard DOS file security (I make this statement with some >> hesitation because I'm not real sure. The docs are so poor I have not found >> much of anything on the subject.) > >VANGuard, which has been available since early 1988, combines user >passwords and ARLs (access rights lists) to provide comprehensive >security across a VINES network. This service has been exceptionally >well received by users, who compare it to mainframe security packages, such >as IBM's RACF and Computer Associates' Top Secret. > >ARLs have long been a feature of VINES. They protect every network >resource. > All of that may be true, but Vines STILL runs over ordinary unix. Witness the following created with the DF command on unix: /disk2 (/dev/dsk/c0d1s1): 64744 blocks 12290 i-nodes /disk1 (/dev/dsk/c0d0s4): 3254 blocks 9297 i-nodes /usr (/dev/dsk/c0d0s3): 3150 blocks 8198 i-nodes / (/dev/dsk/c0d0s1): 9274 blocks 2516 i-nodes disk1 is our Vines volume. I can prowl in there with impunity assuming I have the proper unix permissions (superuser at this site, but big deal!) We have shell scripts that move files from the Vines to the Unix system and back (takes care of filename translation, <cr><lf> to <nl> conversion and so on) > >> Network Media support >> Banyon runs on Ethernet (and not all adaptor cards) > >Banyan VINES does run on Ethernet. It also supports several versions >of Token-Ring, PC-NET, Pronet-10, ARCNET, VistaLAN, StarLAN, OMNINET, >and Northern Telecom's LANSTAR. IBM's 16-Mb Token-Ring is coming >soon. In addition, wide-area networking (async and X.25) is supported >in the same servers concurrently. > I'm not familiar with all the hardware banyan may sell but since the question was based around Unix systems, that's what I've addressed. I really have not seen a mass of advertizements for Token Ring, Pronet, ARCNET or other adaptors to go in our Convergent. :-) > >> Stability > >> Vines (at least the version we have here) is very unstable. It >> "looses" files on the pc drive. These magically reappear when the >> network server is stopped and restarted but it interrupts all network >> activity. Happens a couple of times a day around here. In any event, >> the file system is subject to all the known unix weaknesses. > >A dissenting point of view from another user, as it appeared in PC >Week, September 26, 1988: "... the Banyan hardware has proven very >reliable. We run our servers 24 hours a day, seven days a week. >We've only had one server crash, and that was due to a hard-disk >problem on the LAN." > Johnk very unskillfully avoided the issue here. Our current (upgrade a couple months back) version looses files regularly and will almost always require a restart whenever a DOS user creates a subdirectory. Again, this is for the Unix-based product. I know nothing about their proprietary boxes. Anybody that makes a product decision based on PC Weak gets pretty much what they deserve. >> Documentation >> The Vines documentation I've seen around here is sparse and obscure. >> ... Novell comes with about 10 pounds of relativly good docs > >I am reminded of a TV commercial a few years ago that showed an IBM >system delivered with a pile of documentation and an Apple with one >small manual. The major VINES features are self-documenting. >Pressing F1 within an application displays the help documentation. > Well help screens are nice and useful once you have a handle on the overall system architecture but they don't help a bit while one is trying to learn the system. I have not been 100% pleased with Novell's docs. They are written for the average PC user. There is so much wrapping around the meat of the text that it sometimes becomes tedious to find what I want, but the "guide to docs" at least makes it easy to get to the vicinity. (personal attacks deleted to save net.bandwidth) >------------------------------------------------------------ >John J. Krawczyk >Banyan Systems, Inc. ...buita!banyan!johnk >115 Flanders Road >Westboro, MA 01581 Editorial: (Pilot light ON) First, realize I speak strictly for me and Johnk probably speaks for himself but since he signs himself as a Banyan employee, I must assume he represents at least part of Banyon's philosophy. what disturbes me more than the personal attack and the distortions of what I said in my previous posting is the apparant attitude of Banyan toward a user. Awhile back, I had a problem with a deadly embrace between Novell and DOS. After getting the runaround from Microsoft, I published (here) a summary of my experience. Within a day, I had gotten a call from both Microsoft and Novell telling me how to fix the problem. In the interest of fairness, i published a summary of actions taken. I don't particularly like Microsoft, but at least they responded positively. I see none of that here. Instead of trying to address the weaknesses I've outlined in the product, JohnK attacks me personally and cites spurrious facts to back up his statements. This only hardens my bias against Vines (remember, biases founded on fact are NOT bad. It goes by another name - experience) I know, for example, that Novell distributes utility and shell updates via the public domain BBS system. That fact made it trivial for me to fix my aforementioned problem. I just contacted the local Novell Users' group (yep, one in every city, just about) and found a BBS with the updates on it. Had it in hours. Banyan has an even better media at it's disposal - Usenet. Why don't we see fixes and utilities distributed in comp.xxx.binaries or something like that. I would not consider that an abuse of the net anymore than I would, say, Telebit sending out uucp config files. I view it as helping the user base. JohnK did not even come close to addressing the other problems I pointed out like the HUGE size of the shell program. I can't, for example run Harvard Project with the shell loaded on my Compaq 386 with no other TSRs. A couple of the guys around here have bought a cute little memory board that will take advantage of holes in the memory map above 640k and give them about 700+k of TPA (CP/M-speak :-) ) but that's kinda an obscene solution to sloppy programming. Nor did he address the fact that their copy-protected or install-counted tape they sent us put our system on the ground for over 2 weeks. Whatever that tape did, it kept an image backup made RIGHT BEFORE installing the upgrade from restoring the system. I don't know the details of what happened and I really don't care. The salient fact is a large development shop was down for an extended time period. I can't in my wildest dreams imagine what Novell could to to my server that would keep a backup from restoring the system. Worst case, I reformat the disk and reinstall the OLD system and restore the file system. I wonder if their paranoia that we might install their system on more than one host is really worth the real risk of damage such copy protection creates. We (the user base) killed copy protection in the DOS world so lets not let it infiltrate our networks now. Finally, as to JohnK's remark that my not knowing what market share Banyan has is a sign of ignorance, I have only a small comment. If Novell does indeed have 70 or 80% of the LAN market, that really does not leave much for ALL the rest of the chickens to scratch in does it? So some unknown percentage of almost nothing is still small, eh? (pilot light OFF) I don't like surprises. I try to stay with proven technology sold by market leaders, assuming the leader has attained that position thru superior products as opposed to monopolistic practices. I also live by the philosophy that "if it ain't broke, don't fix it". Novell has serverd me and my customers well. I have a large body of users and developer to call on and it is well supported. There ARE other good networks out there. I sell ViaNET whenever a client needs peer-to-peer services as opposed to the host-slave service provided by Novell. We use 3-com around here in another department and I've heard nothing really bad about it. I think (this is a scientific wild-assed guess) that 3-COM has a unix-based server too for those of you who would need that service. Having the network service on top of Unix is handy in that it facilitates moving files back and forth. we use SCCS for revision control on our DOS products. I'm sure, however, that the bridge/gateway facilities available for other network products would be just as easy to use. (side note: I sold a moderate sized consulting firm to join Sales Technologies When I say "my clients", I refer to clients of RSI, not Sales Technologies.) PS: If someone at Banyan were suddenly to decide to respond to our problems, I AM NOT the sysadmin. Respond to stiatl!steve or stiatl!pda. I hope we have not started yet another round of the great new.wars. I'd suggest that anybody who has first-hand experience with a LAN product to post, but let's not expend megabytes ripping others' posting apart. Personally, my integrety is defended; I will post no further on the subject. John De Armond Sales Technologies, Inc. Atlanta, GA ...!gatech!stiatl!john
alans@spked.UUCP (Alan Smith of IM) (11/19/88)
My two bits to add to this discussion come from my experience as
a satisfied system administrator for a multi-server wide area
Banyan network.
I must first protest the hack job courtesy of John DeArmond from
Sales Technologies in Atlanta. Many of his points about Banyan
networks are simply INCORRECT.
While any network system, including Banyan, has its good and bad
points I am very satisfied with the features that Banyan's product
gives to both end users and administrators. Now if only they could
cut their memory usage just a bit and reduce their prices "a bit"
Banyan could knock others out of the water.
I was going to do a point by point rebuttal to the misleading points
made by John DeArmond but I defer to the previous note by John K from
Banyan Systems itself.
Keep up the good work Banyan !!!! ;-)
--
The contents of this message are totally unauthorized, and represent no person
or entity within any agency, nor any statement of policy.
Standard Form 1 Disclaimer (Rev. 4-87)
{{seismo|ihnp4!}lll-crg|sdcsvax|{decvax!}ucbvax}!ucdavis!spked!spkim!alans