Welche Probleme löse ich – und für wen?

Thorsten Geppert

Ich werde immer wieder gefragt, was ich eigentlich genau mache. Die kurze Antwort: Ich entwickle Software und administriere Systeme, vornehmlich unter FreeBSD. Die längere Antwort ist dieser Beitrag.

Meine Arbeit bewegt sich im Spannungsfeld zwischen Softwareentwicklung, Infrastruktur und Systemarchitektur. Ich helfe dabei, Systeme zu bauen oder zu stabilisieren, die langfristig funktionieren – technisch sauber, verständlich und wartbar.

Softwareentwicklung: Qualität statt Fließband

In meinen Blog-Artikeln über Softwareentwicklung habe ich viel darüber geschrieben, was in Unternehmen schief läuft: unlesbarer Code, fehlende Architektur, technische Schulden, die niemand mehr anfasst, und ein Fokus auf Prozesse statt auf das Produkt selbst. Das ist keine abstrakte Kritik, sondern Dinge, die ich über viele Jahre hinweg in verschiedenen Unternehmen hautnah erlebt habe.

Daraus folgt, was ich anbiete: saubere, lesbare, wartbare Software. Code, den auch jemand anderes in fünf Jahren noch versteht. Ich habe langjährige Erfahrung in verschiedenen Programmiersprachen – von der systemnahen Programmierung bis hin zu komplexen GUI-Anwendungen mit Qt und wxWidgets. Datenbanken (insbesondere PostgreSQL) gehören ebenso dazu wie Server-Client-Architekturen und Netzwerkprogrammierung.

Wenn du ein Projekt hast, das aus dem Ruder gelaufen ist, das von einer Einzelperson entwickelt wurde und jetzt kaum noch jemand durchblickt, oder das dringend eine saubere Neuarchitektur braucht – dann bin ich die richtige Ansprechperson.

FreeBSD-Administration: Stabil, sicher, durchdacht

FreeBSD begleitet mich seit Version 4, also seit über zwei Jahrzehnten. Ich betreibe eigene Server damit, kenne ZFS mit RAIDz, FreeBSD-Jails, Bhyve, pf, CARP, HAST und die gängigen Netzwerkdienste (DNS, DHCP, NTP, NFS, Samba, LDAP u.v.m.) aus der täglichen Praxis – nicht nur aus der Dokumentation.

Was ich löse: Du brauchst einen stabilen, sicheren Server oder eine skalierbare Serverinfrastruktur unter FreeBSD? Du möchtest Dienste in Jails isolieren? Du hast ein laufendes System, das Pflege oder Erweiterung braucht? Oder du stehst vor einem konkreten Problem, das sich partout nicht lösen lässt? Ich bin mit solchen Situationen vertraut – und finde pragmatische Lösungen.

Für Unternehmen

Falls du als Unternehmen schaust: Ich bringe Softwareentwicklung und Systemadministration zusammen. Ich bin kein Spezialist, der nur eine Schraube dreht, sondern jemand, der Systeme im Ganzen versteht. Ich habe in Firmen gearbeitet, in denen beides gefragt war, und weiß, wie wichtig es ist, dass Entwicklung und Infrastruktur zusammenpassen.

Ich schätze eine Unternehmenskultur, in der Fehler als Lernmöglichkeit begriffen werden, Kompetenzen sinnvoll eingesetzt werden und das Produkt im Mittelpunkt steht – nicht das Verwalten von Tickets. Wenn das auch dein Ansatz ist, sollten wir sprechen (E-Mail: thorsten@tgeppert.de).

Hier meine Referenzen in Kurzform

Thorsten Geppert

Lebenslauf

OpenSource-Projekte

Verschiedenes

  • YouTube-Kanal (mit Themen über Programmierung, FreeBSD und verschiedene andere Dinge)

Ausführlicher Vergleich der BSD-Familie: FreeBSD, OpenBSD, NetBSD und DragonFlyBSD

Thorsten Geppert Schreib einen Kommentar

Inhaltsverzeichnis

  1. Einleitung und Geschichte
  2. Philosophie, Entwicklungsmodell und Lizenzierung
  3. Typische Einsatzszenarien – Wo welches BSD am besten passt
  4. Kernarchitektur im Detail
  1. Derivate, Spezialdistributionen und Ökosystem
  2. Pro‑ und Contra‑Tabellen – Schnellvergleich
  3. Entscheidungshilfe – Welches BSD ist das Richtige für mein Projekt?
  4. Zukünftige Entwicklungen und Roadmaps
  5. Quellen, weiterführende Literatur und Community‑Links

Einleitung und Geschichte

Die BSD‑Familie hat ihre Wurzeln in der Berkeley Software Distribution (BSD), die 1977 von der University of California, Berkeley, als Weiterentwicklung des frühen UNIX‑Systems veröffentlicht wurde. Die ersten öffentlichen BSD‑Versionen (1.0 – 4.3) legten das Fundament für den heute bekannten TCP/IP‑Protokoll‑Stack, der damals noch ein Forschungsexperiment war, heute aber das Rückgrat des Internets bildet.

Im Laufe der 1990er‑Jahre spaltete sich das Projekt in mehrere unabhängige Richtungen:

  • FreeBSD (gegründet 1993) fokussierte sich schnell auf Performance, Stabilität und eine umfangreiche Ports‑Sammlung für Drittsoftware.
  • OpenBSD (ab 1995) verfolgte das Ziel, ein so sicher wie möglich zu sein. Der Name selbst stammt von der Kombination aus „Open“ und „BSD“ und betont Transparenz.
  • NetBSD (1993) wählte den Pfad der Portabilität – das berühmte Motto „runs on anything“ stammt von NetBSD und spiegelt die Unterstützung von über 50 Prozessorarchitekturen wider.
  • DragonFlyBSD (2003) entstand aus einem Fork von FreeBSD 4.8, weil einige Entwickler mit der Entwicklungsgeschwindigkeit und den SMP‑Architekturen unzufrieden waren. Das Ergebnis: ein System, das stark auf Multi‑Core‑Skalierung und ein eigenes Dateisystem HAMMER2 setzt.

Diese unterschiedlichen Wurzeln bestimmen bis heute die Design‑Entscheidungen, das Community‑Verhalten und die Einsatzbereiche der einzelnen Betriebssysteme.

Philosophie, Entwicklungsmodell und Lizenzierung

ProjektZielsetzungEntwicklungsmodellLizenzierung
FreeBSDHoch‑performante Server‑ und Desktop‑PlattformZentralisiertes Kernteam, Commit‑Access über Core‑Team; offene Ports‑Tree-Pflege durch freiwillige MaintainerBSD‑Lizenz (2‑Clause) + CDDL für ZFS (Kompatibilitäts‑Ausnahme)
OpenBSDSicherheit über alles, Code‑Qualität, AuditsKleine, sehr konservative Entwicklergemeinschaft; Ein‑Person‑Commit‑Policy; jede Änderung wird auditiertBSD‑Lizenz (ähnlich der 2‑Clause); kein CDDL, alles rein Open‑Source
NetBSDPortabilität, Sauberkeit des Codes, Unterstützung exotischer HWDezentralisiert, Git‑basiertes Repository; pkgsrc (Quellpaket‑System) wird separat gepflegtBSD‑Lizenz (2‑Clause) – keine zusätzlichen Einschränkungen
DragonFlyBSDSkalierbare SMP‑Leistung, moderne DateisystemeKleines, fokussiertes Kernteam, schnelle Release‑Zyklen (alle 6‑8 Wochen)BSD‑Lizenz (2‑Clause)

Die Lizenzierung ist ein wichtiger Faktor für Unternehmen. FreeBSD enthält den CDDL‑Teil für ZFS, was in manchen Unternehmens‑Compliance‑Szenarien zu Diskussionen führt. OpenBSD, NetBSD und DragonFlyBSD verwenden ausschließlich die klassische BSD‑Lizenz, was ihre Nutzung in proprietären Projekten vereinfacht.

