meo@stiatl.UUCP (Miles O'Neal) (10/25/88)
In article <902@stiatl.UUCP> meo@stiatl.UUCP (Miles O'Neal) writes: >Well, we have one here, as a matter of fact. It mostly works OK, but we are >NOT amused when it does not. I got a phone call from the folks at Visual, and while they were perturbed to see the article on the net, they did not act at all perturbed at me, but only at the fact that we had somehow fallen through the cracks. They were VERY interested in helping, and seemed sincerely upset that this happened. I was impressed with their response, not to mention how quick it was! I spoke with someone who is tracking down why we fell through, and also with a Software Engineer who discussed the "problems". First, I was not aware that we have a Beta version. This was our internal communications fowlup and I apologize that this occurred. >1) The documentation is OK, but has holes (so whats new?) Well, its Beta. We should have gotten a followup and didnt, but there is a followup, and everyone else seems to have gotten it. >2) I wish they would have used a faster processor; the 6800 seems to be >just a tad too slow (or they just used a slow part). Of course, that >could have been a cost-cutting move, too. Its a VERY small nitpick; the >speed is really OK. Ive just gotten spoiled by the 386i. > In case I it isn't clear, the speed really, truly is OK. Did I really drop a 0? The above should have read 68000, not 6800. SHEESH! If they could do all this with a 6800, I'd be trying to hire on up there! Or at least looking into their stock, which might not be a bad idea! >3) Which leads to the biggest problem. The clients that come with the >terminal (a login server and font server) came with documentation that >they work on Sun 3 and 4 (or was it 2?) and the MIPS machine. OK, no >problem. Shouldnt be hard to port to the 386i. WRONGWRONGWRONG. > > a) One of the files wouldnt compile at all, due to needing an include > file that wasnt #included. grep saves the day. This was covered in the addendum. > b) The socket addresses are screwed up. Turns out the compiled code > has bigendian vs littleendian problems, and the bytes of the socket > addresses are backwards. We fixed this, and voila! We can now get > the Sun to try to open an xterm on the XDS (Visual 640). Try to open, > I said. Instead, it completely resets the setup information in the > XDS, so that all the addresses, and other stuff has to be reprogrammed. > We hunt code some more, and find all kinds of similar stuff. In fact, > we find a number of places they should have used the calls to get stuff > from or put stuff to the Internet code, and they just stuffed/grabbed > values. They ignored the very calls that were made for big/little Indian > problem prevention. Well, blow me down. The SE explained that the big/little endian diferentiation is all in the X11 server, and that they had not had a chance to connect to one to try things out, and had been waiting for a Beta site to let them know what happened. They have heard from most of the other sites, and have not heard of any reset problem as I describe; we are sending them detailed information to determine the cause. SO, it is possible that our workaround for the socket addresses and other stuff may be no workaround at all, from the standpoint of the software running on the host system. > ... > >WHY THIS IS POSTED. > >We would simply have worked things out with them by now if we could have. >However, we wasted a LOT of time trying to get the terminal working, with >its associated software, and CANNOT get a response from them. We have had >a call in for several days, and have yet to hear back from them. As stated above, we apparently fell through the cracks. This may be due to some recent internal corporate restructuring and having different groups of people at different locations. At any rate, we seem to be the exception rather than the rule, and they are doing their best to remedy the situation. >They offer a 99%-done solution, but for us at least, the missing 1% is >a little too much to take. I will post further developments. So, here they are. While we cannot yet be sure how things will work, given the overall quality of the Beta release, and the response by Visual to our problem, especially the tone of their response in reaction to negative publicity, we are excpecting to get things straightened out quickly, and order more XDS640s. In summary, the people at Visual seem to be hot on the heels of the 1/2% not ready (the other 1/2% was our misconception), and are worth checking out. On the 1 hand, I feel bad about the previous posting; on the other hand it certainly got things back on track... ===================================================================== Miles O'Neal decvax!gatech!stiatl!meo