[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is Systems Software Research Irrelevant?
Yes, I saw this paper some time ago. All in all, I am not favorably
impressed.
A systemic problem with this paper is that he often conflates the
broad term "system software" with a narrow reading of the phrase
"operating systems". In one of the only places where he explicitly
doesn't do this, he says:
"But now there are lots of papers in file systems, performance,
security, web caching, etc.," you say. Yes, but is anyone outside the
research field paying attention?
Yes, in fact, they are. Time passes between when an engineer reads a
paper, and when he makes a design decision influenced by that paper,
and so it's hard to see the connection externally.
His "Software Is Stagnant" slide seems to mean that *he* himself has
stuck with the same software for a long time. There has been all
kinds of new software recently. Just because we're still using Emacs
to do things that Emacs is good at, and TCP/IP to do what it's good
at, doesn't mean there's nothing new under the sun.
Exercise: Compare 1990 Microsoft software with 2000.
Well, as a matter of fact, Windows XP is vastly superior to the
Windows available in 1990!
If systems research was relevant, we'd see new operating systems and
new languages making inroads into the industry, the way we did in the
'70s and '80s.
Again, "operating systems" is being used in a narrow way. Many of the
kinds of things that are cool in operating systems are still
happening. There's exciting work in network-attached storage, in all
kinds of computer security stuff, in distributed computing including
but not limited to the stuff that gets called "peer-to-peer", in
research about how to make a better Web server, and so on. If you
like doing operating system stuff, there's plenty of great stuff for
you to work on right now; it's just probably not going to displace
Unix and Windows.
I could equally well argue that things have gotten boring and stagnent
because the word size of computers, which used to be refreshingly
diverse, has converged into a uniform featureless landscape of 32 and
64 bits and nothing else. Ah, how the good old days have passed us
by! But that's nonsense.
Personally, I think he's really lamenting that Linux is getting all
the headlines while Plan 9 and Inferno have no traction. He's trying
to build a whole edifice on top of this whine, and it just doesn't
hold together.
Even into the 1980s, much systems work revolved around new
architectures (RISC, iAPX/432, Lisp Machines). No more. A
major source of interesting problems and, perhaps, interesting
solutions is gone.
Yup, those things are all gone. They were dubbed "special-purpose
hardware", and though at the time I angrily denied the appropriateness
of this phase as applied to to Lisp Machines, I now concede the point
completely.
My friend Mike Kazar (author of the MagicSix timesharing system at
MIT) is CTO at Spinnaker Networks. They were going to do
special-purpose hardware to make a very fast network-attached storage
device, and they hired all these ASIC guys and made all this hardware.
Eventually they discovered that NAS doesn't have any "inner loop" that
is amenable to hardware speedup, and they retreated into being purely
a software product company. Much the same happened to the field of
"database machines" (e.g. Britton-Lee); you just don't get the bang
for the buck from specialized hardware for these things. I can
sympathize with his lamenting that the "interesting solutions" are
gone, but they're gone because they aren't the answer to "interesting
problems".
He laments:
Estimate that 90-95% of the work in Plan 9 was directly or indirectly
to honor externally imposed standards.
Well, what is he trying to do, "research", or making a computer system
that people will really use? If the latter, the customer is always
right, and if that means you have to do boring programming, well, you
have to. He'd just love it if he could (a) do only the work that he
finds fun, and (b) everyone beat a path to his door so that he became
the big shot instead of Linus Torvalds. Sure, nice work if you can
get it, but it's unreasonable to expect to. (Oh, OK, I'm being too
nasty. I guess from my Lisp Machine experience I have a major "there
but for the grace of God go I" feeling about all this.)
His real lament is about languages and operating systems, both things
which are very much controlled by "network effects". I would not
consider running Plan 9 because when I want to buy some piece of
hardware, there's virtually no chance that the manufacturer has a Plan
9 driver, since nobody else uses Plan 9, etc. It is very, very hard
to "break in" and create the positive-feedback loops that bring a new
language or operating system to prominence. That's why there's an
"orthodoxy". Does it bother him that nearly every automobile in the
USA has essentially the same user interface (steering wheel, brake
pedal on the right, etc)?
(If he wants Inferno to make it to that level, he absolutely must give
it away for free and absolutely must make more information available
about it; the few very terse papers available hardly constitute
documentation.)
Also, the time scale is long: from design to final version can be five
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 groups
must find smaller things to work on.
Wow, what does he think industry is like? When was the last time he
asked his manager to do a project with a scope of five years? A
project that will have zero revenue for twenty quarters?
By the way, in my opinion, there were at least five very intersting
papers at the last SOSP conference.
Startups are too focused on short time scale and practical results to
try new things...
Be courageous. Try different things; experiment. Try to give a cool
demo.
I don't know how he defines "cool", but I've talked to lots of
startups lately and have seen lots of demos that I consider cool.
There has been much talk about component architectures but
only one true success: Unix pipes.
(Oh, you really don't want to hear me answer this!)