Typische Einsatzszenarien – Wo welches BSD am besten passt

Web‑ und Datenbank‑Server

FreeBSD ist dank ZFS‑Integration, Jails und einer ausgereiften TCP‑Stack‑Optimierung (z. B. TCP‑Fast‑Open, RACK‑Algorithmus) die erste Wahl für große Web‑Farmen. Unternehmen wie Netflix, Yahoo! und GitHub betreiben Teile ihrer Infrastruktur auf FreeBSD. OpenBSD wird eher für sicherheitskritische Front‑Ends eingesetzt, wo die Angriffsfläche minimal sein soll – beispielsweise als Reverse‑Proxy mit pf und httpd.

NetBSD wird selten in klassischen Web‑Umgebungen eingesetzt, findet aber in Embedded‑Gateways (Router, IoT‑Edge‑Devices) Verwendung, weil es auf ARM‑ und MIPS‑Boards läuft. DragonFlyBSD ist besonders attraktiv für Rechenzentren, die hohe Kernzahlen nutzen – das HAMMER2‑Dateisystem bietet native Deduplizierung, was Speicher‑Kosten senkt.

Firewall‑ und Router‑Appliance

pf wurde ursprünglich von OpenBSD entwickelt und später nach FreeBSD portiert. Heute ist pfSense (FreeBSD) und OPNsense (FreeBSD) die führenden Open‑Source‑Firewalls – sie bauen auf pf auf, bieten eine Web‑UI, Plugins für VPN, Captive‑Portal und IDS/IPS. OpenBSD selbst kann dank pf und spamd ebenfalls als reine Firewall dienen, wird aber seltener als eigenständige Appliance eingesetzt, weil es kein integriertes Web‑Frontend hat.

Embedded / IoT

NetBSD ist das klar dominante BSD‑Projekt für Embedded‑Systeme: Es läuft auf Raspberry Pi, BeagleBoard, MIPS‑Router, PowerPC‑Systemen und sogar auf Spielkonsolen. Die Clean‑room‑Entwicklung sorgt für stabile, deterministische Builds, die in der Industrie geschätzt werden. FreeBSD hat ebenfalls ARM‑Support, aber das Footprint ist größer, weshalb es primär in NAS‑Geräten (z. B. TrueNAS) verwendet wird.

Desktop / Workstation

FreeBSD selbst ist nicht primär für Desktop‑Nutzer gedacht, aber Projekte wie GhostBSD und MidnightBSD bieten fertig vorkonfigurierte Desktop‑Umgebungen (GNOME/KDE) mit ein‑Klick‑Installern. NetBSDs NomadBSD ist ein Live‑USB‑System, das persistent bleiben kann. DragonFlyBSD nutzt ebenfalls einen Desktop‑Installer, ist aber stärker auf Server‑Anwendungen ausgerichtet.

Storage‑Appliances und NAS

ZFS‑Integration macht FreeBSD zum bevorzugten Kernel für TrueNAS CORE (ehemals FreeNAS). Dort werden Snapshots, Replikation und RAID‑Z professionell verwaltet. DragonFlyBSD bietet HAMMER2, das ebenfalls Copy‑on‑Write, Snapshots und Deduplizierung unterstützt – ideal für Backup‑Server, die große Datenmengen deduplizieren wollen.

Kernarchitektur im Detail

Dateisysteme und Speicherverwaltung

  1. FreeBSD – ZFS
  • ZFS ist ein Copy‑on‑Write‑Dateisystem, das Datenintegrität durch Checksummen gewährleistet. Es unterstützt Kompression, Deduplizierung, scrubbing und end‑to‑end‑Encryption. In FreeBSD ist ZFS seit Version 9.0 integral und kann als Root‑Dateisystem verwendet werden. Das Zpool‑Modell erlaubt das Kombinieren unterschiedlicher physischer Laufwerke zu einem logischen Speicher‑Pool.
  • Lizenz: ZFS stammt aus dem CDDL‑Open‑Source‑Projekt von Sun/Oracle, das mit der BSD‑Lizenz nicht kompatibel ist – deshalb existiert eine separate Lizenz‑Ausnahme in FreeBSD.
  1. OpenBSD – FFS + Soft‑crypto
  • Das Fast File System (FFS), auch als UFS bekannt, ist das traditionelle BSD‑Dateisystem. OpenBSD hat keine native ZFS‑Unterstützung, jedoch gibt es experimentelle Ports. Für Verschlüsselung nutzt OpenBSD soft‑crypto, ein Kernel‑Framework, das Block‑Device‑Verschlüsselung auf Ebene des Dateisystems ermöglicht (z. B. bioctl -c C für GELI‑Verschlüsselung).
  1. NetBSD – WAPBL und FFS
  • NetBSD verwendet ebenfalls FFS. Das WAPBL (Write‑Ahead‑Physical‑Logging) ist ein leichtgewichtiges Journal, das nur Metadaten‑Updates protokolliert, wodurch ein gutes Gleichgewicht zwischen Performance und Datenintegrität entsteht.
  1. DragonFlyBSD – HAMMER2
  • HAMMER2 ist ein eigens entwickeltes Dateisystem, das Copy‑on‑Write, Snapshots, Deduplizierung und Cluster‑Level‑Mirroring (via hammer2 cluster) unterstützt. Es ist hoch skalierbar und besonders gut für Systeme mit vielen CPU‑Kernen und großen Datenmengen geeignet. Im Vergleich zu ZFS fehlt jedoch die breite Dritt‑Tool‑Unterstützung (z. B. zpool‑Utility).

Netzwerk‑Stack und Sicherheitsfeatures

  • FreeBSD: Der Netzwerk‑Stack ist für hohe Durchsatzraten optimiert (TCP‑Fast‑Open, RACK‑Congestion‑Control). ipfw ist das traditionelle Firewall‑Framework, aber seit FreeBSD 12 gibt es auch pf, das aus OpenBSD stammt. Das bpf-Subsystem (Berkeley Packet Filter) ermöglicht sehr effizientes Packet‑Capturing, das in Intrusion‑Detection‑Systemen genutzt wird.
  • OpenBSD: Der pf‑Firewall‑Engine ist das Herzstück. OpenBSD legt extremen Wert auf Code‑Reviews, Memory‑Safety (z. B. ProPolice, Stack‑Canaries) und Standard‑Hardenings (z. B. sysctl‑Defaults, disable_ipv6, login.conf). OpenBSD ist das Referenzsystem für PF, OpenSSH und LibreSSL, die in vielen anderen Projekten wiederverwendet werden.
  • NetBSD: Unterstützt sowohl ipfilter, ipfw als auch pf (via Port). Der Netzwerk‑Stack ist sehr portabel – das macht NetBSD attraktiv für kleine Router‑Boards.
  • DragonFlyBSD: Hat ebenfalls pf integriert, nutzt aber zusätzlich das Vimage/-Vkernel‑Framework für leichte Isolation von Netzwerk‑Namespaces. Der Netzwerk‑Stack ist nicht ganz so umfangreich wie bei FreeBSD, dafür aber sehr sauber implementiert.

Virtualisierung, Container und Isolationstechniken

SystemContainer‑LösungHypervisorBesonderheiten
FreeBSDJails – OS‑Level‑Container mit eigenen IP‑Stacks, Dateisystem‑Views und Ressourcengrenzen (via rctl).bhyve – moderner Hypervisor, unterstützt VirtIO‑Devices, UEFI‑Boot und KVM‑Kompatibilität.runjail ermöglicht Docker‑Kompatibilität; vmm-Modul für KVM‑Beschleunigung.
OpenBSDKeines (kein jails‑Äquivalent)vmm – leichtgewichtiger Hypervisor, unterstützt KVM‑Kompatibilität.Fokus liegt auf Sicherheit, daher kein Container‑Framework eingebaut.
NetBSDKeines (kein jails‑Äquivalent)Xen, bhyve, hyper‑v (via hv‑Modul).Sehr breite Unterstützung, jedoch weniger gebündelte Tools.
DragonFlyBSDVkernel – leichtgewichtige, eigenständige Kernel‑Instanz für Isolation (ähnlich zu jails aber mit weniger Overhead).–Vkernel ist ideal für Micro‑VMs und Container‑ähnliche Workloads.

