Statistig: Minimalistisch und gut integriert

Statistig (Link geht zu den GNOME Extensions) ist ein schlanker Systemmonitor, der CPU- und RAM-Auslastung als kleine Symbole im Systemstatusbereich einblendet – dort, wo ihr auch Lautstärke, Netzwerk oder Akku seht. Die Anzeige bleibt dezent und ist farbcodiert: Gelb ab 70 %, Rot ab 90 % Auslastung. So erkennt ihr auf einen Blick, ob euer System ins Schwitzen gerät.

Das Design folgt den GNOME-Vorgaben und verzichtet bewusst auf grafischen Ballast. Ein kleiner Wermutstropfen: Statistig klinkt sich zusätzlich ins Systemmenü ein. Das wäre nicht nötig – Einstellungen lassen sich bequem über den Erweiterungsmanager vornehmen. Wirklich störend ist das nicht, aber es wirkt ein wenig überflüssig. Der Quellcode ist auf GitHub verfügbar.

TopHat: Mehr Daten, mehr Überblick

TopHat (Link geht zu den GNOME Extensions) richtet sich an alle, die etwas mehr Kontrolle und Transparenz schätzen. Die Erweiterung zeigt neben CPU- und RAM-Auslastung auch Netzwerk- und Festplattenaktivität – direkt oben in der GNOME-Leiste, mit kleinen animierten Graphen. Das Ganze bleibt übersichtlich, ohne den Desktop optisch zu überladen.

TopHat ist hilfreich, wenn ihr regelmäßig nachvollziehen möchtet, warum das System gerade träge wirkt oder wohin der Datenverkehr fließt. Die grafischen Anzeigen sind kompakt, aber informativ – und bieten deutlich mehr Kontext als einfache Prozentwerte. Wer tiefer einsteigen will, ist mit TopHat gut beraten. Auch hier gibt’s den Quellcode auf GitHub.

Wenn’s mehr sein darf: Mission Center

Falls ihr lieber mit einer klassischen Anwendung arbeitet statt mit einer Shell-Erweiterung, lohnt sich ein Blick auf Mission Center. Die App wurde kürzlich in Version 1.0 veröffentlicht und setzt auf GTK4 und Libadwaita – optisch modern, funktional umfassend. Ihr seht Prozesse, CPU-Kerne, Speicher, Netzwerk und mehr – alles in einem übersichtlichen Fenster.

Mission Center eignet sich vor allem dann, wenn ihr systematisch nach Engpässen oder ungewöhnlichem Verhalten suchen wollt. Im Unterschied zu den Erweiterungen braucht es dafür ein geöffnetes Fenster – dafür bietet es mehr Tiefe. Wer regelmäßig mit Systemanalysen arbeitet, bekommt hier ein starkes Werkzeug.

Welcher Monitor passt zu euch?

Ob Statistig, TopHat oder Mission Center – alle drei Werkzeuge haben ihre Berechtigung. Statistig ist ideal für alle, die eine minimalistische Anzeige bevorzugen und einfach nur im Blick behalten möchten, ob der Rechner gerade ausgelastet ist. TopHat geht einen Schritt weiter und bietet zusätzliche Einblicke, ohne dabei den schlanken GNOME-Desktop zu stören. Und wer einen vollwertigen Systemmonitor als eigenständige Anwendung sucht, findet mit Mission Center eine moderne Alternative. Rückblickend: Was ist eigentlich aus Conky geworden? Habt ihr den Klassiker noch im Einsatz?

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Kommentar zu BleachBit und Co.: Seid vorsichtig, wenn ihr mit solchen Tools euer System automatisch aufräumen lasst. Programme legen nicht ohne Grund Cache-Speicher an. So muss Firefox beispielsweise nicht jedes Mal alle Style-Dateien neu aus dem Netz laden, und auch Nautilus muss Thumbnails von Bildern nicht ständig neu erstellen. Ein unbedachter Klick kann jedoch auch wichtige Daten löschen, wie etwa Logins und Passwörter in Firefox oder Chrome/Chromium. Seid also vorsichtig beim Einsatz von BleachBit.

Neue Funktionen und Verbesserungen

Mit der neuen Version erweitert BleachBit seine Unterstützung für verschiedene Programme und Systembereiche:

• Discord kann nun bereinigt werden – inklusive Snap- und Beta-Versionen.
• Auch Microsoft Edge wird unterstützt, sofern es sich um stabile Releases handelt.
• Für Datenschutz-Fans ist Librewolf nun ebenfalls abgedeckt.
• Die GNOME-Mail-App Geary ist neu in der Liste der unterstützten Anwendungen.
• Temporäre Dateien von Bash-Sessions lassen sich gezielt löschen.
• Defekte .desktop-Dateien, die etwa durch Deinstallationen zurückbleiben, erkennt und entfernt das Tool.
• Auch die Bereinigung rotierter Logdateien wurde verbessert.

Linux-Anwender profitieren zusätzlich von einem neuen AppIndicator-Symbol, das im Panel von GNOME oder KDE anzeigt, wenn BleachBit aktiv ist. So lässt sich das laufende Programm auch dann erkennen, wenn es nicht in der Taskleiste sichtbar ist. Für Nutzer, die oft Daten vom System schrubben möchten, ist das sicher eine praktische Funktion.

Allgemeine Verbesserungen

BleachBit 5.0.0 bringt auch plattformübergreifende Verbesserungen mit, die den Umgang mit der Software vereinfachen:

• In den Einstellungen gibt es nun eine Sprachauswahl, mit der sich die Oberfläche anpassen lässt.
• Neue Tastenkombinationen wie Strg + Q und Strg + W erlauben das schnelle Beenden der Anwendung.
• Update-Benachrichtigungen wurden weniger aufdringlich gestaltet.
• Der Kommandozeilenschalter --debug funktioniert wieder wie vorgesehen.
• Im portablen Modus werden persönliche Cleaner nun korrekt geladen.
• Auf Mehrbenutzersystemen ignoriert BleachBit Prozesse anderer Nutzer, um ungewollte Eingriffe zu vermeiden.
• Ungültige Einträge in den Tabs für benutzerdefinierte Cleaner und Whitelist-Elemente werden verhindert.

