jkelly@inland.com (06/13/91)
My experience of working with CTSS has got to have been one of the worst nightmares of my computing carear. I'll take UNIX anyday. From a my perspective and not being familiar with the hardware requirements, I found CTSS to be horrendously inefficient and totally obscure. However, it had the nice feature of being able to abort and restart large number crunching jobs. I still haven't found a machine that is fast enough to make the concept of a lot of small utilities as opposed to one extra large utility obsolete. Besides, it gives you just one enviroment (the shell) to learn, instead of having to learn a separate enviroment for each big utility that you want to use. But I can see how other people might not be comfortable with that.
jlg@cochiti.lanl.gov (Jim Giles) (06/15/91)
Note followup to comp.os.misc. In article <954.285734d7@inland.com>, jkelly@inland.com writes: |> My experience of working with CTSS has got to have been one of the |> worst nightmares of my computing carear. I'll take UNIX anyday. Using UNIX _is_ one of the worst nightmares of my career. |> From a my perspective and not being familiar with the hardware |> requirements, I found CTSS to be horrendously inefficient and totally |> obscure. [...] Obscurity is in the eye of the beholder. MOST (overwhelming the majority - 99.9...%) people find CTSS much _less_ obscure than UNIX. UNIX has the wide reputation (and UNIX 'gurus' are _proud_ of it) of being arcane. As for efficiency, I've yet to see a _real_ code that runs faster on UNICOS than CTSS - or even _as_ fast. |> [...] However, it had the nice feature of being able to abort and |> restart large number crunching jobs. Yes, and CTSS _does_ have, as you point out, a _superset_ of the features of UNIX (though the analog of pipes is quite different). A UNIX shell with UNIX style utilities would make this even more obvious - and would probably _still_ be more efficient than UNIX. (UNIX style pipes can also be supported under CTSS, either as an I/O library feature using controllee/controller chains or by using TCP/IP to implement it.) Note, I distinguish the system from the user interface - if you regard the user interface as being the defining characteristic of an operating system, then CTSS could be made identical with UNIX through the use of libraries and shells. And, CTSS would be a more powerful, more efficient, and a smaller OS kernel. |> [...] |> I still haven't found a machine that is fast enough to make the |> concept of a lot of small utilities as opposed to one extra large |> utility obsolete. [...] In my opinion, the idea was obsolete the day it was invented. It _might_ be a good idea if the small utilities were really written in some rational fashion with complementary features _designed_ to work well together. In that way, it would behave as a _single_ large utility would do - in fact that's why most people prefer large utilities: they may differ from each other, but they're almost certainly internally consistent to a much greater degree than UNIX utilities are 'consistent' with each other. In UNIX, the mess is full of inconsistencies and holes in functionality. |> [...] Besides, it gives you just one enviroment (the |> shell) to learn, |> instead of having to learn a separate enviroment for each big utility |> that you want to use. [...] Well, for most people, there are only three or four big separate utilities you _ever_ need to learn to do your job productively. It is almost always easier to learn these few than it is to learn the _minimal_ UNIX set of dozens of idiosyncratic utilities and shell script techniques. Of course, you can always write a big utility which emulates the UNIX environment if that's what you like. The rest of the world is going the other way though - with GUI's and other big utilities being written to _cover_up_ the UNIX interface. The world is moving _away_ from the UNIX _style_ of programming even as UNIX itself is being spread as the universal standard. Serves them right as far as I can see. J. Giles
dik@cwi.nl (Dik T. Winter) (06/15/91)
In article <954.285734d7@inland.com> jkelly@inland.com writes: > My experience of working with CTSS has got to have been one of the > worst nightmares of my computing carear. I'll take UNIX anyday. As long as the machine is interesting I'll take any OS. Although on occasion you will hear me complain about VM/CMS and upto sometime ago about NEC's SXOS. I do not know CTSS, but I have no serious complaints about systems like COS, NOS/BE and NOS/VE, apart from the kind of complaints I also have about Unix. As far as compiler listings is concerned, I am generally not pleased by compilers that generate a compiler listing by default. If possible I always turn it off (and alas, it is not always possible), to never turn it on again. I live without compiler listings, although the first system I ever used did generate a listing (directly to the printer) and you could not turn it off. (It was a compile and run kind of operating system back in the late 60's.) But that is just opinion. > I still haven't found a machine that is fast enough to make the > concept of a lot of small utilities as opposed to one extra large > utility obsolete. Besides, it gives you just one enviroment (the > shell) to learn, > instead of having to learn a separate enviroment for each big utility > that you want to use. But I can see how other people might not be > comfortable with that. No. You have still more to learn than the shell. You have to learn what options to pass to the other big utilities (like compilers). If you do not get the options right you in general can not make efficient use of the utility. (Of course there is no need to remember *all* options. At least I refuse to remember *all* options of the 'ls' command.) What is the main problem is that all those big or little utilities are not consistent from one implementation to the other. So even if you think that on Unix 'f77' is an utility that just should compile your fortran program you have to be aware that different compilers take different options. And also that identical options have different meanings. Let alone the name of the compiler. (E.g. what does 'f77 -r8' do on different systems? It varies. And never try: fortran -u *.f on an Alliant, although something similar will work on most systems. Perhaps POSIX is doing something about it but for some reason I doubt it.) -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) (06/15/91)
Well, this thread has strayed from a discussion of Fortran to comparisons/ complaints between/about operating systems. So it doesn't belong here. Nevertheless, I'm going to put in my $.02. (At least I didn't start it :-) ) The reason UNIX has become so popular is not because it's efficient and not because it's user-friendly, but because it is the first hardware-independent operating system, modulo SysV vs. BSD. I can go to a Convex, an Alliant, a Sun, an Iris, etc. nearly ad infinitum, and know just what to do to get a directory listing, see a man page, edit a text file, compile and load a program. You can't say that about CMS, VMS, CTSS, etc. Jim Giles complains about several UNIX "features"; for instance, he points out that that in order to get a wildcard character into an application you have to disable the shell's command-line preprocessing by using quotes or escapes. True, but once you know a little about UNIX this becomes intuitive; you do it all the time, for example, when you use "grep" or "find". I don't really have an opinion on this "feature", but even if we assume UNIX did this and many other things the wrong way, I can still take my knowledge and move it to another platforms. I don't have to learn a whole new OS when I have the budget to buy the new latest and greatest brand workstation. Similarly with efficiency. VMS really gets the most out of a VAX, which is great if you are sure a VAX will always be what you want. Taking the long view, hardware has been moving so fast that transportability of my skills is far more important to me than getting the most out of my machine; in two years I can buy another machine which will be faster, even with UNIX's inefficiency, than my present machine would be with an optimal OS -- and it will cost me less than my existing machine as well. People in other sorts of computing environments than mine may differ. If you're running huge codes and need every ounce of performance out of the best hardware available at any moment, it will be worth your while to learn to interact with a new OS every two years. Perhaps this is Jim's situation. Prediction: when these improvements in hardware slow down, the efficiency of an OS will become more important than the transportability of skills. We will see new OSs written that are designed, like VMS for the VAX, to get the maximum out of the architecture, and since these will be written from scratch the user interfaces will correct some of UNIX's mistakes. Summary: UNIX is the wave of the present. -P. ************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************** Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY 10027 (212)854-1418 shenkin@cunixf.cc.columbia.edu(Internet) shenkin@cunixf(Bitnet) ***"In scenic New York... where the third world is only a subway ride away."***