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)

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.

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.

Softwareentwicklung Teil 2: Weitere Erfahrungen

Thorsten Geppert Schreib einen Kommentar

Mir fallen noch einige weitere Dinge ein, die ich hier zu teilen versuche. Meist geht es um technische Schulden und, für mich, komische Ansätze in der Verwaltung von Firmen.

Ich war vierzehn Jahre lang in einem Unternehmen beschäftigt und das hat, zumindest in Bezug auf die IT, auf die IT-Abteilung gehört. Haben wir immer die richtigen Entscheidungen getroffen? Nein. Aber zumeist und aus den fehlgeschlagenen Entscheidungen haben wir immer gelernt. Ich möchte das hier einmal als Positivbeispiel anbringen. Ich schätze, es muss 2012 gewesen sein, als wir neue Server anschafften. Zwei baugleiche Geräte für Redundanz. Wir kamen auf die Idee, dort Festplatten mit 4TB Speicherkapazität einzubauen und entschieden uns für Western Digital SAS. Leider wusste keiner von uns, und da hätten wir uns vorher definitiv noch einmal genauer informieren müssen, dass es SAS-Festplatten und Nearline-SAS-Festplatten gab. Wir waren zwar verwundert über die Preise, denn eine solche Platte mit 4TB in etwa so viel wie welche mit 960GB, aber wir forschten nicht weiter nach, sondern freuten uns.

Wir klatschten die Server also mit einer Menge dieser Platten voll, richteten darauf zraid-2 ein (RAID 6) und banden die Geräte ins Netzwerk ein. Wie zuvor auch, exportieren wir die Home-Laufwerke gut 50 Clients per NFS. In Tests funktionierte alles tadellos und wir schlossen glücklich und schnell die Umstellung ab. Dann kamen die Leute und wollten arbeiten. Es kam zu großen Wartezeiten und ein gewisser Unmut machte sich breit, denn das System performte nicht. In einzelnen Tests lief es hervorragend, sequentielles Schreiben und Lesen funktionierte tadellos. Aber in der Masse und bei der Menge an Dateien war es grottenlangsam und unbenutzbar. Wir suchten zu zweit sicher einen Monat nach dem Problem, bis ich auf die Idee kam, dass die Platten in Form der Hardware schuldig waren. Wir stellten dann ein solches Szenario nach und stellten dem gegenüber ein System mit echten (super teuren) SAS-Festplatten und siehe da: Genau da war das Problem. Die Lösung war schnell da: Neue Festplatten mussten her. Wir besprachen das mit der Geschäftsleitung, räumten ein, dass es letztlich unsere Schuld war, wir das aber vorher nicht wussten und es kein böser Wille war. Das Ende vom Lied war, dass wir neue Festplatten, die teuer waren und eine niedrige Kapazität hatten, kauften und einbauten. Das kostete die Firma natürlich eine Unmenge an Geld (ich habe noch gut 12.000 Euro im Kopf). Uns wurde aber nicht der Kopf abgerissen. Erstens wäre der weitere Betrieb in alter Form ohnehin teurer geworden, da niemand arbeiten konnte, und zweitens wusste man, dass Fehler passieren. Wir haben das zusammengefasst, noch einmal berichtet, was wir gelernt hatten, und solche Probleme traten dann nie wieder auf.

In einer anderen Firma sprach ich einmal an, dass wir einen gewissen Style-Guide einführen sollten, und dieser bezog sich nur auf die Benennung von Variablen, Konstanten und Funktionen. Die Benennung solcher Dinge kann man weiter unten in meinem vorherigen Artikel nachlesen, da habe ich ein Beispiel. Ich sprach mich für „sprechende“ Namen aus. Dies wurde abgelehnt, denn dann hätte man ewig lange Namen, mehr aussagen würden diese auch nicht, und man würde sich tottippen (VI(M) war der Editor der Wahl und mit [CTRL]+[p] bzw. [CTRL]+[n] ergänzt er begonnene Namen vollautomatisch). Aufgrund der Ablehnung und auch aufgrund anderer, vorheriger und späterer Aussagen, war mir klar, dass da keine zielbringende Diskussion möglich war. Also ließ ich es.

