FreeBSD oder OpenBSD für Laptop

PMc

Well-Known Member
Hallo,

normalerweise hab ich überall FreeBSD - und dafür hab ich auch das ganze management, deploy, backup, firewall, logfile-collector usw. alles konfektioniert.

Jetzt hab ich hier einen Laptop. Und suspend/resume geht nicht. Das ist offenbar kein device-treiber Problem und kein Grafik-Problem, sondern der kommt überhaupt nicht zurück zur Einsprungstelle im real-mode, und rebootet nach dem resume-Versuch. Vermutlich ein acpi Problem.

Dann hab ich testweise einen OpenBSD Stick gebootet, und damit funktioniert es.

Jetzt schaue ich mir den Code an. Im OpenBSD ist das klein und übersichtlich, offensichtlich selbergestrickt, und man kann ein paar printf() reinwerfen und die sieht man dann auch.
Im FreeBSD ist es ein Riesenpaket unter contrib, und man muss noch ein extra Debug-System einschalten, und ob man damit dann das sieht was man wissen will ist noch unklar - bisher sehe ich jedenfalls nichts.

Dann das Wlan (iwlwifi). Das funktioniert, aber mit Traffic crasht es alle fünf Minuten. Mit OpenBSD scheint das stabil zu laufen (noch nicht genug genutzt um was richtig verläßliches zu sagen).

Die Source dafür - dasselbe Bild: im OpenBSD eine einzelne Datei. Im FreeBSD ein Verzeichnisbaum mit sieben Unterverzeichnissen.

Was stimmt da nicht?

Und, btw: mir geht es nicht darum, hier eines gegen das andere auszuspielen oder sowas. Ich nutze intensiv ipfw, netgraph, kerberos, bhyve, zfs; vieles davon mit lokalen Patches - und das scheint es alles im OpenBSD nicht zu geben. Ich frage mich vielmehr, ob da ein Fehler in der Entwicklungsstrategie oder QA liegt, oder ob man für Laptops generell besser OpenBSD (was dann auch wieder die Frage aufwirft ob da ein Fehler in der Entwicklungsstrategie oder QA liegt...)
 
Als ich vor langer Zeit mal Open-BSD probiert hatte, erzählte man mir, die meisten der Entwickler dort arbeiteten mit Laptops. Das könnte zumindest erklären, dass dann der Fokus auch eher auf den Laptop-typischen Funktionen liegt.

Obwohl die Schlaf-Modi bei meinen Lenovos mit FreeBSD halbwegs funktionieren (wenn man sie nicht allzu oft verwendet, im Laufe der Zeit verrennt sich immer mal was), benutze ich sie gar nicht mehr. Das Aufwachen geht nicht wesentlich schneller, als der Start von 13.1 von einer SSD, von einer NVME dürfte das nochmal schneller sein und anschließend habe ich keinen Ärger und weiß mit Sicherheit, dass bei AUS kein Strom mehr fließt.
 
Ich glaube es gibt mehrere Gründe. Es dürfte eine Tendenz geben, dass die OpenBSD-Entwickler eher auch OpenBSD auf dem Laptop laufen haben, während man bei den FreeBSD-Entwicklern eher mal ein macOS oder ein Linux am Laufen hat.

Zum Thema Code. Das sind unterschiedliche Herangehensweisen. OpenBSD ist generell auf der Schiene möglichst wenig simplen Code zu haben und FreeBSD mehr auf der Schiene für alles eine Funktion zu haben. Ich habe über beides viele Projekte genutzt, an ihnen gedoktort, etc. und während mir derzeit die wenig Code, selber stricken meist mehr zusagt halte ich es nicht für eine falsche Strategie das anders zu machen. Beides hat Vor- und Nachteile, beides funktioniert (oder nicht) und es gibt zahlreiche Beispiele an denen man das sieht. Ich denke also, dass das eher philosophische Fragen sind wo sich wahrscheinlich noch in hundert Jahren die Geister dran scheiden werden.

Aber es gibt noch andere Themen. FreeBSD geht schon seit langem den Weg das System viel mehr als Framework anzusehen. Das macht es super brauchbar wenn man was aufbaut. Das sieht man meiner Meinung an vielen Ecken, wie dass man durchaus mal poudriere sowohl am Desktop als auch am Server aufsetzt, daran, dass es mittlerweile wohl zig Jail-Management-Tools gibt, daran dass Ports echt stark modifizierbar sind, daran, dass bei den Defaults des System auf Kompatibilität achtet und dann jeder ohnehin seine Maßnahmen hat um das zu konfigurieren, wie man möchte.

OpenBSD ist da mehr auf der Schiene "wir liefern ein ganzes System", was man wiederum daran merkt, was alles als "Basissystem" (von HTTP Server bis zum Window Manager) zählt, dass Ports selber zu Packages bauen einigermaßen verpönt und eher als unsupported gilt. Man hat ein eigenes Sound-System, sndio und alles an Software wird hingebogen, dass es läuft, und FreeBSD kann man auch dieses relativ einfach in der make.conf auswählen.

Ich denke, dass diese Dinge teilweise nicht wirklich bewusst stattfinden, sondern dass ein FreeBSD-Entwickler in einer Situation ist, wo das nicht wirklich so sichtbar ist, wie's einem User beim ersten Aufsetzen am Laptop geht. Wenn ein MacBook als Laptop und ein selbst gebautes Image mit dicker Config am Server verwendet wird dann ist man aus gutem Grund zufrieden.

Ein Effekt davon kann sein, dass auf OpenBSD alles Out Of The Box läuft, und wenn nicht man bei FreeBSD alles hinbiegen kann, damit es überhaupt läuft. Zumindest würde ich so meine Erfahrungen schildern.

Wenn man auf Bluetooth und NVIDIA-Treiber verzichten kann und einen Laptop nutzt der nicht eher ein Außenseitermodell ist (sprich, den auch OpenBSD-Entwickler nutzen) wird man am Laptop mit OpenBSD derzeit tendenziell glücklicher sein.

Um das mit Server zu vergleichen. Wenn man weiß man will hauptsächlich das Basissystem ist OpenBSD prima, wenn man sehr anpassungsfähig sein will/muss, wenn man eine stabile Möglichkeit braucht neues und alles zu mischen, breiten Support für Dinge, die Entwickler potentiell haben will braucht fährt man mit FreeBSD besser.

Also die Herangehensweisen sind eher unterschiedlich als richtig und falsch. Das soll nicht irgendwo versöhnlich sein, sondern ist im Softwarebereich häufig zu sehen. Ist auch bei Programmiersprachen, Datenbanken und sonstigen Dingen so, sonst hätte man sich bei all diesen Dingen wohl längst auf eine.. oder zumindest eine Art Dinge zu machen geeinigt.

Ab und zu färbt natürlich das eine auf das andere ab und beide Systeme sind einfach groß genug, haben Geschichte und unterschiedliche Entwickler und User, dass das natürlich vereinfacht ist und es Ausnahmen gibt. Ich denke aber, dass die Philosophien der beiden Projekte doch recht klar unterscheidbar sind und man die Auswirkungen entsprechend in den jeweiligen Projekten sieht.
 
Zurück
Oben