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 run1401 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?).