In der selben Firma kam man auf die Idee, die (teuer zu bezahlenden) Mitarbeiter ein bis mehrmals pro Woche (später dann die Entwickler, die an einem gewissen Projekt arbeiteten, alle zwei Wochen) halbtägig in den technischen Service zu stecken. Der Tenor, so ich mich noch richtig erinnere, war, dass diese dann mehr vom Drumherum mitbekommen und Prozesse besser verstehen. Man war dann in der Tickethölle und musste bestimmte, ausgewählte, redundante Aufgaben abarbeiten. Das Problem: Für viele Serviceaufgaben gab es entweder keine Tools oder diese waren so dermaßen komplex, fehleranfällig und schwergängig, dass sie ein „normaler“ Servicemitarbeiter nicht hätte benutzen können. Bereits einfache Aufgaben konnten ganze Prozesse zerschießen. Anstatt die Softwareentwickler laut ihrer Kompetenzen dazu zu bringen, Tools zu entwickeln, die der Service nutzen hätte können, nutzten wir die halbgaren Tools in der Hoffnung, nichts Schlimmeres zu machen. Doch trotz großer Vorsicht passierte dies ab und an, auch mir zwei Mal. Einmal, ich weiß es noch, haben ein Kollege und ich mehr als einen halben Tag daran gesessen, das Problem zu fixen. Dabei wäre es wirklich sinnvoller gewesen, diese Tools robust zu machen.

Mir fällt noch ein Beispiel in dieser Firma ein. Wir hatten einen Workshop und mussten danach irgendwelche Funktionen noch fertig machen. Beim Testen wurde bei einem der komplexen Parameter aus Versehen die falsche Datenbank angegeben. Keinem von uns, wir waren drei oder vier Leute, fiel dies auf. Leider wurden dann wichtige Datensätze von Kunden in der Produktivumgebung überschrieben bzw. gelöscht. Die Produktivumgebung für mehrere tausend Kunden war nicht vollständig von der Entwicklungsumgebung abgeschirmt. Mein Chef hat es zwar hinbekommen und war auch nicht böse, aber es hätte auch anders ausgehen können. Beim Vorschlag, dass sowas irgendwie anders gelöst wird, kam nur ein lapidares „Nutzen Sie doch einfach die richtige Datenbank.“. Schlussendlich wurde doch zumindest ein Parameter im Programm umbenannt.

Es gibt an dieser Stelle zwei wichtige Dinge:

  1. Die Fehlerkultur in einem Unternehmen bestimmt auch die Qualität der Software, die Weiterentwicklung dieser, die der Entwickler und zu guter Letzt die des Unternehmens.
  2. Das Unternehmen sollte unbedingt die Vita der Leute, die es beschäftigt, ansehen. Wer kann wo am besten eingesetzt werden? Wert hat wo die besten Erfahrungen? Usw. usf. Das wurde in einigen Unternehmen, in denen ich war, nicht getan.

Die schrecklichste Zeit, die ich je hatte, waren meine zwei Monate bei einem Softwareunternehmen in Koblenz. Das Unternehmen hatte unglaublich viele Probleme. Neben der bescheidenen Bezahlung für die Programmierer war allen voran die Qualität des Codes völlig unzulänglich. Niemand sah sich meine Vita an, doch einer meiner Programmierkollegen meinte irgendwann: „Er soll sich doch mal die Memory-Leaks in unserer Software ansehen, er kennt sich da aus.“

Ich wühlte mich also durch etliche Zeilen kaum lesebaren Codes, da es auch hier keinen einheitlichen Style gab. Viel schlimmer war aber, dass ich nur Zugriff auf einen auf ein Core-System aufsetzenden Code hatte, aber nicht auf das Core-System selbst. Im Core-System gab es aber etliche Probleme. Zugriff bekam ich trotzdem nicht, so dass ich meiner Aufgabe überhaupt nicht sinnvoll nachgehen konnte. Dass nur ich das alles kaum verstand, sah man am Versionsverwaltungssystem (Subversion): Von den meisten Kollegen gab es maximal einen Commit pro Woche und der Commit hatte meistens nur ein bis drei Codezeilen inne. Niemand stieg durch das System.

