The Computer, for Creators
Under construction.

This is a “book/guide/set of blog posts” on computers I’m writing. I see so many related concepts that I want to tie them together. It’s very rough, but I like to do this kind of work in the open.

So much is built on the computer. This computer is built by layering complexity at different levels of abstraction. Yet many layers reuse the same designs; the same logical underpinnings. The underlying principles are the same.

Take the question of scheduling; determining what goes before another. The CPU, the database, and your own program must encounter this dilemma. How many more such questions are there, waiting to be discovered? Well, we will start from the user level and proceed down the stack until we finally look at the individual gates that power the chips, that power the computer!

This is a complete program for understanding the computer. It is a sequential book—a long conversation—the best way to relate so many things together. It is written to connect theory to practicing knowledge, for creators like me. For more and detailed perspectives, I recommend many good books in addition. The road to understanding such a complex, intermeshing set of systems is long. Yet we should want a full perspective, if only we are curious.

Each section shall have its own history overview.

Table of Contents

  1. Conventions of this book. We will only use certain words. The meaning of this chapter is to relate those words to wider usages in industry. However, using one word unlocks us from the domain dependence used, as we realize that the topics are the same.
  2. History of the computer
    1. Control theory
  3. Construction of the classic computer
  4. The ways of specification
  5. Scheduling.
  6. Version and change control
  7. Low-level optimizations: SIMD, computer architecture.
  8. Parallel computations
  9. Filesystems.
  10. System measures: performance and reliability
  11. The design of algorithms https://samwho.dev/big-o/

  12. Communication via protocols

    The images arrive already complete; there is no communication between them and myself, no reciprocal exchange. As much as we like to say that the world is opening up to us, since we can see every part of it, we can also say that the world is closing itself off – in all its openness. ---Karl Ove Knausgård

    https://datatracker.ietf.org/doc/html/rfc7493

  13. The user interface
    1. The shell
  14. Classical construction: POSIX and the Open Base Spec.
  15. Collision detection and optimization https://cairno.substack.com/p/psa-collision-detection-is-an-optimization
  16. Kafka and the log data structure.

  17. Appendix A: on the reasons and motivations to keep things going. (Or, why things are designed as they are) Who will support this new application? How will we keep it updated? How will we secure it? When the APIs we interact with change, is this application well enough documented that someone else can fix the problem or do we need to take you off a project to fix it?

    Part of my job is to help identify these issues early and turn them into infrastructure so that they can concentrate on the business problem and solutions to them – rather than these concerns. Instead of frustrated developers working out non-functional requirements, it’s better when we turn them into things they can take for granted. https://www.morelightmorelight.com/2024/02/18/zero-to-one-to-crumbling/

  18. Appendix B: How to go about creating a system Flyvbjerg, How Big Things Get Done. How Infrastructure works, Chachra. Seeing as a state. https://blog.jim-nielsen.com/2024/zero-to-unmaintainable/
  19. Appendix C: Calculus methods
  20. Appendix D: Statistical methods Accounting for randomness. Probability distributions. Moment generation function.
  21. Appendix E: queueing theory
  22. Appendix F: electrical design Reading list: Fundamentals of Electric Circuits, Sedra/Smith Microelectronics Sedra/Smith, Razavi Electronics lectures

The filesystem

Case study: ZFS

Queueing theory

https://blog.danslimmon.com/ Little’s law. Kendall’s queueing theory

Erlang’s analysis The concepts and mathematics introduced by Agner Krarup Erlang have broad applicability beyond telephony. They apply wherever users arrive more or less at random to receive exclusive service from any one of a group of service-providing elements without prior reservation, for example, where the service-providing elements are ticket-sales windows, toilets on an airplane, or motel rooms. (Erlang’s models do not apply where the service-providing elements are shared between several concurrent users or different amounts of service are consumed by different users, for instance, on circuits carrying data traffic.)

Little’s law & Erlang’s offered traffic offered traffic (queue size, etc in erlangs) = call arrival rate (lambda) * average call holding time (wait time, h).

Erlang-B formula: blocking probability (probability of call losses for a group of identical parallel resources) (M/M/c/c/ queue) An unsuccessful call is not queued or retried, but really vanishes forever. Poisson distribution. https://blog.danslimmon.com/2025/06/25/lecture-queueing-theory-on-a-cocktail-napkin/

Your interface to the computer.

What do you see?

Logical versus implementation data structures

Over the years data structures have been designed with different needs.

First, a need is identified and an ad-hoc solution made.

They allow the user to more easily retrieve elements, in the form of a set of requirements. This is an interface.

Based off of these requirements, a better set of underlying implementations is created.

The evolution of computing structures.

https://en.wikipedia.org/wiki/No_free_lunch_in_search_and_optimization