Mit Version 16 springt openSUSE gewissermaßen in ein neues Zeitalter. Eine Weile war unklar, in welcher Form und auf welcher Basis openSUSE (überhaupt) weitergeführt wird. Letztlich haben sich die Entwickler zu einem pragmatischen Ansatz entschieden: Auch mit Version 16 bleibt openSUSE Leap eine »normale« Distribution mit Paket-Updates (kein Immutable System mit atomaren Updates) — so wie der große Enterprise-Bruder SLES 16. Für diesen Artikel habe ich einen ersten Blick auf die Distribution geworfen.
Die Aufgabenstellung ist sehr speziell, und dementsprechend wird dieser Beitrag vermutlich nur wenig Leute interessieren. Aber egal: Ich habe mich drei Tage damit geärgert, vielleicht profitieren ein paar Leser von meinen Erfahrungen …
Die Zielsetzung ist bereits in der Überschrift beschrieben. Ich besitze einen Mini-PC mit AMD 8745H-CPU und 32 GiB RAM. Die CPU enthält auch eine integrierte GPU (Radeon 780M). Auf diesem Rechner wollte ich das momentan sehr beliebte Sprachmodell gpt-oss-20b ausführen. Dieses Sprachmodell ist ca. 11 GiB groß, umfasst 20 Milliarden Parameter in einer etwas exotischen Quantifizierung. (MXFP4 wurde erst 2024 standardisiert und bildet jeden Parameter mit nur 4 Bit ab. Die Besonderheit besteht darin, dass für unterschiedliche Teile des Modells unterschiedliche Skalierungsfaktoren verwendet werden, so dass die Parameter trotz der wenigen möglichen Werte einigermaßen exakt abgebildet werden können.)
Das Sprachmodell wird von der Firma OpenAI kostenlos angeboten. Die Firma gibt an, dass die 20b-Variante ähnlich gute Ergebnisse wie das bis 2024 eingesetzt kommerzielle Modell o3-mini liefert, und auch KI-Experte Simon Willison singt wahre Lobeshymnen auf das Modell.
PS: Ich habe alle Tests unter Fedora 42 durchgeführt.
Debian 13 »Trixie« ist fertig. Mehrere RC-Releases sind bei mir schon ein paar Monate im Einsatz — bislang ohne jedes Problem. Insofern sieht es so aus, als würde Debian seinem Ruf für stabile, ausgereifte Releases einmal mehr gerecht. Dieser Artikel fasst in kompakter Form die wichtigsten Neuerungen zusammen.
CachyOS ist das Kunststück gelungen, die Spitze der distrowatch-Charts zu erklimmen. Über diesen Meilenstein haben zuletzt die meisten IT-Medien berichtet. Das Ranking spiegelt zwar nicht die Anzahl der Installationen wider (diese Zahlen kennt distrowatch nicht), wohl aber das Interesse, das durch Seitenzugriffe gemessen wird. Und das Interesse an CachyOS ist aktuell hoch.
Warum? CachyOS ist eine relativ neue Distribution auf der Basis von Arch Linux. CachyOS verfügt aber über ein verhältnismäßig komfortables grafisches Installationsprogramm, verwendet einen eigenen, auf Geschwindigkeit optimierten Kernel und eigene Paketquellen, deren Programme ebenfalls im Hinblick auf optimale Geschwindigkeit kompiliert sind (mit mehreren Varianten optimiert je nach CPU-Generationen). CachyOS implementiert interessante Features per Default: btrfs-Dateisystem mit komprimierten Subvolumes und Snapper, ufw-Firewall, systemd-boot, fish als Shell etc. Die CachyOS-spezifischen Details sind im Wiki gut dokumentiert.
In Summe ergibt das ein schnelles, modernes und sympathisches Linux, das ganz offensichtlich den Zeitgeist trifft. Höchste Zeit also, dass ich auch in meinem Blog etwas dazu schreibe :-)
Auf meinen privaten Linux-Installationen gehe ich Flatpak- und Snap-Paketen meistens aus dem Weg. Aber damit mir keiner vorwirft, ich sei zu altmodisch, mache ich hin und wieder doch die Probe auf Exempel: Wie gut funktionieren die neuen Paketsysteme? Meine Testkandidaten waren diesmal Fedora 42 sowie zwei Ubuntu-Installationen (25.04 und 25.10 daily), jeweils auf x86_64-Rechnern.
Wenn Sie meinen vorigen Blogbeitrag über Hetzner-Cloud-Benchmarks gelesen haben, ist Ihnen vielleicht aufgefallen, dass ich Alma Linux 10 in einer Hetzner-Cloud-Instanz ausgeführt habe, um dort Geekbench-Tests auszuführen. Das war nicht so einfach: Hetzner bietet Alma Linux 10 noch nicht als Installations-Image an. (Update 3.7.2025: mittlerweile schon, sowohl AlmaLinux 10 als auch Rocky Linux 10)
Also habe ich eine neue Instanz zuerst mit Alma Linux 9 eingerichtet und danach mit Elevate ein Update auf Version 10 durchgeführt. Das ist erstaunlich unkompliziert gelungen, obwohl Version-10-Updates eigentlich noch im Beta-Test sind.
Update 10.7.2025: Version-10-Updates werden jetzt offiziell unterstützt (Quelle)
Die zwei günstigsten Angebote in der Hetzner-Cloud sind Instanzen mit zwei CPU-Cores, 4 GB RAM und 40 GB Diskspace: Einmal mit virtuellen ARM-CPU-Cores (»CAX11«), einmal mit virtuellen x86-Cores (»CX22«). Der Preis ist identisch: 3,95 EUR/Monat inkl. USt (für D) plus ein Aufpreis von 0,50 EUR/Monat für eine IPv4-Adresse. Die naheliegende Frage ist: Welches Angebot gibt mehr Rechenleistung? Dieser Frage bin ich an einem verregneten Pfingstsonntag auf den Grund gegangen.
Ein »virtueller CPU-Core« heißt in diesem Zusammenhang, dass auf einem Server mehrere/viele virtuelle Maschinen laufen. Je nach Auslastung kann es sein, dass die für eine virtuelle Maschine vorgesehen CPU-Cores nicht vollständig verfügbar sind. Es gibt auch virtuelle Maschinen mit dezidierten Cores, die immer zur Verfügung stehen — aber die sind natürlich teurer.
Seit einigen Jahren ist CentOS kein produktionstauglicher RHEL-Klon mehr. Wer RHEL produktiv nutzen will, aber nicht dafür bezahlen kann, hat die Qual der Wahl: zwischen AlmaLinux, CentOS Stream (nicht für Langzeitnutzung), Oracle Linux, RHEL via Developer Subscription und Rocky Linux. Ich bin ein wenig zufällig im AlmaLinux-Lager gelandet und habe damit über mehrere Jahre, vor allem im Unterricht, ausgezeichnete Erfahrungen gemacht.
Nach diversen Tests mit der Beta-Version läuft AlmaLinux 10 jetzt nativ auf meinem Mini-PC (AMD 8745H), außerdem die aarch64-Variante in einer virtuellen Maschine auf meinem Mac. Dieser Artikel stellt die neue Version AlmaLinux 10 vor, die am 27. Mai 2025 freigegeben wurde, genau eine Woche nach dem Release von RHEL 10. Die meisten Informationen in diesem Artikel gelten auch für RHEL 10 sowie für die restlichen Klone. Oft beziehe ich mich daher im Text auf RHEL (Red Hat Enterprise Linux), also das zugrundeliegende Original. Es gibt aber auch ein paar feine Unterschiede zwischen dem Original und seinen Klonen.
Seit vielen Jahren verwende ich Let’s Encrypt-Zertifikate für meine Webserver. Zum Ausstellen der Zertifikate habe ich in den Anfangszeiten das Kommando certbot genutzt. Weil die Installation dieses Python-Scripts aber oft Probleme bereitete, bin ich schon vor vielen Jahren auf das Shell-Script acme.sh umgestiegen (siehe https://github.com/acmesh-official/acme.sh).
Kürzlich bin ich auf einen Sonderfall gestoßen, bei dem acme.sh nicht auf Anhieb funktioniert. Die Kurzfassung: Ich verwende Apache als Proxy für eine REST-API, die in einem Docker-Container läuft. Bei der Zertifikatausstellung/-erneuerung ist Apache (der auf dem Rechner auch als regulärer Webserver läuft) im Weg; die REST-API liefert wiederum keine statischen Dateien aus. Die Domain-Verifizierung scheitert. Abhilfe schafft eine etwas umständliche Apache-Konfiguration.
Der SSH-Dienst ist ein natürliches Angriffsziel jedes Servers. Klassische Abwehrmaßnahmen zielen darauf aus, den root-Login zu sperren (das sollte eine Selbstverständlichkeit sein) und mit Fail2ban wiederholte Login-Versuche zu blockieren. Eine weitere Sicherheitsmaßnahme besteht darin, den Passwort-Login mit einer Zwei-Faktor-Authentifizierung (2FA) zu verbinden. Am einfachsten gelingt das server-seitig mit dem Programm google-authenticator. Zusätzlich zum Passwort muss nun ein One-time Password (OTP) angegeben werden, das mit einer entsprechenden App generiert wird. Es gibt mehrere geeignete Apps, unter anderem Google Authenticator und Authy (beide kostenlos und werbefrei).
Es gibt verschiedene Konfigurationsoptionen. Ziel dieser Anleitung ist es, parallel zwei Authentifizierungsvarianten anzubieten:
mit SSH-Schlüssel (ohne 2FA)
mit Passwort und One-time Password (also mit 2FA)
Links die App »Google Authenticator«, rechts »Authy«
Diese Website verwendet Cookies nur in minimalem Ausmaß. Es gibt weder Werbung noch Analytic-Funktionen.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
