The theme of this session was a re-examination of the current trends in operating system research, with an emphasis on useful directions for future investigation. The session was moderated by Mary Baker and featured a paper presentation by Rich Draves and short presentations by each of the panelists (Bob Frankston, Alan Nemeth, Dave Presotto, and Jim Waldo). The presentations were followed by a general discussion.

The panelists: (left to right)Rich Draves, Alan Nemeth, Jim Waldo, and Dave Presotto.

The other panelists provided a variety of visions of where operating system research is (or should be) going. Bob Frankston of Microsoft said that large software systems should not be created, but rather should evolve incrementally over time. Alan Nemeth of DEC observed that all software rots, and that it si vital that we focus on ways of slowing this rot by providing better "hygiene." Dave Presotto of Lucent Bell Labs questioned some of the tradeoffs that systems such as Java and Inferno have been making when they rely on software to provide protection between applications, and incur large performance penalties for something that existing memory management hardware can do much faster. The final panelist, Jim Waldo of Java Soft, pointed out that the real "consumers" of operating systems are application developers, and provided a variety of suggestions for areas of research that would be relevant to their concerns.

The ensuing discussion covered a variety of topics, focusing primarily on system administration and the ease of use (or lack of it) in existing systems.

The Rethinking session was chaired by Mary Baker of Stanford University. It consisted of presentations by each of the five panelists, one of which was a paper presentation, followed by general discussion of the issues raised by the panelists.

Extended Discussion

The first speaker was Rich Draves of Microsoft Research, who presented a paper titled, "Operating System Directions for the Next Millenium." Rich and his colleagues are looking at ways to make it easier to build distributed systems. By way of motivation, Rich described extensible systems as systems that allow bright people to do cool things. In contrast, Rich's goal is to allow average programmers to get involved in distributed systems.

In describing what his group hopes to do, Rich drew analogies to previous technologies trends, which have removed programmer control over low-level decisions, sacrificing some performance and application functionality for a decrease in the amount of effort require to design and build the resulting systems. This can be seen in the move from assembly language programming, to higher level program languages, and in the elimination of details such as register allocation, page placement, and instruction scheduling from programmer control. Rich posited that we are ready for a similar increase in the level of abstraction in distributed computing.

To this end, Rich presented several research goals. The first goal is seamless distribution. Rich suggested that the system should determine where in the network computation executes and where data lives. The system would move them dynamically as needed, allowing users to productively use any computing device as easily as their home machine.

A second goal is self-configuration, allowing new machines, network links, and other resources to automatically be assimilated into the system without user intervention.

Another goal is for the system to be self-tuning. The system should be able to reason about computations and resources. The system might automatically move computations around, or reallocate resource, or it might make suggestions to the user about how to reconfigure specific components of the system. (A person sitting near me suggested that every system would endlessly suggest that the user buy more memory!)

Rich and his colleagues are currently considering these issues in the context of small scale distribution with the ultimate goal of scaling it up to the internet.

The ultimate vision is that a user will buy some hardware, and plug it together, then the system will install itself over the network, figure out what resources are available, and integrate them into the larger system. Without further configuration or other intervention, the user would now be able to use the system.

Discussion:

• Dan Duchamp (AT&T Labs) pointed out that there is a wide range of hardware, and asked whether a single operating system would be expected to span the entire thing. Rich's response was, "Yes, it's Windows!" Rich replied more seriously that yes, their ultimate goals include a single system that will support the entire range of hardware platforms.

• John Chapin (MIT) expressed skepticism, pointing out that Sun's Spring system had been designed around the idea of seamless distribution and that that system has been a failure. He also suggested that the authors should read "A Note on Distributed Computing" by Jim Waldo et al. for a good explanation of why transparent distributed computing doesn't work. [Copy link to this paper from the CS 262 homepage]

