Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/5/84; site polaris.UUCP Path: utzoo!linus!philabs!polaris!herbie From: herbie@polaris.UUCP (Herb Chong) Newsgroups: net.followup Subject: Re: Unix from a snob's point of view! Message-ID: <228@polaris.UUCP> Date: Wed, 23-Oct-85 21:43:39 EST Article-I.D.: polaris.228 Posted: Wed Oct 23 21:43:39 1985 Date-Received: Sun, 3-Nov-85 14:17:54 EST References: <298@weitek.UUCP> Reply-To: herbie@polaris.UUCP (Herb Chong) Organization: IBM TJ Watson RC Lines: 111 Keywords: valid and invalid criticisms Summary: In article <298@weitek.UUCP> mmm@weitek.UUCP (Mark Thorson) writes: >It's become soooo fashionable to put down Unix. So why don't you ever hear >valid criticisms of Unix? You always hear chicken---- like: >1. It has cryptic command names. (So what? They work! Alias them if > you'd rather say 'search' to call 'grep'! What do you want, a menu-driven > shell? It would be easy to give you one if that'll put this stupid > criticism to rest!) but then you are paying the price of compatibility. your commands and your documentation don't correspond. i switch between three different operating systems during a single day's work. renaming commands would play havoc with remembering what things do even though i have been using two of the systems for more than a year as a programmer and am considered an expert (but not a guru) on two of them. >2. It has bad documentation. (Have you tried to read it? It is oriented > to working programmers so it does tend to be terse and easy to scan. > But if you need some one to hold your hand, there is an abundance of > books at your local technical bookstore. The books range from ultra- > beginner to advanced topics, specialized to generalized, verbose "user > friendly" to dry reference tomes. What do you want? Unix has been > described from every conceivable angle.) which was fine in the good old days when dennis ritchie was the only one using the system or in the small group that worked on version 6. nowadays, there is a much larger user community and the average level of expertise is lower. as a user consultant when i was with the university of waterloo, i had to interpret the documentation for ordinary users on our 4.2 bsd system. about 10% of the manual pages were clarified locally and still most ordinary users couldn't understand what the documentation meant. all too often, i had to look at the source in order to figure out what was really going on. i was fortunate that i was priviledged enough to be able to look at it. i save said this many times on the net and i will say it again, the unix documentation was written to remind the person who wrote the program what everything does. it also happens that some of the time, an ordinary user can understand it and that most of the time, a system hacker or guru knew what was meant. >3. It's a hack. (Dead wrong. Operating systems from the manufacturers are > hacked --- RSX11 for an extreme example. When I started using Unix ten > years ago, most multitasking operating systems were much larger. They > were also highly restrictive. Things like the command interface were > part of the OS. The SYSTAT program (in DEC parlance) was part of the OS. > The file copy program was part of the OS. The revolutionary thing about > Unix back in 1975 was that it only supported critical functions in the OS. > Everything else was a disc-resident program. Thus you could write your > own shell, your own SYSTAT, your own everything. And people did. Unix > in 1985 is encrusted with all kinds of cute additions. The Unix environ- > ment today is the OR function of everbody's ideas on how to 'improve' the > shell and the system utilities. BUT THE UNDERLYING ELEGANT STRUCTURE IS > STILL THERE. You can delete the extensions if you wish, but it's easier > to turn them off. When I was given my account on the Weitek VAX, the SA > had provided me with .cshrc and .login files that turned on most of the > cute features. Like the funny characters after the file names when you > do an 'ls'. I immediately deleted those files and logged back in.) but it's not the underlying structure that people deal with. it's the interface that we see. do you really care that you could write your own shell to handle commands in your own prefered manner? maybe you do, but there are an awful lot of people who not only don't care, but would use any system as long as it got the job done and on time. the design of a system alone doesn't make it wonderful to use. multics is not bad, from what i hear, and the layered approach to design has been emulated by many other systems, but do you see many out there? >I'm not love-blind to the weaknesses of Unix. There ARE valid criticisms of >Unix, but you won't hear them from 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. it doesn't support the interactive environment very well either if you get larger. unix does not scale up well, and that's where many people are taking the design. they are running it on bigger and bigger machines and the fundamental algorithms used are beginning to chew up a larger and larger percentage of the CPU. admittedly, this is an implementation problem more than a design problem, but it's there. >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. this is fine on a smaller machine where there was only 64K to work with, the CPU and memory are slow, and so was the disk. you can make block sizes bigger, but still you have to live with hardware that doesn't understand it. 2K or 4K blocks make better sense on the machines of VAX size with 4M, 8M, or even 12M or memory. VM/CMS's file system is basically block oriented much like unix's (with certain restrictions) and yet I/O performance is almost an order of magnitude better in terms of byte/s. mind you, CMS never has to lock on I/O because the filesystem is private to each user. Herb Chong... I'm still user-friendly -- I don't byte, I nybble.... New net address -- VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie CSNET: herbie.yktvmh@ibm-sj.csnet ARPA: herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa