FreeBSD ist in der öffentlichen Wahrnehmung ein Nischensystem unter den freien Systemen, obwohl es eine große Geschichte und viele Vorteile gegenüber Linux hat. Mittlerweile läuft es recht zuverlässig auf Standardhardware. Dank eines engagierten Teams ist KDE Plasma immer auf dem neuesten Stand.

BSD – Mehr als der Kernel

Es gibt verschiedene BSD-Systeme. Ein Blick in den Wikipedia-Artikel zur UNIX-Geschichte hilft beim groben Verständnis. Bekannte Vertreter sind neben FreeBSD DragonflyBSD, NetBSD und OpenBSD. Eine Liste findet sich ebenfalls bei Wikipedia. Das BSD-Ökosystem ist jedoch bei weitem nicht so fragmentiert wie die Linux-Welt. BSD wird eher selten auf dem Desktop eingesetzt und häufiger auf Servern und in spezialisierten Anwendungsszenarien. Grundsätzlich ist BSD aber auch für den Desktop-Einsatz geeignet.

BSD-Systeme zeichnen sich dadurch aus, dass sie mehr als nur den Kernel bezeichnen. Bei FreeBSD gibt es keine organisatorische Trennung zwischen dem Kernel, den zentralen Bibliotheken sowie dem sogenannten “Userland”. BSD-Varianten wie FreeBSD fassen alle diese Teile zusammen und entwickeln sie gemeinsam weiter, wodurch ein hohes Maß an Konsistenz erreicht wird. Dieses Userland unterscheidet sich stark von den GNU-Umgebungen der Linux-Distributionen, weshalb man nicht allzu viele Gemeinsamkeiten erwarten sollte. FreeBSD-Versionen wie die aktuelle 14 beziehen sich daher auf dieses Kernsystem und nicht auf die Anwendungen der Ports.

Diese strikte Trennung von Basissystem und nach FreeBSD portierte Anwendungen wird durch die getrennte Verwaltung deutlich. Mit pkg verfügt FreeBSD zwar über einen Paketmanager für Binärpakete, vergleichbar mit den Pendants unter Linux. Dieser ist jedoch nicht für das Basissystem zuständig und muss nach der Installation des Basissystems separat installiert werden. Das eigentliche FreeBSD-Kernsystem wird mit dem Befehl freebsd-update aktualisiert. Mit pkg verwaltet man nur die zusätzlich installierten Programme aus den Ports, was aber unter anderem auch den Desktop und vieles mehr umfasst.

Eine Besonderheit von BSD ist ZFS. Dieses ursprünglich von Sun entwickelte Dateisystem wird von vielen Experten als das beste Dateisystem für freie Systeme angesehen und Canonical hat daher auch versucht, es in Ubuntu zu implementieren. Lizenzfragen bremsen dies immer wieder aus. Vergleicht man die Funktionen, so fällt auf, dass vieles, was ZFS auszeichnet, nun mit Btrfs unter Linux erreicht werden soll.

FreeBSD zeichnet sich durch eine exzellente Dokumentation aus. Diese sollte man bei allen Problemen zu Rate ziehen.

Desktop und Anwendungen über ein Paketsystem

Desktopumgebungen und Anwendungen werden daher getrennt von diesem Kernsystem installiert und gewartet. Die Trennung zwischen Kernsystem und Installation über pkg wird im Dateisystem abgebildet. Die installierten Programme liegen in einer Struktur unterhalb von /usr/local und sind nicht wie bei Linux im System verteilt. Nur das Kernsystem liegt direkt unterhalb von /.

Eine Recherche in den Quellen der Pakete ist über Freshports möglich. Meine persönlichen Nutzungsbedürfnisse sind damit abgedeckt. Die meisten Desktopumgebungen und Programme aus der Linux-Welt sind dank POSIX-Kompatibilität auch für FreeBSD verfügbar. Was fehlt, sind Programme, die auf Abstraktionsschichten basieren, die es nur für Linux gibt, oder viele grafische Administrationsprogramme. Ebenso gibt es kaum proprietäre Anwendungen wie SoftMaker Office, Synology, Spotify usw., die sich auch unter Linux großer Beliebtheit erfreuen.

Installation

Die Installation erfolgt über die Images von FreeBSD.org. Linux-Benutzer werden sich schnell zurechtfinden. Allerdings sind einige Voraussetzungen zu beachten. FreeBSD kann nicht mit SecureBoot umgehen, es muss also deaktiviert sein. Außerdem erfolgt die Installation entweder über das Image oder über ein Ethernetkabel. Live-Images oder Netinstall über WLAN sind bei FreeBSD nicht der Normalfall.

Die Installationsroutine erinnert in ihrer schlichten Oberfläche an den klassischen Debian-Installer. Wer sich einen Eindruck verschaffen möchte, dem sei dieses YouTube-Video ans Herz gelegt. Es gibt sehr wenige Konfigurationsoptionen und entsprechend auch wenig Möglichkeiten bei der Installation etwas falsch zu machen. Im Wesentlichen werden das Tastaturlayout und die Zeitzone festgelegt, ein Root-Kennwort erstellt, ein Benutzer angelegt und bei der Partitionierung zwischen ZFS oder UFS gewählt.

Nach einem Neustart begrüßt einen die nackte Shell. Hier stellt man zunächst sicher, dass das Basissystem auf einem aktuellen Stand ist:

# freebsd-update fetch

Im Anschluss installiert man die Paketverwaltung

# pkg

Aus dieser Paketverwaltung bezieht man X, Plasma und alle Anwendungen. Ein rudimentäres KDE Plasma bekommt man mit folgenden Befehlen.

# pkg install xorg
# pkg install x11/kde6
# pkg install sddm

Zusätzlich benötigt man i.d.R. noch Grafiktreiber. Wenn es hier Probleme gibt hilft die sehr gute Dokumentation weiter.

Theoretisch sollte Wayland auch mit FreeBSD funktionieren, aber ich habe es auf meiner Hardware nicht zum Laufen gebracht.

Für einen erfolgreichen Start sind noch ein paar Konfigurationsänderungen notwendig. Dazu trägt man in der zentralen Konfigurationsdatei /etc/rc.conf folgende Zeilen ein:

dbus_enable="YES"
sddm_enable="YES"

Nach einem Neustart sollte einen SDDM mit einem Standarddesign begrüßen. Nach dem Login erscheint ein rudimentärer Plasma-Desktop, der nun mit weiteren Programmen ergänzt werden kann.

Warum FreeBSD?

Dieser Artikel ist auf Anregung aus einem Kommentar unter diesem Artikel entstanden und beantwortet meiner Meinung nach auch die Frage, warum man FreeBSD einsetzen sollte.

FreeBSD zeichnet sich durch eine deutlich konservativere Entwicklung im Basissystem aus. Es gibt zwar eine aktive Weiterentwicklung, aber große Brüche, wie sie Linux in den letzten Jahren erlebt hat, gibt es meiner Meinung nach bei FreeBSD seltener. Die Entwickler sind stets um Abwärtskompatibilität bestrebt und zielen aufgrund der Einsatzszenarien auf eine wesentlich größere Stabilität ab als dies bei Linux der Fall ist.

Wesentliche Einstellungen werden immer noch auf der Kommandozeile in zentralen Dateien vorgenommen. Wer mit der Entwicklung von Linux unzufrieden ist, weil sie zu schnell geht, zu kompliziert ist oder zu viele Abstraktionsebenen einzieht, sollte sich FreeBSD unbedingt ansehen. Anstelle unaufhörlich die Entwicklung bei Linux zu beklagen, wäre es für manche vielleicht einfach besser auf ein System auszuweichen, das ebenso frei ist (manche würden sagen „freier“) und eher den eigenen Bedarfen entspricht.

