Systems Software Research is Irrelevant (2000) [pdf]

Since Rob Pike wrote this note in 2000, there have been many commercially important advances in systems software:

- iOS and Android: Power-efficient mobile systems, wakelocks, etc.

- Docker, Borg and Kubernetes: Container isolation, cluster orchestrators.

- Modern browser environments, with high degrees of isolation.

- Fast JavaScript runtimes and specialized JITs.

- WASM.

- Ruby and metaprogramming, which rose to considerable commercial success and then petered out. But by the standards of 2000, there's some neat language design there.

- Rust, which successfully applied a lot of lesser-appreciated academic ideas including affine types.

- Type systems retrofitted to many dynamic languages, including Typescript. Typescript is really rather remarkable, even though the types are "unsound", in the technical sense.

Some of these trends were already underway in 2000, when Rob Pike was writing. Admittedly, much of the most important implementation work happened in big tech companies, or occasionally startups. Not in academia. But that's largely a question of scale. Even as early as 1990, it was hard for a professor and a few graduate students to directly change the industry. But plenty of the items on the list above do have roots in academic research.

And Rob Pike did get to write Go. He deliberately ignored quite a bit of interesting research to focus on a specific aesthetic vision, which is fine. And a lot of good systems work has been done in Go.

I have been working as a scientist in academic and industrial systems research for most of my life now and I have a different view on this. There are plenty of ideas that float around in academia for years or even decades before they get adopted by the industry. Examples have been mentioned here. People declaring some research area dead are usually proven wrong by time (as was Pike), because nobody can foresee which results will be relevant in the future. I tend to think of it as sort of scientific entrepreneurship, you need 100 startups to get one unicorn.

The point is: (academic) scientists have no interest in productization, they are merely interested into the next hot topic and the next paper, because that's their job. Productization is for product managers and engineers. Occasionally the lines are blurred, but I consider this separation of concerns a benefit, not a problem.

The problem is there is a research bottleneck with inadequate development of existing ideas, and relatedly a coordination problem where there aren't enough "rich artists" who want to get rid of accidentally complexity simply because it is the beautiful and correct thing to do. Stuff like Linux us funded by marginalist types who too often just chase after the current paper cut, and miss the forest for the trees.

At this point, we can't switch hole hog to a new OS very well. But as I argued in https://news.ycombinator.com/item?id=29697474 I think we should dump a bunch of funding getting CloudABI or something like it (WASI with WASM, don't care what it's called) over the finish line in multiple OSes.

I argue this is a very "non-reformist reform"

- Easy to incrementally adopt e.g. for socket-activated services

- Nonetheless narrows gap between Unix and cool stuff like Fuschia/seL4 and WASM's future plans

- Narrower syscall API that isn't just legacy lowest common denominator will allow multiple implementations of the same interface, which in turn will "unstuck" the whole R&D life cycle:

-- Narrow interface means research experiments can better run real programs

-- Research experiemnts can show better promise, especially to "practitioners"

-- Developing research projects into production systems is cheaper less of a jump

This will restore the much needed "fluidity" where there is a continuum between research protypes and production systems, and multiple competing production systems.

----

The good news is that "library OS" type designs are finally kinda going mainstream on the research end of things. Going back to "competition" bucking the current winner take all trend (LLVM > GCC, Linux > other unix) will be prohibitively expensive unless we start reusing code.

He left off the word Operating, and everyone assumed he meant something else... there really are no new operating systems these days, they're all clone of Unix in some fashion.

Containers and virtual machines are stopgap measures we're all adopted because nothing new has come along, and the Unix model of security isn't up to the task.

We need to be able to download code from the internet, and run it against X, where X is a folder, or a photo, or a URL, and know that the Operating System will only let that code access the things we gave it, and nothing else.

We don't have capability based Operating Systems, all we have that's even close is the ham fisted "capability" flags that allow an "app" on a phone to access or location, or not.

Analogy time: If I'm making a cash purchase, and I owe $14.21, I can pull out exact change, or hand over $20, knowing full well that the other party isn't going to magically be able to sell my house, or otherwise cost me more than that $20 capability I chose to exchange with the hope of getting $5.79 in change.

