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