izumi@violet.berkeley.edu (Izumi Ohzawa) (09/15/88)
In article <626@mace.cc.purdue.edu> mtr@mace.cc.purdue.edu (Miek Rowan) writes: > >> don't know...I think I'll save up for a Sun ;-) > >After cleaning up Sun's code, dealing with thier equipment et al ... >I would not recommend a Sun to my worst enemy. They have had some >good ideas, but thats about it. >mtr Now, could you be more specific. Really, I am quite interested in what you saw. I've only heard praises about Suns and thinking about getting a few ourselves for our lab. Izumi
hyc@math.lsa.umich.edu (Howard Chu) (09/15/88)
You might start by reading the sun-spots digest - you'll see enough bug
reports to make your eyes bug out. Just as the most trivial of problems,
you might wonder at the coined phrase (sorry, I forget who I'm stealing
this from) "the connector is the network."
Lots and lots of problems, no single one of which renders a Sun totally
unusable, but altogether adding up to too many headaches. Bad network
support, flaky network services, etc. etc. etc... For a company whose
motto is "the network is the computer" it's pretty disgusting how
poorly their network software runs.
[disclaimer - these are my own personal opinions, and don't reflect
anything about anyone else anywhere else in the world, as far as I
know, employers included...]
--
/
/_ , ,_. Howard Chu
/ /(_/(__ University of Michigan
/ Computing Center College of LS&A
' Unix Project Information Systemsdrs@bnlux0.bnl.gov (David R. Stampf) (09/15/88)
In article <406@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: >You might start by reading the sun-spots digest - you'll see enough bug >reports to make your eyes bug out. Just as the most trivial of problems, >you might wonder at the coined phrase (sorry, I forget who I'm stealing >this from) "the connector is the network." > >Lots and lots of problems, no single one of which renders a Sun totally >unusable, but altogether adding up to too many headaches. Bad network >support, flaky network services, etc. etc. etc... For a company whose >motto is "the network is the computer" it's pretty disgusting how >poorly their network software runs. > I wasn't going to respond to this figuring that there would be a huge response from Sun users, but since it wasn't posted to the sun newsgroup I'll put in my $.02 worth. I've had a Sun on my desk for 4 years now, and my department has about a dozen. Schools by us have Sun's by the 100's. Compared to other machines, Sun's software is top notch and we frequently use the sun's to monitor our networks. I really think that Howard's opinions are in the minority viewpoint. So much so in fact, that it would be interesting to find out what he *would* recommend to his worst enemies as an alternative. < dave stampf
m1edb00@fed.FRB.GOV (Eric D. Boutilier) (09/16/88)
In article <406@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: > >Lots and lots of problems, no single one of which renders a Sun totally >unusable, but altogether adding up to too many headaches. Bad network >support, flaky network services, etc. etc. etc... For a company whose >motto is "the network is the computer" it's pretty disgusting how >poorly their network software runs. > What! where are you coming from with this? We're extremely happy with our Sun network and I have yet to talk to anyone who shares your views. What would you recommend instead? -- Eric Boutilier UUCP: uunet!fed!m1edb00 (202) 452-2734
pavlov@hscfvax.harvard.edu (G.Pavlov) (09/16/88)
In article <406@stag.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes: > You might start by reading the sun-spots digest - you'll see enough bug > reports to make your eyes bug out...... > Lots and lots of problems, no single one of which renders a Sun totally > unusable, but altogether adding up to too many headaches.... I would not base a decision on whether to buy a Sun on this. One should know/understand that: 1. many reported "bugs" and problems filter out as improper installations, configurations, etc. This may be a commentary on quality of the docu- mentation, but there is nothing unusual about Sun's; 2. In my experience, Sun users/owners are more likely to utilize third-party hardware than users/owners of other vendors' machines. It is almost inevitable that one will eventually encounter problems relating to this fact alone; 3. Suns are frequently networked to other vendors' machines through still other vendors' comm. equipment. Problems arise in interoperability. Sun users/owners typically find that they can tackle the problems more easily from the Sun side than from the other vendors' side; 4. The sun-spots digest is much more active than other manufacture-speci- fic groups, which relates in part to the technical level of people who up to now have formed one of the primary markets for Sun. I don't see the percentage of "problem" messages to total messages in that group to be significantly higher than in other manufacture groups. But there is certainly much more traffic overall. For several years, our site utilized a cpu from a vendor with an excellent reputation for quality and support. This vendor was conscientious enough to publish a quarterly book, containing the 100's of known bugs, there status and disposition. A casual glance at this volume would convince someone that the system was virtually unusable. But even tho it was used for applications development, we rarely encountered a reported problem. Sun's systems my suffer from more bugs than usual. I have used a Sun, know a number of people who own one or more, and have not seen anything that would validate a claim of severe flakiness. greg pavlov, fstrf, amherst, ny.
hedrick@aramis.rutgers.edu (Charles Hedrick) (09/16/88)
> You might start by reading the sun-spots digest - you'll see enough bug > reports to make your eyes bug out. Well, I've made my share of postings to Sun-Spots, but I surely wouldn't want them misinterpreted as advising people against buying Suns. Reading an unedited list of problems from users is always a frightening experience. The monthly listing of bug reports from DEC for TOPS-20 was far scarier than Sun-Spots. (Presumably the same is true with VMS, but I don't look at those.) Back when I looked at bug reports published by IBM for MVS, it was amazing what sorts of bugs there were even in that very reliable system. (They even had this special mechanism for giving you last-minute information on which of the patches they published shouldn't be installed because they turned out to create more problems than they solved.) About all one can say is that there are lots of users out there trying lots of things and so they run into lots of problems. Many of them are user confusion, but there are also plenty of bugs. Sun-Spots is mostly a sign of a large and active user community doing lots of interesting things.
awm@doc.ic.ac.uk (Aled Morris) (09/16/88)
In article <406@stag.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes: > You might start by reading the sun-spots digest - you'll see enough bug > reports to make your eyes bug out. Just as the most trivial of problems, > you might wonder at the coined phrase (sorry, I forget who I'm stealing > this from) "the connector is the network." The sun-spots digest is one of the most useful, informative and entertaining groups that truly reflects the popularity and commitment of Sun's many satisfied customers. The comment on the connector is not a Sun specific complaint, it refers to a long debate on comp.protocols.tcp-ip, regarding the DB15 ethernet drop cable attachment as used by *all* ethernet vendors ('cos its in the standard). Read sun-spots, not these flame wars :-) for the full story. Aled Morris systems programmer mail: awm@doc.ic.ac.uk | Department of Computing uucp: ..!ukc!icdoc!awm | Imperial College talk: 01-589-5111x5085 | 180 Queens Gate, London SW7 2BZ Opinions expressed above are all my own. I have no connection with SMI.
munson@renoir.Berkeley.EDU (Ethan V. Munson) (09/16/88)
I think that this discussion has gone quite astray. Suns and Macs are, for 99.5% of the computing world, oranges and apples. A Macintosh is designed to be a standalone personal computer that will basically run correctly from the moment it is turned on. It is designed around the assumption that the user is not very sophisticated about computing. Suns are diskless workstations, which can be given local disks to allow them to run in standalone mode. A Sun can only be used easily when there is a sophisticated system manager available who will work out the kinks in issues like swap space, disk partitions, etc.. If you are such a person or are part of an organization that already has such a person, a Sun may be a good choice. There is lots of free software that runs on Suns and is useful. For much of it, though, you may need to run make, extract shell archives, and run dbx from time to time. However, I don't think you can find a $150 WYSIWIG word processor for the Sun that will print on a $500 dot matrix printer. In my experience, the only time that Suns and Macs become comparable is when you talk about the bottom of Sun's line (3/50 with a 70meg SCSI disk) and the top of Apple's (Mac II with 80Meg disk, A/UX, 5+Meg of RAM). Network based Sun systems do appear to be more fragile than Macintosh systems (which do not depend on the network for critical resources, like virtual memory). Some of the fault lies with Sun's decision to trade-off reliability for speed and simplicity in the Network File System. But much of the time, any problems arise from the decisions made by the administrators of the local system to spend $5000 on a new 3/50 instead of another 4 Meg of memory for the file server. A Sun is a good machine if you are a programmer or can afford to hire one. A Mac is a good machine no matter who you are, but is not as good as a Sun for computer science research and some other technical pursuits. Pardon my little harangue, Ethan Munson munson@renoir.Berkeley.EDU ...ucbvax!renoir!munson ----------------- "I don't know if they scare the enemy, but they certainly scare me." --Wellington, speaking of the moral character of his troops
gl8f@bessel.acc.Virginia.EDU (Greg Lindahl) (09/17/88)
hi. would you all PLEASE quit cross-posting this message stream to groups that it has nothing to do with -- IBM PC's, Amigas, Atari ST's, etc. there are people who read these newsgroups through digests, and have no way to easily skip over all of the off-topic messages. thanks. Greg Lindahl internet: gl8f@virginia.edu U Va Dept. of Astronomy bitnet: gl8f@virginia.bitnet
roy@phri.UUCP (Roy Smith) (09/17/88)
Either drs@bnlux0.UUCP (David R. Stampf) or hyc@math.lsa.umich.edu (Howard Chu), it's not clear which from the attributions, writes: > Just as the most trivial of problems, you might wonder at the coined phrase > (sorry, I forget who I'm stealing this from) "the connector is the network." 1) It was "stolen" from me. I guess it's too late to apply for a trademark, right? :-( 2) Stop wondering what it means. It's a dig against Sun for putting such crappy ethernet tranceiver connectors on their machines, and is a direct parody of their "the network is the computer" slogan. You would think that a company which makes products which depend so much on networking (let's face it, a diskless workstations with a disconnected tranceiver cable is just a very large paperweight) would pay more attention to how they plug into that network. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
paquette@.ucalgary.ca (Trevor Paquette) (09/18/88)
In article <620@bnlux0.bnl.gov>, drs@bnlux0.bnl.gov (David R. Stampf) writes: > In article <406@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: > > > >Lots and lots of problems, no single one of which renders a Sun totally > >unusable, but altogether adding up to too many headaches. Bad network > >support, flaky network services, etc. etc. etc... For a company whose > >motto is "the network is the computer" it's pretty disgusting how > >poorly their network software runs. > > > > I've had a Sun on my desk for 4 years now, and my department has > about a dozen. Schools by us have Sun's by the 100's. Compared to other > machines, Sun's software is top notch and we frequently use the sun's to > monitor our networks. I really think that Howard's opinions are in the > minority viewpoint. So much so in fact, that it would be interesting to > find out what he *would* recommend to his worst enemies as an alternative. > > < dave stampf I must agree with Dave. I have been using Sun workstations for about 3 years now and I think it is the best devellopement system around. The Sunview window environment is a joy to work in compared to other windowing systems I have seen. Mex on the Iris is totally brain damaged in comparison to it. I have nothing bad to say about Sun (the computer or the company). I really hate it when some people give there 2 cents worth when it is only worth 1. Alot of people don't give things a chance to improve, if it does not work first time then they refuse to look at it again. ============================================================================= Trevor Paquette - GraphicsLand, U of Calgary[Home of The Great Train Rubbery] Email:paquette@cpsc.UCalgary.CA ICBM:51 03 N/114 05 W Luminous beings we are, not this crude matter. *** Don't worry, be happy
hyc@math.lsa.umich.edu (Howard Chu) (09/18/88)
In article <620@bnlux0.bnl.gov> drs@bnlux0.UUCP (David R. Stampf) writes: > I wasn't going to respond to this figuring that there would be a >huge response from Sun users, but since it wasn't posted to the sun newsgroup >I'll put in my $.02 worth. > > I've had a Sun on my desk for 4 years now, and my department has >about a dozen. Schools by us have Sun's by the 100's. Compared to other >machines, Sun's software is top notch and we frequently use the sun's to >monitor our networks. I really think that Howard's opinions are in the >minority viewpoint. So much so in fact, that it would be interesting to >find out what he *would* recommend to his worst enemies as an alternative. > > < dave stampf I think we've seen more than enough of this topic, so I'll try to keep this short. First of all, I'm sure many schools have Suns by the 100's. I'm sure they're also often wondering if they'd made a mistake. I've heard many times how Michigan State University fared, with amazing ethernet broadcast storms and meltdowns rendering their campus-wide broadband completely unusable. We all remember the stories of Sun 3/50's ARP requests getting shunted along cross-country by ethernet bridges, yes? In any case, (consider this a challenge if you wish, I know you will not be able to meet it) you cannot put anywhere near 100 Suns on a single network, and get any useful service out of them. The network would simply collapse under too many collisions. I don't believe you will find any place running more than 40 machines on a single network. Contrast this with, say, an Apollo network. Our engineering school runs over 300 Apollos on a single Apollo token ring, on two campuses spanning over two miles. There's no such thing as a network meltdown there. Diskless nodes don't have to have disk space pre-allocated on servers, and don't eat up bandwidth trying to find their own internet addresses. There's no need for special partitioning of a drive, no particular use for the mount command except for use with NFS. No need to dedicate any piece of disk to swap space - all disk use is dynamically allocated. All disks on a net are always accessible, quickly and transparently. They have a bunch of Suns now too, but they can't compare in performance to the Apollos. Using NFS, all 300+ Apollo disks are accessible thru a single mount point on a Sun. In contrast, it's an amazing hassle to keep fstab's up-to-date to keep all the necessary Sun disks accessible. It would be nearly impossible to run a bunch of Suns as a well-coordinated network without Sun's Yellow Page service. All well and good, as long as it works, which is, unfortunately, not All the time. A Sun workstation just isn't configured to work in a network - load it up off the distribution tapes and it wants to think it's a standalone mini, like a big Vax or something. Its own password file, hell, its own copy of /etc. You know how silly it is to have 25 copies of /etc/termcap or /etc/hosts online? I couldn't even keep a full hosts file in the yp database because it was so huge it would timeout during ypxfr updates. When 1 of the 4 ypservers went down, the silly machines were unable to locate any of the 3 other running servers, and the whole network was unusable. YP is supposed to be fault tolerant, and is billed as a dynamically load balanced system, but in practice it is as inflexible and fragile as a piece of thin glass. It was also quite disconcerting, when I went looking for possible ways to improve the code, to note that my sources and binaries were not the same version, even though they had identical SCCS IDs. (Different date stamps, different object files.) And I'm one of the fortunate few to have access to full Sun source code. Contrast again with an Apollo network - these machines were obviously designed from the start to operate in a distributed computing environment. Sun's network support seems to be more of a hastily added asfterthought in comparison. The password database, for example is dynamically updated among what they call replicated databases. It's the same idea on the surface as yp - a few key nodes playing host to some servers. The implementation is much smoother though. For the password database, or "registry," there is also a locally cached registry, which maintains a selectable history size of local users, so even if the main registry becomes inaccessible due to a network failure, the node can be logged into for use. Apollo's network management software is easily the most sophisticated and mature as any I've seen. And with their filesystem, you won't find your NFS partitions temporarily evaporating, you won't be denied access to files that you own, etc. (This is certainly an odd problem to appear in a "stateless" filesystem, but Sun NFS often gets confused and will deny Joe User access to NFS mounted files that Joe owns. Usually fixed by a couple sync commands, so it's only a minor inconvenience at worst, but nonetheless it's a telling sign.) So much for keeping it short. I didn't even get to talking about how much faster Apollos are, how much more responsive the Apollo Display Manager is than any Sun windowing system, how much more sophisticated the filesystem is, or a lot of other points. Or Apollo's Network Computing System, with which I can writea huge resource intensive application that will utilize all available CPUs and disks on the network. (250 68020's can solve a lot of problems in one helluvausmall amount of time!) So much for that. I have no vested interest in either Suns or Apollos, I use them both all the time. Obviously I prefer the Apollos, even though I'm maintaining 25 Suns here in Math. It's truly amazing how many people I've encountered have only heard good things about Suns, and never bad. Sure, they have their good points, but there's a lot of bad to be aware of, and, more importantly, there are good alternatives to be aware of. -- / /_ , ,_. Howard Chu / /(_/(__ University of Michigan / Computing Center College of LS&A ' Unix Project Information Systems
bobmon@iuvax.cs.indiana.edu (RAMontante) (09/18/88)
I love the IBM PC newsgroup. Where else could I see an Apple flame inspire Sun users to flame their own machines as well as Apollos, with Mac II users taking random potshots from the sidelines? Lemme tell you about the AT&T 7300 I'm trying to use at school.... -- -- bob,mon (bobmon@iuvax.cs.indiana.edu) -- "Aristotle was not Belgian..." - Wanda
perley@mazda.steinmetz (Donald P Perley) (09/21/88)
In article <620@bnlux0.bnl.gov> drs@bnlux0.UUCP (David R. Stampf) writes: >In article <406@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: >>Lots and lots of problems, no single one of which renders a Sun totally >>unusable, but altogether adding up to too many headaches. Bad network >>support, flaky network services, etc. etc. etc... For a company whose >>motto is "the network is the computer" it's pretty disgusting how >>poorly their network software runs. > I really think that Howard's opinions are in the >minority viewpoint. So much so in fact, that it would be interesting to >find out what he *would* recommend to his worst enemies as an alternative. I know I wouldn't reccomend a Sun to my worst enemy. What WOULD I recomend to my worst enemy? If I told you that here, I would probably make more enemies. -don perley
joshua@uop.edu (Ed Bates: Joshua is my son's name.) (09/22/88)
Please move the discussion to some other newsgroup (comp.misc maybe?). It currently has nothing to do with IBM PCs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Edwin J. Bates University of the Pacific Academic Computer Specialist Stockton, CA (pretty close to Sacramento) (Jack-Of-All-Trades) (somewhat near San Francisco)
wg@aluxp.UUCP (Bill Gieske) (09/27/88)
> >In article <406@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: > >>Lots and lots of problems, no single one of which renders a Sun totally > >>unusable... (talking about network problems) > Try using a Sun workstation telneted to a VMS system... Forget about control-y or control-c; the Sun network software goes out to lunch. Then try getting the problem addressed... I've just learned that when I run something I didn't ask for, or type a file larger than I wanted, the best thing to do is do some- thing else.
hedrick@athos.rutgers.edu (Charles Hedrick) (09/29/88)
I don't know why we're discussing bugs in Berkeley Telnet on this newsgroup, but the fact that ^C doesn't stop output in telnet is not peculiar to the Sun implementation. Since the same problem is likely to occur with micro implementations, and people are beginning to use PC's of various kinds as virtual terminals over the network, it is probably worth noting at least briefly what is going on. When you open a virtual terminal connection using telnet (the official virtual terminal protocol for TCP/IP), there are typically delays in getting control characters to take effect. The most obvious delays are when you try to pause output using ^S, or stop it completely using ^O, ^C or whatever your OS uses. Most TCP implementations do lots of buffering of data, in order to improve throughput and decrease overhead. When you do something like ^C, the host may immediately stop generating output, but there may be several pages of data already in flight in various pieces of the networking software. In order to stop output more quickly, telnet has something called "sync," which allows the host to clear all that buffered output. It isn't perfect, but with good software on both ends, the runover can be kept down to a few lines. The problem is that a lot of TCP/IP implementations are based on Berkeley code, and Berkeley didn't implement sync in 4.2 BSD. (Most Unix vendors' TCP/IP code until very recently was based on 4.2.) In order for sync to work, both ends must implement it. 4.3 BSD implements it on the server end but not the user end. I think 4.3 Tahoe may have added user end support as well. (Just server end means that if you use a 4.3 system as a host, and your PC or terminal server does sync, things will work. But if you telnet out of the 4.3 system, things won't work, since it isn't in the user telnet.) Depending upon which VMS implementation you used and how old the software is, there's a good chance that your VMS host didn't do sync. There is another program for doing virtual terminal connections, called rlogin. It transfers a bit more information about the status of the terminal. So it allows stopping and starting to work somewhat more quickly. Although this was initially invented by Berkeley for Unix, many other implementations now support rlogin (including both PC and VMS implementations). So if you want output to stop quickly, you might try rlogin. However if you are buying TCP/IP software, I also suggest checking to see whether it implements telnet sync, since telnet is still more widely available than rlogin. [May I suggest that this is not an appropriate set of newsgroups in which to air everything you've ever tried to do on a Sun and not had work correctly.]
drs@bnlux0.bnl.gov (David R. Stampf) (09/29/88)
In article <989@aluxp.UUCP> wg@aluxp.UUCP (Bill Gieske) writes: >> >In article <406@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: >> >>Lots and lots of problems, no single one of which renders a Sun totally >> >>unusable... (talking about network problems) >> >Try using a Sun workstation telneted to a VMS system... Forget about control-y >or control-c; the Sun network software goes out to lunch. Then try getting >the problem addressed... I've just learned that when I run something I didn't >ask for, or type a file larger than I wanted, the best thing to do is do some- >thing else. Two things Bill, if you want to sun bash, lets move this to the correct group - this is getting tiresome. Second, if you are going to sun bash, get the facts right. Sitting in the window just below the one I am typing in on my Sun is a window to a vms system via telnet. ^C/^Y acts instantly. You may want to make sure that the problem isn't with VMS or (Heavens Forbid) something with your vms login.com file. (set control=(t,y) comes to mind.) Have a nice day. < dave
landman%hanami@Sun.COM (Howard A. Landman) (10/01/88)
In article <989@aluxp.UUCP> wg@aluxp.UUCP (Bill Gieske) writes: >Try using a Sun workstation telneted to a VMS system... Forget about control-y >or control-c; the Sun network software goes out to lunch. Then try getting >the problem addressed... I've just learned that when I run something I didn't >ask for, or type a file larger than I wanted, the best thing to do is do some- >thing else. ^Y (control-Y) is the delayed suspend character. You can change this to anything you want on most UNIX systems (including Sun) by doing (e.g.): % stty dsusp ^A to change it to ^A (control-A). I do this all the time so I can run up-left in certain screen-oriented programs :-) without popping out to the shell. Once you have set dsusp to something else, ^Y is just an ordinary character. There, wasn't that easy? Howard A. Landman landman@hanami.sun.com UUCP: sun!hanami!landman