Download und weitere Informationen

Die aktuelle Version steht auf der offiziellen Website von BleachBit zum Download bereit. Bei Arch Linux ist die neue Version bereits in den Repositories.

• Für Linux wird ein 64-Bit-DEB-Paket angeboten, das auf Ubuntu 20.04 LTS und neueren Versionen läuft.
• Für Windows gibt es sowohl ein Installationsprogramm als auch eine portable Version.

Alle Änderungen im Detail findet ihr auch im GitHub-Repository, inklusive aller Commits zwischen Version 4.6.2 und 5.0.0.

Vorsicht ist die Mutter der Porzellankiste

BleachBit 5.0 bringt sinnvolle Erweiterungen, die sowohl die Funktionalität als auch die Sicherheit verbessern. Trotzdem solltet ihr beim Einsatz vorsichtig sein: Nutzt vor dem Löschen die Vorschaufunktion, um genau zu sehen, was entfernt wird. Insbesondere das Löschen von Caches kann die Performance negativ beeinflussen, wenn diese später wieder neu aufgebaut werden müssen. Wer sein System regelmäßig von überflüssigem Ballast befreien möchte, findet in BleachBit ein leistungsfähiges, quelloffenes Werkzeug.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Was ist Mission Center?

Falls ihr Mission Center noch nicht kennt: Die Anwendung erlaubt es euch, verschiedene Systemressourcen wie CPU, Arbeitsspeicher, Datenträger, Netzwerk und GPU in Echtzeit zu überwachen. Dabei punktet sie mit einer schicken Oberfläche auf Basis von GTK4 und Libadwaita – also perfekt für aktuelle GNOME-Desktops. Besonders gefällt mir der Fokus auf Übersichtlichkeit und Performance: Alle Graphen werden hardwarebeschleunigt gerendert, was die CPU-Belastung minimiert.

Ein paar Highlights der Grundfunktionen:

• Überwachung der CPU-Auslastung pro Kern oder Thread
• RAM- und Swap-Nutzung, inkl. Speicherverteilung
• Datenträger- und Netzwerkaktivität, inkl. Schnittstelleninformationen
• GPU-Auslastung (über NVTOP), inklusive Video-Encoding/Decoding
• Anzeige laufender Prozesse und deren Ressourcenverbrauch
• Kompakte Übersicht für eine reduzierte Ansicht

Was ist neu in Version 1.0?

Mit dem 1.0-Release bekommt Mission Center nicht nur ein rundes Versionsnummern-Upgrade, sondern auch eine Menge sinnvoller Verbesserungen. Die wichtigste: Die Anwendung ist spürbar reaktionsschneller geworden und aktualisiert ihre Anzeigen jetzt deutlich präziser im Takt.

SMART-Daten dank UDisks-Integration

Mission Center 1.0 nutzt jetzt das verbreitete UDisks-Backend, um euch detaillierte Informationen zu euren Festplatten und SSDs zu liefern. Wenn eure Laufwerke SMART (Self-Monitoring, Analysis and Reporting Technology) unterstützen – was bei aktuellen SATA- und NVMe-Geräten üblich ist – seht ihr unter anderem:

• Temperatur
• Betriebszeit
• Fehlerstatistiken
• und mehr

Außerdem könnt ihr Datenträger direkt auswerfen – mit sinnvoller Fehlermeldung, falls etwas nicht klappt. Diese Integration bringt die Ansicht von Speichermedien innerhalb der App deutlich nach vorn und liefert noch einen gewissen Mehrwert gegenüber anderen Systemmonitoring-Tools.

Netzwerk-Nutzung pro Prozess

Endlich könnt ihr auch sehen, welcher Prozess wie viel Netzwerkverkehr verursacht. Diese Funktion setzt allerdings voraus, dass ihr nethogs installiert habt – unter Arch Linux zum Beispiel geht das mit:

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

Danach wird in der Prozesse-Ansicht eine neue Spalte für die Netzwerkaktivität eingeblendet – sortierbar, versteht sich. In der aktuellen Version 1.0 fehlt an dieser Stelle noch die Übersetzung.

GPU-Monitoring auf dem Raspberry Pi

Besitzer eines Raspberry Pi 4 oder 5 dürfen sich freuen: Die GPU wird nun (vorausgesetzt, der richtige Kernel ist installiert) über NVTOP erkannt und überwacht. Voraussetzung ist allerdings mindestens Kernel 6.12 mit entsprechender Unterstützung – zum Beispiel in aktuellen Arch- oder Manjaro-Builds für den Pi.

Licht oder Dunkel? Ihr entscheidet!

Nicht jeder mag den systemweiten Dark Mode – oder will vielleicht tagsüber hell und abends dunkel arbeiten. Mission Center 1.0 erlaubt es euch jetzt, unabhängig vom Systemsetting zwischen Light- und Dark-Mode zu wählen.

Außerdem gibt es eine neue Option, die Graphen animiert „gleiten“ zu lassen – optisch hübsch, allerdings mit einem gewissen Performance-Tradeoff. Auf schwächeren Systemen – Mission Center funktioniert beispielsweise auch auf einem Raspberry Pi – solltet ihr die Funktion daher eventuell besser deaktivieren.

Weitere Neuerungen im Überblick

• Anzeige von nicht geladenen Diensten auf der Services-Seite
• Verbesserte Speicherberichterstattung
• Anzeige der Maximal-Bitrate aller Netzwerkinterfaces
• Konfigurierbare Einheiten: Bits vs. Bytes, Basis 2 vs. Basis 10
• Mehr Tastenkombinationen
• Neue Anordnung der Seitenleisten für bessere Übersicht
• Überarbeitete App- und Prozessseite mit mehr Informationen

Mission Center installieren

Mission Center ist freie Software und für verschiedene Linux-Distributionen verfügbar. Die einfachste und empfohlene Installationsmethode ist Flatpak über Flathub:

$ flatpak install flathub io.missioncenter.MissionCenter

Danach könnt ihr die App über den Anwendungsstarter öffnen oder direkt im Terminal mit:

$ flatpak run io.missioncenter.MissionCenter

