*NIX Systeme?

cabriofahrer

Well-Known Member
Mein langjähriger Favorit in Richtung Exoten-System bleibt ja DragonFly-BSD.
Ich wollte schon immer mal gefragt haben, warum man DragonFly-BSD denn FreeBSD vorziehen würde? Ist das nicht sogar ein Fork von FreeBSD zu 4-er Zeiten? Und warum eigentleich? Weil ein ehemaliger Entwickler da mit etwas nicht einverstanden war oder so ähnlich? Worum ging es da eigentlich?
 

pit234a

Well-Known Member
Ich wollte schon immer mal gefragt haben, warum man DragonFly-BSD denn FreeBSD vorziehen würde? Ist das nicht sogar ein Fork von FreeBSD zu 4-er Zeiten? Und warum eigentleich? Weil ein ehemaliger Entwickler da mit etwas nicht einverstanden war oder so ähnlich? Worum ging es da eigentlich?
so ziemlich genau darum.
Das war ja immer schon der Grund für Forks und die Ideen, mit denen die ehemaligen FreeBSD-Entwickler dann ein eigenes System haben wollten, sind nicht ohne. Das kann durchaus kontrovers diskutiert werden und man liegt auch nicht falsch, wenn man FreeBSD hier für konservativ hält.
Die Entwicklung von OpenBSD oder DragonFly ist ja dann auch nicht abgeschottet, sondern offen und es fließt schließlich auch Code aus allen Projekten zusammen. Somit ist schließlich auch ein teil der Arbeit an DragonFly schließlich FreeBSD zu Gute gekommen.

Wenn jemand sich das ansehen möchte, oder einfach mal fühlen möchte, wie sich dann so ein System verhält, in dem es andere Prioritäten für die Entwicklung gibt, der kann das dann ja mal probieren.
Allerdings ist mein alter Spruch, dass ein LibreOffice oder GIMP sich egal auf welchem System nicht viel anders verhalten wird.
Die Entwicklungsziele von DragonFly wird ein einfacher Desktop-Nutzer kaum nachvollziehen können. Da merkt er keinen Unterschied. Vielleicht noch am deutlichsten hinsichtlich des Dateisystems, falls er sich dafür interessiert.

Also ganz klar: man kann es nicht empfehlen, weil man jemandem einen Gefallen tun möchte, der mit alter HW einen Desktop zum Surfen und Mailen betreiben will.
Wer aber ein Herz und die HW für verteiltes Rechnen hat und dann auch weiß, was er da will, der wird sich da schon eher Vorteile herausholen können.
 

pit234a

Well-Known Member
was ich oben noch vergessen hatte: wieso ich selbst immer wieder mal danach sehe und auch eine gewisse Begeisterung für DragonFly spüre.
Nämlich damals, als Matthew Dillon seinen Fork initiierte, fand ich selbst seine Argumente richtig. Das ist zwar recht anmaßend, so etwas als Laie zu behaupten, aber ich sah damals die Entwicklung von SMP in FreeBSD im Vergleich zu Linux als zu zurückhaltend an.
Wahrscheinlich war ich noch zu jung für FreeBSD.
Ich glaubte damals, dass es genau zwei Chancen gäbe: entweder DragonFly wird die neue (und bessere) Konkurrenz zu Linux, oder es vergeht stillschweigend innerhalb weniger Monate. Nun, wir wissen, dass es noch heute existiert und ob es wirklich eine ernsthafte Konkurrenz zu einem GNU/Linux-System darstellt, kann ich nicht beurteilen. Es hat aber seit Beginn nichts von dem manchmal geradezu überwältigenden Tatendrang eingebüßt, mit es damals gestartet war.
Dabei verstehe ich bei Weitem noch nicht mal Ansatzweise, was und manchmal auch warum gewisse Ziele gepuscht werden.
Nehmen wir das Dateisystem.
Das ist nur ein Dateisystem?
Warum nimmt man nicht einfach ein bewährtes, wie etwa ZFS?
Natürlich kann man seine Unabhängigkeit lieben und eigene Entwicklungsziele haben und davor habe ich großen Respekt und wenn dann das eigene System auch noch funktioniert, begeistert mich das schon, vor Allem angesichts der Anzahl der Entwickler. Und wenn ich das recht verfolgt habe, wurde das DragonFly-Dateisystem HAMMER im Laufe der Jahre mehrmals neu entwickelt. Also wirklich umgekrempelt und nicht nur einige Patches drauf gesetzt.
Es hat also verhältnismäßig viel Man-Power verschlungen und das hat sicher seinen Grund, den ich aber nicht vollends verstehen kann.

Nun ist aber eben die Anzahl der Entwickler begrenzt und dann muss DragenFly Eins nach dem Anderen machen. Es geht Kompromisse ein, die es einige Jahre später wieder weg wirft, um schließlich auch den Teil neu zu machen, der noch nicht ganz gepasst hatte. Das bedeutet, dass es vielleicht etwas flexibler hinsichtlich der eigenen Vorgaben entwickelt wird, als OpenBSD.
Ich vergleiche das auf meinem Niveau mal so.
Theo de Raadt hatte den OpenBSD-Fork in Hinsicht auf Sicherheit und sauberen Code gegründet und dann weiter entwickelt.
Im Laufe der Jahre war das oberste Ziel immer, sauberen und sicheren Code zu haben und das haben die bis heute durchgezogen und es begeistert die Anhänger von OpenBSD. Performance ist Nebensache.
Matthew Dillon hatte DragonFly gegründet, um die unnötigen Bremsen im Kernel zu entfernen und alle alten Flaschenhälse endlich los zu werden. Ich selbst habe das immer übersetzt mit "unleash all your cpu's" und im Laufe der Jahre hat der anfängliche Enthusiasmus für dieses Ziel kaum nachgelassen und die Entwicklung schreitet fort. Eine Bremse nach der Anderen wird entfernt und wenn dazu auch mal ein wenig unsauber gearbeitet werden muss, weil eben nicht Alles auf einmal geht.

