Improve Chapter 01 software installation lesson

docs/lessons/01_where_to_start/1.10_ways_to_find_and_install_software.md

@@ -1,80 +1,324 @@
 ## 1.10 Ways to Find and Install Software
 
-
+Installing software is one of the first Linux tasks that feels simple until it
+goes wrong. The command may be short, but the decision behind it matters: where
+did the package come from, what dependencies will it add, what service will it
+start, and how will you prove the machine is better afterward?
 
 !!! abstract "What you will learn"
-    - Explain where **1.10 Ways to Find and Install Software** fits in day-to-day Linux operations.
-    - Use current Linux tooling to inspect, change, and verify the relevant system behavior.
-    - Connect the concept to a real operational scenario: a first-week junior admin onboarding into a small cloud team.
-
-!!! example "Field story"
-    Imagine a first-week junior admin onboarding into a small cloud team. Your job is not to memorize a command; it is to build a short evidence trail, choose a low-risk change, and prove whether the system improved.
+    - Explain the safest order for finding Linux software.
+    - Compare distribution repositories, upstream releases, vendor packages,
+      language package managers, and containers.
+    - Inspect a package before installing it.
+    - Verify and, when needed, remove software cleanly.
 
 !!! success "Operator principle"
-    Identify the OS, distribution, support window, and package source before changing anything.
+    Prefer the package source your operating system already trusts. Reach for
+    outside repositories only when you can explain the owner, update path,
+    rollback plan, and operational risk.
 
-## Hands-on practice
+## Start with the distribution
 
-Run these on a disposable VM, container, or lab machine unless the lesson explicitly says otherwise.
+Most Linux systems install software through a distribution package manager.
+That package manager knows which repositories are enabled, which packages are
+installed, which dependencies are required, and which files belong to each
+package.
 
-1. Inspect the current state with a read-only command related to this topic.
-2. Save the command and output in a short lab note.
-3. Make one reversible change or simulate the change in a sandbox.
-4. Re-run the inspection and explain what changed.
+Common families include:
 
-## Check your understanding
+- Debian and Ubuntu: `apt`, `apt-cache`, `dpkg`.
+- Red Hat Enterprise Linux, CentOS Stream, Rocky Linux, AlmaLinux, and Fedora:
+  `dnf`, `rpm`.
+- SUSE and openSUSE: `zypper`, `rpm`.
+- Arch Linux: `pacman`.
+- FreeBSD: `pkg`.
+
+On an unfamiliar system, identify the OS before choosing commands:
+
+```bash
+cat /etc/os-release
+```
+
+Then use the native package manager first unless you have a specific reason not
+to.
+
+## Search before installing
+
+Package names are not always obvious. Search the repositories before installing
+anything.
+
+Debian and Ubuntu:
+
+```bash
+apt search nginx
+apt-cache search "web server"
+```
 
-- What evidence would tell you that this system is healthy?
-- What is the riskiest command in this lesson, and how would you make it safer?
-- How would you explain section 1.10 to a teammate during an incident handoff?
+Fedora and RHEL-family systems:
 
+```bash
+dnf search nginx
+dnf list nginx
+```
 
-A distinguishing feature of Linux is its vast, diverse pool of software applications. Finding and installing these applications is as central to Linux as a roadmap is to a journey. This sub-chapter will gently guide you through the process. 🗺️🐧
+FreeBSD:
 
-### Understanding Linux Software Repositories
+```bash
+pkg search nginx
+```
 
-Most Linux distributions maintain software repositories—online databases storing a plethora of software packages ready for download and installation. Think of repositories as your one-stop digital shops for finding and downloading applications. 🛒📦
+Search results are leads, not approval to install. Pick the package that
+matches the service you actually intend to run.
 
-You can access these repositories through "package managers". These work much like app stores, but with command-line interfaces. `apt` (Debian-based distros), `dnf` (Fedora), and `pacman` (Arch) are examples of package managers. They manage software installations, updates, and removals. 🧰💪
+## Inspect the candidate
 
