A paper operating system

Operating Systems are decidedly non-trivial animals (and never have been):

  • I'm writing this, while my radio plays and my chat window is listening. The existence of several simultaneous, or parallel activities, like overlapping I/O operations, and the co-existence in memory of several programs (applications), raises problems of switching from one activity to another, of protecting one activity from another, and of synchronising events which are mutually dependent.
  • For some concurrent activities, for reducing cost, being able to build on the work of others (not having to re-invent the wheel all the time), and for redundancy considerations (producing less waste), sharing resources is a desirable trait.
  • Internal or external storage (if the device is connected) gives us the convenience of being able to share data, but we also want our privacy, and not share everything with everybody.
  • An Operating System is to be determinate and predictable, at least to the extend that if we run a program with the same data as we did yesterday, that it produces the same result today. And, our systems also have to be able to respond to events like run-time errors and interrupts, which will happen. And shit happens in an unpredictable order. The system must be prepared to be surprised.

Furthermore, grounded in best practices so far:

  • Humans are more important (and their time more expensive) than machine resources, so in some cases we will want to accept a less efficient aspect of a system, if it provides a facility which serves humans.
  • Not any system will ever be free of errors and able to handle all contingencies. We can easily forgive a crash, as long as we know the system keeps learning.
  • Maintaining and improving it must be possible. Dividing it into well documented modules with clearly defined interfaces between the modules, which are fitted together in layers is a sound approach. When each layer provides a set of functions dependent only on the layers below it, the lowest layers are those which are the most critical in terms of power, performance and reliability.
  • The larger the system, the more error prone it will be, and a waste of (paper) space. Where possible, reduce the amount of critical code, make modules (more or less) equal, and use messages between modules in a client-server model.

  • Last modified: 2018/07/29 18:04