2024-07-19-Why Do We Need Operating Systems?
Operating systems are generally thought, by software developers, to be necessary.
What do operating systems accomplish?
Engine for running code written in the function-based paradigm.
Library of pre-fabricated subroutines that could be used in any app.
1. Engine for running code written in the function-based paradigm.
CPUs do not inherently support function-based programming.
CPUs are simple sequential sequencer chips that interpret bytes - called opcodes - in memory and perform actions based on those bytes.
CPUs have only a few slots of really fast memory. We usually call these registers.
CPUs access other kinds of memory, usually called RAM and ROM.
Sometimes these kinds of memory come in various cost configurations and are called caches. Cache memory is usually cheaper, more abundant, and slower than the other kinds of memory. Programmers decide which kinds of memory to use, on a per-project basis.
At more expense in terms of chip real-estate, we add levels of indirection using Memory Management Units (MMUs). All memory accesses are indirected through MMUs to translate fake addresses into real, in-memory addresses. Software refers to memory using fake addresses. MMUs map the fake addresses into real addresses. Sometimes, fake addresses refer to blocks of memory that can only be found on super-cheap memory, like disks. When a fake address refers to such swapped-out memory blocks, the MMU creates a hardware signal that wakes up some software that swaps the memory back into real memory, while freeing up real memory by swapping out some other block of memory. The swapping software decides which block(s) to swap out using several heuristics. All of this swapping takes up time and CPU cycles and memory in “system space” (which is typically not swapped out, itself).
All of these kinds of memory and MMU registers are shared and are not reentrant (aka “thread safe”). We fake out reentrancy to support function-based programming, by inserting extra software that swaps registers and memory management details. All of this swapping is called “context switching” and takes time and CPU cycles and code space.
Hence, there exists a large lump of software to support “context switching” which constitutes the engine for programming in the function-based paradigm.
2. Library of pre-fabricated subroutines that could be used in any app.
Ideally, an operating system operates like a library of subroutines that can be used by multiple applications.
In practice, though, the library provided by modern operating systems (Linux, Windows, MacOS) is function-based, thus, can only be used by programs written in the function-based paradigm, and, requires the use of the function-based engine.
This kind of library is a library of functions instead of being a library of subroutines. This kind of library is restricted and not very general.
Using this kind of library restricts programmers to writing programs only in the function-based paradigm and to always using the function-based engine.
Worse, yet, modern operating systems include the complete library in the runtime of production systems. Linux, Windows, MacOS, etc. ship with the complete library as lumps of code stored on slow memory (disk) which gets paged in as required by the virtual memory system using up extra CPU cycles.
Game Cartridges
In an ideal situation, the library should be a feature of the development system’s Integrated Development Environment (IDE). Developers should be allowed to mix and match needed features at development time, then to optimize their apps to run on simple hardware.
This kind of workflow was evident in the late 1900’s, with game cartridges. A game cartridge contained everything needed to run a specific game.
A game cartridge would “take over” the whole machine and used the machine’s features in ways that were efficient-enough for specific games.
The game console - a stripped-down “computer” - did not need to supply a bloated library at runtime and only supplied the bare minimum hardware needed to run games.
The fact that game cartridges were physical devices added to the pressure to cost-optimize and reduce the footprint of game software.
Conclusion
Modern operating systems inflict a single paradigm on the act of programming.
Hardware does not inherently support that paradigm, thus, extra software must be used to fake out that paradigm.
This approach worked sufficiently well in the 1900’s, but is now showing signs of strain.
What’s Wrong With This Picture?
Most non-programmers think that “programming is difficult, ivory-tower sorcery”. Even when non-programmers program computers, e.g. by using spreadsheets, they refuse to call it “programming”.
Most programmers think that asynchronousity, called concurrency, multitasking and threading, is hard. So-called “hard realtime” is considered to be even harder, still. Yet, 5 year-olds all over the world learn to cope with hard-realtime through piano lessons using written music and metronomes. Furthermore, non-programmers - children and adults - deal with asynchronousity on a daily basis and have developed protocols for handling asynchronous behaviour, e.g. calling meetings, shaking hands, etc.
Yesterday’s computer problems mostly consisted of computation - using hardware to build fancier and fancier calculators. Typical uses for computers consisted of moon-shot calculators and military missile ballistics calculators.
Today, though, the interesting problems are mostly asynchronous and distributed. For example internet, robotics, gaming, blockchain, GUIs, etc., etc.
We need a new workflow which uses new notations for programming and allows programmers to mix-and-match notations, using many notations to solve any one specific problem. The religious belief that we need “operating systems” detracts from our abilities to invent new workflows.
See Also
References: https://guitarvydas.github.io/2024/01/06/References.html
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/Jjx62ypR
Leanpub: https://leanpub.com/u/paul-tarvydas
Gumroad:
https://tarvydas.gumroad.com
Twitter: @paul_tarvydas