-### Installing Software
+Before installation, inspect metadata when the package manager supports it.
 
-The simplest way to install software is by using your distribution's package manager. For instance, if you're on a Debian-based system like Ubuntu, you can install a package using the `apt` command:
+Debian and Ubuntu:
 
 ```bash
-sudo apt install [package-name]
+apt show nginx
+apt-cache policy nginx
 ```
-Remember to replace `[package-name]` with the actual name of the software you want to install. 🔧💾
 
-The `apt` command retrieves the software from your distribution’s repository and installs it on your system. The `sudo` keyword is used because software installation requires administrator privileges. 🛡️🔑
+Fedora and RHEL-family systems:
 
-### Finding Software
+```bash
+dnf info nginx
+dnf repoquery --requires nginx
+```
 
-On Linux, you can browse available software in your distribution's repositories:
+FreeBSD:
 
 ```bash
-apt-cache search [keyword]
+pkg info nginx
 ```
-This command lists all packages that contain the `[keyword]` in their names or descriptions. 🕵️‍♂️🔍
 
-For example, if you're looking for a text editor, use the command `apt-cache search text editor` to produce a list of related applications. 📝🎯
+Look for:
+
+- Repository or vendor.
+- Version.
+- Architecture.
+- Dependencies.
+- Package size.
+- Description.
+- Homepage or project source.
+- Whether the package is already installed.
 
-### Uninstalling Software
+If the package comes from an unexpected repository, pause and inspect the
+enabled repositories before proceeding.
 
-Uninstalling software on Linux is as simple as installing it. You can use the `apt` command like this:
+## Install with a narrow change window
+
+On a lab machine, installing a package may be routine. On a production host, it
+is a change.
+
+Debian and Ubuntu:
 
 ```bash
-sudo apt remove [package-name]
+sudo apt update
+sudo apt install nginx
 ```
-This command uninstalls a package but leaves its configuration files intact. To remove these as well, you can use:
+
+Fedora and RHEL-family systems:
 
 ```bash
-sudo apt purge [package-name]
+sudo dnf install nginx
 ```
-Voilà! You've uninstalled the software and cleared its remnants—like a pro! 💪🗑️
 
----
+FreeBSD:
 
