From RootForum Community » Wiki

Im wesentlichen gilt das Konsistenz-Argument für OpenBSD genauso wie für FreeBSD. Bei allen BSD-Systemen (nehmen wir mal noch NetBSD und Dragonfly dazu) wird der Kernel gemeinsam mit dem Userland entwickelt und released (im Unterschied zu Linux, wo der Kernel unabhängig von der glibc und den Coreutils entwickelt wird). Der Unterschied zwischen beiden BSDs liegt zum einen in der Philosophie, zum anderen in einigen technischen Details.

Ein wichtiger Unterschied sei aber gleich vorab noch erwähnt: FreeBSD verfügt über mehr Manpower als OpenBSD. Hinter FreeBSD steht eine eigene Foundation, so dass die Finanzierung der Entwickler von dieser Seite aus abgedeckt ist. Außerdem gibt es einige Unternehmen, die zur Entwicklung von FreeBSD regelmäßig beitragen bzw. FreeBSD-Entwickler beschäftigen. OpenBSD ist an dieser Stelle etwas dünner besetzt, wobei das zu einem gewissen Teil sicherlich auch an Theo's manchmal etwas "spezieller" Art liegen mag ("Shut up and code!").

Zunächst zur Philosophie: OpenBSD ist deutlich dogmatischer als FreeBSD. Das mag vielleicht zum Teil auch daran liegen, dass OpenBSD eine starke, zentrale Figur hat (Theo), während FreeBSD eher "im Kommittee" entwickelt wird. So hat beispielsweise OpenBSD die Adaptec-AAC-Treiber aus dem Kernel geworfen, weil Adaptec die Dokumentation nur unter einem NDA offengelegt hätte. FreeBSD ist an dieser Stelle viel pragmatischer ausgerichtet.

Ähnlich schräge Momente haben OpenBSD-User sicherlich auch erlebt, als Theo sich kurzerhand weigerte, einen Bug in den Secure Levels zu fixen - die seien "by design" sowieso scheiße und verdienten daher keinen Fix.

Darüber hinaus ist OpenBSD sehr konservativ bei der Veränderung bestehenden Codes oder der Aufnahme neuen Codes. Neuer Code muss grundsätzlich ein Peer Review durchlaufen; Dokumentation muss vorhanden und qualitativ hochwertig sein (daher hat z. B. OpenBSD IMHO die besten Man Pages, die ich je bei einem Unix gesehen habe). Als Konsequenz daraus entwickelt sich OpenBSD jedoch technisch nur sehr langsam weiter.

Im Gegensatz zu FreeBSD hält OpenBSD übrigens einen strikten Release-Fahrplan ein: Alle 6 Monate gibt's ein neues Release. Bei FreeBSD wird zwar ein ähnliches Intervall angestrebt, aber die Zyklen geraten in der Regel etwas länger als 6 Monate. Außerdem trennt FreeBSD stärker zwischen Major- und Minor-Releases (was OpenBSD faktisch nicht tut) und bietet auch Versionen mit Long Term Support (was es bei OpenBSD ebenfalls nicht gibt, dort haben alle Releases dieselbe Supportlaufzeit).

Bei FreeBSD werden zu einem Release zwar auch Pakete aus den Ports gebaut, die dann den Release-Stand darstellen - faktisch werden Ports (also Programme von Drittherstellern wie z. B. Apache, MySQL, PHP, Postfix, ...) rollierend immer wieder neu gebaut, so dass unter FreeBSD (ähnlich wie bei Gentoo) i. d. R. die aktuellsten Versionen von Drittsoftware genutzt werden.

Bei OpenBSD sieht das etwas anders aus - die Pakete werden einmalig mit dem Release gebaut, dann aber eingefroren; genauso wie die Ports. Damit haben OpenBSD-User das Problem, jeweils für einen 6monatigen Zyklus auch keine Security Fixes für Software von Drittanbietern zu bekommen - es sei denn, sie umgehen die vorgesehenen Mechanismen zur Paketverwaltung. Das ist übrigens der Hauptgrund, warum OpenBSD IMHO auf einem dedizierten Webserver nichts zu suchen hat.

Sodann gibt es noch einige technische Unterschiede. FreeBSD hat in den vergangenen Jahren (im Prinzip ab RELENG_5 bis RELENG_7) sehr viel Zeit und Energie darauf verwendet, den SMP-Support des Kernels zu verbessern. Kernel-Subsysteme wurden von Locks befreit (ein Prozess, der bei Linux noch im Gange ist), und der Scheduler komplett gewechselt und danach noch mehrfach überarbeitet (bis hin zu topologischem Scheduling). Im Ergebnis skaliert FreeBSD heute auf SMP-Systemen sehr gut (sogar etwas besser als Linux).

