Swap

Right, let’s talk about cgroups memory limits. You’ve probably been here: you’re running a big data processing job, a leaky web app, or just a badly behaved script, and it decides it’s going to try to eat every single byte of RAM on your machine. The OS, in a desperate bid to survive, starts the OOM (Out-of-Memory) Killer, which is basically a glorified game of Russian roulette for your processes. It picks a process and shoots it dead to free up memory. Spoiler alert: it’s almost never the one you wanted it to kill.

Right, let’s talk about your RAM. Or, more accurately, let’s talk about how Linux has already laid claim to most of your RAM the second it finished booting. If you run free -h and see a paltry amount of “free” memory and start panicking, relax. You’re not about to crash. You’re witnessing one of Linux’s best performance tricks: using every spare byte of RAM it can get its hands on as a massive, intelligent cache. It’s not being greedy; it’s being brilliantly pragmatic.

Alright, let’s talk about vm.swappiness. This is the knob the kernel gives you to express your opinion on how much it should like using its swap file or partition. The key word here is opinion. You’re not giving it orders so much as strongly suggesting its drinking habits. The swappiness value isn’t a percentage of memory to use for swap, which is a common and totally understandable misconception. Instead, it’s an abstract value from 0 to 100 that controls the kernel’s aggression in moving memory pages out to disk. A higher value means the kernel will be more eager to swap stuff out to make room for more disk cache in RAM. A lower value tells the kernel to hold onto application memory in RAM for as long as it possibly can, preferring to shrink the disk cache instead.

Alright, let’s talk about huge pages. You know how your CPU’s memory management unit (MMU) has a little book of addresses called the Translation Lookaside Buffer (TLB)? Think of it as the CPU’s favorite contacts list. Every time it needs to access memory, it has to look up the virtual address in this list to find the real physical address. The problem? This list is tiny. Like, “forgets more than three items” tiny.

Right, so you’ve met the OOM Killer. It’s the kernel’s panic button, the process-sacrificing daemon that steps in when your system is gasping for its last breath of RAM. It’s not a graceful exit; it’s a chaotic, shotgun-blast approach to memory reclamation. You can’t turn it off, and you wouldn’t want to—without it, a single memory-hogging process would lock up your entire machine. But you can bribe it. You can whisper in its ear and say, “Hey, if you have to kill someone… please, not this one.” Or, conversely, “For the love of all that is holy, kill that one first.” That’s what oom_score_adj is for.

Right, let’s talk about the OOM Killer. This is the part of the Linux kernel that, when you’re desperately out of memory, stops being polite and starts getting real. It’s the digital equivalent of a bouncer at an over-capacity nightclub: its job is to pick a process to throw out so the whole system doesn’t collapse into a twitching heap. It’s brutal, often surprising, and frankly, a bit of a design admission of failure. We ran out of clever ideas, so we just pick a sucker and shoot it.

Right, let’s talk about /proc/meminfo. You’ve probably run free -h and stared at the numbers, feeling a mix of confusion and vague dread. Is my system about to fall over? Why is “free” memory so low? Is it time to panic-buy more RAM? The free command is just a pretty (well, okay) interface for the raw, glorious data in /proc/meminfo. This file is the kernel’s unvarnished, slightly chaotic confession about its current memory state. It doesn’t care about your feelings. It just reports the facts.

Right, so you’re tired of babysitting an installer. I don’t blame you. Clicking “next” for the tenth time while it asks you about your timezone for the third time is a special kind of hell. This is where we automate ourselves to freedom using either Kickstart (for the Red Hat, Fedora, CentOS crowd) or Preseed (for the Debian/Ubuntu devotees). The core idea is beautifully simple: you craft a single, plain text file that answers every question the installer would ever ask. You then point the installer at this file, go get a coffee, and come back to a fully installed system. It’s like teaching a very obedient, very fast intern how to do your job.

Right, so you want to install Linux on a machine that already runs Windows. This is the digital equivalent of convincing your sensible, corporate roommate to let their brilliant but eccentric artist cousin move into the spare room. It can work beautifully, but you have to set some ground rules first, or you’ll both be tripping over each other’s stuff and someone’s going to end up locked out. The core of the issue is this: Windows and Linux are two different operating systems with two different, mutually ignorant bootloaders. Windows uses a system called UEFI (or the ancient, horrifying BIOS, but we’re not talking about that today) to boot, and it fully expects to be the one and only star of the show. Our job is to install Linux without breaking Windows’s boot process, and then install a new bootloader (almost always GRUB) that is smart enough to find both operating systems and ask you which one you want to run. Let’s get the lay of the land first.

Right, let’s talk about LVM. You might be tempted to just click “Use Entire Disk” and call it a day. I get it. It’s easy. But easy is for people who enjoy reinstalling their OS from scratch when they run out of space on / while /home is sitting on a half-empty drive. We are not those people. LVM—Logical Volume Management—is your ticket out of that particular circus. Think of it as storage with a undo button and a stretchy waistband. It lets you abstract your actual physical disks (hard drives, SSDs, whatever) into a flexible pool of storage that you can carve up, resize, and move around on the fly. It’s one of those things that, once you get used to it, you’ll wonder how you ever lived without it. The goal here is to set it up correctly from the beginning, so your future self will send you a thank-you note.

Alright, let’s talk filesystems. This is one of those moments where your choice actually matters, far more than your distro’s default would have you believe. Picking a filesystem isn’t like picking a wallpaper; it’s foundational. It dictates how your data is stored, how it’s recovered when things go sideways, and what nifty tricks your storage can perform. We’re going to look at the big four for Linux: the old reliable, the speed demon, the young contender, and the beast from beyond. Strap in.

Right, swap. The great debate. Let’s get one thing straight: swap isn’t “extra RAM.” That’s like calling a lifeboat an “extra deck.” It’s an emergency measure, a place to shove idle data from your precious, blazing-fast RAM onto the comparatively glacial pace of your disk drive. The goal isn’t to make things faster; it’s to keep your system from face-planting when memory gets tight. The question is, how do you provision this lifeboat? A dedicated partition, or a humble file?

Alright, let’s get our hands dirty with partition schemes. You might be staring at your installer’s partitioning screen, wondering if you should just click “Use Entire Disk” and be done with it. Resist that urge. A well-thought-out partition layout isn’t just pedantic sysadmin nonsense; it’s your first line of defense against chaos. It’s the difference between a minor oopsie and a full-scale, scream-into-a-pillow disaster. The classic trifecta—/boot, / (root), and /home—is your sensible starting point. But we’re going to be thorough, so we’ll also talk about the often-overlooked but incredibly useful /var. Let’s break down what each of these does and why you’d want to give them their own little plot of land on your drive.

Alright, let’s get our hands dirty with the two big players in the partition table game: MBR and GPT. Think of this as the difference between a meticulously organized, expandable filing cabinet and a slightly cluttered index card box from the 1980s. One is modern and robust, the other is… well, it’s what we had. And you need to know which one you’re dealing with because it fundamentally dictates what your machine can do.