System Software Research Is Irrelevant

 System Software Research Is Irrelevant收藏
新一篇: Windows NT is VMS re-implemented? | 旧一篇: 李嘉诚在汕头大学的讲话
This is an HTML version of the original paper [postscript] [pdf] onRob Pike's web site, converted byEvan Jones.
Systems Software Research is Irrelevant
By Rob Pike - August 05th 2000, 23:59 EST
A Polemic
This talk is a polemic that distills the pessimistic side of myfeelings about systems research these days. I won't talk much about theoptimistic side, since lots of others can do that for me; everyone'sexcited about the computer industry. I may therefore present a picturesomewhat darker than reality.
However, I think the situation is genuinely bad and requires action.
Definitions
Systems:
Operating systems, networking, languages; the things that connect programs together.
Software:
As you expect.
Research:
Primarily academic research -- universities and a few industrial labs.
Is:
Now, not ten years ago, and I hope not in another ten years.
Irrelevant:
Does not influence industry.
Thesis
Systems software research has become a sideline to the excitement in the computing industry.
When did you last see an exciting non-commercial demo?
Ironically, at a time when computing is almost the definition ofinnovation, research in both software and hardware at universities andmuch of industry is becoming insular, ossified, and irrelevant.
There are many reasons, some avoidable, some endemic.
There may be ways to improve the situation, but they will require a community-wide effort.
A Field in Decline