Durch die Kombination aus Jails (FreeBSD) und pf (OpenBSD) können Administratoren sehr feinkörnige Sicherheits‑ und Isolation‑Modelle bauen, die sowohl Performance als auch Härtung liefern.

Derivate, Spezialdistributionen und Ökosystem

DerivatBasis‑BSDZielgruppeBesondere Merkmale
GhostBSDFreeBSDDesktop‑Nutzer (GNOME/KDE)Ein‑Klick‑Installer, automatische ZFS‑Root‑Einrichtung, verschlüsselte Benutzer‑Home.
MidnightBSDFreeBSDDesktop & Server‑Einsteigermidnightbsd-install, grafischer Installer, eigene Paketverwaltung (pkgsrc‑basiert).
TrueNAS COREFreeBSDNAS‑ApplianceVollwertige ZFS‑Verwaltung, Web‑UI, VM‑Support, Replikation, Lizenz: CDDL (ZFS) + BSD.
pfSenseFreeBSDFirewall / RouterUmfangreiche Plugins (OpenVPN, IPsec, Captive‑Portal), Web‑UI, kommerzielle Support‑Optionen.
OPNsenseFreeBSDModerne Firewall‑ApplianceModerne Angular‑UI, IDS/IPS (Suricata), Let’s Encrypt‑Integration, regelmäßige Security‑Updates.
NomadBSDNetBSDLive‑USB + Persistent StorageEinfaches Live‑System, persistente Änderungen, kleine Image‑Größe.
OpenBSD‑based ToolsOpenBSDSicherheitstoolsOpenSSH, OpenBGPD, OpenNTPD, LibreSSL, häufig in anderen Distributionen eingebettet.
DragonFlyBSD‑BobDragonFlyBSDServer‑SkalierungMinimalistisches System, fokussiert auf HAMMER2‑Performance, geringer Overhead.

Durch das breite Derivat‑Ökosystem kann ein Unternehmen das für den jeweiligen Anwendungsfall passende Betriebssystem wählen, ohne tief in die Grund‑BSD‑Distribution einsteigen zu müssen.

Pro‑ und Contra‑Tabellen – Schnellvergleich

FreeBSD

ProContra
Riesige Ports‑Datenbank (≈30 k Pakete)Größerer Footprint – weniger geeignet für ressourcenarme Embedded‑Geräte
Native ZFS‑Integration (Snapshots, Dedupl., Verschlüsselung)Lizenz‑Komplexität (BSD + CDDL) kann in Unternehmen zu Compliance‑Fragen führen
Jails – leichte OS‑Container + Ressourcen‑LimitsJails bieten nicht die gleiche Flexibilität wie Docker‑Container (z. B. keine Overlay‑FS)
Sehr gute Netzwerk‑Performance, pf und ipfw verfügbarTeilweise veraltete Netzwerk‑Features im Vergleich zu Linux‑eigenen Technologien

OpenBSD

ProContra
Höchste Sicherheit (Code‑Audits, securebydefault, minimaler Attack‑Surface)Eingeschränkte Treiberunterstützung, besonders bei neuer Hardware
pf‑Firewall‑Engine, die als Referenz giltKein nativer ZFS‑Support (experimentell)
Kleine, kohärente Code‑Basis – einfach zu auditierenKleine Ports‑Sammlung, selteneres Software‑Portfolio
Integrierte Sicherheits‑Tools (OpenSSH, LibreSSL, OpenBGPD)Fokus auf Sicherheit kann zu Lasten von Performance‑Optimierungen führen

NetBSD

ProContra
Laufzeit auf über 50 Architekturen – ideal für Embedded & ForschungsprojekteKleinere Community, weniger kommerzielle Unterstützung
WAPBL‑Journal für geringes Overhead‑LoggingKein nativer ZFS (nur via Ports)
Saubere, modulare Kernel‑Architektur (leicht zu patchen)Fehlende vorgefertigte Server‑Features (z. B. Jails, pf als Standard)
Starke pkgsrc‑Paketverwaltung – plattformübergreifendDokumentation teils lückenhaft, besonders für Anfänger

DragonFlyBSD

ProContra
HAMMER2 – modernes Copy‑on‑Write‑Dateisystem mit Dedupl. und Snapshots
Vkernel – leichtgewichtige Isolation, ideal für Micro‑VMs
Fokus auf SMP‑Skalierung – gut für Server mit vielen Kernen
Schnelle Release‑Zyklen, aktive Entwicklung
Kleinere Community, weniger kommerzielle Unterstützung
HAMMER2 ist weniger verbreitet als ZFS – geringere Tool‑Unterstützung

Entscheidungshilfe – Welches BSD ist das Richtige für mein Projekt?

AnforderungEmpfohlenes BSDBegründung
Maximale Sicherheit (Firewall, Kryptographie, Audits)OpenBSDpf‑Engine, LibreSSL, OpenSSH‑Audits, securebydefault‑Einstellungen
Enterprise‑Storage (ZFS, Snapshots, Replikation)FreeBSD (bzw. TrueNAS CORE)Native ZFS‑Integration, ausgereifte Verwaltungstools, breite Community
Breite Hardware‑Unterstützung (IoT, ARM, MIPS, SPARC)NetBSDUnterstützt über 50 Architekturen, Clean‑room‑Entwicklung, geringes Footprint
Skalierbare SMP‑Server (viele Kerne, Dedupl.)DragonFlyBSDHAMMER2‑Dedupl., Vkernel‑Isolation, exzellente SMP‑Performance
Desktop‑Erlebnis (Desktop‑Environment, Plug‑and‑Play)GhostBSD (FreeBSD) oder MidnightBSDFertige Installer, vorinstallierte GNOME/KDE, einfacher Paket‑Manager
Firewall‑AppliancepfSense / OPNsense (beide FreeBSD‑basiert)Web‑UI, umfangreiche Plugin‑Bibliothek, kommerzieller Support
NAS / Speicher‑ApplianceTrueNAS CORE (FreeBSD)ZFS‑Management, Web‑Interface, Replikation, VM‑Support
Entwicklung / ForschungNetBSDPortabilität, pkgsrc für plattformübergreifende Pakete

Berücksichtigen Sie zusätzlich Community‑Aktivität, Verfügbarkeit von Paketen (Ports vs. pkg), Lizenz‑Konformität und Unterstützungsoptionen (Mailing‑Liste, Issue‑Tracker, kommerzielle Anbieter).

Zukünftige Entwicklungen und Roadmaps

  • FreeBSD 15.x – Weiterentwicklung des ZFS‑Stacks (z. B. ZFS 2.2 mit Verbesserungen bei Scrubbing und Compression), Unterstützung von GPU‑Pass‑Through für bhyve, engere Integration in Kubernetes via csi‑freebsd.
  • OpenBSD 7.9 – Verbesserungen am pf‑Engine (z. B. stateful‑inspection Optimierungen), Einführung von Trusted Execution Environments (TEE), erweiterte Hardware‑Root‑of‑Trust‑Mechanismen.
  • NetBSD 10 – Fokus auf RISC‑V‑Unterstützung (neue Toolchains, Device‑Tree‑Support), pkgsrc‑Erweiterungen für Container‑Orchestrierung (Docker‑Kompatibilität), Modernisierung der Netz‑Stack‑Bibliotheken.
  • DragonFlyBSD 6 – Finalisierung und Stabilisierung von HAMMER2, neue Vkernel‑Features (z. B. Namespace‑Isolation, cgroups‑ähnliche Ressourcen‑Limits), Integration von ZFS‑Ports für Hybrid‑Lösungen.
  • Derivate: TrueNAS SCALE (Debian‑basiert) entsteht als Konkurrenz zum FreeBSD‑basierten CORE, während pfSense 2.8 führt eBPF‑Unterstützung ein, um modernere Packet‑Processing‑Pipelines zu ermöglichen.

