seg@ingres.com (scott e garfinkle) (11/06/90)
Just to warn prospective users of Esix. First of all, their fast file system (the Rev. D apaptation of the Berkeley FFS) appears to be flaky. It will not work at all on my system. On a friend's system (a normal RLL drive and 25 mHz board), it caused the loss of an entire (root) file system. I have heard that others have had similar problems. If you are currently using their FFS, think about it -- sometimes their fsck program doesn't recognize it as an FFS and proceeds to try to do an automatic s51k fsck! Also, the fs is apparently not appreciably faster for many applications, in any case (that is, in this incarnation). On another, related, front, the new (to Rev. D) SCSI driver is extremely flaky with certain drive/adapter combinations. It doesn't work at all (despite lengthy attempts by their technical staff to make it work) with the HP 97548S (and some other) SCSI drives and the Adaptec adapter. Incidentally, the limits on the size of files you can edit with ex/vi under Esix are there just because the engineers decided not to compile it with the VMUNIX flag turned on. Also, it appears that the Esix X11r4 implementation will not be released for the 3.2 product. Kind of interesting: there is no upgrade to SVR4 because "it is a separate product" and, yet, upgrades to the 3.2 product will not be forthcoming. Draw your own conclusions. scott e. garfinkle These are my own opinions, unrelated to my employer. In fact, I would have posted them from home if Esix wasn't crashing so often.
larry@belch.Berkeley.EDU (Larry Foard) (11/06/90)
In article <1990Nov5.180148.1046@ingres.Ingres.COM> seg@Ingres.COM (scott e garfinkle) writes: >Just to warn prospective users of Esix. First of all, their fast file >system (the Rev. D apaptation of the Berkeley FFS) appears to be flaky. >It will not work at all on my system. On a friend's system (a normal RLL >drive and 25 mHz board), it caused the loss of an entire (root) file >system. I have heard that others have had similar problems. If you >are currently using their FFS, think about it -- sometimes their fsck >program doesn't recognize it as an FFS and proceeds to try to do an >automatic s51k fsck! Also, the fs is apparently not appreciably faster >for many applications, in any case (that is, in this incarnation). > It could be a hardware/software compatibility problem. I have been running esix for a while now using the fast file system and have had no problems even after having crashed the system a # of times (do to ethernet card troubles). According to the people at esix it is finicky (sp?) about the RLL controller it uses. My only major complaint about xenix is that the package installation and deinstallation is to smart for its own good. I accidentally aborted an installation of some of the network software in the middle which massively screwed things up, if you attempt to install the package again it will tell you that it has already been installed and will quit, if you try to remove it it will tell you that it has never been installed. After screwing around for a while I finally gave up and reinstalled the whole system. I don't understand why it won't let you install on top of a partially installed package. I hate having to have a battle of the wits with software (expecially when it wins :( )
bill@unixland.uucp (Bill Heiser) (11/08/90)
In article <1990Nov5.180148.1046@ingres.Ingres.COM> seg@Ingres.COM (scott e garfinkle) writes: >Just to warn prospective users of Esix. First of all, their fast file >system (the Rev. D apaptation of the Berkeley FFS) appears to be flaky. >It will not work at all on my system. On a friend's system (a normal RLL >drive and 25 mHz board), it caused the loss of an entire (root) file Was this "normal" RLL drive listed in the Esix compatibility list? >On another, related, front, the new (to Rev. D) SCSI driver is extremely >flaky with certain drive/adapter combinations. It doesn't work at all >(despite lengthy attempts by their technical staff to make it work) with >the HP 97548S (and some other) SCSI drives and the Adaptec adapter. Again, is this device listed in the Esix compatibility list? >Incidentally, the limits on the size of files you can edit with ex/vi >under Esix are there just because the engineers decided not to compile it >with the VMUNIX flag turned on. Also, it appears that the Esix X11r4 This *is* extremely annoying. I wonder if they would consider releasing a new version of vi with the VMUNIX flag turned on... >implementation will not be released for the 3.2 product. Kind of interesting: >there is no upgrade to SVR4 because "it is a separate product" and, yet, >upgrades to the 3.2 product will not be forthcoming. Well, it does seem like there should be an upgrade path. I for one, however, don't plan on "upgrading" for a while anyway. Since SYSVR4 is such a new product, it is bound to be pretty flakey for a while (not specifically Esix, but the unix product in general). >These are my own opinions, unrelated to my employer. In fact, I would have >posted them from home if Esix wasn't crashing so often. How is your Esix "crashing"? Is it the above problems you're referring to? -- home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill bill@unixland.uucp, bill%unixland.uucp@world.std.com Public Access Unix - Esix SYSVR3 - (508) 655-3848 other: heiser@world.std.com Public Access Unix (617) 739-9753
bill@bilver.UUCP (Bill Vermillion) (11/10/90)
In article <1990Nov5.180148.1046@ingres.Ingres.COM> seg@Ingres.COM (scott e garfinkle) writes: >Just to warn prospective users of Esix. First of all, their fast file >system (the Rev. D apaptation of the Berkeley FFS) appears to be flaky. >It will not work at all on my system. On a friend's system (a normal RLL >drive and 25 mHz board), it caused the loss of an entire (root) file >system. I have heard that others have had similar problems. If you >are currently using their FFS, think about it -- sometimes their fsck >program doesn't recognize it as an FFS and proceeds to try to do an >automatic s51k fsck! Also, the fs is apparently not appreciably faster >for many applications, in any case (that is, in this incarnation). And on my system the FSS is working flawlessly. Using 660 meg Maxtor 8760E ESDI, and running a full news feed. Have had NO problems at all. No crashes, no lost files. fsck performs properly every. The system only needed it after power failures. Maybe it's your RLL system. I have seen more problems with RLL's than any other type. It has never been a robust drive handler from the observations I have made. >These are my own opinions, unrelated to my employer. In fact, I would have >posted them from home if Esix wasn't crashing so often. As I said this system is running a full news feed. One of the sites I distribute to is also running ESIX. We DON'T have crashes. Check your hardware - that's always the first suspect in a crash from what I have experienced. bill -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
chandler@beagle.UUCP (Jim Chandler) (11/11/90)
In article <1990Nov5.180148.1046@ingres.Ingres.COM>, seg@ingres.com (scott e garfinkle) writes: > with the VMUNIX flag turned on. Also, it appears that the Esix X11r4 > implementation will not be released for the 3.2 product. Kind of interesting: > there is no upgrade to SVR4 because "it is a separate product" and, yet, > upgrades to the 3.2 product will not be forthcoming. I talked to ESIX last week and they told me that they WILL have an upgrade path from 3.2 to 4.0. This is a recent change on their part. The 4.0 release will have X11R4. I have been running ESIX for about 1 year with little difficulty. I have had few problems with the SCSI driver and the FFS, even with a SyQuest removable drive. There are some inconvient things about it ie. the vi limitation but over all it is a good product. The biggest plus is the support from ESIX is OUTSTANDING. If you have any problem or question, they are more than willing to talk. They even called me back on a couple of occassions. This level of support in these times of 1-900-CHARGEME is to be commended. I would recommend this os to anyone. -- Jim Chandler asuvax!xroads!beagle!chandler chandler@beagle.uucp
john@jwt.UUCP (John Temples) (11/11/90)
In article <1990Nov5.180148.1046@ingres.Ingres.COM> seg@Ingres.COM (scott e garfinkle) writes: >Just to warn prospective users of Esix. First of all, their fast file >system (the Rev. D apaptation of the Berkeley FFS) appears to be flaky. >It will not work at all on my system. On a friend's system (a normal RLL >drive and 25 mHz board), it caused the loss of an entire (root) file >system. I haven't seen anyone on this thread point out that RLL is *not* officially supported by ESIX. The certified hardware compatibility list does not include any RLL controllers. As I understand it, you're on your own running RLL with ESIX. If it works, great; if it doesn't, too bad. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley ) (11/12/90)
In article <2256@jwt.UUCP> john@jwt.UUCP (John Temples) writes: >I haven't seen anyone on this thread point out that RLL is *not* >officially supported by ESIX. The certified hardware compatibility >list does not include any RLL controllers. As I understand it, >you're on your own running RLL with ESIX. If it works, great; if it >doesn't, too bad. >-- >John W. Temples -- john@jwt.UUCP (uunet!jwt!john) Ah, but that's where you're wrong. In the rev C installation manual (not their advertising literature, not what their sales staff say) it states that ST506 interfaces, MFM and RLL are supported. In the rev D manual, they have changed this to just say ST506 interfaces, with no mention of encoding schemes. Now all of this is subject to some amount of interpretation, but I expect RLL is still considered ST506 in most peoples books. -- Kaleb Keithley Jet Propulsion Labs kaleb@thyme.jpl.nasa.gov "So that's what an invisible barrier looks like!"