Wer beispielsweise das GNOME Software Center nutzt, kann das Flatpak natürlich auch per Mausklick auf seinem System einspielen. Alternativ stehen euch folgende Optionen zur Verfügung:

• Snap Store – für Nutzer von Snap-basierten Systemen wie Ubuntu
• AppImage – portabel, keine Installation erforderlich

Der Quellcode ist offen und auf der Projektseite bei GitLab frei einsehbar.

Gute Alternative zum Systemmonitor

Natürlich gibt es unter Linux viele Monitoring-Tools – htop oder glances im Terminal, der GNOME Systemmonitor oder das neue Resources, um nur ein paar zu nennen. Aber Mission Center sticht für mich durch seine Kombination aus moderner Oberfläche, sinnvoller Funktionsvielfalt und guter Performance hervor. Die Nähe zum Windows-Taskmanager-Layout mag polarisieren – ich finde, das ist pragmatisch und benutzerfreundlich gelöst. Vor allem aber: Die App ist vollständig Open Source, aktiv entwickelt und fügt sich perfekt in den modernen GNOME-Desktop ein.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

USB-Sticks auf Fehler prüfen

Im ersten Schritt müsst ihr die Geräte-ID des USB-Sticks oder der Speicherkarte herausfinden. Steckt den Datenträger daher an den Rechner an oder legt die SD-Karte in das entsprechende Lesegerät und gebt im Terminal lsblk ein. Das Kommando listet euch sämtliche am Rechner angeschlossenen Datenträger auf. Anhand der Größe des Datenträgers lässt sich in der Regel die Geräte-ID erkennen. In meinem Beispiel bindet das System meinen 8 GByte großen USB-Stick unter sdc (also /dev/sdc in der vollständigen Syntax) ein. Seid ihr euch nicht sicher, dann zieht den zu kontrollierenden Datenträger ab und wiederholt lsblk. Fehlt sdc in der ausgegebenen Liste, dann habt ihr die richtige Kennung. Alternativ lässt sich die Kennung auch mit grafischen Tools wie der Laufwerksverwaltung von Gnome ermitteln.

$ 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 
[...]

Für die eigentliche Fehlersuche kommt nun das Kommando badblocks aus dem Paket e2fsprogs zum Einsatz, das zur Grundausstattung der üblichen Distributionen gehört. Es kann vorkommen, dass sich Badblocks erst einmal weigert, die Überprüfung zu starten, da das Laufwerk bereits vom System benutzt sei. In der Regel kommt das davon, dass das Betriebssystem den Datenträger automatisch einbindet, sobald ihr den USB-Stick ansteckt. Auf meinem System genügt das Antippen des Icons zum Aushängen des Laufwerks im Dateimanager nicht, ich muss die Geräte-ID des Laufwerks und der dazugehörigen Partitionen gezielt mit umount aushängen.

Achtung: An dieser Stelle muss ich eine Warnung schreiben: Beim Prüfen auf Fehler überschreibt Badblocks sämtliche Daten und Partitionen auf dem angegebenen Datenträger. Stellt daher auf jeden Fall sicher, dass ihr die richtige Geräte-ID an das Kommando übergibt und sichert vor der Aktion wichtige Daten vom betroffenen USB-Stick oder der SD-Speicherkarte. Im Fall der Fälle könnt ihr die Daten nach der Fehlerüberprüfung nicht wiederherstellen.

$ sudo badblocks -wsv /dev/sdc
/dev/sdc wird offensichtlich vom System genutzt; es ist zu unsicher, Badblocks zu starten!
$ sudo umount /dev/sdc*
umount: /dev/sdc: nicht eingehängt.
umount: /dev/sdc2: nicht eingehängt.
umount: /dev/sdc3: nicht eingehängt.

Beim Aufruf von Badblocks übergebt ihr dem Kommando die Parameter -wsv sowie die Geräte-ID. Die Parameter weisen das Programm an, einen destruktiven Schreibtest auszuführen (-w), den Fortschritt anzuzeigen (-s) und generell mehr Informationen auszugeben (-v). Der ausführliche Test beschreibt jeden Block des Datenträgers viermal hintereinander mit unterschiedlichen Mustern (0xaa, 0x55, 0xff und 0x00). Je nach Geschwindigkeit und Kapazität müsst ihr dafür eine längere Zeit einplanen. Die Prüfung des von mir im Beispiel benutzten USB-Sticks nach dem USB-2.0-Standard und 8 GByte Kapazität benötigte über eine Stunde.

$ sudo badblocks -wsv /dev/sdc
Es wird getestet Mit Muster 0xaa:   0.00% erledigt, 0:00 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x55:   0.00% erledigt, 23:47 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0xff:   0.00% erledigt, 47:33 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x00:   0.00% erledigt, 1:11:26 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt

Neben der destruktiven Prüfmethode unterstützt Badblocks einen zerstörungsfreien Lesen+Schreiben-Modus. Diesen aktiviert ihr mit dem Parameter -n anstatt von -w. In dieser Variante sichert Badblocks die Daten des geprüften Speicherblocks zuerst in den Arbeitsspeicher, überschreibt dann den Datenblock mit Zufallsdaten und prüft, ob die Daten korrekt geschrieben werden konnten. Abschließend schreibt Badblocks die Sicherung wieder auf den Datenträger zurück. Auf den ersten Blick erscheint die Prüfroutine schneller, da es nur einen Prüfdurchlauf gibt, in der Praxis braucht das Sichern und Zurückschreiben der bestehenden Daten allerdings wesentlich mehr Zeit. In meinem Beispiel anstatt nur etwas mehr als einer Stunde über 2,5 Stunden.

$ sudo badblocks -nsv /dev/sdc
Es wird nach defekten Blöcken im zerstörungsfreien Lesen+Schreiben-Modus gesucht
Von Block 0 bis 7812607
Es wird nach defekten Blöcken gesucht (zerstörungsfreier Lesen+Schreiben-Modus)
Es wird mit zufälligen Mustern getestet:  94.36% erledigt, 2:35:18 verstrichen. (0/0/0 Fehler)

Gefälschte USB-Sticks ermitteln