Linux/Unix has no easy way to say... here's a file, run this code with this file as input. The security model of Linux isn't suitable for the any date after the Eternal September of 1993.

The only thing close is to put the code in a virtual machine, or container, to try to limit the scope of the damage a piece of code can do. It's massive overkill, and does the wrong job anyway.

I think he was right, perhaps someone here can convince me otherwise.

See also Timothy Roscoe's USENIX OSDI 2021 keynote where he laments the same thing: https://www.usenix.org/conference/osdi21/presentation/fri-ke...

Slides: https://people.inf.ethz.ch/troscoe/pubs/2021-07-16-OSDIKeyNo...

He seems to think the solution is that "the OS" should expand in scope to also run and manage all the myriad little special purpose processors on a modern SoC.

I think that i understand the argument, but things changed with the advent of microservices. Suddenly everything turned into a distributed system, and it is hard to cope without some understanding of the subject matter. This lecture series by Martin Kleppman has helped me quite a bit here: https://www.youtube.com/watch?v=UEAMfLPZZhE&list=PLeKd45zvjc... Also see his book 'Designing Data-Intensive Applications', which is more focused on discussing practical systems.

System software research sounds like it could benefit from focusing more on the systems than the software. No one is going to be building the next Linux. But they could build the ecosystem, architecture, and incentives for the next Linux to organically form. It's no longer just an engineering problem but an organizational and business one.

> There has been much talk about component architectures but only one true success: Unix pipes. It should be possible to build interactive and distributed applications from piece parts.

Wouldn't Microsoft's COM be another success in that area? It was several years old and in widespread use in Windows at the time the article was written.

Maybe this paper was accurate in 2000, but does not capture the work of systems research since then.

Some examples: - DHT protocols as used in bittorrent - SMR protocols, used in all kinds of distributed systems, from blockchains to cloud computing systems - Cloud computing systems, such as Spark, Mesos, MapReduce

This doesn't even cover work on networks, databases, systems, security, etc.

    research community that writes papers rather than software.

This is like lamenting that physicists are not creating enough physics. The foremost goal of computer science is to understand.

Hmm, doesn't Rob Pike now work at Google, which has developed the Chrome browser, which in addition to being a successor to Netscape (mentioned in the article) is basically a complete OS and runtime environment, as well as the literal ChromeOS, Android, Fuchsia, and Kubernetes, as well as Dart, and Go (and also adopted Kotlin for Android?) Not to mention software systems for special-purpose hardware like tensorflow, quantum, etc..

Which of those are research projects and which are commercial products/projects (or both perhaps?) is left as an exercise for the reader.

In addition to things categorized as “systems research”, there’s a bunch of new stuff like IoT devices which all need their own OS and update mechanisms.

Maybe the classical “write a new OS (because we didn’t understand the economics of hardware)” is no longer the case, but there’s still plenty of research going on: unikernels, containers…

It just looks different than what it used to. Also that paper is from 20 years ago.

> 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 much effect. . .

> Research has contributed little, despite a huge flow of papers on caches, proxies, server architectures, etc

The scale of compute changed:

- Mobile (iOS and Android)

- "The cloud": the systems became multi-computer networks. (Aurora, Mesos, Kubernetes, etc.)

- Web Browser as a platform (and associated technologies, such as Node)

The scale of the problem changed and shifted. Single machine scheduling is not as interesting, since large scale computing is about that, scale (even at the cost of some efficiency). You could say that Amazon EC2 is a cloud operating system (thought as all the separate subsystems that allow a mostly frictionless experience).

Mobile shifted the focus to security and energy consumption.

And the Web changed what a system platform is. The browser is a system abstraction, to the point where things like Chromebooks are viable. Code is now portable, run anywhere.

Systems software research is alive and well. Making new single machine kernels is just no longer priority. Community shifted to distributed system (essentially viewing thousands of computers as one fault-tolerant OS). A lot of things came indeed from academia. The next shift currently underway is in distributed machine learning (how can you build, train and serve trillion trillion parameter models - call it a distributed machine learning OS). A lot of things again is coming from academia. The field has grown up and old folks are lost in nostalgia of not seeing new kernels as they used to.

