Path: utzoo!attcan!uunet!husc6!mailrus!uflorida!gatech!kong!emory!stiatl!john From: john@stiatl.UUCP (John DeArmond) Newsgroups: comp.dcom.lans Subject: Re: NETWARE 2.1 vs. VINES Message-ID: <1658@stiatl.UUCP> Date: 18 Nov 88 15:44:15 GMT References: <339@banyan.UUCP> Reply-To: junk Distribution: na Organization: Sales Technologies Inc., Atlanta, GA Lines: 266 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, to 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