Einen Schritt weiter geht das Tool F3 oder etwas länger Fight Flash Fraud. Das Open-Source-Programm prüft ausführlich, ob ein Datenträger wirklich die Kapazität besitzt, die er vorgibt zu haben. Ein Thema, das leider immer noch aktuell ist, besonders wenn man super günstige Angebote aus dem Internet kauft. Um gefälschte USB-Sticks oder SD-Speicherkarten aufzudecken, müsst ihr das Programm aus den Paketquellen installieren. Debian, Ubuntu, Fedora und Co. führen das Konsolenwerkzeug in den offiziellen Repositories, das Paket nennt sich in der Regel f3. Arch Linux führt das Programm nur im AUR, zur Installation braucht ihr daher einen AUR-Helper.

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

Die Kommandos zum Prüfen von USB-Datenträgern lauten nun f3write, f3read und f3probe. Die ersten zwei Befehle müsst ihr in Kombination nutzen. Als Option übergebt ihr den Kommandos jeweils den Mountpunkt des Datenträgers. f3write schreibt nun so lange ein Gigabyte große Dateien auf den eingebundenen Datenträger, bis der Platz ausgeht. Anschließend prüft ihr mit f3read, ob die geschriebenen Daten auch wirklich wieder gelesen werden können. Falls es sich um einen gefälschten USB-Stick oder eine manipulierte SD-Speicherkarte handeln sollte, dann würde f3read korrupte Sektoren ausgeben. Bei dieser Prüfung bleiben alle Daten auf dem Datenträger erhalten, ihr müsst am Ende nur wieder die h2w-Dateien löschen, sonst habt ihr keinen Platz mehr auf dem 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
insgesamt 3907596
drwxr-xr-x  3 toff toff       4096  1. Jan 1970   .
drwxr-x---+ 4 root root         80  7. Dez 16:27  ..
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:35  1.h2w
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:40  2.h2w
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:44  3.h2w
-rw-r--r--  1 toff toff  777592832  7. Dez 18:47  4.h2w
[...]

Ein wenig schneller arbeitet f3probe --destructive. Die Option --destructive ist optional, sie beschleunigt die Aktion jedoch ganz wesentlich. Bei diesem Test beschreibt F3 nur die nötigsten Sektoren und kümmert sich auch nicht um eine Datensicherung. Da die Probe direkt auf die Hardware zugreift, gebt ihr als Parameter nicht den Mountpunkt, sondern die Geräte-ID (hier /dev/sdg) an. Der Test mit meinem 4 GByte großen USB-2.0-Stick dauert so nur ein wenig mehr als sieben Minuten. Habt aber bei dieser Prüfung wieder im Hinterkopf, dass die Routine sämtliche Datenblöcke auf dem Datenträger überschreibt.

$ 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

Sowohl Badblocks als auch F3 helfen beim Analysieren von Fehlern auf Datenträgern. Bei der Prüfung müsst ihr allerdings immer ein wenig Zeit mitbringen. Die ausführliche Analyse eines 8 GByte großen USB-Sticks kann schon mal zwei Stunden dauern, besonders wenn bei der Prüfung die Daten erhalten bleiben sollen und der USB-Stick nur mit dem langsamen USB-2.0-Protokoll arbeitet. Danach könnt ihr aber davon ausgehen, dass der USB-Stick oder die SD-Speicherkarte auch wirklich funktionieren und die Kapazität besitzen, die auf dem Aufdruck steht.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Nutzer bekommen das Upgrade nun nicht automatisch auf den RasPi gespielt. Das Upgrade muss man von Hand einleiten. Dabei spielt das System nicht nur einen neuen Linux-Kernel auf die Speicherkarte, sondern alle bis dahin aufgelaufenen Neuerungen aus dem Open-Source-Universum rund um GNU/Linux. Für Nutzer des Raspberry Pi 4 oder des Compute Module 4 mit dem aktuellen Chipsatz (zu erkennen an der auf dem Chipsatz aufgedruckten Endung C0T) bedeutet das sogar ein wenig mehr Geschwindigkeit, da das System damit ganz offiziell mit 1,8 GHz laufen darf. Wie bei einem Distributions-Upgrade allerdings üblich sollte man vor der Aktion ein Backup starten.

System- und Firmware-Upgrade

In meinem kleinen Heimnetz läuft ein Raspberry Pi 3 als kleine eierlegende Wollmilchsau. Der Mini-Rechner filtert mittels PiHole Anzeigen aus dem Datenstrom. Er tunnelt via WireGuard einen sicheren Zugang via VPN durch das Internet ins eigene LAN. Zudem macht mein Raspberry Pi einen steinalten Canon-Scanner netzwerkfähig. Von daher sind bei diesem System einige Dienste eingerichtet und das System an mehr als einer Stelle individuell konfiguriert. Ich war daher skeptisch, ob das Upgrade ohne Komplikationen durchläuft und habe erst einmal ein paar Wochen abgewartet, bis etwaige Schwierigkeiten im Upgrade-Prozess ausgebügelt werden konnten.

### Bestehende Installation auf aktuellen Stand bringen:
$ sudo apt update
$ sudo apt full-upgrade
$ sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
[...]
 *** Backing up modules 5.10.63-v7+
#############################################################
WARNING: This update bumps to rpi-5.10.y linux tree
See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=288234
'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer or if you want to help the testing effort
and are comfortable with restoring if there are regressions.

DO NOT use 'rpi-update' as part of a regular update process.

##############################################################
Would you like to proceed? (y/N)

Im oben aufgeführten ersten Schritt solltet ihr die bestehende Installation des Raspberry Pi OS auf einen aktuellen Stand bringen. Ich selbst arbeite auf meinem RasPi ohne grafische Oberfläche, logge mich daher via SSH auf dem System ein. Alternativ könnt ihr das Upgrade natürlich aber auch unter der grafischen Oberfläche des Systems ausführen. Der letzte Schritt sudo rpi-update ist optional: Er bringt die direkt auf dem Raspberry Pi installierte Firmware auf den neusten Stand. Wie immer bei solchen Firmware-Updates ist hier Vorsicht angebracht. Theoretisch könnt ihr damit das System in das Nirvana schicken, auf der anderen Seite bügelt solch ein Update aber auch Schwächen aus oder schaltet neue Funktionen frei.

