Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!thetone!swilson From: swilson%thetone@Sun.COM (Scott Wilson) Newsgroups: comp.sys.mac Subject: Re: Boycott Apple Again -- Now about Suns Message-ID: <68907@sun.uucp> Date: 19 Sep 88 17:12:12 GMT References: <358@island.uu.net> <626@mace.cc.purdue.edu> <14301@agate.BERKELEY.EDU> <406@stag.math.lsa.umich.edu> <620@bnlux0.bnl.gov> <409@stag.math.lsa.umich.edu> Sender: news@sun.uucp Reply-To: swilson@sun.UUCP (Scott Wilson) Organization: Sun Microsystems, Mountain View Lines: 122 (sorry to post this here, but this is where I read it.) In article <409@stag.math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: >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. I'm no network weenie, but this sounds like crap to me. Here at Sun in Mt. View there are at least 5000 Suns connected by ethernet. Of course they're not all on the same ethernet, somehow they're organized hierarchically into subnets or whatever. However it's done, though, it works. >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. Are you sure this is true? Aren't there subrings or something like that? You mean that to transfer one packet from one node to another that the packet and its ACK have to pass through 300 machines? It sounds like a remote login would have lousey interactive performane. >Diskless nodes >don't have to have disk space pre-allocated on servers This is (or at least was) true. I don't know what has happened now that diskless clients use only NFS instead of NFS and nd. >No need to dedicate any piece of disk to swap space - >all disk use is dynamically allocated. One of my favorite things about Apollos was having to shut down diskfull nodes every couple of weeks and run salvol to reclaim about 10 % of the disk that was in use by some invisible objects. >They have a bunch of Suns now too, but they can't >compare in performance to the Apollos. My pre-employed-by-Sun experience was just the opposite. >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. Ever hear of the automount daemon? From the man page: "automount is a daemon that will automatically and transparently mount an NFS file system whenever a file or directory within that system is opened." On my machine I can cd /net/host to get to any NFS server I want. I can also cd to /homes/user to get to any user's home directory. No changes to /etc/fstab necessary. Another thing I never liked about Apollo was that to get to another node you used the un-UNIX like path of //node/... >25 copies of /etc/termcap or /etc/hosts online? So use the yellow pages. What do you do on Apollo? Have 25 links to //foo/etc/termcap? Our experience with Apollos was that it was a hassle to keep the passwd files consistent. Part of the problem is that are automatically generated from Aegis reistry files. Often files on my machine that were owned by me would appear to be owned by other people on other machines. So we would flush the acl cache and rerun mkpasswd, fun stuff. >I couldn't even keep a full >hosts file in the yp database because it was so huge it would timeout during >ypxfr updates. The yellow pages host table at Sun has 7209 entries. Seems to work just fine. >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. Gee, it seems to work just fine here. >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. How about how much un-UNIX like Apollo is? How about how Apollo window mail can't read mail read with Apollo command line based mail (so much for dailing up from home to read your mail, you'll never see it again if you want from window-based mail)? How about files having file types? (If you compile cp on Apollo it can't copy executables because the the defaut output type is ascii, Apollo had to hack cp to make the destination file have the same type as the source.) How about missing features from bsd4.2 that Apollo just omits from man pages without mention (setrlimit, finger, sccs front end)? How about UNIX domain sockets (which are missing)? How about cartridge drives that can only tar one block at a time (this takes forever, I called Apollo and they said it was a hardware problem with the drive, yeah right)? How about stty not working? How about the super kludge to get termcap to work (it starts up a vt100 process that i/o goes through when you call tgetent)? How about /dev/tty not being supported? Why doesn't uptime work? Why doesn't reboot work (you can't reboot a machine unless you are physically next to it type EX AEGIS to the monitor prompt or push the white button)? Why isn't '.' and '..' found as the first two entries in a directory? So what kind of machine are you reading this from, a Sun I bet, I friend of mine tried to get uucp running on Apollo and it never worked quite right, got it running on a Sun in a few hours. I'm sure there are many, many, more examples but I don't like to think about, gives me a headache. >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!) I remember this from Apollo sales hype. Have you actually done this? All of this is my opinion only and was formed before I came to Sun. It in no way represents any implied or explicit opinion of Sun Microsystems. -- Scott Wilson arpa: swilson@sun.com Sun Microsystems uucp: ...!sun!swilson Mt. View, CA "And the fool loves war, and the gentle die." -The Call