Also bei Web- und SQL-Dinesten wirst du mit beidem zurecht kommen. Aber gehen wir mal die Vor- und Nachteile durch. Ansonsten einfach zum Fazit. Hätte noch Fragen bzgl. Anwendungsfall und Technolgiestack. Dann kann ich vielleicht eine bessere Einschätzung geben.
Bitte bedenken, dass meine Erfahrung mit DragonFly ein wenig gößer ist und ich bei OpenBSD ehrlich gesagt nicht am allerletzten Stand bin.
Zunächst einmal
Upgrades und Updates:
Grundsätzlich hast du bei beiden Systemen Sourcebasierte Updates des Basissystems. Diese Aussage hat allerdings bei OpenBSD zwei Einschränkungen. OpenBSD kannst du von Release zu Release auch mittels Install-Kernel upgraden. Das läuft in etwas so ab, dass du ein Installationsmedium bootest und dann eine Upgrade-Installation fährst. Das ist auch ziemlich gut supported. Für Updates (also Sicherheitspatches) gibt es auch noch eine halb-offizielle, aber in jedem Fall 3rd Party-Variante von
M:Tier. Damit kannst sowohl binäre Sicherheitsupdates einspielen. Unter DragonFly bekommst du eher Source-Updates, auch wenn es meines Wissens nach Pläne gibt binäre Updates zur Verfügung zu stellen. Ist aber nicht dringliches.
Bei Paketen sieht das anders aus. OpenBSD hat offiziell keine upgedateten Binärpakete. Auch diese kannst du allerdings über M:Tier erhalten. DragonFly hat up to date Binärpakete von offizieller Seite. Damit kannst du per Default einfach mit pkg update, wobei ich persönlich wie auch unter FreeBSD auf poudriere setze und die Pakete einigermaßen customized (ich brauche am Server kein X11) automatisiert selbst baue. Ist eine Sache von ein paar Minuten das einzurichten und definitiv wert.
Jetzt zu den
SQL- und Webserver:
Unter DragonFly hast du die Ports von FreeBSD mit einem Overlay, wo ein paar Anpassungen für DragonFly drin sind. Wahrscheinlich gibt es da allerdings keine Differenzen. Die sind mehr für Teile rund um Grafiktreiber, etc. Je nachdem was du machen willst wirst du mit DragonFly einen höheren Durchsatz erreichen. Wenn du hohe Last hast, dann kann das ein signifikanter Unterschied sein. DragonFly ist sehr stark auf der Performancesseite, währen OpenBSD das eher als eine niedrige Priorität sieht. Natürlich machen die das auch schneller, wenn es Sinn macht, aber wenn immer es zur Entscheidung von Simplizität oder (manchmal ziemlich theoretischer) Sicherheit geht die Entscheidung gegen Durchsatz aus.
Bitte beachte da dass für den Großteil aller Usecases du weder den Security- noch den Perofrmancevorteil stark merken wirst. Aber da kenne ich deine Anwendung einfach nicht genug. Man muss eben sagen, dass beide Systeme grundsätzlich General Purpose Systeme sind. Niemand will eine Sicherheitslücke oder unnötig langsamen Code. Das vergisst man leicht, wenn man es so runter bricht, wie "X für Performance, Y für Security". So schwarzweiß ist die Welt nicht. Dann hast du eine DDOS-Attacke und schon ist Durchsatz potentiell wichtig. Und die meisten Angriffe, die erfolgreich sind sind einfach große Remote Code Execution Teile, die relativ häufig in interpretierten Code sind, sei es jetzt durch ein PHP-Skript oder gar SQL. Da hilft nur sauber programmieren, Code aktuell halten, etc.
Andere Themen:
Jaills. Wenn du Jails magst, sei es auf Grund von Sicherheit, das Management von Services zu vereinfachen oder aus ganz anderen Gründen. Die hast du unter DragonFly, unter OpenBSD nicht. Dafür hast du andere Features, wie pledge und Co. Die Frage ist da ein bisschen, wie sehr du die einsetzen kannst. pledge ist allem voran ein Interface in C und auch wenn es zum Beispiel Python-Libraries gibt die das ermöglichen musst du das halt auch wirklich korrekt verwenden. Jails sind da generischer, was ein Vorteil und ein Nachteil sein kann.
3rd Party Software. Das ist jetzt vielleicht das Subjektivste in dem Post, aber für mich war es immer eine Art Faustregel, dass wenn ich OpenBSD einsetze das dann tue, wenn ich hauptsächlich eingebaute Software nutze, die NICHT aus den Paketen kommt. Da ist OpenBSD wirklich gut. Man hat OpenSMTPD, man hat einen Webserver, sehr, sehr coole, durchdachte Tools und Libraries. Das ist auch der Grund warum es eine derart gute Lösung für Gateways/Firewalls ist. Bei 3rd Party Software hatte ich vor M:Tier die etwas ernüchternde Situation zwar ein sehr sicheres System zu haben, allerdings eben Pakete mit Lücken für die es keine (binären) Updates gibt. Generell ist die Manpower für OpenBSD ports ein wenig kleiner, als die der anderen BSDs (inklusive NetBSD's pkgsrc[1]). Bei dports hast du FreeBSD's und DragonFly's Leute dahinter hast. Alles in allem würde ich deshalb sagen, dass der Punkt komplett an DragonFly geht. Nur bitte beachten, dass das so wie viele meiner Aussagen stark vom Anwendungsfall abhängig ist
Datenbanken. Das ist wahrscheinlich der Punkt, wo du Performance haben willst. In den meisten Webanwendungen ist hier der Bottleneck und Knackpunkt. Generell holt man viel mehr raus, wenn man anständigen Code hat, weiß was man tut und sich mit der DB auskennt. Allerdings sind Datenbanken die Teile, wo sich das OS am meisten Auswirken kann. Da fällt die Performance von malloc und mmap rein, wenn kein eigenes verwendet wird (unter OpenBSD stark auf Korrektheit und Sicherheit, auf quasi allen anderen Betriebssystemen für gewöhnlich stark auf Performance getrimmt). Wie klug ist der Scheduler, das Caching des Filesystems, das Filesystem selbst. Hat der Port Patches die potentielle Schwächen umgehen, wie viele Leute, nutzen die DB auf einem OS. Letzterer Punkt ist natürlich für OpenBSD mit deutlich mehr Usern vielleicht spannender, allerdings muss man da bedenken, dass sich DragonFly und FreeBSD vieles davon teilen und DragonFly's Performance von dessen Entwicklern allem voran an PostgreSQL gemessen wird. Ist schon fast das Standardtool.
Filesystem. Ob HAMMER spannend für dich ist hängt wieder mal vom Anwendungsfall ab. Es kann, gerade wenn du auf Datenbankdurchsatz schaust wieder mal sein, dass du anders als man vielleicht spontan denkt gar kein HAMMER willst. Sind dir die Features (zurück in der Zeit gehen, etc.) wichtiger, dann ist das vielleicht ein Grund.
Fazit: Auf einem vServer, auch je nach Technolgie darunter sind dir die meisten dieser Vor- und Nachteile, abseits von 3rd Party Software wahrscheinlich relativ egal. Du wirst wohl weder extreme Performancethemen haben, wahrscheinlich auch kein HAMMER wollen. Der Security-Teil von OpenBSD *kann* interessant sein, allerdings wird's tatsächlich wohl auf up to date halten deines Systems hinauslaufen und im ärgsten Fall eben der Host attackiert. Also auch wenn deine C-Software wahrscheinlich ein kleinwenig schwieriger zu attackieren sein wird ist OpenBSD da nicht irgendwie die letzte Bastion.
Kurzum: Die Wahl des Systems hier ist jetzt nichts wo ich ein System wirklich stark empfehlen könnte oder wo man eines eher ausschließen könnte - zumindest nicht auf Basis der Angaben, die du gemacht hast.
Was vielleicht noch spannend wäre ist ein konkreterer Anwendungsfall (nur zum Experimentieren? Hast du einen konkreten Technologiestack im Kopf, abseits des OS?) und wo du das hosten wirst bzw. auf was für einer Technologie (KVM, bhyve, Xen, Virtualbox, VMWare, etc.). Auch die Leistungsmerkmale wären interessant, um einschätzen zu können, ob poudriere, etc. überhaupt eine einigermaßen sinnvolle Wahl ist. Überschätze die aber auch nicht. Ich habe poudriere auch mal auf einem kleinen alten VIA-Board betrieben. Serversoftware ist nicht so riesig und wird nicht täglich geupdated. Das geht schon.
Wenn du kannst würde ich empfehlen beide Systeme über einen fixen Zeitraum zu testen oder das nehmen mit dem du mehr Erfahrung hast. Du könntest ja das Grundsetup, das du vorhast mal lokal in einer Virtualbox machen. Das kann sehr hilfreich sein.
Spontan gefragt würde ich jetzt OpenBSD mit M:Tier-Updates empfehlen, weil du so durchgängig Binärupdates hast, was wohl angenehmer ist auf einem vServer.
[1] Ist erstmals verwunderlich, hängt aber wahrscheinlich damit zusammen, dass es unter anderen Systemen durchaus Verwendung findet. Ich urteile da vor allem auf Basis der Aktualität von Pakten. Da scheint OpenBSD aber gerade besser zu werden. Weiß nicht, wie up to date ich bezüglich dieser Einschätzung bin. Hab das jetzt nicht groß nachstudiert, weil's ohnehin nicht um pkgsrc geht, also gerne korrigieren!
