On Systems Software

A prospective new college hire recently related an odd comment from his professor: systems programming is dead. I was nonplussed; what could the professor have meant? Systems is clearly very much alive. Interesting and important projects march under the banner of systems. But as I tried to construct a less emotional rebuttal, I realized I lacked a crisp definition of what systems programming is.

Wikipedia defines systems software in the narrowest terms: the stuff that interacts with hardware. But that covers a tiny fraction of modern systems. So what is systems software? It depends on when you’re asking the question. At one time, the web server was the application; now it’s the systems software on which many web-facing applications are built. At one time a database was the application; now it’s systems software that supports a variety of custom and off-the-shelf applications. Before my time, shells were probably considered a bleeding edge application; now they’re systems software on which some of the lowest-level plumbing of modern operating systems are built.

Any layer on which people build applications of increasing complexity is systems software. Most software that endures the transition to systems software does so whether its authors intended it or not. People in the software industry often talk about standing on the shoulders of giants; the systems software accumulated and refined over decades are those giants.

Stable interfaces define systems software. The programs that consume those interfaces expect the underlying systems software to be perfect every time. Initially innovation might happen in the interfaces themselves — the concurrent model of Node.js is a great example. As software matures, the interfaces become commodified; innovation happens behind those stable interfaces. Systems is only “dead” at its edges. Interfaces might be flexible and well-designed, or sclerotic and poorly designed. Regardless, new or improved systems software can increase performance, enhance observability, or simply fit a different economic niche.

There are a few different types of systems software. First there’s supporting systems software, systems software written as necessary foundation for some new application. This is systems software written with a purpose and designed to solve an unsolved — or poorly solved — problem. Chronologically, examples include UNIX, compilers, and libraries like jQuery. You write it because you need it, but it’s solving a problem that’s likely not unique to your particular application.

Then there’s accidental systems software. Stick everything from Apache to Excel to the Bourne shell in that category. These didn’t necessarily set out to be the foundation on which increasingly complex software would be written, but they definitely are. I’m sure there were times when indoctrination into systems-hood was painful, where the authors wanted to change interfaces, but good systems software respects its consumers and carries them forward. Somewhat famously make preserved its arcane syntax because two consumers already existed. JavaScript started as a glorified web design tool; now it sits several layers beneath complex client-side applications. Even more recently, developers of Node.js (itself  JavaScript-based) changed a commonly used interface that broke many applications. Historical mistakes can be annoying to live with, but — as the Node.js team determined — compatibility trumps cleanliness.

The largest bucket is replacement systems software. Linux, Java, ZFS, and DTrace fall into this category. At the time of their development, each was a notionally compatible replacement for something that already existed. Linux, of course, reimplemented the UNIX design to provide a free, compatible alternative. Java set about building a better runtime (the stable interface being a binary provided to customers to execute) designed to abstract away the operating system entirely. ZFS represented a completely new way of thinking about filesystems, but it did so within the tight constraints of POSIX interfaces and storage hardware. DTrace added new and unique observability to most of the stable interfaces that applications build on.

Finally, there’s intentional systems software. This is systems software by design, but unlike supporting systems software, there’s no consumer. Intentional systems software takes an “if you build it, they will come” approach. This is highly prone to failure — without an existence proof that your software solves a problem and exposes the right interfaces, it’s very difficult to know if you’re building the right thing.

Why define these categories? Knowing which you’re working with can inform your decisions. If you’ve written accidental systems software that has had systems-ness thrust upon it, realize that future versions need to respect the consumers — or willfully cast them aside. When writing replacement systems software, recognize the constraints on the system, and know exactly where you’re constrained and where you can innovate (or consider if you don’t want to use the existing solution). If you’ve written supporting systems software, know that others will inevitably need solutions to the same problems. Either invest in maintaining it and keeping it best of breed; resign to the fact that it will need to be replaced as others invest in a different solution; or open source it and hope (or advocate) that it becomes that ubiquitous solution.

TL;DR?

What’s systems software? It is the increasingly complex, increasingly capable, increasingly diverse foundation on which applications are built. It’s that long and growing tail of the corpus of software at large. The interfaces might be static, but it’s a rich venue for innovation. As more and more critical applications build on an interface, the more value there is in improving the systems software beneath it. Systems software is defined by the constraints; it’s a mission and a mindset with unique challenges, and unique potential.

Posted on February 25, 2013 at 4:46 am by ahl · Permalink
In: Software · Tagged with: 

5 Responses

Subscribe to comments via RSS

  1. Written by Dan Sutton
    on February 26, 2013 at 4:56 pm
    Permalink

    I’m pretty sure it’s possible to define systems software quite simply: as anything at level 5 or below in the OSI Seven-Layer Model, which, incredibly, is still relevant after all this time:
    http://en.wikipedia.org/wiki/OSI_seven_layer_model

  2. Written by Mark P
    on February 26, 2013 at 5:26 pm
    Permalink

    Systems programming traditionally meant Mainframe programming (FORTRAN, COBOL, etc.). I’m sure that is what the professor meant.

  3. Written by david
    on February 26, 2013 at 7:46 pm
    Permalink

    Actually, on the mainframe, COBOL and Fortran are part of the Application Programmer’s scope. A systems programmer is responsible for tuning the MVS operating system on which these programs run, by tweaking parameters or modifying system exit routines written in either Mainframe Assembler language, Rexx, or PL/S (a proprietary IBM language.) The sysprog also installs regular updates and patches to either the MVS OS (lowest level), or various databases/services that run on top – CICS, IMS, DB2. The MF systems programmers perform less actual programming than ever, so there probably is a trend of declining systems “programming” on all platforms. The job mainly consists of changing parameters, installing patches, troubleshooting what vendor product is hosing up the system, and accepting blame from the user community when the system is unavailable for 5 minutes.

  4. Written by UX-admin
    on March 2, 2013 at 3:02 pm
    Permalink

    I’m pretty sure the “professor” meant (and I question his insight for such a statement) that there is nothing more to innovate or do in the operating systems arena, with which I disagree vehemently.

    In the times where everyone and their brother wants to be writing “cool” high-level applications in Rubies, Pythons, JavaScripts and C#’s of the “Web 2.0″ world, who is going to be writing the low-level system software which interfaces with the hardware? Who is going to fix it, patch it, maintain it? Who is going to architect it, add support for new hardware, if everyone is “high up” in the stack writing web applications, and the art of debugging and writing good old operating system code and drivers in C is lost?

    The entire argument of “systems programming is dead” is ridiculously short sighted. I would like to see what the “professor” would do with “Web 2.0″ programming to fix a bug in a device driver, or how he/she would write a new low-level device driver, for example adding support for a new processor, as a “Web 2.0″ application! Such statements are absolutely ridiculous, and it is alarming that they are coming from the academic corner.

  5. Written by Ali Bahrami
    on March 6, 2013 at 8:52 pm
    Permalink

    At a guess, that professor was channeling Rob Pike’s
    “Systems Software Research is Irrelevant”:

    http://doc.cat-v.org/bell_labs/utah2000/
    or
    http://www.cs.bell-labs.com/cm/cs/who/rob/utah2000.ps

    Clearly he was talking about a fairly specific form of pure research.

Subscribe to comments via RSS