• Noah Mendelsohn (Lotus Development) observed that some of these same goals had turned out to be very hard in LOCUS because the interfaces and user/programmer expectations (from the non-distributed world) didn't match the needs of the distributed system. Rich responded that his group was not being by the interfaces of current systems. Although they work for Microsoft, they are not currently thinking about how to support existing APIs. They have a free hand and by starting with a clean slate are pursuing whatever avenues seem promising.

The next speaker was Bob Frankston (also of Microsoft).

In the sessions leader's words we got rid of all of the Microsoft people right away.

Bob (picture to the left) provided a variety of observations and insights into the construction of large, complex software systems. he started with several caveats; he didn't claim that they were actually implementing anything, and he wasn't sure what the relationship will be between what he described and what will actually get built. Bob observed that operating systems (like databases) were developed as solutions to specific problems. People discovered that they were doing the same thing over and over, solving the same problems and coding up similar solutions to them. THe result was a body of code that dealt with these common cases.

Moving on the the construction of large systems, Bob posited that programs, especially large ones, shouldn't be written. Instead, the should evolve. As a metaphor for this process, he described the process of adding small bits of code to a system as being like throwing small balls at a larger collection of similar balls the represent the system being modified. Ideally, we would like these balls to be covered with velcro, so that they stick together easily. Unfortunately, with most current software, the balls are like oranges. Throwing one orange at a pile of oranges is likely to send oranges flying all over the room.

Bob claimed that object-oriented programming is the not the silver bullet that will solve this problem. The problem with OOPS is that once an interface is designed it becomes very difficult to change it. This makes it difficult to evolve large systems.

On the subject of rethinking, Bob had a variety of observations:

• There is no perfection, just trade-offs.
• Applications drive everything.
• The operating system only matters if it makes my life easier:
  • DOS succeeded because it didn't get in the way.
  • OS/2 made me understand that I did not want Multics on my desk.

Alan Nemeth from DEC was the next speaker. He started his presentation by observing that, "software rots; operating systems are no exception." Extending the metaphor, he suggested that the natural course of action is to apply deodorant, and to add scaffolding to prop them up.

Alan said that the central problem for operating system implementation is to maintain current operating systems as viable offerings when we have to keep up with new ideas and new hardware. Unfortunately, in reality we tend to underinvest in current operating systems, as we are inclined to say that they are old and cruddy and should be scrapped in favor of some new system. Economically, this is abysmal.

Thus, Alan proposed that we need to focus on technology and business models that will let us put existing operating systems on "diets" and "exercise regimens" that will keep them healthy. Furthermore, we shouldn't always be going back to a clean slate whenever we are dissatisfied with currently available systems. [This advice was received with remarkable calm by an audience that included representatives of at least four current "clean slate" operating systems.]

The next panelist was Dave Presotto of Bell Labs. Dave expressed an interested in seeing all of the people currently exploring issues of extensibility move more in the direction that the Java and Inferno crowds have been exploring. He observed that these are the technologies that are currently driving extensibility; the masses are now extending their operating systems because everything is interpreted and safe.

Dave observed that in the past, we have relied on hardware protection to provide safety between different applications or between applications and the operating systems. The trend now, as exhibited by Java and Limbo (or "Lava and Jimbo") is to rely on code to provide the same safety guarantees as the MMU. Dave questioned whether this code can be as reliable as hardware, and whether it is worthwhile in light of the fact that we are now taking a 10x performance hit because we are using a lot of code, and interpreting our executables to provide the same safety guarantees that the MMU already gives us.

The final panelist was Jim Waldo of Java Soft. Although he didn't have slides, Jim chose to give his talk standing up and walking around because he figured would make him a tougher target....

In response to John Chapin's earlier comments [link] Jim started by recommending that the Microsoft folks *not* read his paper on the impossibility of transparent distributed computing, as that might give his own company a competitive advantage. In fact, Jim declined.

Jim stated that he doesn't care where operating system research goes. He presented the assembled crowd with a choice. The first choice is to continue on their current path, and hope that people from Microsoft show up at their conferences, and pay attention. Jim said that he can relate to the satisfaction of working on hard intellectual exercises, after all, he has a PhD in philosophy, and in his view, trying to make IPC as fast as possible is like trying to figure out how many angels can dance on the head of a pin.