-Remember, each journey begins at a single spot. This is yours. Don't be daunted by Linux's vastness—embrace it! Linux’s power welcomes questions, rewards courage, and equips you with knowledge pivotal to the new-age digital world. Keep exploring, keep experimenting. Through this, you’ll learn Linux with ease.
+```bash
+sudo pkg install nginx
+```
+
+Before confirming an install on a real system, read the transaction summary.
+Notice new packages, removed packages, upgraded packages, and service-related
+post-install scripts.
+
+## Verify after installation
+
+Installation is not the same as success. Verify the result.
+
+Common checks:
+
+```bash
+command -v nginx
+nginx -v
+systemctl status nginx --no-pager
+systemctl is-enabled nginx
+ss -ltnp
+```
+
+Not every package starts a service. Some install only libraries, command-line
+tools, documentation, or development headers. Choose verification that matches
+the package.
+
+For a command-line utility, run:
+
+```bash
+command -v jq
+jq --version
+```
+
+For a library, inspect the package contents:
+
+```bash
+dpkg -L libssl3
+rpm -ql openssl-libs
+```
+
+## Remove software carefully
+
+Removing a package can remove dependencies or stop services. Inspect before
+confirming.
+
+Debian and Ubuntu:
+
+```bash
+sudo apt remove nginx
+sudo apt purge nginx
+sudo apt autoremove
+```
+
+`remove` keeps most configuration. `purge` removes package-managed
+configuration files. `autoremove` removes dependencies that are no longer
+needed, which can be helpful or dangerous depending on the host.
+
+Fedora and RHEL-family systems:
+
+```bash
+sudo dnf remove nginx
+```
+
+FreeBSD:
+
+```bash
+sudo pkg delete nginx
+```
+
+After removal, verify that the command, service, listener, and package record
+match the intended state.
+
+## Outside package sources
+
+Sometimes the distribution repository is not enough. You may need a newer
+version, a vendor-supported build, or a tool that is not packaged by the
+distribution.
+
+Common alternatives:
+
+- Vendor repositories, such as Docker, HashiCorp, Google, Microsoft, or
+  PostgreSQL repositories.
+- Upstream release archives, such as `.tar.gz` or binary release bundles.
+- Language package managers, such as `pip`, `npm`, `gem`, `cargo`, or `go
+  install`.
+- Container images.
+- Flatpak, Snap, or AppImage for desktop applications.
+- Source builds.
+
+Each alternative shifts trust and maintenance. Ask:
+
+- Who signs or publishes the package?
+- How are updates delivered?
+- Does it bypass the distribution security-update path?
+- Does it install files under `/usr`, `/usr/local`, `/opt`, or a user home
+  directory?
+- Does it create services, users, sockets, timers, or scheduled tasks?
+- How do you uninstall or roll back it?
+
+For servers, a distribution package or vendor repository is usually easier to
+operate than a manual binary copied into place without ownership metadata.
+
+## Language package managers
+
+Language package managers are useful for developer tooling and application
+dependencies, but they are not a substitute for operating-system package
+management.
+
+Avoid casually running global installs on shared servers:
+
+```bash
+sudo pip install something
+sudo npm install -g something
+```
+
+Prefer isolated environments when possible:
+
+- Python: virtual environments.
+- Node.js: project-local dependencies.
+- Ruby: Bundler-managed project dependencies.
+- Go: pinned module versions.
+- Rust: `cargo install` into a known user path for CLI tools.
+
+The goal is to keep application dependencies from silently replacing system
+libraries or tools.
+
+## Containers as software delivery
+
+Containers can be a good way to run software without installing every
+dependency on the host. They are still software from a source you must trust.
+
+Inspect:
+
+- Image publisher.
+- Image tag.
+- Digest, if pinning matters.
+- Exposed ports.
+- Mounted volumes.
+- Required environment variables and secrets.
+- Update and rollback process.
+
+Avoid treating `latest` as a stable version in production. Use explicit tags or
+digests when repeatability matters.
+
+## Keep an install note
+
+For nontrivial installs, leave a short record:
+
+```text
+Package: nginx
+System: Ubuntu 24.04
+Source: Ubuntu noble-updates repository
+Reason: reverse proxy for internal dashboard
+Pre-checks: apt show nginx; apt-cache policy nginx
+Installed with: sudo apt install nginx
+Verification: nginx -v; systemctl status nginx; ss -ltnp
+Rollback: sudo apt remove nginx; restore previous firewall rule set
+Owner: platform team
+Date: 2026-05-14
+```
+
+This note gives the next operator a starting point.
+
+## Lab: install and verify a small tool
+
+Use a disposable VM, container, or lab machine.
+
+1. Identify the OS:
+
+   ```bash
+   cat /etc/os-release
+   ```
+
+2. Search for `jq` with the native package manager.
+3. Inspect the candidate package metadata.
+4. Install `jq`.
+5. Verify the command path and version:
+
+   ```bash
+   command -v jq
+   jq --version
+   ```
+
+6. Record the package source, install command, and verification output.
+7. Remove the package only if the lab machine does not need it afterward.
+
+## Check your understanding
 
-Onward, to the next sub-chapter! 🚀🛠️
+- Why is the distribution repository usually the safest first source?
+- What should you inspect before confirming a package transaction?
+- What is the difference between removing and purging a package on
+  Debian-family systems?
+- Why can global language-package installs be risky on shared servers?
+- When might a container image be a better delivery path than a host package?