Upgrade von Buster auf Bullseye

Zur Sicherheit startet ihr das System nach diesem Upgrade einmal durch und kontrolliert, ob der Raspberry Pi auch sicher mit Strom versorgt wird. Das komplette Upgrade hat bei mir in etwa zwei Stunden gedauert, während dieser Zeit sollte der Strom auf keinen Fall ausfallen. Loggt euch nun wieder in das System ein und erstellt zunächst eine Sicherheitskopie der für die Paketverwaltung zuständigen Konfigurationsdatei /etc/apt/sources.list. Das nächste Kommando im folgenden Listing tauscht dann jede Erwähnung von buster gegen bullseye innerhalb der Datei. Alternativ könnt ihr diesen Schritt natürlich auch mit einem Texteditor erledigen.

### Upgrade auf Raspberry Pi OS Bullseye einspielen:
$ sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list
$ sudo apt update
[...]
Reading state information... Done
429 packages can be upgraded. Run 'apt list --upgradable' to see them.
$ sudo apt full-upgrade

Danach lasst ihr mit sudo apt update die Paketquellen neu einlesen und startet abschließend mit dem sudo apt full-upgrade den eigentlichen Upgrade-Prozess, der auf meinem System über 300 MByte an neuen Paketen in das System spült. Das Upgrade läuft mehr oder minder automatisch durch, allerdings informiert die Paketverwaltung zwischendurch über eine Reihe von Neuerungen, die ihr mit [Q] quittieren müsst. Sind wie bei mir Dienste installiert, fragt das Upgrade zudem im weiteren Verlauf ab, ob ihr die Dienste während des Upgrade-Prozesses ohne Nachfrage neu starten möchtet — in der Regel könnt ihr das erlauben.

Kritisch wird es bei Nachfragen wie hier im nachfolgenden Bild. In diesem Fall registriert die Paketverwaltung eine Änderung an der Konfigurationsdatei /etc/default/useradd. Ihr habt nun die Wahl: Mit [Y] das unveränderte Original des Entwicklers zu übernehmen und somit eure eigenen Änderungen zurückzusetzen oder mit [N] eure Version der Konfiguration zu behalten und somit eventuell Neuerungen des Dienstes zu verpassen. Am besten schaut ihr euch mit [D] den Unterschied zwischen beiden Versionen an und entscheidet dann von Fall zu Fall, was zu tun ist. Ganz ohne Wissen über die betroffenen Dienste kann es hier allerdings zu ein paar kniffligen Situationen kommen. Ich für meinen Teil übernehme gerne die Version der Paketentwickler und passe meine Konfiguration danach wieder von Hand an.

Auf meinem Raspberry Pi 3 mit einer Reihe von Diensten hat das System in etwa zwei Stunden an dem Upgrade gearbeitet — allerdings war ich zwischendurch immer wieder mal nicht am Platz, das Upgrade hat dadurch immer mal wieder auf meine Eingaben gewartet. Nach der erfolgreichen Installation von Raspberry Pi OS Bullseye meldet das System am Ende den Wunsch nach einem Neustart an. Startet daher den Raspberry mit dem Kommando sudo reboot einmal neu und meldet euch wieder am System an. Als letzten Schritt kontrolliert ihr, ob das System nun wirklich mit Bullseye läuft und entfernt nicht mehr benötigte Pakete aus dem System. Danach ist euer Raspberry Pi auf dem neusten Stand und wieder bereit für seine Aufgaben im Netz.

$ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
[...]
$ sudo apt autoremove
[...]
0 upgraded, 0 newly installed, 40 to remove and 0 not upgraded.
After this operation, 173 MB disk space will be freed.

Kleiner Tipp am Ende: Wie eingangs angesprochen dürfen die aktuell gefertigten Raspberry Pi 4 und Compute Module 4-Platinen (mit der Kennung C0T am Ende der aufgedruckten CPU-Kennzeichnung) nun ganz offiziell mit einer Taktrate von 1,8 GHz arbeiten. Damit die CPU jedoch überhaupt so hoch taktet, müsst ihr in der Datei /boot/config.txt die Zeile arm_freq=1800 eintragen. Ansonsten habt ihr bis zur nächsten großen Änderung am System wieder ein wenig Zeit. Das nächste große Update steht analog zum Release-Zyklus von Debian in etwa zwei Jahren an, die Basis bildet dann Debian 12 „Bookworm“.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Die Installation des Programms ist inzwischen nicht mehr sonderlich schwer. Wie schon ein schneller Blick auf Repology zeigt, führen viele aktuelle Distributionen die Anwendung in ihren offiziellen Paketquellen. Der Paketname gleicht in der Regel dem Namen des Programms: Ein mit administrativen Rechten ausgeführtes apt install bpytop, pacman -S bpytop oder dnf install bpytop genügt also. Zahlreiche Hinweise zur Installation liefert auch die GitHub-Seite des Entwicklers. Optional lässt sich das Programm auch über den Python-Package-Manager PyPI installieren, dann erhält man auf jeden Fall die gerade neuste Version, auch wenn die Paketverwaltung der genutzten Distribution nicht auf dem aktuellen Stand ist.

Nach der Installation ruft ihr das Programm aus dem Terminal heraus mit dem Kommando bpytop auf. Eine kurze Animation zeigt an, dass zum Betrieb alles Nötige installiert ist. Hier wartet vielleicht noch gleich eine Baustelle auf euch: Damit Bpytop die Temperaturen des Systems auslesen und dann rechts oben neben der Auslastung der Prozessorkerne anzeigen kann, müsst ihr die LM-Sensors einrichten. Je nach Distribution geht das immer ein wenig anders. Entsprechende Anleitungen finden sich in den Dokumentationen der von euch genutzten Distribution, hier etwa für Ubuntu oder Arch Linux.

