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