Zu DragonFly möchte ich mich nochmal zu Wort melden. Ich verwende das System derzeit in keiner Form.
Zur Geschichte. Ja, es gab technische Meinungsverschiedenheiten. Ein anderer Punkt ist aber wohl, dass Matt Dillion nachdem vieles (oder sagen wir einfach ein beachtlicher Teil) in 4.x von ihm kam das Commit-Recht entzogen wurde. Dazu mag ich mir keine Meinung bilden, aber er hat seit ewig an OSs und solchen Dingen gehacked, also kann man kaum erwarten, dass er aufhört.
Zu den Unterschieden mit FreeBSD. DragonFly war eigentlich seit seiner Existenz quasi immer performanter als die anderen BSDs wenn es um reihes (paralleles) Number Crunching geht. Das allein kann meines Erachtens schon ein Grund sein es zu nutzen. Der Anwendungsfall "Ich brauch Performance und würde gerne ein offenes BSD nutzen" scheint mir nicht so komisch.
Ein weiterer Punkt ist, dass mit DragonFly in vielen Situationen als pragmatischer erschien. Die Entwickler dog-fooden ihr System. Matt Dillon hat scheinbar genug Geld und Zeit um aktiv daran zu arbeiten. Beispiele für diesen Pragmatismus sieht man in unterschiedlichen Formen. Meine Beispiele sind etwas älter, weil ich das System eben schon eine Weile nicht mehr nutze. Aber das beginnt beim Makefile in /usr/ zu System/Kernel/ports/pkgsrc einfach bauen, als die anderen BSDs über sendmails Unsicherheit geredet und philosophiert haben, wie das im Defaultsystem sein soll hat DragonFly mal schnell dma hingehackt und damit war das Problem komplett gegessen, als die Leute sich über FreeBSD lustig gemacht und ewig diskutiert haben, warum das so ist, dass wenn man einen USB-Stick aus dem System zieht das System crasht haben sich die DragonFly-Entwickler einfach hingesetzt genau das gemacht und alle Crashes die dadurch auftraten gefixed, als die Leute sich bei den anderen BSDs drüber beschwerten, dass die Beschleunigung bei aktuellen Intel-Grafikkarten nicht klappt, hat man ein bisschen Wrapper-Code gebaut, damit aktuelle Linux-Treiber einfach portierbar sind, und sogar als damals OpenSolaris ZFS vorstellte hat man (Dillon) sich überlegt das zu portieren, hat sich dann dagegen entschieden und mittlerweile zwei Major-Versionen von einem alternativen FS mit anderen technischen Entscheidungen und Trade-Offs gebaut.
Die Sache mit Entwickler-Zhal und Userbase sehe ich nicht mehr so kritisch in vielen Situationen. Die Sache ist nämlich, dass Software-Projekte ganz generell nicht so funktionieren, dass man einfach Mengen an Entwickler drauf haut und man dann erwarten kann, dass was gutes dabei rauskommt. Ein anderer Punkt ist, dass die BSDs und generell viele Open Source Projekte selbst wenn unzählige Leute schonmal einen Commit gemacht haben von relativ wenigen Core-Commitern, die wirklich regelmäßig dran arbeiten und auch Verständnis von großen Bereichen des Projekts haben getragen werden.
Am Meisten Unterschied gibt es wohl noch bei Hardware-Support, aber die Beispiele der Intel-Grafikkarte und den USB-Sticks zeigen wohl, dass es selbst hier nicht so eindeutig ist. Ich glaube auch bei Ryzen war DragonFly relativ schnell.
Klar, bei irgendwelchen exotischeren Geräten, vor allem so Dinge, die man mit USB und Bluetooth anspricht ist das wohl was anderes. Da gibts wohl mehr Linux-Entwickler, aber selbst da ist das eher eine Glückssache als sonst was.
Ein anderer Punkt ist der Fokus von Projekten. Für alles was ein Projekt an Code hat braucht man halt Entwickler bzw. Zeit die anderswo genutzt werden kann. DragonFly ist da ziemlich fokussiert auf der Performance-Kernthema. Man hat außer amd64 keine Plattformen um die man sich kümmern muss, man entfernt regelmäßig ungewarteten Code, sei das MIDI oder SCTP (übrigens auch eigener Code) im Kernel und man trifft regelmäßig zukunftsträchtige Entscheidungen, die auch dafür sorgen, dass Code in anderen Systemen mit viel mehr Entwicklern landet.
Also kurz gesagt: Man darf aus Anzahl an unterschiedlichen Entwicklern oder gar Usern auch keine falschen Schlüsse ziehen. Die ganze Welt verwendet unterschiedlichste Software, mit nur einzelnen Entwicklern, vor allem wenn man vom Kernteam spricht, also Leuten die wirklich Erfahrung haben und auch das große Ganze sehen können. Man muss halt bedenken, dass viele Leute einmal, vor allem in der Unizeit mal einen Patch an ein OS schicken, die irgendwo einen kleinen Bug fixen, oder schauen, dass irgendein Identifier von Hardware in einer Liste ist, damit ein Treiber funktioniert. Das ist gut, wichtig und gut so. Allerdings ist glaube ich eine Stärke von DragonFly und OpenBSD, dass halt wirklich sehr viel auch am Desktop verwendet wird und Bugs, Features, etc. stärker auffallen. Das machen sicher auch FreeBSD-Entwickler, aber FreeBSD als Fokus hat auch den Fokus überall. Nicht falsch verstehen, das ist sogar der Grund warum ich FreeBSD einsetze. Dadurch, dass es so in die Breite geht macht das ein super System wenn man einfach ein (Server-)OS mag, wenn man vielleicht noch nicht so genau weiß wo sich die Dinge hinentwickeln.
Und dann gibt es ja noch die Tatsache, dass Dinge Open Source sind und gerade Betriebssysteme sich oft in eine Richtung entwickeln dass Code auch "leicht" portiert werden kann, sowohl unter den BSDs, als auch von Linux. Siehe Intel-Grafikkarten-Treiber zum Beispiel.
Ich glaube, dass Bewertung von einigermaßen komplexer Software nicht sehr sinnvoll mit ein paar Statistiken dazu gemacht werden könne. Ich selbst habe den Fehler viel zu oft gemacht nur um später eines besseren belehrt zu werden. Manpower und solche Dinge klingen erstmal vernünftig, aber sagen nicht viel aus, wenn zum Beispiel der Fokus entweder zu groß ist, oder einfach in eine Richtung gehen, die für den persönlichen Einsatz nicht relevant sind. Ich glaube alle hier im Forum verwenden unterschiedlichste Software, Open Source und Closed Source, wo es Konkurrenzprodukte mit mehr Entwicklern/Geld gibt, die trotzdem viel "schlechter" sind, zumindest für den eigenen Zweck.
Und komplett unabhängig davon. Ich glaube unterschiedliche Wege zu gehen ist eine gute Sache. Wäre anders, wenn nur das Logo oder die Default-Software anders werden, aber ist ja eher so, dass da unterschiedliche technische Entscheidungen mit unterschiedlichen Trade-Offs genommen werden und man auch von den anderen Entscheidungen lernen kann und das passiert definitv.