Quellen, weiterführende Literatur und Community‑Links

  • FreeBSD Project – Offizielle Dokumentation: https://www.freebsd.org/docs/
  • OpenBSD Project – Ziele & Sicherheit: https://www.openbsd.org/faq/faq4.html
  • NetBSD Project – Plattform‑Übersicht: https://www.netbsd.org/ports/
  • DragonFlyBSD – HAMMER2‑Dokumentation: https://www.dragonflybsd.org/docs/hammer2/
  • pfSense – Dokumentation & Release‑Notes: https://docs.pfsense.org/
  • OPNsense – Features & Roadmap: https://opnsense.org/
  • TrueNAS – ZFS‑Management: https://www.truenas.com/
  • GhostBSD – Desktop‑Projekt: https://ghostbsd.org/
  • MidnightBSD – Release‑Notes: https://midnightbsd.org/
  • NomadBSD – Live‑USB System: https://nomadbsd.org/
  • NetBSD – WAPBL & FFS: https://netbsd.org/docs/technical/
  • OpenBSD – pf‑Manpage: https://man.openbsd.org/pf.conf
  • FreeBSD – Jails‑Handbuch: https://docs.freebsd.org/en/books/handbook/jails/
  • DragonFlyBSD – Vkernel‑Übersicht: https://www.dragonflybsd.org/docs/vkernel/

Was ist neu in Qt 6.10? Ein Überblick für Entwickler

Thorsten Geppert Schreib einen Kommentar

Qt 6.10 ist ein klassisches „Framework‑Release“, das an vielen Stellen nachzieht, wo sich in den letzten Jahren Anforderungen und Best Practices geändert haben: moderneres UI‑Layouten mit Flexbox, stärkere Unterstützung für Vektoranimationen (SVG/Lottie), vereinfachte Datenanbindung zwischen C++ und QML, neue Hilfstypen für Modelle und Bindungen – und dazu ein spürbares Update bei Accessibility und Plattformintegration.

Im Folgenden ein Überblick über die wichtigsten Änderungen von Qt 6.10, auf Basis der offiziellen Release‑Informationen.

Accessibility: High Contrast und Screenreader werden ernster genommen

Qt 6.10 legt sichtbar mehr Wert auf Barrierefreiheit:

  • High‑Contrast‑Mode auf allen Plattformen:
  • Die eingebauten Styles orientieren sich stärker an den jeweiligen System‑Einstellungen für hohen Kontrast.
  • Ziel: Qt‑Apps sollen sich optisch nahtlos in die restliche Oberfläche einfügen und dabei besser lesbar sein.
  • Für dich als Entwickler bedeutet das: Ohne Codeänderung profitierst du von verbessertem Kontrast, wenn Nutzer das systemweit aktivieren.
  • Bessere Integration mit Assistive Technologies:
  • Qt Widgets und Qt Quick Controls wurden überarbeitet, damit Screenreader und andere Hilfsmittel sauberer angesprochen werden.
  • Besonders für WebAssembly gab es Verbesserungen in der Accessibility‑Implementierung.
  • Viele Änderungen fließen auch in LTS‑Branches zurück (Patch‑Releases), sofern du dort aktuell bleibst.

Unterm Strich: Qt 6.10 hilft dir bei der Einhaltung von Accessibility‑Vorgaben, ohne dass du an jeder Ecke Speziallogik schreiben musst.

Qt Quick: FlexboxLayout und moderne UI‑Bausteine

Qt Quick bleibt die Speerspitze für neue UI‑Konzepte. Mit Qt 6.10 kommen unter anderem:

FlexboxLayout (Tech Preview)

  • Neues Layout‑Element FlexboxLayout für Qt Quick, das sich an CSS Flexbox anlehnt.
  • Vorteile:
  • Besseres Verhalten bei unterschiedlich großen Screens und Aspect Ratios.
  • Weniger Custom‑Layoutcode für „responsive“ UIs.
  • Vertraut für alle, die bereits mit Web/CSS arbeiten.
  • Integration:
  • Bindet sich in das bestehende Layout‑System von Qt Quick ein (attached properties etc.).
  • Ist als Technologievorschau gekennzeichnet – API kann sich bis zum nächsten LTS noch ändern.

Animierte Vektorgrafiken (SVG & Lottie)

Qt 6.10 baut konsequent auf den SVG/Vektor‑Verbesserungen der vorherigen Versionen auf:

  • VectorImage (aus 6.8 bekannt) wird erweitert:
  • Unterstützung für animierte Vektorgrafiken in
    • SVG‑Format und
    • Lottie‑Format.
  • Qt Lottie‑Modul:
  • Deutlich verbesserte Unterstützung moderner Lottie‑Dateien.
  • Lottie‑Assets können jetzt als skalierbare, hardwarebeschleunigte Vektorgrafiken direkt im Qt‑Quick‑Scenegraph gerendert werden.

Für UI‑Designer bedeutet das: Aufwendige, aber leichtgewichtige Animationswelten lassen sich direkt aus Design‑Tools (Figma/After Effects → Lottie) in Qt übernehmen.

Neuer Quick Control: SearchField

  • Spezialisierter Eingabebaustein für Suchfelder.
  • Bringt:
  • nativen Look & Feel auf allen Plattformen (wie andere Qt Quick Controls),
  • integrierte Vorschlagsliste mit Modellanbindung.
  • Integration:
  • suggestionModel kann über die üblichen Mechanismen (QAbstractItemModel, Kontextobjekte, QML‑Modelle) befüllt werden.
  • Besonders interessant in Kombination mit den neuen Modell‑/Bindungswerkzeugen (siehe unten).

Einfachere Verbindung zwischen C++‑Daten und QML‑UIs

Ein klassischer Schmerzpunkt in Qt‑Projekten war die Verbindung zwischen C++‑Backend und QML‑UI. Qt 6.10 nimmt sich genau dieser Nähte an.

QRangeModel: C++‑Container direkt als Modell

  • QRangeModel ist eine schlanke QAbstractItemModel‑Implementierung, die C++‑Ranges (z.B. std::vector, std::array, beliebige iterierbare Container) direkt als Modell zur Verfügung stellt.
  • Eigenschaften:
  • Kann einfache Typen (int, QString, …) wie auch komplexe Typen (GADGETs, std::tuple) abbilden.
  • Modellrollen werden automatisch erzeugt.
  • Funktioniert gleichermaßen in Qt Widgets (Views) und in QML/Qt Quick.
  • Beispiel‑Anwendung:
  • std::vector<int> als Liste in einer QML‑ListView,
  • std::vector<MyGadget> als typ‑sicheres Modell in Delegates mit required property.

Damit entfällt für viele Anwendungsfälle das Schreiben eigener QAbstractItemModel‑Subklassen.

delegateModelAccess: Zurückschreiben in das Modell vereinfachen

Bisher war das Schreiben aus einem Delegate zurück in das Modell oft umständlich:

  • Entweder über model‑Objekte im Delegate
  • oder über Kontextproperties und eigene Signal‑Handler.

Mit Qt 6.10 kann eine View über delegateModelAccess: DelegateModel.ReadWrite explizit erlauben, dass required‑Properties im Delegate direkt zurück ins Modell schreiben. Das reduziert Boilerplate deutlich, insbesondere in größeren QML‑UIs.

Synchronizer: Zwei‑ und Mehrwege‑Bindungen

  • Neues Element Synchronizer (Tech Preview, Modul Qt.labs.synchronizer).
  • Zweck:
  • Mehrere Properties so synchron halten, dass sie (so weit möglich) denselben Wert haben, ohne klassische Bindungen zu „brechen“.
  • Funktioniert für Kombinationen von C++‑ und QML‑Eigenschaften.
  • Praxisnutzen:
  • Typische „Slider ↔ Modell‑Wert“‑Szenarien lassen sich deklarativ und ohne zusätzliche Signal‑Handler abbilden.