Natürlich kann man auch einfach aus Interesse einen Blick auf BSD werfen, obwohl man mit Linux zufrieden ist. Es ist ein freies System mit einer tollen Entwicklungsgeschichte und als solches auf jeden Fall einen Blick wert. Außerdem glaube ich, dass das Kennenlernen von BSD-Systemen das Gefühl für UNIX als Systemfamilie verbessert und warum bei Linux nicht alles perfekt ist.

Ausprobieren kostet nichts und ist allemal sinnvoller als die x.te Linux Distribution zu testen, die sich kaum von den anderen unterscheidet.

Mir persönlich fehlen hier ein paar Errungenschaften, die Linux in den letzten 10 Jahren erreicht hat. Von grafischen Administrationsoberflächen bis Secure Boot und TPM. Deshalb beabsichtige ich aktuell keinen Wechsel auf FreeBSD.

Ich habe seit ich denken kann zwei Aliase in meiner .bashrc:

alias neustarten='sudo shutdown -r now'
alias ausschalten='sudo shutdown -h now'

So kann ich meinen PC ausschalten oder neustarten, und muss nicht viel tippen.

Diese Art des shutdown ist jedoch eher ungeeignet, und auch systemctl reboot und systemctl poweroff sind mit KDE-Plasma nicht ideal, da kein korrekter Logout aus der Plasmasession erfolgt, sondern die Kiste einfach alles abwürgt und runterfährt.

Um mich also korrekt aus Plasma abzumelden, und dann erst herunterzufahren, habe ich die Aliase entsprechend angepasst.

alias neustarten="[[ -o login ]] && logout || qdbus org.kde.Shutdown /Shutdown  org.kde.Shutdown.logoutAndReboot"
alias ausschalten="[[ -o login ]] && logout || qdbus org.kde.Shutdown /Shutdown  org.kde.Shutdown.logoutAndShutdown"
alias logout="[[ -o login ]] && logout || qdbus org.kde.Shutdown /Shutdown  org.kde.Shutdown.logout"

Diese Variante dauert etwas länger, eben weil alles erst korrekt abgemeldet wird, führt aber genau das aus, was passieren würde, wenn ich mich per UI-Knopf abmelde oder den Rechner neustarte. Ich muss bei dieser Variante auch kein Passwort eingeben, da der Befehl ohne “sudo” auskommt (genau so wie die UI-Knöpfe).

Meine alten Aliase habe ich aber unter neuer Kennung beibehalten, aus nostalgischen Gründen, und falls ich mal außerhalb einer Plasmasitzung zügig rebooten will.

alias neustartenc='sudo shutdown -r now'
alias ausschaltenc='sudo shutdown -h now'

Weblinks

• https://discuss.kde.org/t/logout-reboot-and-shutdown-using-the-terminal/743/9

Diskussion per Matrix unter https://matrix.to/#/#produnis-blog:tchncs.de

 

Viele Linux-Anwender halten sich für fortschrittlich und innovativ. Dieses Selbstbild rührt daher, dass es ihnen vor langer Zeit gelungen ist, sich von Microsoft zu lösen. Das Phänomen kennt man von anderen Gruppen wie den Alt-68ern, bei denen Fremd- und Selbstbild mit der Zeit auseinander klaffen. Dabei sind viele Linux-Anwender strukturkonservativ und lehnen Veränderungen krampfhaft ab. Einige Beispiele von bis D bis W.

Aktuell ist eine Debatte um run0 und sudo entbrannt. Die alten Konfliktlinien werden wieder sichtbar. Dieser Rückblick auf die letzten 15 Jahre soll ein wenig Gelassenheit vermitteln. Innovationen haben bei Linux immer Widerstand hervorgerufen. Am Ende haben sie sich aber meist durchgesetzt. Die verzögernden Konfliktmuster sind unvermeidlich und liegen in der Nutzerschaft begründet.

