Statistig: Minimalist and well integrated

Statistig (the link goes to GNOME Extensions) is a lean system monitor that shows CPU and RAM usage as small icons in the system status area, right where you also see volume, network, or battery. The display stays discreet and is color-coded: yellow from 70% usage, red from 90%. That way you can see at a glance whether your system is starting to sweat.

The design follows the GNOME guidelines and deliberately skips any graphical ballast. One small downer: Statistig also hooks into the system menu. That wouldn’t be necessary, since settings can easily be changed in the extension manager. It’s not really annoying, but it feels a bit superfluous. The source code is available on GitHub.

TopHat: More data, more overview

TopHat (the link goes to GNOME Extensions) is aimed at everyone who appreciates a bit more control and transparency. Besides CPU and RAM usage, the extension also shows network and disk activity, right in the GNOME top bar, with small animated graphs. It all stays clear and doesn’t clutter the desktop visually.

TopHat is helpful if you regularly want to figure out why the system feels sluggish right now or where the network traffic is going. The graphs are compact but informative, and they give you a lot more context than plain percentages. If you want to dig deeper, TopHat is a good choice. Here, too, the source code is on GitHub.

If you want more: Mission Center

If you prefer a classic app over a Shell extension, take a look at Mission Center. The app was recently released in version 1.0 and is built on GTK4 and Libadwaita, so it looks modern and is functionally comprehensive. You see processes, CPU cores, memory, network, and more, all in one clear window.

Mission Center is best when you want to systematically hunt for bottlenecks or unusual behavior. Unlike the extensions, it needs an open window for that, but it offers more depth in return. If you regularly analyze your system, this is a strong tool.

Which monitor is right for you?

Whether Statistig, TopHat, or Mission Center, all three tools have their place. Statistig is ideal if you prefer a minimalist display and just want to keep an eye on whether the computer is under load. TopHat goes a step further and offers additional insight without disturbing the slim GNOME desktop. And if you’re looking for a full-fledged system monitor as a standalone app, Mission Center is a modern alternative. Looking back: whatever happened to Conky? Do you still have the classic running?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

What is Mission Center?

If you don’t know Mission Center yet: the app lets you monitor various system resources such as CPU, RAM, drives, network, and GPU in real time. It scores with a slick interface built on GTK4 and Libadwaita, which makes it a perfect fit for current GNOME desktops. What I like most is the focus on clarity and performance: all graphs are rendered with hardware acceleration, which keeps the CPU load low.

A few highlights of the basic features:

• Monitoring CPU usage per core or thread
• RAM and swap usage, including memory distribution
• Drive and network activity, including interface information
• GPU usage (via NVTOP), including video encoding/decoding
• Display of running processes and their resource consumption
• A compact summary view for a reduced layout

What’s new in version 1.0?

With the 1.0 release, Mission Center gets more than a nice round version number. It also brings a lot of useful improvements. The most important one: the app has become noticeably more responsive, and it now updates its displays much more precisely in time.

SMART data thanks to UDisks integration

Mission Center 1.0 now uses the widespread UDisks backend to give you detailed information about your hard drives and SSDs. If your drives support SMART (Self-Monitoring, Analysis and Reporting Technology), which is standard on current SATA and NVMe devices, you’ll see things like:

• Temperature
• Power-on time
• Error statistics
• and more

You can also eject drives directly, with a helpful error message if something goes wrong. This integration moves the storage view inside the app a big step forward and gives it a bit of added value over other system monitoring tools.

Network usage per process

At last, you can see which process causes how much network traffic. This feature requires nethogs to be installed, though. On Arch Linux, for example, you get it with:

$ <strong>sudo pacman -S nethogs</strong>
$ <strong>sudo setcap cap_net_admin,cap_net_raw,cap_dac_read_search,cap_sys_ptrace+pe $(which nethogs)</strong>
$ <strong>getcap $(which nethogs)</strong>

After that, the Processes view shows a new column for network activity, sortable, of course. In the current version 1.0, the translation for this column is still missing.

GPU monitoring on the Raspberry Pi

Owners of a Raspberry Pi 4 or 5 can look forward to this: the GPU is now detected and monitored via NVTOP, provided the right kernel is installed. That means at least kernel 6.12 with the corresponding support, for example in current Arch or Manjaro builds for the Pi.

