As a rudimentary computer user, the operating system can seem like something well out of reach. You use it, but what it does, how it is developed and all the intricacies of it seem like something that is far, far away. Closing that distance is eminently possible, and a great idea as well, as understanding an operating system can immensely help one’s understanding of much more.
Earlier in my career, as I began to understand Unix, one thing I understood quickly is that with Unix, you must understand a little about more your operating system than when using Windows. Back in those days, a graphical user interface existed, but then, as now, most Unix (and today, Linux) users tend to like or even prefer a terminal command line. The commands give some insight into the operating system and how it works, especially through using a shell and understanding how Unix-like operating systems are built with many tools that do one thing and do it well. Using commands means having a little more understanding than merely clicking or double-clicking on something.
In those days, I came to realize that as I understood Unix more (I did not come to work with Linux until several years into my professional career), I became a better user and developer on Windows. I came to understand at a very basic level some operating systems concepts that are independent of the particular system, and felt that knowledge carry over.
Later, I took a course on operating systems concepts, which helped solidify a lot. One thing that working at that level helps that becomes more important all the time is multithreaded programming. Early in my career, that was seemingly a novelty, even as Java built that support right into the language. Nowadays, you can’t really be a developer without understanding that subject, along with things like inter-process communication (IPC) and process synchronization that go with it.
A big reason why understanding operating systems concepts helps is because there is less room for error there. At the application level, a memory issue such as a memory leak can be small and not really get noticed. It is still a problem, to be sure, but there is unlikely to be a symptom at first, and depending on how long the application runs before the system is re-started again, there might never be one. At the operating system level, however, a failure has bigger implications; a bad memory access likely leaves you with little choice but to reset. Similarly, an application can have a deadlock; closing and re-starting the application is not ideal, but is not difficult to do. A deadlock at the operating system level, however, means a heavier penalty, as re-starting the system is a little bigger deal than re-starting an application.
Looking at embedded systems further drives home the importance of understanding operating systems concepts. The heart of software development on embedded systems is manipulating or managing hardware, which is what operating systems do. Device drivers are often right there with the operating system and usually use services or system calls for a lot of their work.
Such systems are also resource-constrained, which means memory management becomes more important in addition to shared resources. In a sense, this parallels the reality of an error at the application level vs. an error at the operating system level – a memory hog on an embedded system is unlikely to have the exact same damaging consequences on a PC, where memory is usually more plentiful. Such a memory hog is still undesirable and should be avoided by developers if possible, but is less noticeable when memory is more plentiful, as is usually the case with a PC.
As I have learned more about real-time operating systems, I have come to better understand the full spectrum of embedded systems software development. Many systems nowadays use an RTOS, and there are many of them available to choose from. Knowing how to use an RTOS goes a long way towards developing the best software for such systems, but more to the point, understanding an RTOS also helps one appreciate what happens on a PC, as well as what is happening with applications that use it. It is a great vehicle for learning the concepts of an operating system.
The demands of an operating system developer are, as you might imagine, a little more than those of an application developer given its place in systems. An operating system is at the center of the software, it operates close to the hardware and without the protections an application has – indeed, it forms some of the protections an application has against a catastrophic result. An application might crash, which is certainly undesirable, but the same error in an operating system likely has a bigger consequence. Understanding what goes into this thus helps someone who never develops at that same level just on that basis alone.
The operating system ties so much together in a computer system, whether it’s a desktop personal computer or a hand-held gadget. For that reason and more, one of the best things a software developer can do is understand what an operating system does on more than a basic level. So many things make more sense once the operating system is no longer a mystery that feels out of reach.