Umstrittene Neuerungen von D bis W

Dateisysteme

Ältere Linux-Anwender können sich noch an die Einführung von ext4 erinnern. Es gab damals ein paar Bugs bei der Einführung. Diese wurden maßlos überzeichnet und ließen Anwender an ext3 festhalten. Damals hieß es dann, dass doch niemand ext4 braucht, weil ext3 super ist. Das gleiche Drama begleitet bis heute Btrfs, das zwar inzwischen Standard bei vielen großen Distributionen wie openSUSE oder Fedora ist, aber dem immer noch vermeintliche Instabilität vorgeworfen wird, weshalb so mancher ältere Handbuchautor weiterhin ext4 empfiehlt.

Flatpak

Flatpak/Snap soll die Grenzen der klassischen Paketverwaltung überwinden. Die Palette der Probleme reicht von fehlendem Sandboxing über die Abhängigkeitshölle bis hin zu fehlender Abwärtskompatibilität etc. pp. Dennoch finden viele ältere Linux-Anwender diese Paketverwaltung perfekt und wollen keine Alternative. Die Entwicklung geht derzeit in Richtung Flatpak – Überraschungen nicht ausgeschlossen.

NetworkManager

Jüngere Anwender können es sich gar nicht mehr vorstellen, aber den NetworkManager, den heute alle Distributionen mitliefern, gab es nicht immer. Eine erste Version gab es 2004, natürlich von Red Hat. Nach und nach übernahm der NetworkManager die Kontrolle über Ethernet, WLAN, (Open)VPN und andere Verbindungen. Zuletzt verdrängte er mit dem Kommandozeilentool nmcli die letzten Konkurrenten. Überladen und überflüssig fanden NetworkManager viele Anwender. Schließlich gab es ja noch ifupdown und wpa_supplicant.

PulseAudio

PulseAudio wurde 2008 mit Ubuntu 8.04 einer breiten Nutzerschaft zugänglich gemacht. Sofort begannen die üblichen Diskussionen. PulseAudio sei überdimensioniert und zu undurchsichtig. Man brauche es sowieso nicht. ALSA und esound reichen völlig aus. Noch heute findet man viele Anleitungen, wie man PulseAudio abschaltet und durch damals abgekündigte Backends ersetzt. Daran erinnert sich heute niemand mehr und PulseAudio war bis zur Einführung von PipeWire Standard.

systemd

Braucht man eigentlich nicht mehr weiter ausführen. Die Entwicklung und Implementierung von systemd in die meisten Linux-Distributionen ist ein Paradebeispiel für Hass und Hetze in der Linux-Welt. Weil es von Lennart Poettering ist, weil es anders ist, weil Administratoren ihre Init-Skripte umschreiben mussten, weil Unix-Veteranen umlernen mussten. Heute gibt es eine Handvoll Distributionen, die systemd nicht verwenden. Ihre Gemeinsamkeit: Wenige Benutzer und keine größere Relevanz im Linux-Ökosystem.

systemd-logs

Binäre Logs benötigen weniger Speicherplatz, schonen die SSDs durch wesentlich effizientere Schreiboptionen und sind besser gegen Manipulation geschützt. Aber sie waren neu und anders, und man brauchte ein winziges Tool, um auf sie zuzugreifen. Außerdem kamen sie aus dem Systemd/Poettering Stall. Genug für massiven FUD und Aufruhr bei der Einführung. Heute benutzen es fast alle Distributionen.

PolKit

PolKit (früher: PolicyKit) ist ein System zur Vergabe von Berechtigungen an Benutzer. Damit bricht das System die traditionelle Trennung zwischen Benutzer- und Administratorkonto auf. Das war umständlich und anders und löste 2011, als PolicyKit weitere Verbreitung fand, massive Vorbehalte aus. Weil die bisherigen Lösungen nicht mehr funktionierten etc. pp. Heute funktioniert keine Linux-Distribution mehr ohne PolKit.

run0