The second option that Jim presented is to try to work on things that lots of people will care about. Since this was a workshop on operating systems research, this begged the question, "Who cares about operating systems research?"

Jim's opinion is that users don't care about operating systems. As evidence, he pointed to the operating system that most of the choose. He also noted that in one operating system that users do get excited about---MacOS---what they like is the user interface, not the operating system! Finally, he observed that many of the topics that had been repeatedly discussed earlier in HotOS, performance, flexibility, and extensibility, just don't matter except at the high end, and that high end applications, such as Oracle, frequently do their best to ignore the underlying operating system.

So, if users don't care about operating systems, what do they care about, Jim asked. His answer was, "Three things, applications, applications, applications."

Jim therefore hypothesized that the real market for operating systems is application developers, since they are the ones who actually have to get intimate with the operating system.

Taking this line of thought one step further, Jim asked, "What do developers actually care about?" His answer was, "Three things, volume, volume, volume." Thus developers choose the operating system that has the most users.

Jim suggested that there are two possible conclusions from this. Either "it's all over and we should all go and work for Microsoft," or we need to find some other features that application developers might actually care about. Jim went on to outline some areas of research that might fit the bill:

1. Portability. This is just another way for application developers to get more volume. It will let them reach the other 3% of the market.
2. Distribution. How to distributed computation in a more reasonable way.
3. Being able to test for correctness so that we can improve on the current situation which is "satisfaction guaranteed or we won't be surprised."
4. System administration---the ugly back corner. It's dull, boring---and hard. "You've got to be a 14 year old male covered with Clearasil to understand windows administration."
5. How about a security model that everyone understands.
6. Plug and play instead of plug and pray.

• Margo Seltzer (Harvard), playing curmudgeon, pointed out that we all drive cars, and that car mechanics are sort of like developers. There are far fewer mechanics than cars. If we rethink the world, she asked, is there any reason to think that there will be that many more developers?

• Bob Frankston replied using a different analogy, that we are all telephone operators, even though none of us think of ourselves that way. Years ago, you needed the assistance of a specially trained operator to complete every phone call. Now, we've made the interface so simple that anyone can do it. Bob suggested that the problem with computers is that we haven't figured out how to make them simple enough.

• Mike Jones (Microsoft Research) responded to Jim Waldo's suggestion that making system administration was a good area for research by pointing out that if you assume that Rich Draves and his other colleagues at Microsoft get the Millenium system to work, then most people's need for system administration will go away because it will happen automatically.

• Jim Waldo agreed with the goal of making system administration happen automatically, but pointed out that it is already a hard job to do on a single machine, and that believing we can solve the problem on the the scale of the internet is "replacing a mystery with a miracle."

• Dave Presotto (Lucent Bell Labs) followed up by pointing out that Plug and play is a nice idea, but that the only system where it actually works is that Mac, and that the reason it works there is that one vendor controls the whole system. Dave concluded that we won't get real plug and play until Microsoft controls everything.

• Alan Nemeth suggested a different way to think about system administration. Imagine that there are a bunch of switches that you use to administer some machine. There are only two possible ways that such a system might work. Either nothing changes when you fiddle with the switches, or there is only one setting where the system works. Either way, the correct thing to do is to remove all of the switches.

• Jeff Mogul (DEC WRL) was critical of all of the analogies that he had heard in this discussion, because they all described systems that are much simpler than computer systems. Jeff argued that what we have to do in system administration is more like management and politics. He described politics as the art of "muddling through," and not letting the system collapse, and suggested that this is what system administration is about.

• Jay Lepreau (University of Utah) returned to the issue of seamless distribution, observing that in many areas, people like local control and that global control frequently doesn't work well. He suggested that this might be a concern for the Millenium groups goal of transparent system configuration and administration.

• Rich Draves agreed that this might be a concern, but pointed out that lots of people aren't into endless customization; they just want the system to work.