Speaker 1: Welcome back to the deep dive. You know, I was
Speaker 1: looking at the stack of notes for today we are
Speaker 1: tackling William Stallings's massive text Operating Systems, internals and design principles,
Speaker 1: and it really hit me. We spend all this money
Speaker 1: on faster processors, better ram but the thing that actually
Speaker 1: decides if we have a good experience is this invisible
Speaker 1: layer we almost never talk about.
Speaker 2: It's the ghost in the machine, literally.
Speaker 1: And Stallings makes this comparison right out of the gate
Speaker 1: that to stop me. He doesn't compare the operating system
Speaker 1: to a brain or you know, an engine. He compares
Speaker 1: it to a.
Speaker 2: Government, which, depending on your political views, might make you
Speaker 2: a little nervous about turning on your laptop.
Speaker 1: It definitely gives you pause. But when you dig into
Speaker 1: the book the analogy it fits surprisingly well. The OS
Speaker 1: doesn't actually produce anything, does it.
Speaker 2: No, it doesn't write your email or edit your photo.
Speaker 2: It just it creates the environment where those things can happen.
Speaker 2: That's the core function. It paves the roads, polices the intersectctions,
Speaker 2: and it collects taxes in the form of memory and
Speaker 2: processing power.
Speaker 1: And like a government, it's constantly fighting this sort of
Speaker 1: three way war with itself. Stallings lays these out really clearly. Convenience, efficiency,
Speaker 1: and the ability to evolve, and.
Speaker 2: Those three things do not naturally go together.
Speaker 1: Not at all. In fact, they seem like they would
Speaker 1: actively sabotage each other.
Speaker 2: They absolutely do. I mean, think about convenience. That's you,
Speaker 2: the user. You want a beautiful desktop, you want transparent windows,
Speaker 2: plug and plate devices. You do not want to see
Speaker 2: the wiring.
Speaker 1: I definitely do not want to see the wiring. I
Speaker 1: just want to click the button and have it work.
Speaker 2: But hiding the wiring is expensive. Yeah, that eats up
Speaker 2: system resources, which fights against objective number two efficiency. The
Speaker 2: hardware just wants to run raw code as fast as possible,
Speaker 2: not paint pretty pictures for you. Every cycle spent drawing
Speaker 2: a drop shadow on a window is a cycle not
Speaker 2: spent calculating a spreadsheet.
Speaker 1: So the OS is basically stuck in the middle trying
Speaker 1: to make me happy without making the CPU quit in frustration, while.
Speaker 2: Also handling objective three evolution. It has to be built
Speaker 2: in a way that allows it to change completely next
Speaker 2: year without breaking all the software you bought five years ago.
Speaker 2: It's a juggling act.
Speaker 1: An unbelievable juggling.
Speaker 2: App billions of times a second.
Speaker 1: So let's get into the mechanics of this. Stallings breaks
Speaker 1: it down to the instruction cycle. Fetch, execute, fetch execute.
Speaker 1: It sounds so simple.
Speaker 2: It is. It's the heartbeat of the machine. But there's
Speaker 2: a massive physiological problem with this computer body. Okay, the brain,
Speaker 2: the CPU is moving at the speed of light, but
Speaker 2: the hands and feet, the input output devices like your
Speaker 2: hard drive or your Wi Fi card are moving through molasses.
Speaker 1: Stalling's had a stat on this that just blew my mind.
Speaker 1: The speed difference isn't a little bit, it's orders of magnitude.
Speaker 2: It's astronomical. If the CPU's a Ferrari driving it at
Speaker 2: two hundred miles an hour, the hard drive is a tractor. No,
Speaker 2: that gives a hard drive too much credit.
Speaker 1: It's a snail.
Speaker 2: It's a snail exactly.
Speaker 1: So you didn't have a smart operating system and you
Speaker 1: told the computer to save file that Ferrari effectively has
Speaker 1: to slam on the brakes and just idle for what
Speaker 1: feels like one hundred years while the snail writes the data.
Speaker 2: That's the polling method. CPU just sits there, asking the
Speaker 2: drive Are you done yet? Are you done yet? Are
Speaker 2: you done yet?
Speaker 1: What a waste.
Speaker 2: It's a massive waste, a billion dollar hardware. You have
Speaker 2: the world's smartest mathematician sitting there waiting for a printer
Speaker 2: to warm up.
Speaker 1: So they invented interrupts. And I love this term because
Speaker 1: it sounds rude, but it's actually the most polite thing
Speaker 1: the hardware can do.
Speaker 2: It's save computing with interrupts. The Ferrari sends the save
Speaker 2: command to the snail and then immediately peels out and
Speaker 2: goes to do something else.
Speaker 1: Okay, so it goes off and runs a spreadsheet, plays music, whatever.
Speaker 1: But wait, how does it know when the snail is done?
Speaker 2: The snail has a direct line to the CPU. When
Speaker 2: it's finished, it sends an electrical signal and interrupt. It
Speaker 2: forces the CPU to pause whatever it's doing to acknowledge
Speaker 2: that the task is complete.
Speaker 1: See that's the part that stresses me out. If I'm
Speaker 1: in the middle of a complex math problem and you
Speaker 1: interrupt me, I lose my place. I have to start over.
Speaker 2: And that is the magic trick. Yeah, the OS performs
Speaker 2: a context switch. Okay, imagine you're reading a really dense
Speaker 2: novel and the doorbell rings, You don't just throw the
Speaker 2: book on the floor, right, you put a bookmark in.
Speaker 2: You write down exactly which line you were on, maybe
Speaker 2: even the thought you were having in that split second.
Speaker 1: So that's the state of the process.
Speaker 2: Correct, the program counter, the register values. Everything gets pushed
Speaker 2: onto a control stack. It's a snapshot of reality frozen
Speaker 2: in time. Wow, you go answer the door, handle the
Speaker 2: big job, and when you come back, you pop that
Speaker 2: snapshot back off the stack. The software doesn't even know
Speaker 2: it was passed, so.
Speaker 1: To me, it looks like everything happened at once exactly.
Speaker 2: It completely decouples the user's perception of time from the
Speaker 2: computer's reality.
Speaker 1: But what happens if the doorbell rings while I'm already
Speaker 1: on the phone?
Speaker 2: Ah, the nightmare scenario multiple.
Speaker 1: Interrupts, is the system just crash?
Speaker 2: Depends on how it's designed. You can disable interrupts basically
Speaker 2: take the phone off the hook while you answer the door,
Speaker 2: or you can have nested interrupts.
Speaker 1: Which implies a hierarchy. Some things are more important.
Speaker 2: Precisely, if your network card says incoming data that's urgent.
Speaker 2: If your printer says I'm out of paper, that can
Speaker 2: wait The OS prioritizes the urgent interrupt handles it then
Speaker 2: goes back to the less urgent one, and finally back
Speaker 2: to your program.
Speaker 1: And all of this happens so fast that I just
Speaker 1: see a smooth mouse cursor.
Speaker 2: Well underneath, it's just controlled chaos.
Speaker 1: So we have the CPU maximizing its time with interrupts.
Speaker 1: But there's another bottleneck, right memory. We all want terabytes
Speaker 1: of storage that's instantly accessible. But Stallings points out the
Speaker 1: iron triangle of memory capacity, speed, and cost.
Speaker 2: And you can pick two because you cannot have all three.
Speaker 2: Fast memory like the registers right inside the CPU, is
Speaker 2: incredibly expensive and tiny. Big memory like your hard drive
Speaker 2: is cheap but slow.
Speaker 1: So the OS has to lie to us again. It
Speaker 1: has to create the illusion that we have unlimited, super
Speaker 1: fast memory.
Speaker 2: And it does that through the memory hierarchy. It's a pyramid.
Speaker 2: Data is constantly moving up and down. But the secret sauce,
Speaker 2: the thing that makes the lie convincing is this concept
Speaker 2: of locality of reference.
Speaker 1: This is essentially the OS gambling right. It's betting on
Speaker 1: what I'm going to do next.
Speaker 2: It's a rigorous statistical gamble. They are two types. First,
Speaker 2: temporal locality Okay, if you looked at a photo five
Speaker 2: seconds ago, the odds are really high you'll look at
Speaker 2: it again in the next five seconds. Think about a
Speaker 2: loop and a piece of code.
Speaker 1: It's the same instructions over and over, so you keep
Speaker 1: that data close exactly.
Speaker 2: And then there's spatial locality. If you're reading a document
Speaker 2: at line ten, there is a ninety nine percent chance
Speaker 2: you're going to need line eleven next.
Speaker 1: You almost never jump from line ten to line five thousand.
Speaker 2: Right, So the OSCs you're reading line ten and quietly
Speaker 2: in the background, it runs down to the slow warehouse,
Speaker 2: grabs lines eleven through twenty and puts them on the
Speaker 2: fast on the top, right next to the CPU that's cashing.
Speaker 2: That's cashing, and it works surprisingly well. A well toned
Speaker 2: o S can get a hit on that cash maybe
Speaker 2: ninety percent of the.
Speaker 1: Time, which explains why when I open a huge app
Speaker 1: for the very first time, it sometimes chugs for a second.
Speaker 2: That's a miss, right. The chef reached for the salt,
Speaker 2: but it wasn't on the counter. He had to run
Speaker 2: to the pantry. But once he brings it out, it
Speaker 2: stays on the counter. It stays on the counter. The
Speaker 2: next time you click. It's instant.
Speaker 1: It's fascinating to think about this because it means my
Speaker 1: computer is constantly trying to predict the future based on
Speaker 1: the immediate past.
Speaker 2: And when a guess is right, you feel like you
Speaker 2: have a supercomputer. When a guess is wrong, you get
Speaker 2: the spinning wheel of death.
Speaker 1: It's so easy to take this for granted. Now we
Speaker 1: have casing, we have interrupts. Everything feels instant. But Stallings
Speaker 1: takes us back to the nineteen forties and fifties to
Speaker 1: show us the dark Ages.
Speaker 2: It really was the dark Ages. No operating system, no mouse,
Speaker 2: no screen. It's a clipboard, a literal clipboard outside the
Speaker 2: computer room. You signed up for a thirty minute block.
Speaker 2: You walked in with your deck of punch cards. You
Speaker 2: loaded them into the machine, and you prayed.
Speaker 1: And if you had a typo, a light.
Speaker 2: Flashed, the machine stopped, and your thirty minutes were up.
Speaker 2: You had to go back to your desk and debug
Speaker 2: by just staring at holes in paper.
Speaker 1: The inefficiency is painful to even think about. While you
Speaker 1: were walking around loading cards, checking the lights, this million
Speaker 1: dollar machine was just sitting.
Speaker 2: There burning electricity, doing nothing. That idle time is what
Speaker 2: drove the invention of the OS. It wasn't about user comfort,
Speaker 2: it was about money. They needed batch processing to keep
Speaker 2: the machine.
Speaker 1: Fed, and this is where we see the first monitor programs.
Speaker 2: Yes, you'd hand your cards to an operator. The operator
Speaker 2: fed them to the machine one after another. The monitor
Speaker 2: was a simple program that just said Okay, job one
Speaker 2: is done, load job two.
Speaker 1: But even then, if a job had to wait for
Speaker 1: a tape to rewind, the CPU starped again.
Speaker 2: Which led to the biggest leap inefficiency multi programming, the
Speaker 2: idea that you could hold multiple job and memory at once.
Speaker 1: So if job A waits for a.
Speaker 2: Tape, the OS switches to Joe B.
Speaker 1: Stallings mentions that uniprogramming had something like what three percent
Speaker 1: CPU utilization? Multiprogramming just blew that away.
Speaker 2: It changed the economics of computing, but it was still impersonal.
Speaker 2: You submitted a job and came back hours later for
Speaker 2: the print.
Speaker 1: Out, which brings us to the moment the computer became
Speaker 1: personal time sharing.
Speaker 2: This is the MIT system CTSS. Before this, the goal
Speaker 2: was always maximized the CPU. With time sharing, the goal
Speaker 2: shifted to maximize the user.
Speaker 1: And this is where we get the concept of time
Speaker 1: slicing right.
Speaker 2: Yes. Imagine a chess master playing fifty games at once.
Speaker 2: He walks to board one, makes a move, walks to
Speaker 2: board two, makes a.
Speaker 1: Move, and if he moves fast enough.
Speaker 2: Every player feels like they have his full attention.
Speaker 1: So the OS is the chess master. It runs my
Speaker 1: browser for a fraction of a second, then switches to
Speaker 1: your music player, then the system clock and back to
Speaker 1: my browser.
Speaker 2: Every point two seconds in those early systems. Now it's
Speaker 2: much much faster. It creates the illusion of concurrency.
Speaker 1: You think you're multitasking, but the computer is actually just
Speaker 1: panic switching.
Speaker 2: Panic switching between tasks fast enough to fool your eyes.
Speaker 1: This required a huge leap in software architecture, though Stallings
Speaker 1: really emphasizes the concept of the process.
Speaker 2: It sounds abstract, but it's so vital. A program is
Speaker 2: just a static set of instructions on a disc. It's dead.
Speaker 2: A process is that program in execution. It's alive.
Speaker 1: It has baggage, it has.
Speaker 2: Context, it has ownership of memory, it has security clearance,
Speaker 2: it has a priority level. By treating running programs as processes,
Speaker 2: the OS could finally manage them safely.
Speaker 1: It could isolate them.
Speaker 2: Isolate them, so if one process crashes, it doesn't necessarily
Speaker 2: kill the others.
Speaker 1: And this ties into virtual memory too, because if you
Speaker 1: have fifty processes running, they can't all fit in the
Speaker 1: physical RAM.
Speaker 2: Virtual memory is the ultimate illusion. The OS breaks a
Speaker 2: process into these fixed sized blocks called pages. It can
Speaker 2: scatter them those pages anywhere, some in RAM, some on
Speaker 2: the desk.
Speaker 1: With the program thinks it's all in one continuous piece.
Speaker 2: The program sees a continuous, beautiful block of memory. It
Speaker 2: uses virtual addresses. The hardware, specifically, the memory management unit
Speaker 2: translates those virtual desks into physical addresses.
Speaker 1: On the fly, so a developer can write a program
Speaker 1: that uses four gigabytes of RAM even if the machine
Speaker 1: only has two gigabytes free. It's basically gas lighting the software.
Speaker 1: Oh yeah, you totally have all the space while frantically
Speaker 1: shuffling data in and out of the back door.
Speaker 2: Gas Lighting is a harsh word for it, but technically accurate.
Speaker 2: It's abstraction. You abstract the harsh reality of the hardware
Speaker 2: to create a better reality for the software.
Speaker 1: Speaking of harsh reality, let's talk about the hardware we
Speaker 1: use today. We aren't just using single processors anymore.
Speaker 2: We have SMP and multi core Symmetric multiprocessing. SMP was
Speaker 2: the first step. You plug two or four separate CPUs
Speaker 2: into one motherboard.
Speaker 1: They share everything, they.
Speaker 2: Share memory IO. The US has to schedule tasks across
Speaker 2: all of them.
Speaker 1: Which is great for real life liability. If one burns out,
Speaker 1: the other keeps going.
Speaker 2: But multi core is where we are now putting multiple
Speaker 2: brains on a single chip. It's faster, more efficient, but
Speaker 2: it creates a huge headache for the OS designer called
Speaker 2: cash coherence.
Speaker 1: Because each core has its own little cash right, its
Speaker 1: own little countertop of ingredients exactly.
Speaker 2: So Core A changes the value, you say, updates your
Speaker 2: bank balance in its private cache, but COREB tries to
Speaker 2: read that balance from its own cash.
Speaker 1: COREB has old information. You have a synchronization nightmare.
Speaker 2: So the OS and the hardware have to constantly gossip
Speaker 2: with each other. Hey, I changed this value, invalidate your copy.
Speaker 2: It has a lot of complexity.
Speaker 1: It's fascinating that all these tricks interrupts caching, time slicing.
Speaker 1: They're universal, but how they're packaged differs. Stallings compares the
Speaker 1: big three Windows, Linux, and Android, and they have very
Speaker 1: different personalities.
Speaker 2: They do take Windows. Windows is the ultimate corporate manager.
Speaker 2: It's highly modular. It has this thing called the HL,
Speaker 2: the Hardware abstraction.
Speaker 1: Layer, which sounds like the villain from two thousand and
Speaker 1: one A Space Odyssey.
Speaker 2: Fortunately it's helpful. The HAL is a translator. It means
Speaker 2: the core of Windows does need to know if you're
Speaker 2: running an Intel chip or an AMD chip, or what
Speaker 2: motherboard you have. AHL handles the specifics.
Speaker 1: It isolates the kernel.
Speaker 2: From the messiness of the real world. This is why
Speaker 2: you can build a PC out of random parts and
Speaker 2: Windows generally just boots up.
Speaker 1: It prioritizes compatibility, compatibility, and portability.
Speaker 2: It uses a client server model. Even internally, different parts
Speaker 2: of Windows talk to each other by sending messages, almost
Speaker 2: like they're on a network.
Speaker 1: Now contrast that with Linux. Stallings calls it monolithic. That
Speaker 1: sounds heavy.
Speaker 2: It is, but in a good way. In Linux, the
Speaker 2: kernel is one giant, highly optimized brain. All the drivers,
Speaker 2: the file systems, the memory management, it's all living in
Speaker 2: the same address space.
Speaker 1: Isn't that dangerous If the audio driver crashes, doesn't it
Speaker 1: take down the whole brain?
Speaker 2: Historically, yes, that was the big criticism, but Linux got clever.
Speaker 2: They added loadable.
Speaker 1: Modules like Lego bricks sort of.
Speaker 2: It means you can plug in a new device driver
Speaker 2: or a file system while the kernel is running. You
Speaker 2: don't have to shut down and rebuild the whole LOS
Speaker 2: just to add support for a new webcam.
Speaker 1: So you get the raw speed of a monolithic kernel with.
Speaker 2: The flexibility of a modular one. It's the Borg approach,
Speaker 2: adapt and assimilate without stopping.
Speaker 1: And then Android is basically Linux putting on a hiking backpack.
Speaker 2: It is Linux optimizing for survival power management on a server.
Speaker 2: Linux assumes it has a wall socket. It runs tasks
Speaker 2: whenever it wants. On a phone, Android has to be ruthless.
Speaker 2: It uses wayclocks to prevent apps from keeping the CPU awake.
Speaker 1: It kills background processes.
Speaker 2: Aggressively because the dead battery makes the smartest OS completely useless.
Speaker 1: True.
Speaker 2: Android also uses a unique software stack for apps. It
Speaker 2: doesn't run standard Linux programs. It runs apps inside a virtual.
Speaker 1: Machine, which creates a sandbox.
Speaker 2: Right, so if an angry bird crashes, it doesn't crash
Speaker 2: your phone dialer.
Speaker 1: It really highlights that the OS is the unsung hero.
Speaker 1: We've talked about efficiency, convenience, evolution, but stallings leaves us
Speaker 1: with one final, slightly terrifying concept, fault tolerance.
Speaker 2: It's the realization that hardware will fail, not might will.
Speaker 1: It's the law of large numbers. If you have billions
Speaker 1: of transistors, one of them is going to flake out.
Speaker 2: Eventually, a cosmic ray is going to hit your hard drive.
Speaker 2: So the OS has to be paranoid. It relies on redundancy.
Speaker 1: Redundancy in what sense.
Speaker 2: Three senses actually spatial redundancy, having backup hardware like raid discs.
Speaker 2: If one fails, the other takes over. Temporal redundancy. If
Speaker 2: a calculation looks weird or fails, run it.
Speaker 1: Again, just turn it off and on again at the
Speaker 1: microchip level basically.
Speaker 2: And information redundancy using air correcting codes to check if
Speaker 2: a one accidentally flipped to a zero.
Speaker 1: So the OS isn't just a manager. It is a
Speaker 1: disaster prevention team.
Speaker 2: Ideally, yes, it's managing a constant state of low level crisis.
Speaker 2: It's masking the chaos of the physical world so that
Speaker 2: you can exist in the pristine world of software. If
Speaker 2: the OS does its job right, you never know how
Speaker 2: close he came to a crash.
Speaker 1: Well, on that comforting note. Next time your phone buzzes
Speaker 1: with a notification, just remember that's an interrupt signal, saving
Speaker 1: you from staring at a frozen screen. And that smooth scrolling,
Speaker 1: that's a gamble that paid off. Thanks for listening to
Speaker 1: the deep dive.
Speaker 2: We'll catch on the next one.