Der neueste Zankapfel. Lennart Poettering hat sich sudo vorgenommen und präsentiert eine Alternative aus dem systemd-Stall. Sofort formiert sich Widerstand, denn es ist von Poettering und systemd steht irgendwo im Beschreibungstext. Dass die Konfigurationssyntax von sudo eine Katastrophe ist und mit visudo ein Werkzeug benötigt wird, damit Administratoren ihre Konfiguration nicht zerstören. Geschenkt!

Verzeichnisstruktur

Der sogenannte usrmerge bricht die veraltete UNIX-Verzeichnisstruktur auf und führt die Verzeichnisse unterhalb von /usr zusammen. Das ist für viele Anwendungsszenarien sinnvoll und die bisherige Struktur war auch nur historisch gewachsen (Warum das so ist, wurde hier mal aufgeschrieben). Das ändert nichts daran, dass es massive Vorbehalte dagegen gab und gibt, weshalb Community-getriebene Distributionen wie Debian mit massivem Zeitverzug nachziehen. Keine größere Distribution hält heute noch an der alten Struktur fest.

Wayland

Wayland wurde erstmals 2008 in groben Zügen skizziert. Es sollte X.Org ablösen, da X.Org nicht mehr den damaligen Anforderungen entsprach. Zur Erinnerung: X.Org war ein Produkt der 1980er Jahre und letztlich auch für Anwendungsszenarien der 1980er Jahre konzipiert. Der Code ist nach Aussage aller Programmierer, die daran gearbeitet haben, schon lange nicht mehr wartbar und de facto wird X nur noch von Red Hat gepflegt. X ist konzeptionell unsicher und das lässt sich nicht ändern. Programme wie xinput können z.B. alle Tastatureingaben mitschneiden. Niemand, der etwas von X.org versteht, hat diesen Zustand bestritten. Es gibt anhaltende Proteste gegen Wayland. Weil X.Org doch funktioniert, weil liebgewonnene Dinge wie Netzwerktransparenz nicht mehr funktionieren, weil es Änderungen am Desktop geben muss, weil es neu und anders ist. Die ersten Distributionen entfernen jetzt die alten X11-Sessions. Wenn Red Hat die Wartung einstellt, ist der Tod des alten Systems nur noch eine Frage der Zeit.

Gesamtschau

Bestimmt habe ich ein paar vergleichbare Phänomene vergessen. Der Debattenverlauf ist eigentlich immer gleich:

1. Es gibt eine bestehende Lösung. Diese Lösung funktioniert aber ist nicht perfekt und wurde unter anderen Rahmenbedingungen entwickelt.
2. Die bestehende Lösung lässt sich nicht konstruktiv weiterentwickeln.
3. Es gibt einen neuen Ansatz.
4. Weil der Ansatz neu ist, zieht er sofort Kritik auf sich. Wenn es keine Argumente gibt werden Lügen und Halbwahrheiten verbreitetet.
5. Am Ende setzt sich die neue Lösung nahezu immer flächendeckend durch.
6. Niemand will mehr etwas gegen die Lösung gehabt haben.

Die Argumente bedienen sich auch immer aus einem bestimmten Pool:

• Widerspricht dem KISS-Prinzip
• Widerspricht den UNIX-Prinzipien
• Ist unnötig
• Ist intransparent
• Ist unsicher
• Ist aufgeblasen

Glücklicherweise gibt es auch Ausnahmen. Die Einführung von Avahi als zeroconf-Implementierung löste meiner Erinnerung nach 2006 keine größere Debatte aus. Die meisten Anwender waren schlicht froh, dass es diese Implementierung nun endlich gab. HAL trauerte nach der Ablösung durch udev/upower und Konsorten auch niemand nach. Gleiches gilt für Gummibot / systemd-boot und das obwohl sogar systemd im Namen vorkommt.

