Chapter 00 · Why Learn Linux?
Chapter Overview
Hello, World! In this opening chapter, I share what more than a decade of learning and teaching Linux has taught me. Learn Linux the Right Way inherits the strengths of the previous editions while adding new material and perspectives—so you can master Linux with less friction.
Linux thrives because it stands on the shoulders of a vibrant open‑source community. Together we’ll explore why learning open‑source software is so rewarding and look closely at the main open‑source licenses you’ll encounter—GPL, LGPL, BSD, Apache, MIT, and Mozilla—so that you can make informed choices later.
Open source shines in four ways: lower risk, lower cost, higher quality, and greater transparency. The spirit of open source is also something we Linux professionals carry with pride. I’ll use a plain‑spoken style (with a few lighthearted “gossip” moments) to tell the story of UNIX and Linux since 1969. You’ll see the arc of open‑source technology over more than half a century, meet today’s 10 most popular Linux distributions—RHEL, CentOS Stream, Fedora, Debian, Ubuntu, and more—and learn how open‑source projects make money and where the industry is headed.
0.1 About the Author
I work in Linux operations and administration. In high school, pure curiosity drew me to Linux, and I began learning systems administration early. I earned RHCE 6 in 2012; in early 2015 I obtained RHCE 7 and RHCA. In 2017 I published Learn Linux the Right Way, which has sold over 100,000 copies and earned “Author of the Year” from Posts & Telecommunications Press (PTPress). In 2020 I earned RHCE 8; in 2021 the 2nd Edition was released. In 2023 I published A Self‑Study Handbook of Common Linux Commands, selected by PTPress as a “Bestselling New Title,” and I received the “Influential Author of the Year” award. In 2024 and 2025 I earned RHCE 9 and RHCE 10, which further strengthened the technical foundation for this new edition of Learn Linux the Right Way.
Even so, I’m acutely aware of my limits. Without the generous help of mentors and friends, none of the above would have come so smoothly—nor would this book have reached you on time. Like many ordinary technologists, I’ve been the student studying late into the night at a training center, the person stuck for six hours in traffic, the person slogging through a dozen joyless Linux books. Those experiences hardened my resolve to write this book. With some nerves and a lot of care, I’ve tried my best to share what’s truly useful—so that this new edition helps you avoid detours and get comfortable with Linux faster.
In my view, a great instructor is not a mere courier of information but a distiller of high‑quality knowledge. So I did not try to cram everything I know into these pages. Instead, I wrote from a beginner’s point of view: deliberately cutting nonessential material and doubling down on the essentials—then practicing them repeatedly. The payoff is simple: you deepen your theoretical understanding while gaining the practical skills used in real‑world environments.
This book is based on Red Hat Enterprise Linux 10 and is broadly applicable to most Linux distributions. All companion software and materials are free at www.linuxzone.net. We’ll begin from zero and gradually raise the difficulty to match what production environments expect from operations engineers. Every chapter includes illustrations, tables, command examples, and review questions. Follow along and complete the hands‑on labs as you read—you’ll learn faster and remember more.
Finally, a confession: my original motivation wasn’t lofty—it was to repay a debt. For years, countless training providers in China charged handsomely, yet few offered truly good textbooks. That debt—owed to learners—should have been repaid long ago. By 2025 my motivation has gained a small selfish twist: in addition to maintaining the online learning site for this book and serving more students and readers, I want this free, open‑source textbook to be so good it surpasses many paid training materials—while holding ourselves to the highest ethical standards as a Chinese open‑source community: no deception, no dark patterns, a clean technical space. Please keep us honest. Our hope is simple: if you find value here—both in the book and in the companion services—tell your friends and help more people discover what we’re building together.
0.2 Learning Is Hard Work
I sometimes wonder whether humans carry a Linux‑like environment variable in our DNA. Let’s call it STUDY_LEVEL. It shapes our behavior: at 1, we’re irresistibly drawn to learning; at 0, we fully savor life. For most of us it probably hovers around 0.5. Every day, faced with the choice between learning and leisure, we seem to be running a while(true) loop. If only a biologist could find this variable and bump it up Monday through Friday—then dial it back on weekends. It sounds like sci‑fi, but one can dream.
Until then, what do we do?
There’s only one answer: self‑discipline.
Let’s not dodge reality: learning is rarely easy. If someone tells you learning Linux is effortless, they’re selling you something—and it won’t be a high‑paying job. Each morning, the inner battle begins anew: chat for a bit? Scroll short videos? Or crack open that intimidating Learn Linux the Right Way? When you’re wavering, remember why you started. Ten years from now, you’ll be grateful for the effort you put in today. My promise as the author is to respect your time, energy, and money—so that every chapter genuinely moves you forward.
Writing a book is exhausting work. From first draft to your hands can take two or three years—or more. A passage from Kazuo Inamori’s Ikigai sustained me and now I pass it on to you:
“If you slack off at work and seek only fun, you’ll get a fleeting thrill at best, never that deep joy that wells up from within. The joy that comes from work isn’t like candy—sweet the moment it touches your tongue. It seeps out from effort and hardship. When we focus, persevere, and push through difficulty to reach our goal, the sense of achievement is incomparable. And since work fills a large part of life, if we can’t find fulfillment in it, any other pleasures will eventually feel empty.”
That paragraph taught me that real happiness doesn’t come from momentary entertainment but from the achievement that follows effort. Skill‑building works the same way: every ounce of effort compounds into future rewards.
I suggest you grab a pen and write down, right here, your initial motivation—curiosity, career needs, higher pay, anything. Reading this book and completing the labs will take at least two to three months. When fatigue hits, re‑read your note and let your past self refuel your present self.
A note to myself:
Year Month Day
0.3 The Spirit of Open Sharing
Most software keeps its source code private. Open‑source software is released differently: the executable and the source code are provided together, so users can run the software freely and adapt the code to better fit their hardware and work needs. Users enjoy the freedom to use, copy, modify, and create derivatives—and, under some licenses, to charge for their work.
Yes, you read that right: you can create derivatives and sell them. You can take an open‑source program, customize it deeply, add real value, and—so long as you follow the license—register a trademark and release a commercial edition. If customers are willing to pay for what you’ve improved, that revenue is yours. This kind of freedom is exactly what hackers and geeks cherish. Through a blend of collaboration and competition, open‑source communities at home and abroad have taken deep root and attracted massive energy.
Of course, if freedom came at the expense of creators, momentum would stall. To balance freedom with fairness, more than a hundred licenses are now recognized by the Open Source Initiative (OSI) to protect contributors’ rights. Those who plagiarize, tamper with, crack, or pirate will eventually meet their court summons.
Since many readers may one day publish their own software, this book highlights six developer‑favorite licenses—frequently recommended by the OSI and widely used in practice—and shows you how to choose among them. Picking the license that best protects your work matters, especially for startups.
Tips: “Open‑source license” and “open‑source licensing agreement” mean the same thing. We’ll use them interchangeably.
Tips:
The Free Software Foundation (FSF) is a nonprofit that defends the rights of free/open‑source authors. Its mission is to promote users’ freedom and ensure they can use technology without undue restrictions. Linux, as a model open‑source project, was born from this spirit.
In open‑source circles you’ll often see copyleft—sometimes translated as “share‑alike.” In contrast to traditional copyright, copyleft ensures software remains free by granting the rights to copy, modify, and redistribute while requiring derivatives to remain under the same free terms.
You’ll also hear that open‑source software is “free.” Here, free means freedom, not price—“free as in freedom, not free as in beer,” as Richard Stallman puts it. It’s about the freedom to use, study, share, and improve software.
Let’s review six popular licenses and the freedoms they grant.
GNU General Public License (GPL). One of the most widely used licenses, the GPL guarantees the freedoms to run, study, share, and modify software. Originally drafted by Richard Stallman, it is now on version 3. Its core aim is to keep community achievements available to the world, protect against enclosure by proprietary vendors, and prevent exploitation by bad actors.
Under the GPL, any software that contains GPL‑licensed code must continue to publish its source code and remain free to use. For this reason, GPL code is typically unsuitable for software you intend to sell as proprietary. The GPL covers a vast array of open‑source projects—including the Linux kernel—and is often summarized with five freedoms:
Freedom to use: run the software as you wish, for any purpose.
Freedom to copy: copy and share the software with anyone, without limits.
Freedom to modify: add or remove features as you like—provided your modified version remains under the GPL.
Freedom to derive: create and publish derivative works in your own name.
Freedom to charge: sell the software in any medium—but you must inform buyers that it is available free of charge. Hence, many open‑source business models monetize services such as support and customization.
Tips: Do these licenses carry real legal weight? Yes. In 2008, the FSF sued Cisco’s Linksys division for using GNU software in routers without providing source code, as the GPL requires. In 2009, Cisco settled—paying damages, releasing the relevant source, and committing to internal compliance training. The case affirmed the enforceability of open‑source licenses and set an industry benchmark.
Lesser General Public License (LGPL). Created by the GNU Project and supported by the FSF, the LGPL mainly protects the openness of libraries. Compared with the GPL, the LGPL allows commercial software to link dynamically to open‑source code without requiring the entire product to be open‑sourced. In short, code covered by the LGPL—and modifications or derivatives of that code—must remain under the LGPL, but code that merely links to it need not be opened.
This license focuses on libraries rather than whole applications—its original name was Library GPL. It suits developers who want to use open‑source libraries in commercial products without opening their entire codebase. Famous projects under the LGPL include glibc (the GNU C standard library), the GTK+ toolkit, and the FreeType font engine. By ensuring that the LGPL‑covered part stays open while allowing linked code to remain closed, it supports commercial software sales—standing tall while still getting paid, as we say.
Berkeley Software Distribution (BSD) license. Widely used and exceptionally business‑friendly, the BSD family offers greater flexibility than the GPL. Users may use, modify, and redistribute BSD‑licensed software and may incorporate it into commercial products. To preserve integrity and credit, three basic conditions apply:
Source‑code retention: if you redistribute products containing original BSD‑licensed code, you must keep its license text.
Copyright notice: if you redistribute only binaries, you must include attribution in documentation or a copyright file.
No endorsement: you may not use the names of the original software, authors, or institutions for promotion without permission.
BSD’s minimal restrictions ease the combination of open‑source and commercial software, helping spread technology and encourage commercialization.
Apache License. Issued by the Apache Software Foundation, this license is famous both for its widespread adoption and for protecting developers with clear copyright and patent terms. The current mainstream is version 2.0 (2004). It grants broad rights to modify and redistribute while preserving notice requirements, making it an excellent choice for commercial development. Many well‑known projects—Hadoop, Apache Kafka, and the Apache HTTP Server—use it. Three core obligations apply:
If you modify source code, document your changes.
If your software builds on others’ code, preserve the original license, trademarks, patent notices, and attributions.
If you redistribute software that includes Apache‑licensed code, retain the original license file so users know the terms.
These rules maintain openness and freedom while protecting developers and original authors—an ideal balance for commercial use.
MIT License. Originating at MIT and once used by the X Window System (X11), MIT is among the most permissive licenses. You may use, copy, modify, and redistribute software with only one requirement: keep the original copyright and license notice. That’s it. MIT’s generous terms have propelled the spread of software like jQuery and many Node.js ecosystem components (for example, libuv). You can feel the creators’ love of technology and freedom—mind and hand indeed.
Tips: Beyond defending your rights, you can adjust licensing to fit markets and grow users. ZeroMQ, a high‑performance messaging library used in low‑latency systems, was originally released under the LGPL. In 2013 the project switched to the much more permissive MIT License to lower barriers for adoption. The result: faster growth and broader use across projects.
Mozilla Public License (MPL). Created by Netscape in 1998 as part of the Mozilla project, the MPL sought a middle path between the GPL and BSD. The current version is 2.0 (2012), used by Firefox, Thunderbird, and more. Key features:
File‑level copyleft: only files under the MPL must remain open; new modules can be kept proprietary, much like the LGPL.
Flexible code mixing: MPL, GPL, BSD, and other code can be combined in one project, which helps in complex, mixed‑stack products.
Transparent change history: releases must include a file listing the dates and nature of changes to the original code, improving traceability and collaboration.
In short, the MPL promotes reuse and innovation while respecting developers’ rights and commercial needs.
After so many licenses, you may ask: “They all look similar—how do I choose?” Engineer Paul Bagwell’s flowchart (Figure below) summarizes the six licenses we just discussed and can help you pick one.
A common question is: “How do open‑source developers make a living?” You’ll often hear two answers:
Passion: contributors write code for the love of it and to benefit society.
Services: get users to adopt the software, then earn revenue from support and customization.
Both are partly right but incomplete. Open‑source and commercial software aren’t enemies; good projects need good business models. Typical models include:
Multiple product lines: different tiers for different users. For example, MySQL has community and enterprise editions—the former builds adoption; the latter sells licenses.
Technical services: JBoss is a classic example—free to use, revenue from documentation, training, and custom development.
Hardware bundling: companies sell servers bundled with AIX or Linux to ensure hardware revenue.
Publishing: O’Reilly both publishes books and supports open‑source projects; many titles align with the projects they back. Win‑win.
Brand and reputation: even Microsoft has embraced open source. Much of Visual Studio Code, PowerShell, and TypeScript is open‑sourced.
0.4 Why Learn Linux?
In class I often ask, “Why learn Linux?” Many students answer, “Because it’s open source.” That’s not enough. There are a hundred operating systems and thousands of programs that are open source—why not learn them all? Openness is a plus, but it’s not the whole reason to invest serious effort.
What matters most is Linux’s quality. It offers UNIX‑like elegance and efficient interfaces and inherits UNIX‑grade stability. The community keeps contributing high‑quality code and rich third‑party software, so Linux meets demanding requirements for availability and performance.
Many of us first used computers on Microsoft Windows, so it’s natural to think, “Windows works fine for daily tasks.” It is excellent in many ways, but its security, availability, and performance often fall short for critical workloads. You’ve probably seen the infamous blue screen. While rare, if it occurs in production, the consequences can be severe.
So learning Linux isn’t just about openness; it’s about reliability. Linux excels on key operational metrics and gives systems a solid foundation. Add the freedom and flexibility of open source and you have a compelling case to learn it.
Linux dominates servers and cloud computing, too. As of 2025, authoritative data shows Linux holding a commanding share in the web‑server market, with more than 90% among high‑traffic sites—making it the first choice for many enterprises and developers.
Google’s search, mail, and cloud services run on Linux. Android is built on the Linux kernel. Amazon Web Services deploys Linux on well over 90% of its servers, underscoring Linux’s central role in public‑cloud infrastructure.
In high‑performance computing, the TOP500 list—Frontier, Summit, Sierra, Fugaku, LUMI, Sunway TaihuLight, and more—runs exclusively on Linux, reflecting its dominance at the edge of performance.
To make the differences between Linux and Windows more concrete, the figure below summarizes real‑world contrasts drawn from my own experience. You may not fully agree yet—keep learning and judge for yourself.
Every technologist who embraces Linux feels pride in open source. This isn’t just about profit: the community lifts one another up to serve more users. Anyone can contribute code and ideas—and benefit in return. That virtuous cycle yields four core advantages:
Low risk: closed software creates dependency on a single vendor. If it’s abandoned, you’re stuck. With open source, even if the original maintainer leaves, others can take over and keep the project alive.
High quality: open projects have many maintainers and testers; bugs are often fixed before they blow up. Pride and peer review discourage shipping “half‑baked” code.
Lower cost: by reusing open components, organizations save time and money otherwise spent on ground‑up development.
Transparency: no one would knowingly plant malware in a public repository—it would be exposed quickly by watchful contributors worldwide.
This culture delivers high‑quality, low‑cost solutions and democratizes technology—fueling innovation and global knowledge sharing.
Here’s a compact timeline—far from exhaustive—of key milestones:
1965: Bell Labs, GE, and MIT launched the MULTICS OS to support multi‑terminal computing. The project proved too complex and lost funding.
1969: After Bell Labs withdrew, Ken Thompson wrote a new kernel in assembly for the PDP‑7 to run his Space Travel game. A tongue‑in‑cheek name, UNICS, stuck. It later became UNIX.
1973: Dennis Ritchie and Ken Thompson rewrote the kernel in C, enabling portability across architectures and fueling UNIX’s spread.
1979: AT&T reclaimed UNIX copyrights and moved toward proprietary licensing, restricting source access—disappointing hackers who valued freedom to share.
1983–1989: Richard Stallman launched the GNU Project and wrote the GPL. GCC, Emacs, and bash arrived, galvanizing the community.
1984–1987: Andrew S. Tanenbaum created MINIX as a UNIX‑like teaching OS.
1991: Linus Torvalds released Linux 0.02, inviting feedback in a now‑famous post:
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).
I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)
Linus torvalds
Tux, Linux’s penguin mascot, is said to have been inspired by a childhood penguin encounter. Whether or not that story is true, we can be glad it wasn’t a tiger.
1993: Bob Young and Marc Ewing founded Red Hat and released early versions of Red Hat Linux. Backed by a support‑driven business model, Linux adoption accelerated. In 2012 Red Hat became the first pure‑play open‑source company to pass 1 billion USD in annual revenue, later crossing 2 and 3 billion.
Today: the Linux kernel is in the 6.x series, with hundreds of downstream distributions. Linus Torvalds remains the project’s guiding voice. Red Hat’s technical depth and mature business model make it a pillar of the ecosystem.
0.5 Common Linux Distributions
First, two definitions:
Linux kernel: initiated by Linus Torvalds and maintained by a global community, the kernel provides hardware abstraction, disks and filesystems, and multitasking (see Chapter 2).
Linux distribution: a complete operating system built from the kernel plus components such as a shell, desktop environment, and applications.
Hundreds of distributions exist. Some emphasize stability and security; others emphasize zero cost or customization. Below are ten popular ones from a user’s perspective.
Tips: Throughout the book, “Linux system” refers to a distribution.
Red Hat Enterprise Linux (RHEL)
Red Hat Enterprise Linux (RHEL). Founded in 1993 and listed on NASDAQ in 1999, Red Hat has long led open‑source commercialization. Since 2006 it has acquired JBoss (middleware), CentOS, Inktank (Ceph), and others, consolidating its position. In 2019 IBM acquired Red Hat for 34 billion USD.
RHEL debuted in 2000 and quickly gained support from Dell, HP, Oracle, and IBM. Over the next two decades RHEL’s market share rose on the strength of performance and support. Airlines, telcos, banks, and healthcare rely on it. The latest release at the time of writing is RHEL 10, the default system for this book and for Red Hat certification exams. With GCC 14, Rust 1.82, Python 3.12, and LLVM 19, RHEL 10 further boosts developer productivity.
RHEL system and companion tools download: https://www.linuxzone.net/tools
CentOS Stream (Community Enterprise Operating System)
CentOS. Originally rebuilt from RHEL source and famous for being free, CentOS delivered RHEL‑like stability without licensing fees. Versions roughly tracked RHEL (CentOS 8.0 ≈ RHEL 8.0). Packages were cross‑compatible. Because CentOS is compiled from the RHEL source after removing subscription features, it does not develop sweeping new features like an independent distribution would; the community focuses on security updates and small fixes.
In January 2014 Red Hat brought CentOS under its wing; in 2019 the project became CentOS Stream. CentOS Stream inherits the free‑to‑use feature of its predecessor, but it’s no longer merely a downstream rebuild—it functions as a rolling preview of the next RHEL, where users and developers can try upcoming features without conflicting with RHEL’s commercial positioning.
Fedora Linux
Fedora Linux. The name “Fedora” literally means a soft‑brim felt hat; in Chinese it’s often transliterated as “Feiduo‑la.” Fedora is very much Red Hat’s own community distribution. Originally created to build and test third‑party software for RHEL, it nurtured one of the earliest open‑source communities. Fedora typically releases every six months and now serves millions of users worldwide. It targets users who want the latest desktop technologies rather than ultra‑long‑term stability. New software first lands here, and once it matures it graduates into RHEL—hence Fedora’s nickname as RHEL’s “test field.” If you want to push yourself to learn new Linux tech every day, keep an eye on Fedora’s changes and adjust your learning accordingly.
Rocky Linux
Rocky Linux. Established in 2021 by CentOS co‑founder Gregory Kurtzer after CentOS Linux ended, Rocky is a community‑driven rebuild of RHEL with long lifecycles (up to ten years). It aims to be a drop‑in replacement for CentOS/RHEL, minimizing migration friction for enterprises.
Debian
Debian Linux. Launched in 1993 and named after Ian Murdock and Debra, Debian is renowned for stability, security, and breadth: its repositories include tens of thousands of packages and support many architectures. Debian uses the APT toolchain rather than RHEL’s YUM/DNF. Most people simply say “Debian.”
Ubuntu
Ubuntu Linux. A derivative of Debian with its own cadence (a release every six months) and long‑term‑support options. The name comes from a Bantu concept meaning “I am because we are.” Canonical provides commercial support. Desktop LTS releases are supported for five years; server LTS can be extended to ten.
openSUSE
openSUSE. A German‑born distribution with a friendly desktop and robust server capabilities. Despite changes in corporate ownership over the years, the community remains active. Users can choose among desktop environments (GNOME, KDE, Cinnamon, MATE, LXQt, Xfce) and install from a large set of packages.
Kali Linux
Kali Linux. Designed for penetration testing and digital forensics, Kali includes hundreds of security tools (Nmap, Wireshark, SQLmap, and more). It runs on PCs, servers, and tiny devices like the Raspberry Pi—like carrying a pocket arsenal.
Tips: The most common Linux desktops are GNOME and KDE. Kali lets you choose; most other distributions default to GNOME.
Gentoo
Gentoo Linux. Named for the swift gentoo penguin, Gentoo offers maximum customization—users routinely rebuild even core libraries and compilers. Power comes with complexity; Gentoo is best for experienced users, not beginners.
deepin (Deepin OS)
deepin. A successful Chinese distribution that pairs technical R&D with solid productization. Initially derived from Ubuntu and later rebased on Debian, deepin offers 32 language versions and tight localization for Chinese users (WPS Office, Sogou IME, Youdao Dictionary, and more). While there’s room to grow technically, its polish helps newcomers.
In short, while these distributions differ in look‑and‑feel and tooling, they are all Linux if they share the Linux kernel. This book uses RHEL 10. The labs work on mainstream distributions such as CentOS Stream, Fedora, and Rocky Linux. The companion ISO images align closely with Red Hat’s RHCSA/RHCE exams, making this text suitable for certification prep.
0.6 Thank You for Believing in Me
First, thank you for choosing this book from among so many Linux titles. I won’t let you down.
Second, my thanks to every teammate, in order of joining: Pang Zengbao, Zhang Hongyu, Zhang Zhenyu, Wang Hao, Guo Jianpeng, Ni Jiaxing, Jiang Xianhe, Feng Ruitao, Yang Binbin, Wang Huachao, Wang Yanmin, and Yue Yong. Thank you for trusting me and fighting alongside me. Without your help we would not be here. In the past decade we grew from a blog with a dozen daily visitors into a technology community with nearly 100,000 daily visits. In the past five years we launched nearly 60 QQ groups with more than 200,000 members. Our WeChat account grew from zero to 400,000 followers. These heights are rare among technical books in China. In the past three years we’ve outpaced our peers, and our content and reputation have made each step steadier. We can say with pride: we kept users with hard work, and users saw our effort.
Third, my thanks to editor Fu Daokun of PTPress, who proposed publishing Learn Linux the Right Way in 2015 and helped polish it into a best‑seller that surpassed 100,000 copies. Thank you for more than a decade of trust and companionship as we arrive at the third edition. Thanks also to Professor Wang Tingmei of Beijing Union University, who advised me during my education master’s program and guided me into education and computer science.
Finally, my special thanks to my parents and my wife. When I said I wanted to write a technical book, you chose to believe in me without reservation. Thank you, my wife, for understanding the pressure I was under and for helping operate and recruit for our online training classes, freeing up time for me to write. Without your trust and companionship, I dare not imagine where my life would have gone.