Unter Arch Linux oder Manjaro spielt ihr via sudo pacman -S lm_sensors die Sensors-Tools ein und führt dann das Kommando sudo sensors-detect aus, das euer System ausführlich analysiert. Es erscheint dabei eine ganze Reihe von Abfragen, die ihr im Normalfall einfach mit einem Druck auf [Eingabe] beantworten könnt. Am Ende schreibt das Tool auf Wunsch einen Eintrag in die Konfigurationsdatei /etc/conf.d/lm_sensors und startet dann automatisch den Dienst lm_sensors.service. Über das Kommando sensors liefert euer System dann in Zukunft Informationen der integrierten Temperatursensoren und Lüfter. Bpytop bindet diese Daten dann in die eigenen Anzeigen ein.

$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +71.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:        +68.0°C  (high = +100.0°C, crit = +100.0°C)
Core 1:        +71.0°C  (high = +100.0°C, crit = +100.0°C)
Core 2:        +67.0°C  (high = +100.0°C, crit = +100.0°C)
Core 3:        +68.0°C  (high = +100.0°C, crit = +100.0°C)

dell_smm-isa-0000
Adapter: ISA adapter
fan1:        2540 RPM
fan2:        2536 RPM
[...]

Danach sollte Bpytop komplett einsatzbereit sein: In der Übersicht schaltet ihr mit einem Druck auf [M] zwischen den verschiedenen Darstellungen um. Via [Esc] oder [Umschalt]+[M] öffnet ihr einen Dialog, der eine Hilfe und die Optionen anzeigt, oder das Programm gleich beendet und aufs Terminal zurückgeht (optional direkt über [Strg]+[C]). In den Einstellungen ändert ihr das Theme oder deaktiviert die beim Start angezeigte Initialisierung (Show init auf False). Da Bpytop auf „richtige“ grafische Elemente verzichtet, funktioniert das Tool auch via SSH. Etwa auf einem Raspberry Pi, auf dem ihr das Raspberry Pi OS nur in der abgespeckten Variante ohne grafische Desktopumgebung installiert habt.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Sudoedit, das bessere sudo $editor

Das gilt nicht nur in einer grafischen Desktopumgebung, sondern auch für Editoren im Terminal. Wir rufen üblicherweise nano, vi, emacs und Co. mittels sudo nano /was/auch/immer komplett mit Root-Rechten auf. Dadurch müssen wir darauf vertrauen, dass sich der Editor nicht auf irgendeine Art und Weise missbrauchen lässt. Wenn man bedenkt, welche Funktionsfülle Vi oder Emacs mitbringen, birgt das Vorgehen durchaus ein Gefahrenpotential. Daher gibt es bereits seit 2004 mit sudoedit bzw. sudo -e ein Kommando, das dieses Problem umschifft.

$ sudo -e /etc/hosts
$ sudoedit /etc/hosts

Dabei kopiert Sudo die zu bearbeitende Datei erst einmal in ein temporäres Verzeichnis (unter Arch Linux nach /var/tmp), öffnet die Kopie dann im Kontext des Benutzers im Editor und schiebt die temporäre Datei dann nach dem Schließen des Editors wieder an die ursprüngliche Stelle. Auf diesem Weg muss man den Editor selbst und damit alle mit angezogenen Bibliotheken nicht mehr mit Root-Rechten ausführen. Nur für das Kopieren der Dateien braucht es die administrativen Rechte.

$ VISUAL=gedit sudoedit /etc/hosts
$ EDITOR=nano sudoedit /etc/hosts

Mit den Umgebungsvariablen $VISUAL und $EDITOR lässt sich dem Kommando der gewünschte Editor mit auf den Weg geben, wobei $EDITOR für einen einfachen Editor wie etwa Nano oder Joe steht und $VISUAL mit einem Brocken wie Emacs oder Vi (oder grafischen Editoren wie Gedit oder Kate) belegt werden sollte — Sind beide Variablen definiert, zieht Sudo $VISUAL dem einfachen $EDITOR vor. Ich definiere „meine“ Editoren daher in der ~/.bashrc (den einfachen Editor) sowie in der ~/.xprofile (mit Gedit einen Editor in der GUI). Somit muss ich dann zum Bearbeiten einer Systemdatei nur noch sudoedit /foo/bar eingeben und öffne die Datei dann automatisch im „passenden“ Editor.

### Die Umgebungsvariablen $EDITOR und $Visual kann man beispielsweise
### über die ~/.bashrc oder 
$ grep EDITOR ~/.bashrc
export EDITOR=/usr/bin/joe
$ grep VISUAL ~/.xprofile
export VISUAL=/usr/bin/gedit
### Je nachdem ob man sich in einer grafischen Umgebung befindet, oder
### in einem virtuellen Terminal, startet sudoedit den Terminal-Editor
### Joe oder Gedit.
$ sudoedit /etc/hosts

Sudoedit gibt es nun schon seit 2004, aber kaum jemand nutzt diese Methode: Das Wiki der Ubuntuusers erwähnt das Kommando zum Beispiel mit keinem einzigen Wort und auch im Arch Wiki findet sich Sudoedit nur auf einer einzigen Unterseite — Damit ignorieren die in meinen Augen zwei besten Dokumentationen rund um Linux Sudoedit bisher fast komplett. In Sachen Root-Rechte in der grafischen Desktopumgebung hat mich allerdings ein aktueller Blogbeitrag von KDE-Entwickler Martin Grässlin auf etwas Neues gebracht: Der Files-Dateimanager (aka Nautilus) beherrscht seit der Version 3.22 dank einer Neuerung in Gvfs (dem Gnome virtual file system) einen Administrator-Modus, der ähnlich wie Sudoedit funktioniert.

Root-Rechte für Files aka Nautilus

Im Gnome-Dateimanager kann man ja mit [Strg]+[L] eine Adresszeile öffnen, über die sich Pfade eintippen lassen oder über die man durch Eingabe von smb://server/freigabe oder ssh://username@example.com Daten von entfernten Rechnern direkt in den Dateimanager einbinden kann. Mithilfe von aktuellen Entwicklungen in Gvfs-admin und Polkit gibt es nun aber auch eine Art Admin-Modus, diesen erreicht ihr über die Eingabe von admin:///pfad/zu/verzeichnis oder einfach nur admin:// ohne eine Pfadangabe. Über eine Maske fordert der Dateimanager danach eure Root-Rechte an und leitet euch entweder in das Wurzelverzeichnis des Systems oder den angegebenen Ordner weiter.