Haben diese Lösungen Linux komplizierter gemacht? Vielleicht. Ich erinnere mich durchaus noch an Zeiten, in denen man Arch Linux in 2-3 Dateien konfiguriert hat und sich das nach Kontrolle angefühlt hat. Diese Zeiten sollte man aber auch nicht verklären, denn damals ging einfach viel nicht, was mit anderen Systemen schon funktionierte und die Tätigkeiten, für die wir unsere Systeme verwendeten waren viel beschränkter.

Ursache

Die Ursache liegt meiner Meinung nach in der Struktur der Linux-Anwender auf dem Desktop.

• Fast alle Nutzer sind Umsteiger, die von Windows oder macOS auf Linux umgestiegen sind, um bestimmten Entwicklungen zu entgehen. Sie haben in der Regel eine steile Lernkurve hinter sich und glauben, das System verstanden zu haben. Entsprechend frustriert reagieren sie auf neue Entwicklungen bei Linux, die sie nicht verstehen oder nicht verstehen wollen, weil sie ihren Wissensstand bedroht sehen.
• Während der steilen Lernkurve haben sie oft verinnerlicht, dass die Lösung bei Linux besser ist als bei macOS oder Windows. Die Überlegenheit ist vielen Anleitungen und Erklärungen für Umsteiger immanent. Warum diese bessere Lösung nun doch schlechter als eine Neuentwicklung sein soll, erschließt sich ihnen nicht. Es stellt infrage, ob die Lösung wirklich besser war.
• Die Community ist stark männlich geprägt. Das war sie schon immer. Es liegt am Thema, der Netzkultur etc. pp. Für die Debattenkultur war das nie förderlich.
• Das Durchschnittsalter steigt mangels Nachwuchs stetig an. Viele Linux-Anwender haben ihre prägenden Migrationserfahrungen irgendwann zwischen 2005 und 2010 oder sogar noch früher gemacht. Das ist fast schon zwangsläufig, weil der Desktop als privat genutztes Gerät für jüngere Anwender nicht mehr selbstverständlich ist und Linux auf modernen mobilen Geräten nie angekommen ist.

Der Kausalzusammenhang zur Debattenkultur zwischen Geschlecht und Generation ist kein exklusives Linux-Thema. Studien zur Verbreitung von Fake News zeigen, dass Männer und ältere Menschen anfällig dafür sind und diese häufiger verbreiten. Zusammen mit den ersten zwei Punkten führt zu einem stark innovationsfeindlichen Klima. Alles was wirklich neu ist, wird kritisch beäugt und schlecht gemacht. Positives Feedback bekommen nur noch kosmetische Änderungen am bestehenden Status quo.

Lösung

Das Schöne an der Situation ist, dass es für alle eine Lösung gibt. Wer die neuen Entwicklungen gut findet und nur von den Debatten genervt ist, kann sich zurücklehnen. Auf diese Unix-Veteranen hören die Entwickler und Distributoren schon lange nicht mehr. Kritische Kommentare haben keine der oben genannten Entwicklungen verhindert. Entwicklung und die Diskussion in der Community haben sich tendenziell entkoppelt. Das lässt sich mindestens seit 2010 beobachten (Entwicklung GNOME 3).

Wer sich an den Entwicklungen stört, dem empfehle ich immer FreeBSD. Das ist mittlerweile auf dem Desktop sehr gut einsetzbar und zeichnet sich durch eine wesentlich konservativere Entwicklungsrichtung aus. Dort bleibt man von solchen ungeliebten Änderungen und Vereinfachungen weitgehend verschont. Die geringe Wechselbereitschaft zu FreeBSD wundert mich immer und lässt mich mutmaßen, dass die geringe Lernbereitschaft für neue Tools schon so weit ausgeprägt ist, dass man sich auch kein neues Unix-System mehr anschauen will. Schließlich ist man ja schon ein mal migriert: Zu Linux. Noch eine Migration möchte man sich selbst scheinbar nicht zumuten. Das ist dann zu viel Innovation.