TreeModel für QML

  • Neues QML‑TreeModel, mit dem sich Baumdaten direkt in QML deklarieren lassen.
  • Zielgruppe:
  • Prototyping,
  • kleinere Datenmengen,
  • Szenarien, in denen ein kompletter C++‑Baummodell‑Layer Overkill wäre.

Zusammen genommen macht Qt 6.10 die Kante zwischen C++‑Backend und QML‑Frontend deutlich angenehmer.

Qt Graphs: FilledSurface und mehr

Qt Graphs wird auch in 6.10 weiter ausgebaut:

  • Neue Diagrammtypen und Anpassungen:
  • u.a. ein neuer „FilledSurface“‑Graph zur besseren Darstellung gefüllter Flächen.
  • Bessere Integration in Qt Quick und die neuen Layout‑/Vektorfeatures.

Wenn du bereits mit Qt Graphs arbeitest, lohnt sich ein Blick in die konkreten Release Notes für dieses Modul.

Sonstige Verbesserungen und Plattform‑Updates

Wie bei jedem Qt‑Release gibt es eine Reihe weiterer Verbesserungen:

  • Plattformintegration:
  • Qt 6.10 richtet sich nach den jeweils aktuellen Versionen der großen Desktop‑, Mobile‑ und Embedded‑Plattformen (siehe Release Note und Wiki‑Seite).
  • Bugfixes und Feinschliff:
  • Dutzende Fehlerkorrekturen in den Untermodulen (Widgets, Quick, Network, etc.).
  • Viele Details lassen sich in den detaillierten Release Notes (6.10.0–6.10.2) nachlesen.

Fazit

Qt 6.10 ist kein „großer Sprung“ im Sinne völlig neuer Konzepte, sondern ein Release, das viele typischen Alltagsbaustellen adressiert:

  • Accessibility wird ernst genommen (High Contrast, Screenreader‑Integration).
  • Qt Quick bekommt mit FlexboxLayout, animierten Vektorgrafiken und SearchField Werkzeuge, die aktuelle UI‑Designs besser abbilden.
  • Die Verbindung zwischen C++‑Daten und QML‑UIs wird durch QRangeModel, delegateModelAccess, Synchronizer und TreeModel deutlich entschärft.

Wer bereits auf Qt 6.x unterwegs ist, sollte Qt 6.10 vor allem dann in Betracht ziehen, wenn:

  • Accessibility und regulatorische Vorgaben eine Rolle spielen,
  • moderne, animierte UIs (Vektor/Lottie) benötigt werden,
  • oder die Brücke zwischen C++‑Backend und QML‑Frontend bislang viel Handarbeit erfordert.

Quellen

  • Qt Blog: Qt 6.10 Released! – https://www.qt.io/blog/qt-6.10-released
  • Qt Wiki: Qt 6.10 Release – https://wiki.qt.io/Qt_6.10_Release
  • Qt Doku: New Features in Qt 6.10 – https://doc.qt.io/qt-6.10/whatsnew610.html

FreeBSD in den letzten sieben Tagen: Zwischen 14.4-Realität, ZFS-Sorgen und kleinen pkg-Ideen

Thorsten Geppert Schreib einen Kommentar

Wer bei FreeBSD auf den großen Trommelwirbel wartet, wartet oft lange. Das ist einer der Punkte, die ich an dem System gleichzeitig schätze und gelegentlich unerquicklich finde. Schätze, weil man nicht jeden zweiten Tag mit irgendeinem Marketingfeuerwerk belästigt wird. Unerquicklich, weil man sich die wirklich interessanten Entwicklungen oft aus Mailinglisten, Release Notes und Nebensätzen zusammensuchen muss.

Wenn man auf die letzten sieben Tage blickt, dann ergibt sich im Kern ein recht typisches Bild für FreeBSD: Nach außen ist es vergleichsweise ruhig, unter der Oberfläche wird aber an genau den Stellen diskutiert, an denen Betriebssysteme im Alltag entweder angenehm oder unerquicklich werden. Performance beim Bauen von Software, Stabilität und Speicherverhalten von ZFS sowie die Frage, wie sich pkg im PKGBASE-Umfeld sinnvoller bedienen lässt.

FreeBSD 14.4 ist weiterhin das beherrschende Thema

Die wichtigste offizielle Nachricht im betrachteten Zeitraum bleibt letztlich die Veröffentlichung von FreeBSD 14.4-RELEASE am 10. März. Das fällt zwar knapp aus dem Sieben-Tage-Fenster heraus, prägt aber die Diskussionen dieser Woche deutlich. Und das ist auch kein Wunder.

Zu den wichtigen Punkten von 14.4 gehören unter anderem:

  • OpenSSH 10.0p2
  • standardmäßig der hybride Post-Quantum-Algorithmus mlkem768x25519-sha256
  • OpenZFS 2.2.9
  • bessere cloud-init-/nuageinit-Kompatibilität
  • ein neues p9fs(4) für Dateisystem-Sharing zwischen Host und bhyve-Gästen
  • Verbesserungen bei den Manpages und deren Werkzeugen

Das ist insgesamt ein ordentliches Release. Keine Revolution, aber genau diese Sorte Version, die für FreeBSD eigentlich typisch ist: evolutionär, pragmatisch, mit Fokus auf sinnvolle Pflege statt auf Show.

Erwähnenswert ist auch die Widmung der Version an Ken Smith, der Ende letzten Jahres verstorben ist und als Release-Engineering-Leiter über viele Jahre hinweg eine wichtige Rolle bei FreeBSD gespielt hat. Solche Hinweise gehen in technischen Veröffentlichungen gerne unter, sind aber durchaus bedeutend, weil sie zeigen, dass hinter der ganzen Sache eben doch Menschen stehen und nicht nur Code.

Erste Rückmeldungen nach 14.4: Build-Zeiten sorgen für Unmut

Interessanter als die reine Release-Ankündigung waren in dieser Woche die Rückmeldungen aus der Praxis. Auf der Mailingliste wurde ein Fall beschrieben, bei dem sich nach dem Upgrade von 14.3 auf 14.4 die Build-Zeiten mit poudriere teils drastisch erhöht haben. Konkret war von teils doppelt so langen Zeiten die Rede.

Das ist kein kleines Detail. Für Leute, die Ports bauen, Pakete pflegen oder generell viel lokal kompilieren, ist das kein Schönheitsfehler, sondern schlicht Alltagsschmerz. Wenn ein Full Build plötzlich nicht mehr einen Tag, sondern zwei braucht, dann ist das keine Randnotiz mehr.

In der Diskussion wurde darauf verwiesen, dass hier vermutlich ein bereits bekanntes Performance-Problem hineinspielt und dass es dafür inzwischen einen Schalter gibt, um das frühere Verhalten wiederherzustellen. Das ist zunächst einmal die gute Nachricht. Die weniger gute Nachricht ist aber, dass solche Dinge überhaupt erst einmal wieder in der Praxis auffallen müssen und man sich die Informationen aus Threads und Commit-Hinweisen zusammensuchen darf.

Das ist bei FreeBSD leider nicht ganz unüblich: Die Technik ist oft solide, die Kommunikation darüber mitunter weniger komfortabel, als sie sein könnte.

ZFS bleibt hervorragend – und manchmal unerquicklich

Wirklich interessant wurde es bei einer Diskussion zu ZFS-Deadlocks und Memory-Accounting-Problemen auf NFS-Servern. Beschrieben wurde dort ein Verhalten, bei dem Maschinen trotz sehr viel freiem RAM unter Speicherdruck geraten, anfangen zu swapen und im schlimmsten Fall sogar im OOM-Kontext landen. Das ist schon deshalb unerquicklich, weil gerade große Speicher- und Storage-Systeme unter FreeBSD häufig genau mit dem Versprechen betrieben werden, dass ZFS dort besonders gut aufgehoben sei.