In diesem Modus könnt ihr beispielsweise nach /etc navigieren und dann die Hosts-Datei /etc/hosts in Gedit öffnen, bearbeiten und wieder abspeichern (mit abermaliger Eingabe eures Passworts). Dasselbe funktioniert mit allen anderen Konfigurationsdateien, die man mal schnell an die eigenen Wünsche anpassen möchte. Ihr könnt auch Verzeichnisse oder Dateien in geschützten Ordnern wie /, /etc oder /usr/local/bin anlegen, diese dann verschieben, wieder löschen oder die Benutzerrechte ändern. Sinnlos schalten und walten lässt euch Files jedoch in der Regel nicht: Dateien und Ordner, die dem Root-User gehören, die User der Root-Gruppe aber nur lesen und/oder ausführen dürfen (also Dateien und Ordner mit der Zuordnung root:root und den Rechten 644 oder 755) erscheinen mit einem Schloss-Symbol. Diese lassen sich dann beispielsweise nicht löschen oder ausschneiden.

In Sachen Root-Rechte in KDE wird sich demnächst einiges ändern: Martin hat in seinem Posting angekündigt, dass die KDE-Editoren Kate und Kwrite sich in Zukunft nicht mehr direkt mit Root-Rechten öffnen lassen. Stattdessen informieren die Programme, wie der User die gewünschte Datei mittels sudoedit in den ohne Root-Rechte gestarteten Editor bekommt. Dies wird mit Sicherheit den Workflow zahlreicher User beeinträchtigen (und wie die Kommentare schon zeigen, für Unmut in der KDE-Community sorgen), allerdings ist dieser Schritt zum Beispiel in Bezug auf Wayland sowieso überfällig.

Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit. Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.

Langfristig wäre dann das Ziel, dass KIO und PolicyKit die eigentliche Arbeit übernehmen. So könnte man die gewünschten Dateien im Editor öffnen, dann über Polkit „beweisen“, dass man Root-Rechte auf dem System hat, und dann die gewünschten Aktionen direkt über den Dateimanager oder den Editor durchführen. Das Ganze würde transparent im Hintergrund funktionieren, ohne dass man sich verrenken müsste. Wie das Ganze am Ende aussieht, gibt der Blog-Artikel von Martin noch nicht her. Im KDE-Bugtracker gibt es jedoch bereits einen entsprechenden Eintrag. Dieser stammt allerdings bereits von 2009 und bekommt hoffentlich durch die aktuelle Entwicklung ein wenig Leben eingehaucht.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

$ mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=3991400k,nr_inodes=997850,mode=755)
[...]
/dev/sdb1 on /home type ext4 (rw,relatime,data=ordered)
[...]
/etc/autofs/auto.misc on /misc type autofs (rw,relatime,fd=6,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect)
-hosts on /net type autofs (rw,relatime,fd=12,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect)
/etc/autofs/auto.nas on /mnt/nas type autofs (rw,relatime,fd=18,pgrp=1207,timeout=60,minproto=5,maxproto=5,indirect)
//192.168.178.79/daten on /mnt/nas/daten type cifs (rw,relatime,vers=1.0,cache=strict,username=me,domain=NAS,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.178.79,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
[...]

Zur Ausgabe von Laufwerksinformationen bietet sich jedoch als Alternative zu mount das Kommando findmnt an. Es steckt schon seit geraumer Zeit im Paket mount und findet sich in der Regel von Haus aus auf dem System. Allerdings nutzt kaum jemand das kleine Programm, im Forum von ubuntuusers.de wird es beispielsweise nur in ein Dutzend Threads erwähnt. Ohne weitere Optionen gibt findmnt einen Verzeichnisbaum mit der Geräte-ID, dem Dateisystemtyp und den Mount-Optionen aus. Bei Bedarf kann man die Ausgabe nach Mount-Punkten oder beispielsweise nach Dateisystemarten filtern.

$ findmnt
TARGET                           SOURCE      FSTYPE          OPTIONS
/                                /dev/sda1   ext4            rw,relatime,data=ordered
├─/proc                          proc        proc            rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc     systemd-1   autofs          
[...]
├─/tmp                           tmpfs       tmpfs           rw,nosuid,nodev
├─/home                          /dev/sdb1   ext4            rw,relatime,data=ordered
├─/misc                          /etc/autofs/auto.misc
│ autofs          rw,relatime,fd=6,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect
├─/net                           -hosts      autofs          rw,relatime,fd=12,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect
└─/mnt/nas               /etc/autofs/auto.nas
  autofs          rw,relatime,fd=18,pgrp=1207,timeout=60,minproto=5,maxproto=5,indirect
  ├─/mnt/nas/daten       //192.168.178.79/daten
  │ cifs            
[...]

$ findmnt /home
TARGET SOURCE    FSTYPE OPTIONS
/home  /dev/sdb1 ext4   rw,relatime,data=ordered
$ findmnt -t cifs
TARGET SOURCE FSTYPE OPTIONS
/mnt/nas/daten //192.168.178.79/daten cifs rw,relatime,vers=1.0,cache=strict,[...],addr=192.168.178.79,un
/mnt/nas/homes //192.168.178.79/homes cifs rw,relatime,vers=1.0,cache=strict,[...],addr=192.168.178.79,un
[...]

Der Unterschied zwischen den Ausgaben beider Kommandos wird am besten über einen Screenshot verdeutlicht. Während man mit mount am besten gleich nach einem bestimmten Eintrag per mount | grep foo filtert, erhält man mit findmnt einen übersichtlich formatierten Verzeichnisbaum, den man ohne umständliche Pipes sofort im Blick hat. Zusätzlich könnte man mit etwa findmnt --poll --mountpoint /foo/bar gezielt einen Mountpunkt überwachen lassen und in einem Skript Aktionen auslösen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Das Problem lässt sich wohl auf vielen Linux-Systemen (ich habe Arch und Ubuntu 16.04 getestet) nachvollziehen, auf denen Calibri als Font installiert wurde. Ein weiteres Beispiel für das schlechte Rendering dieser Schrift im System wäre etwa die finnische Nachrichtenseite Uusi Suomi — Nein, Finnisch gehört nicht gerade zu den Sprachen, die ich fließend spreche, die Seite war jedoch in einem Bugreport zum Thema als weiteres Beispiel verlinkt. Auch hier erscheint die Schrift in weiten Teilen sehr krakelig. Alternativ könnt ihr auch in LibreOffice ein Writer-Dokument öffnen und Calibri als Font einstellen. Auch hier sollte das Problem schnell erkennbar sein.

