Bershad talked about David Cheriton's frying pan model. The problem, as Cheriton stated it, is that your head hurts. You're hitting yourself over the head with a frying pan. To solve this problem, you can take aspirin or drink a lot and that will deaden the pain. Or, alternatively, you could stop hitting yourself with a frying pan.
The point of the story is to attack the problems which bother you when you wake up in the morning. For example, Java security model sucks, that bothered Brian, so he started the Kimera project.
John Wilkes had some advice
Noah suggested that OS research not be done unless there's a good knowledge of the paplications that run on top of them.
Mogul suggested that the lack of freely available source for large applications was hindering OS development. He suggested that Noah make it easy to get the source for Lotus apps.
Mark Day responsed that the OS community should go out and buy the tools people are using (VB, Visual C++, etc.) and use them.
Presotto had serveral points to amke. First, he agreed with Noah in that the use, build, and design of applications is the only way to design succesful systems. He aruged that systems people can only solve their own problems - since they're only really acquainted with the requirements of their own problems. He said that most of the issues around large systems are social and maanagerial. Every once in a while, through all the grunge, you find a nugget. However, you have to build the applications to really understand the system. He spoke of his experience at Bell Labs with UNIX/Plan-9/Inferno. For the most part, they were designed to solve internal requirements they had. He said that every time he needed to come up with an idea, he'd go over to the application guys (e.g. guys building telephone switches) and talk over their problems. He'd try to equate that with the work he was doing to see if he couldn't come up with some reasonable solutions.
As some models for excellent systems research, he pointed out the Oberon Project. He lauded the people there for coming up with a complete system and living on it. Also, he like the Cambridge University model where the systems they build come out of campus-wide computing infrastructure projects.
Frankston pointed out that you can't do serious research in OS, because there's no way of doing a scientific experiment (too many variables)
Presotto pointed out that it was impossible to try out one idea in a larger context, since the medium is so malleable.
Chapin said that one good idea in isolation is not relevant. Somebody in industry has probably already come up with it. Also, he fretted that OS research was becoming too expensive. There were so many prerequisistie to building a "real OS" (e.g. networkig, GUI, object model, etc.) that people don't consider the stuff academia is generating as real OSes.
Chapin sees OS research as pushed by application guys on top and the hardware trends on the bottom. To tackle tommorrow's problems, he recommends a strategy he got from Mendel Rosenblum - take one issue and push it to an extreme to see solution. Industry will pick up your solution, though they might use only 50% of it. That's OK - you were taking the problem to an extreme anyway.
Black argued that the defintion of "real system" was probably wrong and he said that a small teams of talented people still do the best OS work.
Mogul pointed to computer and miroprocessor design at DEC's Western Research Laboratory. They gave up trying to outdo Intel or Digital's offerings just because of the hundreds of man-years it now takes to generate a processor. Instead, they focused on interesting designs or tweaks. Perhaps, operating systems have reached a similar point seemd to be the implication.
Rawson talked about seven areas he thought were intersting for OS research:
Mike Jones said that the development organizations were in general not looking for 10% imrpovements but things that change the game and provide compelling value. Alan Nemeth agreed, pointing to a special agreement between Oracle and Digitial, where special optimizations on the part of Digital in the operating system allowed ORacle to run two orders of magnitude faster. Oracle was willing to adjust their product to take advantage of that sort of speed-up.
The other interesting problem is getting research work in the product. One way is to see the research group as having internal customer. He pointed to Jeff Mogul as someone who had worked with several internal customers for a long enough period of time that they trusted him to the point that they accepted code from him.
Mogul said you have to be careful about when you give people ideas. If you give them an idea they don't need right now, they'll look at you puzzled and ignore it and work on the problem at hand. Also, tech transfer is much easier when the customer is desperate.
Leach suggested that looking for technology discontinuites was a useful place (e.g. move to the Web introduced a new portable language - Java).
Jones mentioned that he was personally torn between impact and fundamental research.
David Cohn pointed out that the free propagation of ideas and new ways of thinking are a valuable result of OS research, even if it doesn't get embodied in a product.
Liuba Shrira also argued the differentation between ideas and products. She says that object databases have largely been a failure but many of the techniques have been transfered over to relational databases.
Rawson suggested a good metric for research vs. product development is whether the problem is hard and long-term enough. Kaashoek disagreed that hard is a good metric. He also disagreed with success. After all, did the community fail because the web didn't come out of the OS community?
Seltzer argued there is such a thing as computer science research and that people should know what it is. It's a matter of posing questions and coming up with answers. Finding the relevant questions is the hard part.
Presotto pointed out that we're not scientists (i.e. not discussing aspects of nature). We're engineering - solving current of future problems and finding new ways of doing things. As such, you have understand your problems and other's problems to do good research.
Kaashoek also argued that training students is a significant value of OS research. Rawson ended by arguing that university OS research has created more competent hackers.