#3: The unreasonable ineffectiveness of MTS

posted Mar 11, 2011, 10:25 AM by Jeff Ogden
The following is taken from a longer very thoughtful note that John Hogg entered in the opinion section of Tom Valerio's MTS Wiki in April 2005:

The unreasonable ineffectiveness of MTS

OK, so MTS worked well in a number of ways over quite a period of time. However, given all those early successes, it seems appropriate to ask why MTS is now so little known in the world at large.

In his book "Dreams of a Final Theory", Steven Weinberg refers to what Wigner called the "unreasonable effectiveness of mathematics." Then he turns Wigner's phrase on its head and uses most of a chapter to discuss the "unreasonable ineffectiveness of philosophy." If you'll allow me the privilege of a stretched analogy, I'd like to try to address what I see as the "unreasonable ineffectiveness of MTS".

When I say that MTS is somehow ineffective, I mean now, not then. It was certainly a very effective system in its time. However, given its history, you might expect it to be better known. After all, Multics still gets mention. For that matter, so does CTSS. I'd guess that both those systems were used by fewer people over their lifetimes.

Why? Let me suggest a few possible reasons. None of these reasons invalidate the many positive attributes of MTS. They're just possible explanations why MTS faded from the collective consciousness of the computing world. These are not in any particular order.

We didn't sell MTS

I think that, collectively, we (the MTS community) did much less than we could have to promote MTS. This was not entirely accidental. I can remember some heated discussions at MTS workshops on topics related to this. There were some people who wanted to do more, but the prevailing opinion was that we were willing to help people adopt MTS if they came to us, but we weren't willing to go to them.

A large part of this was fear of a possible "free rider" problem. All the MTS installations contributed lots of time and effort to the development of MTS. The idea that late comers might be able to walk in and use the system without contributing was offensive to many MTS people.

Another factor might have been (whisper this quietly) arrogance. We were here first, we thought of ourselves as top notch developers, and who might these other green newcomers be, and why should we listen to them?

So we missed the boat on promotion. I confess to guilt on both counts: "free rider" fear and arrogance. Interestingly, you can see signs of both of these things in the Open Source (or Free Software, pick your religion) community. That hasn't crippled the spread of GNU software and Linux, at least partly because the Open Source community has a good supply of promoters. In some cases, zealots might be a better word. And it seems to work.

Speaking just about UBC, I think UM was better at getting the word out about MTS than we were. For instance, several UM people wrote papers that were accepted and published in well known journals.

We alienated some of our user community

Later in the life of MTS, I suspect that some of us (including me) weren't as open to ideas for change as we should have been.

Example 1: at least at UBC, we didn't cooperate with the Computing Science department as much as we should have. For instance, they wanted to have a way for their senior students to work on the internals of a system. We dismissed requests to give them access to MTS. We should have tried harder to find a way to accommodate them. After all, there were possibilities: the virtual machine, a second hand 4341 ...

Example 2: many people hated being told what they had spent at the end of every session. We didn't listen carefully enough to those complaints. Consider the effort that cell phone providers, ISPs, and hosting companies put into providing varying billing plans. Some of those plans, tellingly, are designed to at least provide the illusion of flat rate. None of them inform their customers of the state of their account after each session or call.

Example 3: software developers outside the charmed inner circle could not deploy programs into a well defined public name space. Only the priesthood could create software whose executable name started with the magic asterisk. This meant that perfectly competent people who wrote perfectly competent and useful programs were made to feel like second class citizens when they tried to make those programs available to their colleagues, the campus, or the MTS world. I think we were less sensitive to the negative psychology of this and other insider/outsider distinctions than we should have been.

MTS ideas may have been invisible to most people

Many of the ideas that were developed in the MTS context were "internal". By that I mean that things like virtual memory, multi processing support, and clever paging algorithms weren't very accessible ideas to much of our user community. They were crucial to the quality and effectiveness of the service, but many people didn't understand them

Contrast this with Unix, in which things like the combination of pipes and unadorned text as a loose component coupling mechanism were directly exposed to the user community. Add the idea of replaceable command shells, and you have a very visible kind of computing style that distinctly represents the system.

This may have been a somewhat time-dependent disadvantage for MTS. When MTS was first developed, these internals were not widely understood. The MTS developers had to put energy into the user-invisible things because otherwise they wouldn't have had a viable system. Unix came along later, and many of those "internal" issues, if not quite easily solved problems, at least had lots of precedents to help.

MTS wasn't portable

MTS was trapped in the 360/370 world. When that world shrank, MTS had nowhere to go. In contrast, Unix migrated among various architectures.

MTS didn't scale well

Because MTS was very parsimonious in its use of resources, it should have been able to scale to desktop systems. As a matter of fact, there were some efforts to port it to smaller scale 370 clones and emulators.

We at UBC had connections to an Amdahl project manager (John Hiles) who failed in his attempt to get Amdahl to build a desktop 370. Partly out of frustration at this, he left Amdahl and formed his own company to do just that. He actually got the hardware built, but he failed in solving the software problem. He explored the possibility of using MTS, but it turned out that getting commercial licenses for many important MTS components such as compilers was effectively impossible. In many cases (IBM being the most important one) the companies that held the rights to the software wouldn't even negotiate with him. As a one-man company, he wasn't believable as a market. He also found it difficult to get clear answers to questions about commercial usage of MTS itself.

So, through no inherent fault of its own, MTS was cornered into whatever price/performance slots IBM, Amdahl, Hitachi, and Fujitsu decided to address with their 370 and 370-compatible machines. For whatever reasons, they weren't interested in scaling down to the desktop or up to supercomputers.
Comments