Krakelige Darstellung von Bitmap-Fonts

Die krakelige Schriftdarstellung tritt nun bei allen Fonts auf, die Bitmap-Schriften enthalten. Dazu zählt nicht nur der wohl am häufigsten auftretende Fall Calibri, sondern auch andere Microsoft-Schriften wie etwa Cambria (seit Windows Vista und Microsoft Office 2007) oder Monaco (stammt aus OS X). Unter Linux lässt sich der Gebrauch dieser Bitmap-Schriften nun aber recht leicht abstellen. Dazu müsst ihr die Datei /etc/fonts/conf.avail/20-no-embedded.conf mit Root-Rechten anlegen und den Inhalt aus folgendem Listing einfügen. Damit die Einstellung aktiv wird, erstellt ihr am Ende einen Symlink der Datei nach /etc/fonts/conf.d/.

$ sudo nano /etc/fonts/conf.avail/20-no-embedded.conf

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <match target="font">
    <edit name="embeddedbitmap" mode="assign">
      <bool>false</bool>
    </edit>
  </match>
</fontconfig>

$ sudo ln -s /etc/fonts/conf.avail/20-no-embedded.conf /etc/fonts/conf.d/

Euer System sollte die Konfiguration direkt aufgreifen, ihr müsst lediglich die gewünschten Anwendungen komplett neu starten — Zur Not loggt ihr euch einfach einmal aus der Desktopoberfläche aus und gleich wieder neu ein. Alternativ zum beschriebenen Vorgehen packt ihr das Listing ohne Root-Rechte in das Homeverzeichnis eures Benutzers nach ~/.config/fontconfig/conf.d/20-no-embedded.conf. Allerdings gilt die Einstellung dann nur für euren User, sodass andere Benutzer wieder über das schlechte Rendering der Schrift klagen werden.

Nach Deaktivieren der Bitmap-Fonts

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Netdata ist freie Software und wird aktuell sehr aktiv vorangetrieben. Das Projekt gehört seit Wochen zu den Trending-Repos auf Github. Aktuell lässt es sich jedoch noch nicht aus den Paketquellen der gängigen Distributionen installieren. Anwender mit Arch-Linux auf dem Rechner können es jedoch aus dem AUR relativ leicht einspielen (Wer der Entwicklung folgen möchte, kann alternativ auf die Git-Variante zurückgreifen). Anschließend kann man den Dienst entweder per Hand starten oder ihn per Systemd automatisch mit dem Rechner laden lassen. Für Debian/Ubuntu beziehungsweise Centos/Redhat gibt es auf der Homepage eine ausführliche Installationsanleitung. Ich habe sie auf einem RasPi mit Raspbian Jessie getestet.

Netdata unter Arch Linux installieren

$ pacaur -S netdata
### Zum Testen starten
$ sudo netdata   ### (Mit [Strg]+[C] abbrechen
### Als Dienst einrichten
$ sudo systemctl enable netdata.service
$ sudo systemctl start netdata.service

Netdata unter Debian/Ubuntu/Raspbian installieren

$ sudo apt install zlib1g-dev gcc make git autoconf autogen automake pkg-config
$ git clone https://github.com/firehol/netdata.git --depth=1
$ cd netdata
$ sudo ./netdata-installer.sh
[...]
Uninstall script generated: ./netdata-uninstaller.sh

Auf einem Raspberry Pi mit Raspbian meldete das Installationsskript am Ende noch, dass dem RasPi-Kernel Kernel Samepage Merging (alternativ kernel.org dazu) oder kurz KSM fehlen würde. Diese Funktion versucht identische Memory Pages im Arbeitsspeicher zu finden und diese zusammenzuführen, der Entwickler spricht davon, dass sich mit der Funktion etwa 30 Prozent des von Netdata in Anspruch genommenen Arbeitsspeichers einsparen ließen. Ohne den RasPi-Kernel neu zu bauen, wird sich das jedoch nicht lösen lassen. Aktuell gibt es bereits einen Bugreport zu diesem Thema, große Resonanz gab es bisher jedoch nicht.

I see you do not have kernel memory de-duper (called Kernel Same-page
Merging, or KSM) available.

To enable it, you need a kernel built with CONFIG_KSM=y

If you can have it, you will save 20-60% of netdata memory.

Netdata erreicht ihr nach der Installation (unter Debian und den diversen Debian-Derivaten startet der Dienst nach dem Ausführen der Installationsroutine automatisch) auf Port 19999 unter beispielsweise http://127.0.0.1:19999 oder alternativ der IP beziehungsweise unter dem Namen des jeweiligen Rechners, also etwa http://raspberrypi:19999. Das Programm muss nicht weiter eingerichtet werden, es zeigt sämtliche Informationen an, die es aus dem System extrahieren kann. Über die Seitenleiste springt ihr direkt zu den einzelnen Übersichten. Die Graphen könnt ihr per Drag&Drop verschieben, oder mittels gedrückter Shift-Taste Ausschnitte vergrößern. Auf Smartphones oder Tablets funktionieren Pinch&Zoom-Gesten.

Insgesamt wirkt Netdata wirklich durchdacht und sehr gut umgesetzt, besonders die Installation fällt leicht, da weder ein Webserver und Datenbanken aufgesetzt noch irgendwelche Konfigurationen vorgenommen werden müssen: Netdata ist quasi eine Fire-and-Forget-Lösung für Systemmonitoring. Das Programm selbst nimmt dabei relativ wenig Systemressourcen in Anspruch, sodass es auch auf einem Raspberry Pi gut funktioniert. Kleiner Tipp am Rande: Netdata gibt es auch für Synology-NAS-Systeme: Auf diesen muss man das Programm aus der Syno-Community installieren und dann noch ein paar Abhängigkeiten von Hand auflösen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.