Light or dark? You decide!

Not everyone likes the system-wide dark mode, or maybe you want to work in light mode during the day and dark in the evening. Mission Center 1.0 now lets you choose between light and dark mode independently of the system setting.

There’s also a new option to make the graphs “glide” with an animation. It looks pretty, but it comes with a certain performance tradeoff. On weaker systems (Mission Center also runs on a Raspberry Pi, for example) you may be better off disabling it.

Other changes at a glance

• Display of unloaded services on the Services page
• Improved memory reporting
• Display of the maximum bitrate of all network interfaces
• Configurable units: bits vs. bytes, base 2 vs. base 10
• More keyboard shortcuts
• New arrangement of the sidebars for a better overview
• Reworked Apps and Processes page with more information

Installing Mission Center

Mission Center is free software and available for various Linux distributions. The easiest and recommended way to install it is Flatpak via Flathub:

$ <strong>flatpak install flathub io.missioncenter.MissionCenter</strong>

After that, you can open the app from the app launcher or straight from the terminal with:

$ <strong>flatpak run io.missioncenter.MissionCenter</strong>

If you use GNOME Software, for example, you can of course also install the Flatpak on your system with a mouse click. Alternatively, you have these options:

• Snap Store: for users of Snap-based systems like Ubuntu
• AppImage: portable, no installation required

The source code is open and freely available on the project page on GitLab.

A good alternative to System Monitor

Of course, there are plenty of monitoring tools on Linux: htop or glances in the terminal, GNOME System Monitor, or the new Resources, to name just a few. But Mission Center stands out for me with its combination of a modern interface, a sensible range of features, and good performance. The similarity to the Windows Task Manager layout may be divisive, but I think it’s a pragmatic and user-friendly solution. Above all, though, the app is fully open source, actively developed, and fits perfectly into the modern GNOME desktop.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

Checking USB sticks for errors

First, you need to find out the device ID of the USB stick or memory card. So plug the device into your computer or insert the SD card into the card reader and type lsblk in the terminal. The command lists all storage devices connected to the computer. As a rule, you can identify the device ID by the size of the device. In my example, the system attaches my 8 GB USB stick as sdc (that is, /dev/sdc in full). If you’re unsure, unplug the device you want to check and run lsblk again. If sdc is missing from the list, you have the right ID. Alternatively, graphical tools such as GNOME Disks also show the ID.

$ lsblk
[...]
sdc           8:32   1   7.5G  0 disk
├─sdc1        8:33   1   2.9G  0 part /run/media/toff/Ubuntu 21.10 amd64
├─sdc2        8:34   1   4.1M  0 part
└─sdc3        8:35   1   300K  0 part
[...]

For the actual error check, the badblocks command from the e2fsprogs package comes into play, which is part of the standard installation of the usual distributions. Badblocks may refuse to start the check at first because the drive is supposedly in use by the system. This usually happens because the operating system mounts the device automatically as soon as you plug in the USB stick. On my system, clicking the eject icon in the file manager isn’t enough; I have to unmount the device ID of the drive and its partitions explicitly with umount.

Caution: I have to issue a warning at this point: when checking for errors, Badblocks overwrites all data and partitions on the specified device. So make absolutely sure you pass the right device ID to the command, and back up important data from the USB stick or SD memory card beforehand. If the worst happens, you won’t be able to recover the data after the check.

$ sudo badblocks -wsv /dev/sdc
/dev/sdc is apparently in use by the system; it's not safe to run badblocks!
$ sudo umount /dev/sdc*
umount: /dev/sdc: not mounted.
umount: /dev/sdc2: not mounted.
umount: /dev/sdc3: not mounted.

When calling Badblocks, you pass the parameters -wsv and the device ID. The parameters tell the program to run a destructive write test (-w), show the progress (-s) and output more information in general (-v). The thorough test writes every block of the device four times in a row with different patterns (0xaa, 0x55, 0xff and 0x00). Depending on speed and capacity, you need to allow quite some time for this. Checking the USB 2.0 stick with 8 GB of capacity from my example took more than an hour.

