Personal collections

All interesting systems are comprised of a few general ideas and a number of details. Sometimes, when you are learning about these systems, you think to yourself “Oh, I get the general idea; the rest is just details,” and you use this to only half-learn how things really work. Don’t do this! Many times, the details are critical. As we’ll see with LFS, the general idea is easy to understand, but to really build a working system, you have to think through all of the tricky cases.

Operating Systems: Three Easy Pieces, by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau

Design Philosophy
Pick always the simplest and easiest solution.
When in doubt, always use brute force, and when not in doubt, use brute force too.
Nothing should be ‘designed’, everything should grow organically, sit down and hack.

Go-FuckYourSelf, a toy OS kernel

Benchmark sub-setting without strong justification
I am particularly allergic to formulations like “we picked a representative subset” or “typical results are shown”. There is no such thing as a “representative” subset of SPEC, and the ”typical” results are most likely cherry-picked to look most favourable. Expect no mercy for such a crime!

Systems Benchmarking Crimes, by Gernot Heiser

All non-trivial abstractions, to some degree, are leaky.
One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to.

The Law of Leaky Abstractions, by Joel Spolsky

An operating system is similar to a government. Like a government, it performs no useful function by itself.

Operating System Concepts, by Abraham Silberschatz et al.

What we see depends mainly on what we look for.

John Lubbock