"Who needs new operating systems, anyway?" you ask. Maybe no one, but then that supports my thesis.
"But now there are lots of papers in file systems, performance,security, Web caching, etc.," you say. Yes, but is anyone outside theresearch field paying attention?
Systems Research's Contribution to the Boom
A high-end workstation 1990 2000
Hardware
33 MHz Mips R 3000
32 megabytes of RAM
10 Mbps Ethernet
600 MHz Alpha or Pentium III
512 megabytes of RAM
100 Mbps Ethernet
Software
Unix
X
Emacs
TCP/IP
Unix
X
Emacs
TCP/IP
Netscape
Language
C
C++
C
C++
Java
Perl (a little)
Hardware has changed dramatically; software is stagnant.
Where is the Innovation?
Microsoft, mostly. Exercise: Compare 1990 Microsoft software with 2000.
If you claim that's not innovation, but copying, I reply that Javais to C++ as Windows is to the Macintosh: an industrial response to aninteresting but technically flawed piece of systems software.
If systems research was relevant, we'd see new operating systems andnew languages making inroads into the industry, the way we did in the'70s and '80s.
Instead, we see a thriving software industry that largely ignoresresearch, and a research community that writes papers rather thansoftware.
Linux
Innovation? New? No, it's just another copy of the same old stuff.
OLD stuff. Compare program development on Linux with Microsoft Visual Studio or one of the IBM Java/Web toolkits.
Linux's success may indeed be the single strongest argument for mythesis: The excitement generated by a clone of a decades-old operatingsystem demonstrates the void that the systems software researchcommunity has failed to fill.
Besides, Linux's cleverness is not in the software, but in thedevelopment model, hardly a triumph of academic CS (especially softwareengineering) by any measure.
What is Systems Research these days?
Web caches, Web servers, file systems, network packet delays, allthat stuff. Performance, peripherals, and applications, but not kernelsor even user-level applications.
Mostly, though, it's just a lot of measurement, a misinterpretation and misapplication of the scientific method.
Too much phenomenology: invention has been replaced by observation.Today we see papers comparing interrupt latency on Linux vs. Windows.They may be interesting, they may even be relevant, but they aren'tresearch.
In a misguided attempt to seem scientific, there's too much measurement: performance minutiae and bad charts.
By contrast, a new language or OS can make the machine feel different, give excitement, novelty.But today that's done by a cool Web site or a higher CPU clock rate orsome cute little device that should be a computer but isn't.
The art is gone.
But art is not science, and that's part of the point. Systemsresearch cannot be just science; there must be engineering, design, andart.
What Happened?
A lot of things:
PC
Hardware became cheap, and cheap hardware became good. Eventually,if it didn't run on a PC, it didn't matter because the average, mean,median, and mode computer was a PC.
Even into the 1980s, much systems work revolved around newarchitectures (RISC, iAPX/432, Lisp Machines). No more. A major sourceof interesting problems and, perhaps, interesting solutions is gone.
Much systems work also revolved around making stuff work across architectures: portability. But when hardware's all the same, it's a non-issue.
Plan 9 may be the most portable operating system in the world. We'reabout to do a new release, for the PC only. (For old time's sake, we'llinclude source for other architectures, but expect almost no one willuse it.)
And that's just the PC as hardware; as software, it's the same sort of story.
Microsoft
Enough has been said about this topic. (Although people will continue to say lots more.)
Microsoft is an easy target, but it's a scapegoat, not the real source of difficulty.
Details to follow.
Web
The Web happened in the early 1990s and it surprised the computer science community as much as the commercial one.
It then came to dominate much of the discussion, but not to mucheffect. Business controls it. (The Web came from physicists andprospered in industry.)
Bruce Lindsay of IBM: HDLC ~= HTTP/HTML; 3270s have been replaced by Web browsers. (Compare with Visicalc and PC.)
Research has contributed little, despite a huge flow of papers on caches, proxies, server architectures, etc.
Standards
To be a viable computer system, one must honor a huge list of large,and often changing, standards: TCP/IP, HTTP, HTML, XML, CORBA, Unicode,POSIX, NFS, SMB, MIME, POP, IMAP, X, ...
A huge amount of work, but if you don't honor the standards, you're marginalized.
I estimate that 90-95% of the work in Plan 9 was directly or indirectly to honor externally imposed standards.
At another level, instruction architectures, buses, etc. have the same influence.
With so much externally imposed structure, there's little slop left for novelty.
Even worse, commercial companies that "own" standards, such asMicrosoft and Cisco, deliberately make standards hard to comply with,to frustrate competition. Academia is a casualty.
Orthodoxy
Today's graduating PhDs use Unix, X, Emacs, and Tex. That's theirworld. It's often the only computing world they've ever used fortechnical work.
Twenty years ago, a student would have been exposed to a wide variety of operating systems, all with good and bad points.
New employees in our lab now bring their world with them, or expectit to be there when they arrive. That's reasonable, but there was atime when joining a new lab was a chance to explore new ways of working.
Narrowness of experience leads to narrowness of imagination.
The situation with languages is a little better -- many curriculainclude exposure to functional languages, etc. -- but there is also alanguage orthodoxy: C++ and Java.
In science, we reserve our highest honors for those who prove we were wrong. But in computer science...
Change of scale
With so many external constraints, and so many things already done,much of the interesting work requires effort on a large scale. Manyperson-years are required to write a modern, realistic system. That isbeyond the scope of most university departments.
Also, the time scale is long: from design to final version can befive years. Again, that's beyond the scope of most grad students.
This means that industry tends to do the big, defining projects --operating systems, infrastructure, etc. -- and small research groupsmust find smaller things to work on.
Three trends result:
Don't build, measure. (Phenomenology, not new things.)
Don't go for breadth, go for depth. (Microspecialization, not systems work.)
Take an existing thing and tweak it.
I believe this is the main explanation of the SOSP curve.
Unix
New operating systems today tend to be just ways of reimplementingUnix. If they have a novel architecture -- and some do -- the firstthing to build is the Unix emulation layer.
How can operating systems research be relevant when the resulting operating systems are all indistinguishable?
There was a claim in the late 1970s and early 1980s that Unix hadkilled operating systems research because no one would try anythingelse. At the time, I didn't believe it. Today, I grudgingly accept thatthe claim may be true (Microsoft notwithstanding).
A victim of its own success: portability led to ubiquity. That meant architecture didn't matter, so now there's only one.
Linux is the hot new thing... but it's just another Unix.
Linux -- the Academic Microsoft Windows
The holy trinity: Linux, gcc, and Netscape.
Of course, it's just another orthodoxy.
These have become icons not because of what they are, but because of what they are not: Microsoft.
But technically, they're not that hot. And Microsoft has beenworking hard, and I claim that on many (not all) dimensions, theircorresponding products are superior technically. And they continue toimprove.
Linux may fall into the Macintosh trap: smug isolation leading to (near) obsolescence.
Besides, systems research is doing little to advance the trinity.
Startups
Startups are the dominant competition for academia for ideas, funds,personnel, and students. (Others are Microsoft, big corporations,legions of free hackers, and the IETF.)
In response, government-funded and especially corporate research is directed at very fast "return on investment".
This distorts the priorities:
Research is bent towards what can make big money (IPO) in a year.
The horizon is too short for long-term work. (There go infrastructure and the problems of scale.)
Funding sources (government, industry) perceive the same pressures, so there is a vicious circle.
The metric of merit is wrong.
Stanford now encourages students to go to startups becausesuccessful CEOs give money to the campus. The new president of Stanfordis a successful computer entrepreneur.
Grandma
Grandma's online.
This means that the industry is designing systems and services forordinary people. The focus is on applications and devices, not oninfrastructure and architecture, the domain of systems research.
The cause is largely marketing, the result a proliferation ofincompatible devices. You can't make money on software, only hardware,so design a niche gimmick, not a Big New Idea.
Programmability -- once the Big Idea in computing -- has fallen by the wayside.
Again, systems research loses out.
Things to Do
Startups are too focused on short time scale and practical resultsto try new things. Big corporations are too focused on existingpriorities to try new things. Startups suck energy from research. Butgold rushes leave ghost towns; be prepared to move in.
"Why do you use Plan 9?"
Go back to thinking about and building systems. Narrowness is irrelevant; breadth is relevant: it's the essence of system.
Work on how systems behave and work, not just how they compare.Concentrate on interfaces and architecture, not just engineering.
Be courageous. Try different things; experiment. Try to give a cool demo.
Funding bodies: fund more courageously, particularly long-termprojects. Universities, in turn, should explore ways to let studentscontribute to long-term projects.
Measure success by ideas, not just papers and money. Make the industry want your work.
Things to Build
There are lots of valid, useful, interesting things to do. I offer asmall sample as evidence. If the field is moribund, it's not from alack of possibilities.
Only one GUI has ever been seriously tried, and its best ideas datefrom the 1970s. (In some ways, it's been getting worse; today thescreen is covered with confusing little pictures.) Surely there areother possibilities. (Linux's interface isn't even as good as Windows!)
There has been much talk about component architectures but only onetrue success: Unix pipes. It should be possible to build interactiveand distributed applications from piece parts.
The future is distributed computation, but the language community has done very little to address that possibility.
The Web has dominated how systems present and use information: themodel is forced interaction; the user must go get it. Let's go back tohaving the data come to the user instead.
System administration remains a deeply difficult problem.Unglamorous, sure, but there's plenty of room to make a huge, evencommercial, contribution.
Conclusions
The world has decided how it wants computers to be. The systemssoftware research community influenced that decision somewhat, but verylittle, and now it is shut out of the discussion.
It has reached the point where I doubt that a brilliant systemsproject would even be funded, and if funded, wouldn't find the bodiesto do the work. The odds of success were always low; now they'reessentially zero.
The community -- universities, students, industry, funding bodies -- must change its priorities.
The community must accept and explore unorthodox ideas.
The community must separate research from market capitalization.
Copyright © 2000 Lucent Technologies Inc. All rights reserved.
Rob Pike (rob@plan9.bell-labs.com),well known for his appearances on "Late Night with David Letterman", isalso a Distinguished Member of Technical Staff at Bell Laboratories inMurray Hill, New Jersey, where he has been since 1980, the same year hewon the Olympic silver medal in Archery. In 1981 he wrote the firstbitmap window system for Unix systems, and has since written ten more.He was a principal designer and implementor of the Plan 9 and Infernooperating systems. With Bart Locanthi he designed the Blit terminal;with Brian Kernighan he wrote The Unix Programming Environment and The Practice of Programming.A shuttle mission nearly launched a gamma-ray telescope he designed. Heis a Canadian citizen and has never written a program that uses cursoraddressing.
发表于 @2006年05月19日 01:49:00|评论(0)|编辑