Ich finde das toll und es begeistert mich immer wieder, wenn ich darüber lese und sehe, wie die Entwickler immer noch an ihren Zielen festhalten und sie auch realisieren. Wie gesagt, ohne alles zu verstehen oder nachvollziehen zu können, aber mit großem Respekt.
Auch, wenn ich da nun keinen Nutzen für mich privat ableiten kann, ein solches System zu nutzen.
Es ist toll, dass es so was gibt und ich das sehen und verfolgen und immer mal wieder auch selbst probieren kann.
 

cabriofahrer

Well-Known Member
Prozessoren mit mehreren Kernen sind doch schon lange der Standard und jedes aktuelle OS erkennt sie auch standardmäßig und nimmt sie in Anspruch. Hat da Dragonfly wirklich so einen enormen Vorteil gegenüber anderen Betriebsystemen? Oder reden wir hier über spezielle Serverhardware mit besonders vielen Prozessoren?
 

stadtkind

Well-Known Member
Prozessoren mit mehreren Kernen sind doch schon lange der Standard und jedes aktuelle OS erkennt sie auch standardmäßig und nimmt sie in Anspruch. Hat da Dragonfly wirklich so einen enormen Vorteil gegenüber anderen Betriebsystemen? Oder reden wir hier über spezielle Serverhardware mit besonders vielen Prozessoren?
Heute ja, um 2000 rum eher nicht. Microsoft mit Windows NT und Linux sind um die Zeit an FreeBSD mit ihrem SMP Support vorbei gezogen. Mit FreeBSD 5.0 sollte das anders werden, aber die ganzen 5er Releases von FreeBSD wollte am Ende keiner benutzen (siehe z.B. http://www.lemis.com/grog/SMPng/Singapore/slides.pdf, z.B. "Conclusion: release FreeBSD 5.0 in November 2001, ready or not. FreeBSD 5.0 was finally released in December 2002.". Ich glaube ich hab mich erst wieder mit den 7er Releases zu FreeBSD getraut...

Ansonsten kann man sich verschiedene Benchmarks angucken (z.B. https://www.dragonflybsd.org/performance/ oder DragonFlyBSD 6.0 Is Performing Very Well Against Ubuntu Linux, FreeBSD 13.0 oder einfach mal selber testen. Schade das es immer noch andere machen müssen und nicht jedes Projekt z.B. mit jedem Release z.B. den Output von https://github.com/redhat-performance/libMicro mitliefert...
 

marmorkuchen

Well-Known Member
Ach lustig, das hatte ich vor 386bsd auf meiner Kiste :)

PS: Installation per Disketten, 386bsd kam dann standesgemäß vom SLR-Tape :)
Ich hatte "damals" mit mir gehadert. Minix, Coherent oder ein richtiges UNIX (mit entsprechenden Kosten). Die Entscheidung viel dann auf Esix System V R4 inkl. Development-Kit, aber noch ohne X11/Motif. Die Lieferung umfasste dann so 50 Disketten. Tape hatte ich da noch nicht. Entsprechend lange dauerte ne Installation... :)
 

berni51

OpenBSD user & NetBSD newbie
An Coherent hab ich eigentlich ganz gute Erinnerungen! Hatte es auf einem 286er Amstrad installiert und zum OS gab es reichlich Sourcen: Spiele, Editoren, sogar ein BTX-Programm - und fast alles lies sich prima kompilieren. Kennt noch jemand den Editor Gnome?
 

Athaba

Libellenliebhaber
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.
 

Yamagi

Possessed With Psi Powers
Teammitglied
Matt Dillon hat scheinbar genug Geld und Zeit um aktiv daran zu arbeiten.
Matt Dillon gehört, wie auch einige andere Entwickler aus dem weiteren BSD-Umfeld, die finanziell ausgesorgt haben. Er hatte damals in den 90ern in San Francisco und Umland zur richtigen Zeit einen kleinen ISP gegründet und die Firma für sehr viel Geld verkauft. Leider bin ich zu spät geboren, um die Dotcom-Blase für schnellen Reichtum nutzen zu können. ;)

Es war damals die gleiche Leier wie heute: FreeBSD größter Vor- und Nachteil ist, dass es eines der wenigen wirklich komplett demokratisch organisierten Open Source Projekte ist. Es gibt keinen großen Diktator, der den Weg vorgibt oder zumindest das Chaos in Bahnen lenkt. Jeder macht, was er will und wenn es in Bereiche anderer Entwickler geht, wird diskutiert. Manchmal sehr lange. Bei dem Disput ging es damals vor mehr als 20 Jahren im Kern darum, dass Matt Dillon Maintainer der virtuellen Speicherverwaltung war. Er hatte sein Handwerk bei John Dyson gelernt und den Posten von ihm übernommen. Die virtuelle Speicherverwaltung stand irgendwo prinzipbedingt im Kern des SMPng-Projektes, also der grundsätzlichen Modernisierung des Kernels hinsichtlich Multiprozessorunterstützung. Matt Dillon hatte Ansichten hinsichtlich der als die anderen Entwickler, es kam zu einem wirklich üblen Streit und am Ende entschied das Core-Team nach langen Diksussionen Matt Dillon rauszuwerfen. Zur "Schuldfrage" kann ich nichts sagen.

Aber das nur am Rand, denn eigentlich soll es hier um alternative Unixe gehen.
 
Oben