$ sudo badblocks -wsv /dev/sdc
Testing with pattern 0xaa:   0.00% done, 0:00 elapsed. (0/0/0 errors) done
Reading and comparing: done
Testing with pattern 0x55:   0.00% done, 23:47 elapsed. (0/0/0 errors) done
Reading and comparing: done
Testing with pattern 0xff:   0.00% done, 47:33 elapsed. (0/0/0 errors) done
Reading and comparing: done
Testing with pattern 0x00:   0.00% done, 1:11:26 elapsed. (0/0/0 errors) done
Reading and comparing: done

Besides the destructive method, Badblocks supports a non-destructive read-write mode. You enable it with the -n parameter instead of -w. In this variant, Badblocks first backs up the data of the block being checked to RAM, then overwrites the block with random data and checks whether the data was written correctly. Finally, Badblocks writes the backup back to the device. At first glance, this routine seems faster because there is only one pass, but in practice backing up and restoring the existing data takes considerably more time. In my example, it took more than 2.5 hours instead of just over one hour.

$ sudo badblocks -nsv /dev/sdc
Checking for bad blocks in non-destructive read-write mode
From block 0 to 7812607
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern:  94.36% done, 2:35:18 elapsed. (0/0/0 errors)

Detecting fake USB sticks

The tool F3, short for Fight Flash Fraud, goes one step further. The open-source program thoroughly checks whether a storage device really has the capacity it claims to have. Unfortunately, this is still a relevant topic, especially if you buy super cheap deals online. To expose fake USB sticks or SD memory cards, install the program from your distribution’s repositories. Debian, Ubuntu, Fedora and others carry the command-line tool in their official repositories; the package is usually called f3. Arch Linux only has the program in the AUR, so you need an AUR helper to install it.

### Installation on Arch Linux or Manjaro:
$ yay -S f3
### Installation on Debian, Ubuntu or Raspberry Pi OS:
$ sudo apt install f3

The commands for checking USB storage are f3write, f3read and f3probe. You have to use the first two in combination, passing each the mount point of the device as an option. f3write keeps writing one-gigabyte files to the mounted device until it runs out of space. Then you use f3read to check whether the written data can really be read back. If the device is a fake USB stick or a manipulated SD memory card, f3read would report corrupted sectors. This check leaves all data on the device intact; you just have to delete the h2w files at the end, otherwise there’s no space left on the stick.

$ f3write /run/media/toff/291E-6F9C
[...]
Free space: 3.72 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 3.91 MB/s
$ f3read /run/media/toff/291E-6F9C
[...]
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1518736/        0/      0/      0

  Data OK: 3.72 GB (7810192 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 14.73 MB/s
$ ls -al /run/media/toff/291E-6F9C
total 3907596
drwxr-xr-x  3 toff toff       4096 Jan  1  1970 .
drwxr-x---+ 4 root root         80 Dec  7 16:27 ..
-rw-r--r--  1 toff toff 1073741824 Dec  7 18:35 1.h2w
-rw-r--r--  1 toff toff 1073741824 Dec  7 18:40 2.h2w
-rw-r--r--  1 toff toff 1073741824 Dec  7 18:44 3.h2w
-rw-r--r--  1 toff toff  777592832 Dec  7 18:47 4.h2w
[...]

f3probe --destructive works a little faster. The --destructive option is optional, but it speeds things up considerably. In this test, F3 only writes the sectors it absolutely needs and doesn’t bother with backing up data. Since the probe accesses the hardware directly, you pass the device ID (here /dev/sdg) instead of the mount point. This way, the test with my 4 GB USB 2.0 stick takes only a little more than seven minutes. Keep in mind again, though, that this routine overwrites all data blocks on the device.

$ f3probe --destructive --time-ops /dev/sdg
[...]
Good news: The device `/dev/sdg' is the real thing

Device geometry:
	         *Usable* size: 3.73 GB (7831552 blocks)
	        Announced size: 3.73 GB (7831552 blocks)
	                Module: 4.00 GB (2^32 Bytes)
	Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 7'17"
 Operation: total time / count = avg time
      Read: 2.73s / 4812 = 568us
     Write: 7'13" / 3637313 = 119us
     Reset: 1us / 1 = 1us

Both Badblocks and F3 help you analyze errors on storage devices. You always need to bring a bit of time for the check, though. A thorough analysis of an 8 GB USB stick can easily take two hours, especially if the data is to be preserved during the check and the stick only supports the slow USB 2.0 protocol. Afterward, however, you can assume that the USB stick or SD memory card really works and has the capacity printed on the label.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.