Speaker 1: You know, when you pick up a technical manual, you
Speaker 1: usually expect the dedication page to be standard boilerplate, like
Speaker 1: to my spouse or to my kids. It's sweet, but
Speaker 1: it's completely predictable.
Speaker 2: It's the one page of the text you generally just
Speaker 2: flip right past to get to the actual architecture diagrams
Speaker 2: right exactly.
Speaker 1: But today we are doing a deep dive into Ahmed
Speaker 1: al Khaberi's work. Learn Linux Quickly, and his dedication genuinely
Speaker 1: made me laugh out loud. He thanks his mom naturally,
Speaker 1: but then he drops this note to his dad. He says,
Speaker 1: I know you wanted me to go to medical school
Speaker 1: to be a doctor, just like you. Sorry, pops, computer
Speaker 1: science is the future.
Speaker 2: I mean, it is a very confident opening m but
Speaker 2: historically speaking, he really wasn't wrong to make that bet.
Speaker 1: He was completely right. And that is our mission for
Speaker 1: you today to decode the architecture of the world's most powerful,
Speaker 1: yet largely invisible operating system, Linux, because if your perception
Speaker 1: of Linux is still stuck on that old trope of
Speaker 1: a lone hacker in a dark room compiling source code,
Speaker 1: you're missing the macro scale of what this system actually is.
Speaker 2: Oh, absolutely. The scale is staggering when you actually look
Speaker 2: at the numbers.
Speaker 1: Right, we are talking about the engine powering over ninety
Speaker 1: percent of the world's supercomputers, seventy five percent of all
Speaker 1: cloud solutions, your Android phone, government servers, Lexus and Toyota
Speaker 1: smart cars, and I mean even some washing machines.
Speaker 2: Yeah, you are interacting with a Linux kernel dozens of
Speaker 2: times a day, even if a command line interface never
Speaker 2: once flashes across your screen.
Speaker 1: It's wild. Okay, let's unpack this before we start parsing
Speaker 1: command syntax and all that. We need to understand where
Speaker 1: it came from, because we need to know how it
Speaker 1: differs from the systems we're used to, like Windows or macOS.
Speaker 2: Well, the contrast with proprietary systems is stark, unlike Windlows
Speaker 2: or mac which were engineered by massively funded corporate teams
Speaker 2: under strict NDAs. Linux originated in nineteen ninety one as
Speaker 2: a mere hobby project. Wait, a hobby project, yeah, by
Speaker 2: Linus Torvoldz who just a computer science student in Fenmlas
Speaker 2: and at the time he built his own Unix like
Speaker 2: operating system and crucially it became the ultimate open source.
Speaker 1: Project, meaning the source code, like the actual underlying logic
Speaker 1: of the software is entirely public. Anyone can edit it.
Speaker 1: But let me push back on this for a second.
Speaker 2: Sure, go ahead. Wait.
Speaker 1: If it's free and literally anyone on the internet can
Speaker 1: edit it, how is it secure and stable enough to
Speaker 1: run massive corporate infrastructure for like Amazon or Google?
Speaker 2: That is a totally fair question. The open source model
Speaker 2: relies on the idea of thousands of developers constantly reviewing
Speaker 2: and patching the code. But to really understand how it
Speaker 2: maintains stability for an Amazon server farm, we have to
Speaker 2: break down the anatomy of the system. We have to
Speaker 2: separate the concept of the operating system from the kernel.
Speaker 1: Right, let's draw that line. Because people use those terms interchangeably,
Speaker 1: don't they all the time?
Speaker 2: But they are very different. The operating system is the
Speaker 2: complete package. It includes the graphical user interface, text editors,
Speaker 2: all the bundled apps. It manages the hardware and software overall,
Speaker 2: but the kernel. What's fascinating here is that the kernel
Speaker 2: is strictly the core.
Speaker 1: The absolute center of it all exactly.
Speaker 2: It's the part that organizes access to the CPU memory
Speaker 2: and disc doesn't care about your web browser. It just
Speaker 2: dictates resource allocation.
Speaker 1: Let me try to map this out with an analogy
Speaker 1: to see his tracks. So the operating system is a
Speaker 1: full restaurant. You have the tables, the menus, the waiters,
Speaker 1: the whole dining room. That's the environment we interact with.
Speaker 2: I like where this is.
Speaker 1: Going, But the kernel is the busy kitchen expediter. They
Speaker 1: aren't talking to the customers at all. They actually decide
Speaker 1: which chef gets which ingredients, which pan goes on which burner,
Speaker 1: and exactly when a dish gets plaited.
Speaker 2: That analogy holds up perfectly. And because this expeditor the
Speaker 2: Linux kernel is open source, developers quickly realized they didn't
Speaker 2: have to build just one type of restaurant around.
Speaker 1: It, right, They could build thousands of different types of
Speaker 1: dining rooms, all using that same amazing expeditor in the
Speaker 1: kitchen exactly.
Speaker 2: And that brings us to the concept of distributions or distros.
Speaker 2: Since the kernel is free, people package it with different
Speaker 2: apps and interfaces to create unique variations. Android is actually
Speaker 2: a Linux distro.
Speaker 1: Oh wow, I didn't even realize Android counted as a distro,
Speaker 1: And Alcaberi mentions one called scientific Linux.
Speaker 2: Right, yes, scientists use Scientific Linux specifically because it comes
Speaker 2: pre packed with specialized scientific apps and research tools.
Speaker 1: There are distros for everything, so if you're listening to
Speaker 1: this and want to try it out, replacing your Windows
Speaker 1: OS with a Linux distro sounds honestly terrifying for a beginner,
Speaker 1: but the book has a safe way to play around.
Speaker 2: Right, very safe. The book strongly suggests using a virtual
Speaker 2: machine or a VM. You definitely don't need to wipe
Speaker 2: your hard drive.
Speaker 1: Which is a relief. A VM is basically like the
Speaker 1: movie Inception for computers. It's a dream within a dream.
Speaker 2: Ah, that's exactly what it is.
Speaker 1: It's a computer running inside your host computer. It shares
Speaker 1: your physical resources, but acts as a completely standale, isolated machine.
Speaker 2: Right, so if you completely break the Linux system while learning,
Speaker 2: you just delete the VM and start over. Your actual
Speaker 2: computer is totally fine.
Speaker 1: The technical specifics in the book are great for this.
Speaker 1: You use a program called virtual box, grabbing a Buntu
Speaker 1: ISO image and set it up. Alceberry suggests giving it
Speaker 1: at least two gigabytes or ideally four gigabytes of RAM
Speaker 1: and a dynamically allocated hard disc of at least ten gigabytes.
Speaker 2: Four gigs of Ram is really the sweet bot if
Speaker 2: you want the graphical interface of a Buntu to run
Speaker 2: smoothly without lagging your host machine.
Speaker 1: And there's this fun pop culture easter egg in the book.
Speaker 1: When you create your username during setup, the author suggests
Speaker 1: using Elliott.
Speaker 2: A nod to the TV show Mister Robot.
Speaker 1: Yep, the hacker main character. It's a great touch. So
Speaker 1: you've booted up your Ubuntu virtual machine. You see a
Speaker 1: familiar graphical user interface or GUI. You have apps like Libra,
Speaker 1: Office and Dash. But to be a true power user,
Speaker 1: you have to leave the mouse behind.
Speaker 2: You really do. The guy is nice, but the real
Speaker 2: of Linux is in the command line.
Speaker 1: And this brings up a major point of confusion for beginners,
Speaker 1: the difference between the terminal and the shell.
Speaker 2: Oh, people mix these up constantly.
Speaker 1: Let's go back to the drive through for an analogy.
Speaker 1: The terminal is just the drive through speaker box. It's
Speaker 1: the physical or emulated window where you speak your order.
Speaker 2: Right. The terminal just displays the text. It doesn't actually
Speaker 2: understand what you're typing exactly.
Speaker 1: But the shell is the line cook wearing the headset
Speaker 1: inside the shell is interpreting your order and actually making
Speaker 1: the food or you know, executing the commands.
Speaker 2: This raises an important question, though, what happens when you
Speaker 2: type absolute gibberish into the terminal like you just mash
Speaker 2: your keyboard and hit enter.
Speaker 1: It doesn't crash, No, not at all.
Speaker 2: The shell simply replies command not found. It's a literal interpreter.
Speaker 2: If it doesn't recognize the exact order, it just hands
Speaker 2: it back to you.
Speaker 1: Here's where it gets really interesting to me. I love
Speaker 1: how literal Linux commands are. You don't need to memorize
Speaker 1: arcane magic spells. The commands are exactly what they do.
Speaker 2: The Unix philosophy is to do one thing and do
Speaker 2: it well, so the commands are very straightforward.
Speaker 1: Let's run through some examples. You type date and it
Speaker 1: prints the system date and time simple enough. You type
Speaker 1: Michael Fagele it prints the calendar, and I love this.
Speaker 1: You can time travel. You can type I'll call twenty
Speaker 1: twenty two to see that year, or even autocoll FEP
Speaker 1: nineteen ninety three.
Speaker 2: Surprisingly fun, just to see what day of the week
Speaker 2: you were born on. Yeah.
Speaker 1: Then there's clear, which just wipes the screen when it
Speaker 1: gets too messy, an echo, which literally repeats back whatever
Speaker 1: you type. So if you type echo, cats are better
Speaker 1: than dogs, it just prints cats are better than dogs.
Speaker 2: Right back, which seems silly at first, but echo is
Speaker 2: actually vital later on for writing automated scripts makes sense.
Speaker 1: And my absolute favorite history. It shows a number list
Speaker 1: of everything you've typed. If you want to run the
Speaker 1: seventh command you typed again, you don't retype it. You
Speaker 1: just type an exclamation point in the seventh like point seven.
Speaker 2: It saves so much time. But commands rarely just run
Speaker 2: in their basic state. They have options or flags to
Speaker 2: change the behavior.
Speaker 1: Right. Let's talk about hyphens, because this confused me at first.
Speaker 2: Sure, a single hyphen is for abbreviations like a single letter,
Speaker 2: so H. A double hyphen is for full words so human.
Speaker 1: So if I want to check my available memory, I
Speaker 1: type free, but it gives me the answer in raw kilobytes,
Speaker 1: which is practically unreadable for a normal person.
Speaker 2: Right, It's just a massive string of numbers.
Speaker 1: So you add the option. You can type free H
Speaker 1: or free human, and they do the exact same thing.
Speaker 1: They display the memory in megabytes or gigabytes, a format
Speaker 1: humans can actually read exactly.
Speaker 2: Options just modify the command's default behavior. Now, we know
Speaker 2: how to ask the computer for the date or its memory,
Speaker 2: but how do we ask it how hard it's working
Speaker 2: right now?
Speaker 1: Taking the system's pulse, that is where the uptime command
Speaker 1: comes in. You type it and it shows how long
Speaker 1: the system has been running, who is logged in, and
Speaker 1: something kind of intimidating called load average.
Speaker 2: Load average is a great metric, but it confuses a
Speaker 2: lot of people. It outputs three decimal numbers.
Speaker 1: Yeah, what exactly do those three numbers mean?
Speaker 2: They represent the system load basically the amount of work
Speaker 2: the CPU is doing over the past one minute, five minutes,
Speaker 2: and fifteen minutes.
Speaker 1: So if my system is doing absolutely nothing, what does
Speaker 1: it say?
Speaker 2: A load average of zero point zero means the system
Speaker 2: is completely idle. No processes are waiting in line for
Speaker 2: the CPU.
Speaker 1: Okay, so why does it give me three different timeframes, one, five,
Speaker 1: and fifteen.
Speaker 2: Because spotting trends is critical. Let's say your numbers are
Speaker 2: two point zero zero four point zero zero zero zero.
Speaker 2: The one minute load is a two, but the fifteen
Speaker 2: minute load is a six. That means the system load
Speaker 2: is much lower now than it was fifteen minutes ago.
Speaker 1: Ah, so the system is cooling down exactly.
Speaker 2: But if the numbers are reversed like five point zero zero,
Speaker 2: three point zero two point zero zero, your one minute
Speaker 2: load is way higher. That means the system load is
Speaker 2: actively spiking right now.
Speaker 1: That's incredibly useful for diagnosing a slow server. And Alcaberi
Speaker 1: also notes you can use the lcpu command to quickly
Speaker 1: list your CPU architecture and DFAIH to check available disk
Speaker 1: space right.
Speaker 2: Df stands for disc free, and throwing that H on
Speaker 2: there makes it human readable again.
Speaker 1: So now we know how the system is feeling and
Speaker 1: how hard it's working, but we need to know how
Speaker 1: to move around inside its brain. Where are all these
Speaker 1: files actually.
Speaker 2: Kept the filesystem? This is where Linux is very different
Speaker 2: from Windows, which uses C drives and D drives.
Speaker 1: Yeah. Algebra explains that the Linux filesystem is like an
Speaker 1: upside down tree. It starts at the very top with
Speaker 1: the root directory, which is represented simply by a single
Speaker 1: forward slash.
Speaker 2: Just everything branches out from that single forward slash, and.
Speaker 1: To move around you use CD, which stands for change directory.
Speaker 1: So CD takes you to the very top, but if
Speaker 1: you get lost, use PWD.
Speaker 2: Right working directory.
Speaker 1: Yes, I love PWD, it's the ultimate you are here
Speaker 1: a red star on a mall map. If you're lost,
Speaker 1: you just have PbD and it tells you exactly what
Speaker 1: folder you're standing in.
Speaker 2: It's essential, and once you know where you are, you
Speaker 2: use LS to list the files, or ll ls l
Speaker 2: e L for a long list that shows all the
Speaker 2: file permissions.
Speaker 1: The directory structure is so organized too. It's not just
Speaker 1: a free for all.
Speaker 2: Oh, it is trickly segregated by design. For example, you're
Speaker 2: the home directory, which is where regular users live, your documents,
Speaker 2: your downloads, but.
Speaker 1: The administrator, the root user, doesn't live there.
Speaker 2: No, the root user has their own exclusive home called Root.
Speaker 2: It's completely separate from regular users to prevent accidental damage.
Speaker 1: And then there's Bin and SPIN. Bin holds your essential
Speaker 1: everyday programs, your standard binaries, but SPIN holds the system
Speaker 1: administration programs.
Speaker 2: Right, the tools that require special privileges to run. It
Speaker 2: keeps the heavy machinery locked away from the standard tools.
Speaker 1: But there is one directory that comes with a massive
Speaker 1: warning label, the tempep directory.
Speaker 2: Ah, yes, the temporary folder.
Speaker 1: This holds temporary files obviously, but the book explicitly warns
Speaker 1: you never ever store important files here. Why is that?
Speaker 2: Because of how it's mounted. In many systems, TEMP exists
Speaker 2: in the system's volatile memory. Yeah, meaning the moment this
Speaker 2: system reboots or loses power, that entire wi your folder
Speaker 2: is wiped out completely, just poof gone exactly. It's designed
Speaker 2: for apps to drop temporary session data and clean it
Speaker 2: up automatically. If you save your novel on there and
Speaker 2: restart your computer, it is gone forever.
Speaker 1: That is a brutal lesson to learn the hard way.
Speaker 1: So let's zoom out think about how far we've come
Speaker 1: today on this deep dive.
Speaker 2: Let's a lot of ground to cover.
Speaker 1: We started with understanding Linus Torvald's little nineteen ninety one
Speaker 1: hobby project. We talked about spinning up in a Buntu
Speaker 1: virtual machine, literally talking directly to the shell with commands
Speaker 1: like echo and corticle. We learned how to check the
Speaker 1: CPU's load average to spot performance bikes, and navigated the
Speaker 1: upside down tree of the root file system.
Speaker 2: Once you understand the logic, it's actually incredibly elegant.
Speaker 1: So what does this all mean? Why go through the
Speaker 1: effort of learning to talk to a machine like this?
Speaker 2: Well, I think it leaves you with something really fascinating
Speaker 2: to ponder think about this. The very same free, open
Speaker 2: source code written by a college student as a fun
Speaker 2: hobby in nineteen ninety one is currently washing your clothes.
Speaker 2: It's managing global banking clouds. It is literally running the
Speaker 2: International Space Station right now.
Speaker 1: That is insane to think about.
Speaker 2: It really makes you wonder what other small, collaborative, weird
Speaker 2: little hobbies happening on the Internet right now might quietly
Speaker 2: become the invisible infrastructure of our future.
Speaker 1: A hobby today, the invisible engine of the world tomorrow.
Speaker 1: Thanks for taking this deep dive with us, and we'll
Speaker 1: see you on the next one.