Der geschilderte Fall betraf Systeme mit sehr viel RAM, bei denen ARC-Speicher zwar als evictable erschien, das System aber dennoch in einen problematischen Zustand lief. Dazu kamen Hinweise auf blockierte Prozesse und Wartezustände rund um ARC- und dbuf-Mechanismen. Das ist natürlich erst einmal ein Einzelfall aus einer Mailingliste und keine allgemeingültige Aussage über alle 14.x-Installationen. Aber es ist genau die Sorte Signal, bei der Administratoren hellhörig werden sollten.

Denn solche Probleme sind im Alltag nicht deswegen unangenehm, weil sie spektakulär sind, sondern weil sie sich oft lange als „komisches Verhalten“ tarnen. Ein bisschen Swap hier, etwas Last dort, ein paar hängende Prozesse, und plötzlich steht ein System, das laut oberflächlicher Kennzahlen eigentlich gar nicht in Schwierigkeiten sein dürfte.

FreeBSD hat im Storage-Bereich nach wie vor sehr gute Argumente. Aber wenn solche Berichte auftauchen, dann sollte man sie ernst nehmen. Nicht hysterisch, aber ernsthaft.

Kleine pkg-Diskussion, aber durchaus mit praktischer Relevanz

Weniger dramatisch, aber praktisch nicht uninteressant war eine Diskussion um pkg und den Umgang mit PKGBASE. Konkret ging es um den Wunsch, Upgrades für Drittanbieter-Pakete und Base-System sauberer voneinander zu trennen.

Vorgeschlagen wurden zusätzliche Aliase wie:

  • pkg upgrade-packages
  • pkg upgrade-base

Die Idee dahinter ist simpel und vernünftig: Man möchte im Alltag nicht immer alles in einen Topf werfen, sondern bewusst entscheiden können, ob gerade nur Ports-Pakete oder nur das Base-System angefasst werden sollen.

Das ist nun keine Nachricht, bei der irgendjemand in Begeisterung ausbrechen müsste. Aber es ist ein gutes Beispiel dafür, wie sich FreeBSD verändert: oft in kleinen, unaufgeregten, aber alltagstauglichen Schritten. Gerade solche Verbesserungen machen am Ende häufig mehr Unterschied als irgendein groß angekündigtes Großprojekt.

Zugleich zeigt die Diskussion aber auch ein typisches Problem: Benennung und Verständlichkeit sind eben nicht nebensächlich. Wenn man „packages“ sagt, obwohl technisch betrachtet am Ende alles Pakete sind, dann ist die Verwirrung fast schon eingebaut. Das ist kein Drama, aber auch kein Detail, das man völlig ignorieren sollte.

Was bleibt also von dieser Woche?

Wenn man die letzten sieben Tage rund um FreeBSD zusammenfasst, dann ergibt sich aus meiner Sicht vor allem dieses Bild:

FreeBSD wirkt nach außen oft ruhig, fast schon zu ruhig. Unter dieser ruhigen Oberfläche zeigen sich aber genau die Themen, die für Anwender und Administratoren wirklich relevant sind:

  • Wie gut läuft ein frisches Release im Alltag?
  • Gibt es Performance-Regressions?
  • Ist ZFS unter realer Last so stabil, wie man es erwartet?
  • Werden Werkzeuge wie pkg im täglichen Betrieb besser bedienbar?

Das ist am Ende vielleicht auch das eigentlich Sympathische an FreeBSD. Die interessanten Nachrichten sind dort selten bloß „Neu! Größer! Schneller!“. Oft sind es eher Hinweise darauf, wo die Praxis gegen die Theorie arbeitet. Und genau dort entscheidet sich, ob ein System auf Dauer Vertrauen verdient.

14.4-RELEASE ist ohne Frage die wichtigste jüngere Entwicklung. Die anschließenden Diskussionen zu Build-Performance und ZFS zeigen aber auch, dass ein Release eben nicht mit der Veröffentlichung fertig ist. Es beginnt dann erst die Phase, in der sich herausstellt, wie gut die Dinge außerhalb von Release Notes und Ankündigungen wirklich funktionieren.

Und genau diese Phase war in den letzten sieben Tagen die eigentlich interessante.

Quellen

  • FreeBSD News Flash: https://www.freebsd.org/news/newsflash/
  • FreeBSD News RSS Feed: https://www.freebsd.org/news/feed.xml
  • FreeBSD 14.4-RELEASE Announcement: https://lists.freebsd.org/archives/freebsd-announce/2026-March/000228.html
  • FreeBSD-announce Archiv März 2026: https://lists.freebsd.org/archives/freebsd-announce/2026-March/date.html
  • Thread: „Huge build times increase after updating from 14.3 to 14.4“: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003900.html
  • Antwort von Olivier Certner zum bekannten Performance-Problem: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003901.html
  • Nachfrage von Philip Paeps zu den Package-Buildern: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003907.html
  • Thread: „ZFS deadlocks/memory accounting issues“: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003910.html
  • Antwort von Alan Somers im ZFS-Thread: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003911.html
  • Thread/Proposal zu pkg-Aliases: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003942.html
  • Rückfrage zur Benennung der pkg-Aliases: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003944.html
  • FreeBSD-stable Archiv März 2026: https://lists.freebsd.org/archives/freebsd-stable/2026-March/date.html

Internat Alzen: Mobbing gemeldet – Schulvertrag kurze Zeit später beendet – Wie unser autistischer Sohn unverschuldet den Schulplatz verlor

Thorsten Geppert Schreib einen Kommentar

In unserem ausführlichen Erfahrungsbericht schildern wir, wie unser autistischer Sohn nach einem vielversprechenden Start am Internat Alzen wiederholt von Mitschülern belastet wurde und wir dies frühzeitig dokumentiert und gemeldet haben. Aus unserer Sicht reagierte die Schule nicht mit ausreichenden Schutzmaßnahmen, sondern hielt an einem festen Konzept fest, das die Situation unseres Kindes nicht angemessen berücksichtigte. Wenige Wochen nach unseren Hinweisen auf die Problematik wurde das Schulverhältnis beendet.

Wir ordnen den Fall im Kontext von Kinderschutz, Inklusion und schulischer Verantwortung ein und geben Hinweise, worauf Eltern in ähnlichen Situationen achten sollten und berichten von unseren Erfahrungen.

Den vollständigen Artikel mit allen Hintergründen und Dokumentationen findest du hier.

CENMATE Festplattengehäuse als Erweiterung für meinen Server

Thorsten Geppert Schreib einen Kommentar

Mein Hauptserver, den ich mit FreeBSD (15) betreibe, hat acht Bays. Die sind bereits voller SAS- bzw. Nearline-SAS-Festplatten. Ich hatte aber noch drei 4TB große SSDs, die ich gerne für Virtualisierung nutzen wollte, da mir die NL-Platten zu langsam sind.

Nach langem Überlegen und Herumprobieren habe ich dann die externen Gehäuse von CENMATE entdeckt. Ich wollte mir zuerst das mit 10 Bays kaufen, doch das gab es im ganzen Internet nicht. Dann las ich, dass viele andere Menschen Probleme mit den Geräten an Desktop-Systemen haben, da Festplatten immer wieder „verschwinden“ würden. Also dachte ich mir, bevor ich so viel Geld ausgebe, hole ich mir das Gerät mit drei Bays für gut 100 Euro und probiere einmal herum. Ich hatte mir bereits vorher extra eine zusätzliche USB-3-PCIe-Karte gekauft und eingebaut, die gut funktioniert.

CENMATE Festplattengehäuse mit drei Bays.
CENMATE Festplattengehäuse mit drei Bays.

Ich habe das Gerät jetzt seit zwei Wochen und bisher funktioniert es super. Ich habe meine drei SSDs mit 2,5″-auf-3,5″-Adaptern eingesteckt und fahre ein verschlüsseltes RAIDz darauf (ZFS + RAID-5). Die Performance ist in Ordnung, könnte aber besser sein. Richtige Messwerte habe ich nicht, ich kann aber gleichzeitig etliche VMs (getestet mit zehn, davon zwei mit Windows) drauf laufen lassen und es lässt sich gut damit arbeiten. Einen einfachen Schreibtest habe ich mit dd gemacht, da kam ich auf gut 220MB/s. Wäre ausbaubar, denn die Platten schaffen mehr, aber vielleicht schaue ich mir das Problem irgendwann noch genauer an. Bisher bin ich auch so erst einmal zufrieden, da alles stabil läuft.

