I think it would be a unfortunate for people to start redefining what "Systems Programming" means because it is vague enough now as it is - and we don't have the luxury of being able to go back and update the term in the historic literature.<p>My understanding is that, in effect, "Systems Programming" is analogous to "Operating Systems Programming", or rather you might say (given the increasing size of operating systems these days) that "Systems Programming" is a subset of "Operating Systems Programming" that deals with the direct manipulation of memory in order to provide a useful abstraction for "user" software - remembering that most hardware interaction is via memory. Obviously, in order to do "Systems Programming" you need a "Systems Programming Language" that allows such direct access to memory.<p>These days, "Systems Programmers" would be those working on the Linux kernel, or microkernels, or graphics drivers (basically those who have complete access to memory) though those developing services one layer up might also consider themselves to be such (especially micro-kernal-based operating systems).<p>It is probably worth emphasising that "System" is a generic term that is used in a lot of different contexts. I think "Systems Programming" is used in the context of a "Computer System", while modern day cloud programming would be better described as "Distributed Systems Programming" as it is in the context of a "Distributed System" (though I've probably just annoyed a whole bunch of distributed systems researchers).<p>I think that what the author of the article is talking about is "System Architecture" (or perhaps "Distributed Systems Architecture").<p>Should we talk about this as programming at all?