Ubuntu: The Default Choice, and When It Should Not Be

Ubuntu is the distribution most people mean when they say “Linux”. It is what cloud providers offer first, what hardware vendors certify, and what nine out of ten tutorials assume you are running. That ubiquity is a real advantage: when something goes wrong, someone has already written up the fix. This page covers how its release cycle works, the parts that trip people up, and where a different distribution would serve you better.

Reading the version number

Ubuntu versions are dates, not sequence numbers. 26.04 means April 2026. 25.10 means October 2025. Releases land every six months, in April and October, and the number tells you exactly how old a system is at a glance — which is more useful than it sounds when you inherit a server.

Each release also gets an alliterative codename, an adjective and an animal, advancing one letter of the alphabet each time: Jammy Jellyfish, Noble Numbat, Resolute Raccoon. The codename is not decoration — it is what appears in your /etc/apt/sources.list and in third-party repository instructions, so it is worth knowing yours. lsb_release -a tells you both.

LTS versus interim releases

This is the one decision that matters, and it is close to being made for you.

Run an LTS. A nine-month support window means an interim release stops receiving security updates roughly three months after its successor arrives, and upgrading a production server twice a year is not a hobby anyone enjoys. Interim releases exist for people who want a newer desktop stack and are happy to keep pace.

Ubuntu Pro extends each of those by five more years and is free for personal use on up to five machines. On a server you are not planning to rebuild, enabling it is a sensible default rather than an upsell to resist.

Snaps, and why people argue about them

Ubuntu ships two packaging systems. apt installs traditional .deb packages from the Ubuntu archive. snap installs self-contained bundles that carry their own dependencies and update themselves automatically.

The case for snaps is genuine: application authors ship one build that works everywhere, users get current versions without waiting two years for the next LTS, and confinement limits what a package can reach. The objections are equally genuine. Snap applications start slower. They update whether you asked or not, which is uncomfortable on a machine you need to behave predictably. And the store’s server side is Canonical’s alone, which sits awkwardly in an ecosystem built on being able to run your own.

What matters in practice is that some software is only available as a snap on Ubuntu — Firefox on the desktop is the well-known case — and that apt install will sometimes quietly install a snap instead. If that bothers you, Debian, Fedora and Linux Mint are all reasonable answers, and Flatpak covers most of the same ground with a decentralised store.

# What snaps are installed
snap list

# Snaps keep old revisions; this is often gigabytes
du -sh /var/lib/snapd/snaps

# Keep only two revisions of each
sudo snap set system refresh.retain=2

# Delay automatic updates (does not disable them)
sudo snap set system refresh.hold="$(date --date='today+30 days' +%Y-%m-%dT%H:%M:%S%:z)"

# What snaps are installed
snap list

# Snaps keep old revisions; this is often gigabytes
du -sh /var/lib/snapd/snaps

# Keep only two revisions of each
sudo snap set system refresh.retain=2

# Delay automatic updates (does not disable them)
sudo snap set system refresh.hold="$(date --date='today+30 days' +%Y-%m-%dT%H:%M:%S%:z)"

On a server, snaps are much less intrusive — a default Ubuntu Server install has only a handful, and the disk cost is the main thing to watch. See checking disk space if /var starts filling up unexpectedly.

Flavours and editions

The official flavours are the same Ubuntu underneath with a different desktop environment preinstalled. Switching between them is a matter of installing a different package set, not reinstalling.

Linux Mint deserves a mention here even though it is a separate distribution: it is built on Ubuntu LTS, ships no snaps by default, and its Cinnamon desktop is the friendliest landing spot for someone arriving from Windows.

Day-to-day package management

# Refresh the package lists, then upgrade
sudo apt update
sudo apt upgrade

# Install and remove
sudo apt install nginx
sudo apt remove nginx
sudo apt purge nginx        # also removes config files

# Clean up dependencies nothing needs any more
sudo apt autoremove

# Search, and inspect before installing
apt search nginx
apt show nginx

# Which package owns this file?
dpkg -S /usr/sbin/nginx

# Refresh the package lists, then upgrade
sudo apt update
sudo apt upgrade

# Install and remove
sudo apt install nginx
sudo apt remove nginx
sudo apt purge nginx        # also removes config files

# Clean up dependencies nothing needs any more
sudo apt autoremove

# Search, and inspect before installing
apt search nginx
apt show nginx

# Which package owns this file?
dpkg -S /usr/sbin/nginx

apt update and apt upgrade are two different things and both are needed: the first refreshes the catalogue, the second installs. Running upgrade alone against a stale catalogue does nothing useful. Package management covers this and the equivalents on other distributions.

PPAs

A PPA is a third-party repository hosted on Launchpad, and it is how you get software newer than the archive ships.

sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install php8.4-fpm

# List what you have added
ls /etc/apt/sources.list.d/

# Remove one
sudo add-apt-repository --remove ppa:ondrej/php

sudo add-apt-repository ppa:ondrej/php
sudo apt update
sudo apt install php8.4-fpm

# List what you have added
ls /etc/apt/sources.list.d/

# Remove one
sudo add-apt-repository --remove ppa:ondrej/php

Two cautions. A PPA is someone’s personal archive with root-level access to your machine, so add only ones you have a reason to trust. And PPAs are the most common reason a release upgrade fails: they are built for one Ubuntu release and are disabled during the upgrade, sometimes leaving packages stranded at versions the new release cannot resolve.

Upgrading between releases

# Fully update the current release first
sudo apt update && sudo apt full-upgrade
sudo reboot

# Then upgrade the release itself
sudo do-release-upgrade

# On an LTS, offer the next LTS before it reaches .1
sudo do-release-upgrade -d

# Fully update the current release first
sudo apt update && sudo apt full-upgrade
sudo reboot

# Then upgrade the release itself
sudo do-release-upgrade

# On an LTS, offer the next LTS before it reaches .1
sudo do-release-upgrade -d

By default an LTS system is not offered the next LTS until its first point release, around July of the release year. That delay is deliberate and worth respecting on anything important.

You cannot skip an LTS. Going from 22.04 to 26.04 means passing through 24.04. On a cloud server, the honest advice is that building a fresh machine on the new release and moving the workload across is usually less painful than an in-place upgrade, and it leaves you with a rollback — see migrating a server without downtime. Take a snapshot either way. Run the upgrade inside tmux or screen if you are doing it over SSH, so a dropped connection does not kill it half-finished.

Things that catch people out

The /boot one is worth pre-empting. It is a small partition, Ubuntu keeps several kernels, and it fills silently until an update fails in a confusing way. Running sudo apt autoremove --purge occasionally is enough to prevent it.

Who should run Ubuntu

Yes, if you want the path of least resistance. Every guide assumes it, every cloud image exists for it, commercial software that supports Linux at all supports it, and hardware support is as good as Linux gets because vendors certify against it. For a first Linux machine, or a server you want to stop thinking about, it is the correct boring answer.

Look elsewhere if any of these describe you:

• You want no snaps and no vendor-specific packaging — Debian is Ubuntu without Canonical.
• You are targeting a Red Hat environment at work — Fedora matches the tooling you will actually use.
• You want current software continuously rather than in two-year jumps — Arch, if you accept the maintenance that comes with it.
• You are running containers on minimal hosts, where Ubuntu’s default install is more than you need.

Quick reference

Related reading

• Debian — what Ubuntu is built on, and why you might prefer it directly
• Fedora — the Red Hat side of the family
• Arch Linux — the rolling-release alternative
• Package management — apt, dnf and pacman side by side
• Securing a new server — the first thing to do with a fresh Ubuntu install
• Command line basics — if this is your first Linux machine, start here