Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucla-cs.ARPA Path: utzoo!linus!philabs!prls!amdimage!amdcad!amd!pesnta!hplabs!sdcrdcf!ucla-cs!scw From: scw@ucla-cs.UUCP Newsgroups: net.followup Subject: Re: Unix from a snob's point of view! Message-ID: <7525@ucla-cs.ARPA> Date: Sun, 10-Nov-85 11:49:43 EST Article-I.D.: ucla-cs.7525 Posted: Sun Nov 10 11:49:43 1985 Date-Received: Wed, 13-Nov-85 03:28:36 EST References: <298@weitek.UUCP> <228@polaris.UUCP> Reply-To: scw@ucla-cs.UUCP (Stephen C. Woods) Organization: UCLA Computer Science Department Lines: 39 Keywords: valid and invalid criticisms In article <228@polaris.UUCP> herbie@polaris.UUCP (Herb Chong) writes: >In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes: >>It's become soooo [...] these pseudo-intellectual snobs. >> >>1. Unix does not support the traditional scientific computing environment >> well. This means compute-bound FORTRAN programs. If you want to program >> in FORTRAN or if you want to run crunching FORTRAN programs like DRACULA, >> get VMS. At Weitek we run one VMS machine solely for this reason. > This is mainly because there has been no reasonable FORTRAN compiler (f77 is a joke). Although I suspect that this is going to change. > >it doesn't support the interactive environment very well either if you get >larger. unix does not[...] an implementation problem more >than a design problem, but it's there. Can't really argue with this. > >>2. Unix does not support the traditional business computing environment well >> This means sequential I/O bound COBOL programs. Unix does not even have >> sequential I/O. It's random-access I/O is so fast that it is used to fake >> sequential I/O. But it does not fake it as fast as the real thing. So >> get an IBM computer if you want that (or look up a back issue of Computer >> Graphics to see how Tom Farrin made Unix support true sequential I/O). > >it's partly a function of hardware as well. tradition has it that all disk >blocks are 512 bytes.[...] lock on I/O because the filesystem >is private to each user. Don't forget that a 3380 is a WHOLE BUNCH faster that almost anything else around, (I mean as in ***WOW***!!!). In fact IBM has always (well at least since early S/360) been concerned about I/O bandwith, just for this reason. I mean who else has hardware such that their latest and greatest machine can run 1401 emulators each running 50 times faster than the real thing, (can you see DEC supporting PDP-8 emulation on the 8600 so that people can run old PDP-8 accounting stuff?).