Auch die Aufteilung innerhalb dieser Firma war äußerst komisch. Es kam SAFE zum Einsatz, das aber nur nebenher. Aufgeteilt wurde die Entwicklung zwischen zwei Menschen: dem Requirements-Engineer (kurz RE) auf der einen, dem Programmierer auf der anderen Seite. Gehen wir von einer Rolle als Senior-Softwareentwickler (was auch immer das sein soll) aus. Der RE bekam den Auftrag für ein neues Modul oder einen Teil eines Moduls. Dieser beschrieb dann, was gemacht werden sollte (aus meiner Sicht noch ok) und dann unterteilte er es in etliche Untertasks. D.h. der RE musste dem Softwareentwickler seine eigenen Kompetenzen wegnehmen und für ihn planen, wie der Softwareentwickler dies umzusetzen hatte. Und der Softwareentwickler musste auf diese Tickets seine Zeiten buchen (das war übrigens die Hauptaufgabe: Verwalten seiner Zeiten, jede Sekunde musste protokolliert werden) und sich dafür rechtfertigen, wenn er länger brauchte oder Dinge nicht funktionierten. Das habe ich in den zwei Monaten, in denen ich da war, öfter erlebt. Man musste sich vor seinem Vorgesetzten und mitunter vor dessen Vorgesetzten verantworten. Es war die pure Hölle, was ich mittlerweile aber auch verstehen kann, weiß ich doch mittlerweile, in welcher Szene sich der Gründer des Unternehmens widerwärtig aufhält.

Kommen wir noch einmal auf die erste Firma zurück. Dort war eines der Probleme, wie ich in einem anderen Artikel bereits schrieb, dass unglaublich viel Code generiert wurde. Dabei ging es um eine Art OR-Mapper für DBMS und XML. Objektorientierte Entwicklung und generische Programmierung wurden hier immer wieder abgelehnt, obwohl diese unglaublich viele Probleme gelöst hätten. Man entschied sich für die Erneuerung des Codes für eine Multiparadigmensprache. Diese kann zwar Objektorientierung, aber nicht wirklich Vererbung. Warum die Wahl auf diese Programmiersprache fiel, war mir nie klar. Letztlich wurde das damit bekräftigt, dass die neue Generation von Programmierern kein C mehr kann. Auf C basierte die meiste alte Software (wenig auf C++, Ruby, Python, Shell-Scripts, usw.). Die Wahl hielt ich für suboptimal. Ein sinnvoller Weg wäre vielleicht gewesen, auf C++ umzusteigen. Da ein Projekt bereits in C++ umgesetzt war, waren auch schon bestimmte Kompetenzen vorhanden. Auch hätte man einen Teil des alten Codes leichter weiterverwenden können, als es mit der ausgewählten Programmiersprache möglich war (wenn diese auch C unterstützte). Die Ablösung wäre vielleicht einfacher gewesen, aber natürlich auch, dass Programmcode 1:1 übernommen worden wäre, was vielleicht nicht das eigentliche Ziel war. Es wurde allerdings Code übernommen und nahezu 1:1 in die neue Programmiersprache gesetzt. Variablen hießen gleich, Funktionen hießen gleich, der Programmablauf war der gleiche.

Zum Einsatz kamen zwei DBMS. Ein teures von einem teuren Hersteller und, für das neue Projekt, ein super gutes, welches ich auch oft empfehle. Beide DBMS wurden aber nicht wirklich als DBMS genutzt, sondern nur als Puffer für irgendwelche Daten. Auch auf vernünftige referentielle Integrität wurde, so wie ich die Datenstrukturen wahrnahm, verzichtet. Je nachdem, ob man in der Entwicklung war und Daten löschen wollte, musste man die händisch aus etlichen Tabellen entfernen. Von Normalisierung und Stored Procedures usw. müssen wir gar nicht sprechen.