Dan Cross writes:
First, thank you for all of the thoughtful responses, both on-list and off.
An interesting theme in many of the responses was essentially questioning
whether the underlying OS still matters, since the focus on development has
shifted to higher levels? E.g., we now provision components of our
enormously large and complicated distributed applications with
building blocks like containers, less physical machines, let alone
processes etc. That is certainly a trend, but it strikes me that those
containers have to run somewhere, and at some point, we've still got
instructions executing on some CPU, modifying words of memory, registers,
etc; presumably all of that runs under the control of an operating system.
It is a worthwhile question to ask whether that operating system still
matters at all: what we have works, and since it's so hidden behind layers
upon layers of abstraction, do we really care what it is? But I claim that
it does perhaps more than most folks realize. Certainly, there are metrics
that people care about (tail latency, jitter, efficiency at the 90th, 95th,
99th percentile...) and OS effects can have outsized impacts there; Mothy's
talk alludes to this when he talks about all of the hidden processing
that's happening all over a modern computer, eventually some of that
trickles onto the cores that are running one's containerized Node
application or whatever (lookin' at you, SMM mode...). At the end of the
day, the code we care about still runs in some process under some OS on
some bit of physical hardware, regardless of all of the abstractions we've
placed on top of those things. What that system does, and the abstractions
that its interface provides to programs, still matters.
Perhaps another question worth asking is, does it make sense to look at
different models for those systems? My subjective impression is that, back
in the 60s and 70s, there was much greater variation in system
architectures than today. A common explanation for this is that we didn't
know how to build systems at the time, so folks threw a lot of stuff at the
wall to see what would stick. But we no longer do that...again, Mothy
alludes to this in his brief survey of OSDI papers: basically, new systems
aren't being presented. Rob Pike also lamented that state of affairs 20
years ago, so it's been going on for a while. Does that mean that we've
come up with a recipe for systems that work and work well, and therefore we
don't need to rethink those basic building blocks? Or does that mean that
we're so used to our systems working well enough that we've become myopic
about their architecture, and thus blind to their faults?
- Dan C.
Well, I have two different thoughts on this question.
The obvious one to me is that of course it matters.
I'll start by drawing a lame analogy as our 12 week deck reconstruction
project just finished up an hour ago. In a conversation with the
contractor he said "You're technically doing a repair so you don't have
to pull a permit and bring it up to current code. But, there are some
things that I recommend that you do anyway because the technology is much
better than what it was when this thing was built 30 years ago." My point
here is that sure, we can survive with what's there, but that doesn't mean
that we should ignore new technology.
I had dinner with one of the people I mentor a few weeks ago. He told me
that while he was generally ok working for Google and making gobs of money
that he felt sort of empty. He told me that if his project got cancelled
he didn't think that the world would notice, and as a mid-20s person seeing
the planet that he's living on burning up, he's thinking about changing
careers to something that's more meaningful (to him). I think that there is
still plenty of work to do on things like efficiency that would be easy to
justify if politically energy wasn't so heavily subsidized. Think back a
few decades to all of the power-saving changes that the OLPC spawned. Most
felt like things were fine the way they were back then too. I think that
layers upon layers is wasteful.
As I've said before, I'm having difficulty distinguishing the "full
stack"
in full stack programming from a compost heap. It's not OK to me from a
security, safety, and reliability perspective to build on a rotting
foundation.
It's my opinion that the whole container thing sort of started as a "we
can't secure the underlying system so we'll build something secure on top"
combined with "it's no fun to fix the unnecessary incompatible mess among
virtually identical systems that we've made so we'll build a new fix-it
layer" ideologies. How long until problems are found with containers
it's decided that the way to fix it is to build "safe deposit boxes" that
run in container? Is there ever an end in sight?
My second train of thought is to ask the question "what is a computer?"
Having started in an era where computing meant basking in the warm glow
of vacuum tubes, it's easy to think that it's the hardware. But somewhere
along the line microcode made an appearance, followed by nanocode and so
on. I'm guessing, especially from spending time with current CS students,
that to many a computer is some high-level abstraction. So the question is,
below what layer is considered a computer today?