This paper came to my mind when I watched this clip which is extended material from the documentary Side by Side https://youtu.be/lepOQ2KfDwo

I just think writing off all the ideas that will follow, sometimes in different venues, is just sour grapes.

Rob Pike was drinking the poison chalice well before the rest of us. He wasn't wrong, here, back, in 2000. But damn. We've seen net zero systematic gain in computing across the entire industry in TWO FUCKING DECADES. Not a single iota of gains or win. Not a single systems software change has made it into the world. Everything is dead dead dead dead. Applications claim more and more and more, networks portals & endless walled gardens claiming bigger and bigger chunks of mindshare. General computing has won not a single drop. It's not because Pike was right: it's because we let everything except Systems Software grow, because we failed utterly to even try to deliver "wide" value in computing. Systems research was already giving the fuck up, it's funding was disappearing, & Pike was merely pounding another cynical nail in the coffin of trying for better at a time when we were desperately in need. Few concerted efforts were materializing then, & less & less have materialized along the way.

Perhaps the biggest modern counter-example we might point to is Rust. But in many ways, I feel like Rust justifies many of Pike's complaints:

> 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.

Now, I don't think this expectation is fair. But I do think that Rust is primarily different for developers. It hasn't really given rise to anything new, from what I can see. There's no new potentials here, no new possibilities embued by Rust: it's simply the same, but less, deliberately less, deliberately more choosy: it's a deliberate subset. It will never help us explore further, make better user systems. Only ones which fuck up slightly less. Generally I think the paranoia fear & sadness over software camp already had too strong a hold.

This paper hurt like fuck when I originally read it. It's still not wrong. But it's unnecessary overkill, to a world that was already suffering, and which, I believed then & believe now, must ultimately rise like a phoenix & rediscover itself, re-find purpose, & make itself real. Computing has gotten only ever more fake & bullshit since this decrial, and 99% of what Pike pissed on is exactly what is necessary for computing to regain even the most faint sense of vitality & aliveness. We've been in the deadzone for decades now, decades since this was written. Pike was not wrong when he warned about what a doledrums we were in, but it's not Systems Software that's at fault. It's failure to make real, failure to believe, failure to live in a better world, failure to build with as opposed to build alternatives-to that had been dooming us. This call for anti-vision is 100% the black miasma we have had to live inside of for the past two decades, has perfectly described the nihilism that hope has been trapped inside of. It's fucking time to open the god damned pandora's box again, and let hope try to make it's way out.

Rather than measure by how many operating systems are being created, I'd prefer measuring by more forward thinking metrics. The results are still not good. But measuring how many cross-website information systems emerge. Counting systems like Tim Berners-Lee's Solid or ActivityPub: they are where the puck is. The truth is, operating systems are irrelevant, because they have never succeeded beyond a single computer, and no one cares about a single computer anymore. It's no longer where the puck is. Systems research needs to be connected, communicative today. It needs to be online, and preferrably if at all possible offline too. The new frontiers of systems research are tech like CRDTs and Git. They're tools like Web Annotations that give us read-annotate-write capabilities to the general computing medium/fabric of the day, like the web. To a lesser degree it's also systems like FreeDesktop & DBus, which help applications & daemons expose themselves to user-scripting, it's tools like systemd which are intensely automateable & advanced new master-control-programs for the OS. I think we're still missing layers to really surface the malleability of this digital matter to the user, we're still not making a real difference, & we need to some day emerge from behind the digital curtain & become real to the world, to make systems research relevant. But systems research is happening, it is important, it has changed everything. Just... alas... very very very little for the user. That still needs to be changed. But new OSes will probably not make the difference. We already have great mediums, great systems; the frontier merely needs research to be bridged back into the mundane everyday experience of the "user'.

I am a big fan of Mr Pike’s work. I would love to see Mr. Pike revisit this whitepaper as of 2021/2022.

It takes a person like this to design a language like Go, whose fundamental philosophy is that people cannot and do not want to learn anything new, ever. It takes that kind of cynicism to also view hardware with disdain and horror.