Warum ich FreeBSD statt Linux auf Servern einsetze

Thorsten Geppert Schreib einen Kommentar

Wenn es um Server-Betriebssysteme geht, denken viele zuerst an Linux. Das ist nachvollziehbar: Linux ist weit verbreitet, hat eine große Community und wird von vielen Unternehmen eingesetzt.

Trotzdem arbeite ich seit vielen Jahren bevorzugt mit FreeBSD. Angefangen habe ich damit ungefähr zur Zeit von FreeBSD 4 – und seitdem ist es für viele meiner Server die erste Wahl geblieben.

Warum eigentlich?

Die kurze Antwort: FreeBSD wirkt für mich wie ein durchdachtes Gesamtsystem, während sich viele Linux-Installationen eher wie eine Sammlung einzelner Komponenten anfühlen.

Die längere Antwort folgt hier.

Ein Betriebssystem statt vieler Einzelteile

Ein grundlegender Unterschied zwischen Linux und FreeBSD ist die Struktur des Systems.

Bei Linux besteht eine Distribution meist aus vielen Komponenten verschiedener Projekte:

  • Kernel
  • GNU-Tools
  • Init-System
  • Paketmanager
  • zusätzliche Werkzeuge

Das funktioniert gut, führt aber manchmal zu Inkonsistenzen.

FreeBSD verfolgt einen anderen Ansatz: Das Basissystem wird als einheitliches Betriebssystem entwickelt und gepflegt.

Kernel, Systemwerkzeuge und viele zentrale Komponenten gehören zusammen. Dadurch wirkt das System sehr konsistent – sowohl in der Konfiguration als auch in der Dokumentation.

Gerade bei langfristig betriebenen Servern ist das ein großer Vorteil.

Vorhersagbarkeit im Betrieb

Ein wichtiger Punkt für mich ist Vorhersagbarkeit.

Server sollen möglichst langweilig sein: Sie sollen stabil laufen, sich nachvollziehbar konfigurieren lassen und keine Überraschungen produzieren. Ähnlich wie ein Flugzeug.

Viele meiner FreeBSD-Systeme laufen über lange Zeiträume sehr unauffällig. Updates sind in der Regel gut planbar, und das Verhalten des Systems bleibt konsistent.

Das ist besonders dann wertvoll, wenn ein System über Jahre betrieben wird.

ZFS als integraler Bestandteil

Ein weiterer großer Vorteil ist die enge Integration von ZFS.

ZFS bietet Funktionen, die im Alltag enorm hilfreich sind:

  • Snapshots
  • einfache Backups
  • Datenintegrität
  • flexible Storage-Strukturen

Gerade bei Servern mit vielen Daten oder virtuellen Systemen macht das einen großen Unterschied.

Viele meiner Systeme nutzen ZFS als Grundlage für Storage und Backups. Das ermöglicht sehr robuste und wartbare Setups.

Jails: leichtgewichtige Isolation

FreeBSD bietet mit Jails eine sehr elegante Möglichkeit, Dienste voneinander zu isolieren.

Im Gegensatz zu vollständigen virtuellen Maschinen sind Jails sehr leichtgewichtig. Dienste lassen sich getrennt betreiben, ohne dass jede Anwendung ein eigenes Betriebssystem benötigt.

Das hat mehrere Vorteile:

  • geringerer Ressourcenverbrauch
  • klare Trennung von Diensten
  • einfache Verwaltung

Für viele Server-Szenarien ist das ein sehr praktischer Ansatz.

Gute Werkzeuge und klare Struktur

Ein weiterer Punkt, den ich an FreeBSD schätze, ist die klare Struktur des Systems.

Dazu gehören beispielsweise:

  • das klassische rc-System zur Dienstverwaltung
  • ein konsistentes Konfigurationsmodell
  • das Paketmanagement mit pkg
  • sehr gute Manpages und Dokumentation

Gerade wenn man Systeme länger betreibt oder später wieder nachvollziehen muss, was einmal eingerichtet wurde, zahlt sich diese Klarheit aus.

Praxis statt Theorie

Ich nutze FreeBSD nicht nur gelegentlich, sondern betreibe damit seit vielen Jahren verschiedene Systeme.

Darunter Server mit:

  • Webdiensten
  • Datenbanken
  • DNS, DHCP und NTP
  • NFS, Samba, Apple-Talk (netatalk), iSCSI
  • verschiedenen Anwendungen in Jails
  • Bhyve als Virtualisierer, um auch Linux-Instanzen laufen zu lassen

Teilweise auch mit komplexeren Storage-Konfigurationen und mehreren virtuellen Systemen.

Diese Erfahrungen aus dem Alltag sind der Hauptgrund, warum ich FreeBSD weiterhin gerne einsetze.

Fazit

Linux ist ein sehr gutes Betriebssystem und für viele Szenarien eine sinnvolle Wahl.

Für meine eigenen Server greife ich trotzdem häufig zu FreeBSD.

Die Gründe dafür sind vor allem:

  • ein konsistentes Gesamtsystem
  • stabile und vorhersehbare Server
  • integrierte Technologien wie ZFS
  • elegante Isolation mit Jails
  • klare Struktur und gute Dokumentation

Gerade für langfristig betriebene Infrastruktur hat sich FreeBSD für mich immer wieder als sehr zuverlässige Plattform erwiesen.

FreeBSD auf einem Lenovo T480

Thorsten Geppert Schreib einen Kommentar

Ich, der derzeit fast ausschließlich seit sechs Jahren MacBooks nutzt und relativ glücklich mit seinem M5-Gerät ist, wollte schon immer mal FreeBSD auf einem Notebook ausprobieren. Ein gut kompatibles Gerät hatte ich bisher nie finden können, doch tauchte dann irgendwann ein Artikel auf, der meinte, dass das Lenovo T480 gut mit FreeBSD funktioniert. Also habe ich mir eins bei eBay für 170 Euro geklickt. 14″, i5, 256GB SSD, 16GB RAM. Nichts tolles, aber zum herumspielen reicht es, dachte ich.

Ich habe eine kurze Weile OpenBSD auf einem Eee-PC vor vielen Jahren genutzt und das Ding sogar mal für eine Weile mit ins Krankenhaus genommen. Es funktionierte echt gut, sogar Suspend und Resume. Leider ging es dann kaputt.

Bild vom Lenovo T480 mit FreeBSD und KDE

Das Gerät kam an, Windows 11 war installiert. Ich habe es direkt platt gemacht und FreeBSD 15 amd64 von einem USB-Stick installiert. Letztlich eine Standardinstallation. Was funktioniert alles?

  • Grafikkarte funktioniert, Monitor wird mit voller Auflösung (naja, ist nur Full-HD) unterstützt
  • Tastatur geht
  • Trackpad geht, auch mit Scrolling
  • Trackpoint geht auch
  • Der SD-Card-Reader funktioniert
  • WLAN- und Ethernet funktionieren
  • Beide Akkus (interner und externer) werden erkannt
  • Tonausgabe geht
  • USB-Anschlüsse funktionieren
  • Suspend und Resume funktionieren
  • Bluetooth

Was ich noch nicht ausprobiert habe, sind:

  • Smart-Card-Reader
  • HDMI-Anschluss

Installiert habe ich Xorg, KDE und ein wenig Software. Das Gerät funktioniert recht gut und für jemanden, der unbedingt FreeBSD auf einem Notebook haben möchte, ist es nicht schlecht, wenn man denn mit den ganzen Nachteilen leben kann (langsamer Prozessor, schlechte Grafikkarte, schlechter Bildschirm, mittelmäßiges Trackpad, billiges Plastikgehäuse).

