Debian — The Swiss Army Knife of Linux
Debian isn’t the flashiest distribution, but it’s the most reliable foundation in the Linux world. Behind it stands the largest community of volunteer developers, and behind its track record are decades of uninterrupted operation on servers, embedded systems, and cloud infrastructure. If you manage Linux machines in production, Debian (or one of its derivatives) is already in your stack — whether you’ve acknowledged it or not.
Managing Packages: apt and dpkg
Two tools form the core of Debian’s packaging system. apt is the high-level interface for working with repositories, resolving dependencies, and upgrading the system. dpkg is the low-level engine that installs, removes, and inspects individual .deb files without contacting repositories.
dpkg -i does not resolve dependencies. If a package pulls in other libraries, use apt install ./package.deb instead — apt will fetch missing dependencies from the repository.
A common mistake is mixing apt and dpkg during partial installations. If dpkg -i fails with a dependency error, run apt --fix-broken install and complete the operation through apt.
Stability Model and Release Branches
Debian is built on three branches that determine the aggressiveness of updates and the level of testing.
| Branch | Codename | Stability | When to Use |
|---|---|---|---|
| stable | bookworm (12) / trixie (13) | High — security and critical fixes only | Production servers, base infrastructure |
| testing | bookworm-progress | Medium — packages go through a stabilization period | Development machines, containers |
| unstable | sid | Low — daily snapshots | Experiments, binary package building |
In sources.list this looks like:
The non-free and non-free-firmware sections were introduced starting with Debian 12. Without them, certain proprietary drivers (Wi-Fi, GPU) won’t install.
Moving between branches is apt dist-upgrade with a swapped sources.list. Do this only on test benches — binary compatibility between testing and stable is not guaranteed for all packages.
Architecture Support
Debian officially supports more hardware platforms than any other distribution. This is critical for embedded and IoT projects.
| Architecture | Port | Typical Use |
|---|---|---|
| amd64 | amd64 | Servers, desktops, cloud |
| arm64 | arm64 | ARM servers (AWS Graviton, Raspberry Pi 4/5) |
| armhf | armhf | Embedded devices with FPU |
| i386 | i386 | Legacy systems |
| ppc64el | ppc64el | IBM Power Systems |
| s390x | s390x | IBM Z mainframes |
| riscv64 | riscv64 | Open RISC-V platforms |
Multi-architecture support allows installing packages for foreign platforms:
Debian as a Base for Other Distributions
Nearly every major distribution you use is built on Debian or inherits its packaging model.
- Ubuntu — takes the testing branch, adds its own PPAs and proprietary drivers.
- Linux Mint — based on Ubuntu, and therefore on Debian packages.
- Proxmox VE — a modified Debian 12 with added enterprise repositories.
- Kali Linux — Debian unstable with a suite of pentesting tools.
- Raspberry Pi OS (formerly Raspbian) — Debian armhf/arm64 with Pi-specific patches.
- MX Linux, antiX — Debian stable with lightweight desktop environments.
If you need a stable backend with fresher software, use Debian stable with the backports repository. This gives you updated kernel, nginx, PostgreSQL versions without switching to testing.
Practical DevOps Scenarios
In day-to-day work, the Debian approach manifests in several key patterns.
Base container images. Official Docker images like debian:bookworm, debian:slim are the starting point for hundreds of minimalist containers. debian:slim weighs around 70 MB compared to 200+ MB for ubuntu:latest.
VM templates. Proxmox, which runs on Debian, uses debootstrap to create LXC container templates. It is the same tool that underlies a fresh system installation.
Configuration management. Ansible, Puppet, Chef — all three work directly with Debian packages. The apt module in Ansible is one of the most-used modules in any playbook.
CI/CD pipelines. Building .deb packages in GitLab CI or GitHub Actions is a standard pattern. debhelper, dh_make, pbuilder, or sbuild provide reproducible builds in a clean chroot.
Key Commands for Daily Work
Bookmark this table — it covers 90% of tasks on a Debian server.
| Task | Command |
|---|---|
| Update package list | apt update |
| Upgrade all packages | apt upgrade -y |
| Full upgrade resolving dependencies | apt full-upgrade -y |
| Install a package | apt install -y <pkg> |
| Remove a package with configs | apt purge -y <pkg> |
| Search for a package | apt search <query> |
| Show package info | apt show <pkg> |
| List installed packages | apt list --installed |
| Find which package owns a file | dpkg -S <path> |
| List files in a package | dpkg -L <pkg> |
| Check package status | dpkg -l <pkg> |
| Fix broken dependencies | apt --fix-broken install |
| Clean apt cache | apt clean && apt autoclean |
| Add an architecture | dpkg --add-architecture <arch> |
| Build .deb from source | debuild -us -uc |
Debian isn’t the fastest at first glance — no rolling releases and no fresh software versions out of the box. But that predictability is exactly what makes it the foundation for production environments running millions of servers. If you want reliability over trending versions, Debian won’t let you down.