OpenBSD hat diese Anstrengungen zum großen Teil noch vor sich. Zwar unterstützt der OpenBSD-Kernel mehrere CPUs (bzw. Kerne), kann diese aber (noch) nicht so richtig nutzen. Darüber hinaus kommt ein ziemlich wichtiges Subsystem, nämlich das systrace-Framework, nicht so richtig mit SMP klar (bzw. wird durch SMP angreifbar, und zwar "by design"). Wie bereits oben angesprochen ist auch zu erwarten, dass die Beseitigung dieser Schwächen noch geraume Zeit in Anspruch nehmen dürfte.

A Propos systrace: Hier zeigt sich ein weiterer Unterschied zwischen Open- und FreeBSD. FreeBSD hat ein eigenes Subsystem für OS Level Virtualisierung geschaffen, bekannt unter dem Namen Jails. OpenBSD kennt einen solchen Mechanismus nicht; auf Basis des bereits genannten systrace-Frameworks gibt es aber eine Jails-Implementierung für OpenBSD, genannt sysjails - diese leidet jedoch auf SMP-Systemen (und welcher Server ist heute schon Single Core?) unter der bereits angesprochenen Schwachstelle des systrace-Frameworks.

Als letzten technischen Unterschied vor dem Fazit (versprochen!) sei noch die Verwaltung von Festspeicher angesprochen. rudelgurke hat es ja bereits erwähnt - per default mounted OpenBSD synchronisiert. Praktisch bedeutet das, dass der I/O-Scheduler erst dann die nächste Operation an die Platte schickt, wenn diese eine erfolgreiche Durchführung der vorhergehenden Operation vermeldet hat. Das ist gut für die Datenkonsistenz auf der Platte, aber schlecht für die Performance, da Caching-Mechanismen von Controller und Platte ausgehebelt werden.

Dieses Problem lässt sich noch durch Ändern der Konfiguration beheben - nicht jedoch das hoffnungslos veraltete Dateisystem (FFS), mit dem OpenBSD daher kommt. OK, das Dateisystem ist sehr robust und vermutlich inzwischen so gut wie bugfrei, technisch aber in etwa auf einem Level mit ext2. Kein Journal, keine Volumes, keine Snapshots (und übrigens auch keine einfach zu realisierende Disk encryption). Hier ist FreeBSD mit UFS2 und dem GEOM-Framework klar im Vorteil, mit ZFS sogar haushoch überlegen.

So, jetzt endlich das Fazit: OpenBSD ist gut für (verhältnismäßig) kleine Systeme mit nur einem CPU-Kern (Atom o. ä.), die ausschließlich Software aus dem OpenBSD-Basissystem verwenden (z. B. Router, Firewall, WLAN-AP). Da ist es wirklich richtig gut; das Basis-System ist sehr gut dokumentiert, der Code weitgehend auditiert (z. T. mehrfach), und der WLAN-Stack und pf mit ALTQ gehören mit zum besten, was in dieser Richtung verfügbar ist.

OpenBSD ist nicht gut für SMP-Systeme und I/O-intensive Anwendungen (z. B. Datenbank-Server). In sicherheitskritischen Umgebungen sollte man keine Software aus den Packages oder Ports verwenden, da diese nicht regelmäßig aktualisiert werden.

FreeBSD ist gut für kleine bis mittlere Server (2 - 32 Cores), die auch mal die eine oder andere Festplatte mehr im Bauch haben dürfen - Software RAID mit GEOM oder RAIDZ mit ZFS machen's möglich. Dank Jails und tagesaktueller Software aus den Ports kann man mit FreeBSD toll Multi-Role-Server bauen, wobei die verschiedenen Funktionen durch Jails sauber voneinander getrennt werden können. Den Netzwerk-Verkehr zwischen Jails und den externen Interfaces kann man übrigens wie bei OpenBSD mit pf und ALTQ regeln - diese beiden hervorragenden Stücke hat FreeBSD bei OpenBSD gemopst (ist ja alles Open Source).

FreeBSD ist nicht (so) gut für kleine Systeme (Geode, Atom & Co) geeignet, da das System erst dann richtig Spaß macht, wenn man sich seine Software aus den Ports baut. Kompilieren auf schmalbrüstiger Hardware macht aber keinen großen Spaß...