Comment by zaarn
7 years ago
I think systems programming should be split in two, honestly.
You have the kernel-level systems programming where you need to be near the bare metal, where you write kernels or program microcontrollers with less RAM than a x86 CPU has L1 cache, where taking a microsecond longer can mean the overall system crashing (or even costing a human life).
And you have system-level systems programming where you write services and supportive infrastructure to enable user programs, where garbage collection and non-realtime behaviour is acceptable, where you can skip a microsecond and it'll be alright.
I think the two "poles" you've identified are good ones (~microseconds matter and ~100ms matters) but there's a wide range in between. If you do anything with video at modern resolutions, then you're in the single-millisecond-matters regime (this includes games as mentioned upthread, and just about anything in VR as well).
Video streaming and gaming have some soft realtime guarantees, yeah, though generally these aren't systems programming and application programming instead.
The plumbing below, ie graphics rendering pipeline, tend to fall into the category of kernel systems programming, controlling the GPU is pretty close to doing what a kernel does IMO.
It seems a bit telling that you described one as "kernel" systems programming and the other as "system" systems programming.
Well, I think the distinction is fair, kernel systems programming is largely concerned with things a kernel would normally do (ie, a kernel or µC code), very close to the metal or such. Maybe bare metal systems programming would have been more accurate but I feel it doesn't convey the same meaning.
System systems programming is what it says on the tin; it's about constructing systems, multiple objects interacting with rules on the interaction, etc. An alternative name might be "user space systems programming" though again I think that doesn't convey the meaning as well.
I think that in user space, it is not clear what is an application and what is a subsystem. Is a database a system or an application? I could issue queries to it directly as part of some ad-hoc research, or I could build a production process using it as a component. In one use-case, it's the application, and in the other, it's just a subsystem. And so I think the distinction between kernel-space and user-space is the only one that makes sense. Once you're in user-space, the distinction between systems and applications can no longer be applied to a tool, but only to particular use-cases for that tool.
1 reply →
You can make a distinction between the kernel and the shell (shell = all the system tools between the kernel and the applications, cf. https://www.tutorialspoint.com/operating_system/images/linux... not only sh or bash), but this distinction remains an implementation detail, and you can change the position of this interface at will. From microkernels who handle only the messaging between processes, to OSes like Multic or Windows-NT that include even GUI operations in the kernel...
You cannot either count on the hardware protection to make the distinction. Some systems may use the hardware to protect objects at a different level of granularity. For example, capability based OSes will use a single address space, and use the hardware to protect not processes, but smaller objects (capabilities). Accesses and communications is not managed to prevent processes to access objects of other processes, but to prevent or allow access to capabilities. In a softer way, it's also the case of Lisp OS (including eg. GNU emacs). There's not much specific protection on these systems, but it still works safely, because you can access only the objects to which you have a reference, and you cannot compute random addresses (it's a controlled execution environment).