Bhyve: can’t find ‚/boot/entropy‘ und can’t find ‚/etc/hostid‘ beim Virtualisieren von FreeBSD

Thorsten Geppert Schreib einen Kommentar

Ich hatte jetzt auf älteren MicroServern von HP das Problem, dass FreeBSD nach dem Bootloader in Bhyve stoppte:

  _____              ____ ____  ____     ___           _        _ _
 |  ___| __ ___  ___| __ ) ___||  _ \   |_ _|_ __  ___| |_ __ _| | | ___ _ __
 | |_ | '__/ _ \/ _ \  _ \___ \| | | |   | || '_ \/ __| __/ _` | | |/ _ \ '__|
 |  _|| | |  __/  __/ |_) |__) | |_| |   | || | | \__ \ || (_| | | |  __/ |
 |_|  |_|  \___|\___|____/____/|____/   |___|_| |_|___/\__\__,_|_|_|\___|_|



 +-------- Welcome to FreeBSD ----------+     ```                        `
 |                                      |    s` `.....---.......--.```   -/
 |  1. Boot Installer [Enter]           |    +o   .--`         /y:`      +.
 |  2. Boot Single user                 |     yo`:.            :o      `+-
 |  3. Escape to loader prompt          |      y/               -/`   -o/
 |  4. Reboot                           |     .-                  ::/sy+:.
 |  5. Cons: Serial                     |     /                     `--  /
 |                                      |    `:                          :`
 |  Kernel:                             |    `:                          :`
 |  6. kernel (1 of 1)                  |     /                          /
 |                                      |     .-                        -.
 |  Options:                            |      --                      -.
 |  7. Boot Options                     |       `:`                  `:`
 |                                      |         .--             `--.
 +--------------------------------------+            .---.....----.-
   Autoboot in 2 seconds. [Space] to pause
Loading kernel...
/boot/kernel/kernel text=0x1865e8 text=0xdbf5d4 text=0x4474db data=0x180+0xe80 data=0x1972e0+0x468d20 0x8+0x1949a0+0x8+0x1b90eb\
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'

Der Prozessor ist ein „Intel(R) Celeron(R) CPU G1610T @ 2.30GHz“. FreeBSD ist 15.0p2 und 15.0p3. Gelöst werden konnte das Problem mit folgender Zeile in der /boot/loader.conf:

vm.pmap.la57=“0″

Nach einem Neustart funktioniert dann die Virtualisierung.

Quelle: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291768 – https://www.freebsd.org/security/advisories/FreeBSD-EN-22:07.la57.asc

Nachtrag vom 13.03.2026

Wie ich festgestellt habe, kam bei mir der Fehler auch, wenn ich bei der Installation auf mehr als eine CPU konfigurierte. Wenn ich die Installation durchführen wollte, habe ich in der Konfiguration jetzt einfach auf eine zugewiesene CPU gestellt und danach wieder erhöht.

Der neue Server mit FreeBSD (15.0-RELEASE)

Thorsten Geppert Schreib einen Kommentar

Über die letzten 15 Jahre habe ich HP MicroServer als Home-Server eingesetzt. Ich hatte immer zwei mit FreeBSD (einen Main- und einen Backup-Server) sowie meist noch einen mit Windows, um dort Windows-Software auszuführen, der aber auch nicht permanent lief, sondern nur, wenn er gebraucht wurde.

In meinem letzten Hauptserver liefen vier vier Terrabyte große SATA-Festplatten im RAIDz1, also letztlich eine Art RAID-5 in Software. Das Ganze lief stabil und gut, aber meine heutigen Ansprüche waren viel zu langsam. Neben etlichen Jails mit etlichen Diensten (Web, Datenbanken, DHCP, NTP, DNS, Samba, NFS, uvm.) liefen auch zwei Minecraft-Server darauf und, gelinde gesagt, machte es einfach keinen Spaß mehr.

Etwas Neues musste her. Diesmal wollte ich keinen HP MicroServer mehr, da ich verschiedene Festplattenkombinationen wollte, um mehr Speed zu bekommen. Er sollte vernünftig virtualisieren können. Er sollte auch eine Möglichkeit haben, SAS-Festplatten mit Near-Line-SAS-Festplatten und SATA-Festplatten und -SSDs mischen zu können.

Dell PowerEdge T330

Aufgrund dessen, dass der Server für einen Privathaushalt ist, aber dennoch wichtig, speichert er immerhin wichtige Dokumente, ist für Entertainment da und auch zum Entwickeln von Software, entschied ich mich für eine gebrauchte Maschine, allerdings von einem Händler. Bei ServerShop24 entschied ich mich für einen Dell PowerEdge T330.

Meine Vorteile:

  • Die Maschine ist einfach zu öffnen und zu erweitern
  • Man kann, out of the box, 8 3,5″ HDDs reinstöpseln
  • SAS und SATA sind problemfrei mischbar (bei meiner Konfiguration).
  • FreeBSD läuft problemfrei drauf.

Meine Nachteile:

  • Dell (bäh).
  • FreeBSD bietet keine integrierte Lüftersteuerung, die muss man selbst bauen, was aber nicht so schwer ist – ansonsten drehen die Lüfter auf Vollgas und das macht keinen Spaß.
  • Sehr groß (eigentlich ist es mir egal).

Das ganze Ding hat 64GB RAM. Genug, für die ganzen Dienste, Jails, Virtualisierung von Windows 11. Ich habe zwei 300GB SAS HDDs für das Betriebssystem und Software drin (ZFS Mirror, gmirror für SWAP), 4 3TB NL-SAS HDDs (raidz-1) für das Datengrab und zwei SATA-SSDs für Virtualisierung und Minecraft (ZFS Mirror). Das System ist verschlüsselt.

Zusätzlich habe ich für ein paar Euros einen SD-Card-RAID-Controller gekauft, der zwei SD-Cards aufnimmt und die miteinander synchron hält. Darauf sichere ich immer wieder Systemdateien als Backup. Das ist aber eher eine Spielerei.

Weiterhin habe ich eine Netzwerkkarte mit vier Ports verbaut, mit der ich den Server mehrfach via LACP ans Netzwerk anbinden kann. So hat bspw. die Windows-VM ein eigenes Netzwerkinterface. Auch habe ich noch ein zweites (Redundanz) Netzteil eingebaut.

Hier liegen dann noch Ersatzplatten herum. Alles zusammen schätze ich, dass der Server „nur“ um die 1.200 Euro gekostet hat.

Das Gerät läuft jetzt hier seit mindestens einem halben Jahr durchgängig mit FreeBSD und völlig problemfrei. Nächtliche Backups gehen auf einen weiteren Home-Server sowie auf meinen Online-Server.

Bisher kann ich das System empfehlen, warten wir aber mal ab, wie es in zwei Jahren aussieht.

KooKooK: App für neurodivergente Menschen als Testballon

Thorsten Geppert Schreib einen Kommentar

Vor einiger Zeit wollte ich mich mit QML näher auseinandersetzen und suchte nach einer Projektidee. Als Domain hatte ich noch „kookook.org“ bei mir registriert und dachte, dass ich einfach damit was mache. Bei der Projektidee ging es, allen voran, darum, dass ich mich mit dieser Technik auseinandersetzen und mich vor allem auf mobile Plattformen (iOS, Android) konzentrieren wollte.

Ich habe mich entschieden, an einer App für neurodivergente Menschen zu arbeiten, um ein Ziel vor Augen zu haben. Herausgekommen ist jetzt eine kleine App, mit der man seine Stimmungen und Reize tracken kann. Das Programm kann noch nicht viel, aber vielleicht interessiert es jemanden.

Hier sind ein paar Screenshots:

Es gibt auch eine Android-Version, die ist im Google Play Store allerdings noch nicht freigegeben, da ich dafür erst 12 Tester benötige und mir dazu gerade die Zeit fehlt. Wer Lust hat: Gerne per E-Mail an mich, ich schalte die Version dann frei.

Die App ist kostenlos und benötigt keine Internetverbindung.