the abstraction stack
A computer is built as a tower of layers, each one hiding the messy details of the one below and offering a cleaner set of services to the one above. This tower is the abstraction stack. Like floors in a building, each layer trusts the floor beneath to hold it up without needing to know how the concrete was poured.
From the bottom up, a typical stack looks like this: the hardware (CPU, memory, devices); the operating system kernel that shares that hardware safely among programs; system libraries (like the C standard library) that wrap raw kernel services in friendlier functions; then applications - the programs people actually use. Each layer offers an interface to the one above and hides its own internals. 'Open a file' at the top might become a library call, which becomes a system call into the kernel, which becomes commands to a disk controller, which becomes magnetism on a platter - and the app never sees any of it.
Why it matters: abstraction is what makes large systems buildable at all, because nobody has to understand everything at once. But abstractions 'leak' - when something breaks or runs slow, the lower layers poke through and you must reason across them. Systems programming is largely the craft of working below where most people stop, building and fixing the lower floors. Knowing the stack tells you where a bug could live, who is responsible for a behavior, and which layer to inspect when an abstraction fails.
Typing a letter into a web app touches every floor: the keypress is hardware; the OS delivers it; a runtime and libraries turn it into an event; the app shows the letter. When the app freezes, finding out why may mean climbing down through those same floors.
Hardware → kernel → libraries → application: each layer hides the one below.
Abstractions are useful fictions, not perfect walls - this is the 'law of leaky abstractions'. Performance, errors, and security routinely leak across layers, which is exactly why understanding the floors below your own pays off.