These days using Fedora Workstation there are multiple commands necessary to update the entire software on the system: not everything is installed as RPMs anymore – and some systems hardly use RPMs at all anyway.
Background
In the past all updates of a Fedora system were easily applied with one single command:
$ yum update
Later on, yum was replaced by DNF, but the idea stayed the same:
$ dnf update
Simple, right? But not these days: Fedora recently added capabilities to install and manage code via other ways: Flatpak packages are not managed by DNF. Also, many firmware updates are managed via the dedicated management tool fwupd. And lost but not least, Fedora Silverblue does not support DNF at all.
GUI solution Gnome Software – one tool to rule them all…
To properly update your Fedora system you have to check multiple sources. But before we dive into detailed CLI commands there is a simple way to do that all in one go: The Gnome Software tool does that for you. It checks all sources and just provides the available updates in its single GUI:
The above screenshot highlights that Gnome Software just shows available updates and can manage those. The user does not even know where those come from.
If we have a closer look at the configured repositories in Gnome Software we see that it covers main Fedora repositories, 3rd party repositories, flatpaks, firmware and so on:
Third party RPM repositories 
Fedora default repositories 
Flatpak and firmware sources
Using the GUI alone is sufficient to take care of all update routines. However, if you want to know and understand what happens underneath it is good to know the separate CLI commands for all kinds of software resources. We will look at them in the rest of the post.
System packages
Each and every system is made up at least of a basic set of software. The Kernel, a system for managing services like systemd, core libraries like libc and so on. With Fedora used as a Workstation system there are two ways to manage system packages, because there are two totally different spins of Fedora: the normal one, traditionally based on DNF and thus comprised out of RPM packages, and the new Fedora Silverblue, based on immutable ostree system images.
Traditional: DNF
Updating a RPM based system via DNF is easy:
$ dnf upgrade
[sudo] password for liquidat:
Last metadata expiration check: 0:39:20 ago on Tue 18 Jun 2019 01:03:12 PM CEST.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
kernel x86_64 5.1.9-300.fc30 updates 14 k
kernel-core x86_64 5.1.9-300.fc30 updates 26 M
kernel-modules x86_64 5.1.9-300.fc30 updates 28 M
kernel-modules-extra x86_64 5.1.9-300.fc30 updates 2.1 M
[...]
This is the traditional way to keep a Fedora system up2date. It is used for years and well known to everyone.
And in the end it is analogue to the way Linux distributions are kept up2date for ages now, only the command differs from system to system (apt-get, etc.)
Silverblue: OSTree
With the recent rise of container technologies the idea of immutable systems became prominent again. With Fedora Silverblue there is an implementation of that approach as a Fedora Workstation spin.
[Unlike] other operating systems, Silverblue is immutable. This means that every installation is identical to every other installation of the same version. The operating system that is on disk is exactly the same from one machine to the next, and it never changes as it is used.
Silverblue’s immutable design is intended to make it more stable, less prone to bugs, and easier to test and develop. Finally, Silverblue’s immutable design also makes it an excellent platform for containerized apps as well as container-based software development development. In each case, apps and containers are kept separate from the host system, improving stability and reliability.
https://docs.fedoraproject.org/en-US/fedora-silverblue/
Since we are dealing with immutable images here, another tool to manage them is needed: OSTree. Basically OSTree is a set of libraries and tools which helps to manage images and snapshots. The idea is to provide a basic system image to all, and all additional software on top in sandboxed formats like Flatpak.
Unfortunately, not all tools can be packages as flatpak: especially command line tools are currently hardly usable at all as flatpak. Thus there is a way to install and manage RPMs on top of the OSTree image, but still baked right into it: rpm-ostreee. In fact, on Fedora Silverblue, all images and RPMs baked into it are managed by it.
Thus updating the system and all related RPMs needs the command rpm-ostreee update:
$ rpm-ostree update
⠂ Receiving objects: 98% (4653/4732) 4,3 MB/s 129,7 MB
Receiving objects: 98% (4653/4732) 4,3 MB/s 129,7 MB... done
Checking out tree 209dfbe... done
Enabled rpm-md repositories: fedora-cisco-openh264 rpmfusion-free-updates rpmfusion-nonfree fedora rpmfusion-free updates rpmfusion-nonfree-updates
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2019-03-21T15:16:16Z
rpm-md repo 'rpmfusion-free-updates' (cached); generated: 2019-06-13T10:31:33Z
rpm-md repo 'rpmfusion-nonfree' (cached); generated: 2019-04-16T21:53:39Z
rpm-md repo 'fedora' (cached); generated: 2019-04-25T23:49:41Z
rpm-md repo 'rpmfusion-free' (cached); generated: 2019-04-16T20:46:20Z
rpm-md repo 'updates' (cached); generated: 2019-06-17T18:09:33Z
rpm-md repo 'rpmfusion-nonfree-updates' (cached); generated: 2019-06-13T11:00:42Z
Importing rpm-md... done
Resolving dependencies... done
Checking out packages... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Freed: 50,2 MB (pkgcache branches: 0)
Upgraded:
gcr 3.28.1-3.fc30 -> 3.28.1-4.fc30
gcr-base 3.28.1-3.fc30 -> 3.28.1-4.fc30
glib-networking 2.60.2-1.fc30 -> 2.60.3-1.fc30
glib2 2.60.3-1.fc30 -> 2.60.4-1.fc30
kernel 5.1.8-300.fc30 -> 5.1.9-300.fc30
kernel-core 5.1.8-300.fc30 -> 5.1.9-300.fc30
kernel-devel 5.1.8-300.fc30 -> 5.1.9-300.fc30
kernel-headers 5.1.8-300.fc30 -> 5.1.9-300.fc30
kernel-modules 5.1.8-300.fc30 -> 5.1.9-300.fc30
kernel-modules-extra 5.1.8-300.fc30 -> 5.1.9-300.fc30
plymouth 0.9.4-5.fc30 -> 0.9.4-6.fc30
plymouth-core-libs 0.9.4-5.fc30 -> 0.9.4-6.fc30
plymouth-graphics-libs 0.9.4-5.fc30 -> 0.9.4-6.fc30
plymouth-plugin-label 0.9.4-5.fc30 -> 0.9.4-6.fc30
plymouth-plugin-two-step 0.9.4-5.fc30 -> 0.9.4-6.fc30
plymouth-scripts 0.9.4-5.fc30 -> 0.9.4-6.fc30
plymouth-system-theme 0.9.4-5.fc30 -> 0.9.4-6.fc30
plymouth-theme-spinner 0.9.4-5.fc30 -> 0.9.4-6.fc30
Run "systemctl reboot" to start a reboot
Desktop applications: Flatpak
Installing software – especially desktop related software – on Linux is a major pain for distributors, users and developers alike. One attempt to solve this is the flatpak format, see also Flatpak – a solution to the Linux desktop packaging problem.
Basically Flatpak is a distribution independent packaging format targeted at desktop applications. It does come along with sandboxing capabilities and the packages usually have hardly any dependencies at all besides a common set provided to all of them.
Flatpak also provide its own repository format thus Flatpak packages can come with their own repository to be released and updated independently of a distribution release cycle.
In fact, this is what happens with the large Flatpak community repository flathub.org: all packages installed from there can be updated via flathub repos fully independent from Fedora – which also means independent from Fedora security teams, btw….
So Flatpak makes developing and distributing desktop programs much easier – and provides a tool for that. Meet flatpak!
$ flatpak update
Looking for updates…
ID Arch Branch Remote Download
1. [✓] org.freedesktop.Platform.Locale x86_64 1.6 flathub 1.0 kB / 177.1 MB
2. [✓] org.freedesktop.Platform.Locale x86_64 18.08 flathub 1.0 kB / 315.9 MB
3. [✓] org.libreoffice.LibreOffice.Locale x86_64 stable flathub 1.0 MB / 65.7 MB
4. [✓] org.freedesktop.Sdk.Locale x86_64 1.6 flathub 1.0 kB / 177.1 MB
5. [✓] org.freedesktop.Sdk.Locale x86_64 18.08 flathub 1.0 kB / 319.3 MB
Firmware
And there is firmware: the binary blobs that keep some of our hardware running and which is often – unfortunately – closed source.
A lot of Kernel related firmware is managed as system packages and thus part of the system image or packaged via RPM. But device related firmware (laptops, docking stations, and so on) is often only provided in Windows executable formats and difficult to handle.
Luckily, recently the Linux Vendor Firmware Service (LVFS) gained quite some traction as the default way for many vendors to make their device firmware consumable to Linux users:
The Linux Vendor Firmware Service is a secure portal which allows hardware vendors to upload firmware updates.
This site is used by all major Linux distributions to provide metadata for clients such as fwupdmgr and GNOME Software.
https://fwupd.org/
End users can take advantage of this with a tool dedicated to identify devices and manage the necessary firmware blobs for them: meet fwupdmgr!
$ fwupdmgr update No upgrades for 20L8S2N809 System Firmware, current is 0.1.31: 0.1.25=older, 0.1.26=older, 0.1.27=older, 0.1.29=older, 0.1.30=older
No upgrades for UEFI Device Firmware, current is 184.65.3590: 184.55.3510=older, 184.60.3561=older, 184.65.3590=same
No upgrades for UEFI Device Firmware, current is 0.1.13: 0.1.13=same
No releases found for device: Not compatible with bootloader version: failed predicate [BOT01.0[0-3]_* regex BOT01.04_B0016]
In the above example there were no updates available – but multiple devices are supported and thus were checked.
Forgot something? Gnome extensions…
The above examples cover the major ways to managed various bits of code. But they do not cover all cases, so for the sake of completion I’d like to highlight a few more here.
For example, Gnome extensions can be installed as RPM, but can also be installed via extensions.gnome.org. In that case the installation is done via a browser plugin.
The same is true for browser plugins themselves: they can be installed independently and extend the usage of the web browser. Think of the Chrome Web Store here, or Firefox Add-ons.
Conclusion
Keeping a system up2date was easier in the past – with a single command. However, at the same time that meant that those systems were limited by what RPM could actually deliver.
With the additional ways to update systems there is an additional burden on the system administrator, but at the same time there is much more software and firmware available these ways – code which was not available in the old RPM times at all. And with Silverblue an entirely new paradigm of system management is there – again something which would not have been the case with RPM at all.
At the same time it needs to be kept in mind that these are pure desktop systems – and there Gnome Software helps by being the single pane of glas.
So I fully understand if some people are a bit grumpy about the new needs for multiple tools. But I think the advantages by far outweigh the disadvantages.
/home/liquidat 
You can ship command line tools with Flatpack, but they wouldn’t appear on your default $PATH (at least in all distros I know). After installing a CLI tool you would need to set an alias to launch it as you used to do.
Yeah, true. The vim package at flathub is good example for that. But I decided to not mention it here because flatpak primarily targets desktop applications currently…