Bitrig - ein neuer OpenBSD-Fork

[h^2]

Wie die Phoronix-leser (und die OpenBSD-Insider) wahrscheinlich schon wissen gibt es einen neuen OpenBSD-Fork: Bitrig

http://www.bitrig.org
http://www.phoronix.com/scan.php?pag...tem&px=MTExODY

Was haltet ihr davon? Und was fuer Leute stehen dahinter?

Ein paar der Gruende nicht mehr an OpenBSD zu arbeiten, die sie nennen sind, dass sie weniger konservativ und dafuer feature-freundlicher sein wollen. Die Base soll kleiner werden, clang einziehen, Fokus auf i386+amd64+arm, das Giant-Lock fallen...
Das hoert sich aus meiner Sicht sinnvoll an, aber ich frage mich schon, dass wenn man den Konservatismus von OpenBSD aufgibt (der vielleicht viel der Sicherheit ausmacht), wo liegt dann der Vorteil ueberhaupt mit der OpenBSD-Base zu arbeiten? Warum nicht gleich ein anderes BSD, was wenigstens einige der Ziele schon erreicht hat und bei den anderen auf dem Weg ist?
Gerade DfBSD sollte doch von der community her so klein sein, dass eine handvoll gute Entwickler auch wirklich mitmischen koennen...

[Elwood]

Für diese (eher schwachen) "Goals" wäre mir persönlich ein Fork zu viel Arbeit. Aber wer's braucht.

[hawky]

im ersten moment denkt man ja immer gleich, dass nun entwickler von openbsd abspringen und nicht mehr zur verfuegung stehen.

aber selbst wenn es so ist, dann wird die arbeit dieser leute am fork auch wieder openbsd befruchten.

vielfalt bedeutet auch mehr inspiration und kreativitaet ... von daher freu ich mich und schau mal was da entsteht.

--hawky

[darktrym]

Schwer vorzustellen, dass das Projekt länger leben wird. Es sind doch größtenteils NetBSD/FreeBSD Feature die eingebaut werden sollen.

Item Description Comments
llvm/clang support Kernel, userland, and xenocara compiled with clang Completed
KVM support Add kernel and user space changes to support KVM
WAPBL support Add a journaling filesystem
ARM support Add support for beagle and panda board
Fine grained MP Get rid of biglock
FUSE/puffs support Add kernel and user space pieces to support FUSE functionality.
Support latest GNU binutils Port latest GNU binutils in order to get things like gold and LTO Rewrite anyone?
Port libc++ to Bitrig In order to remove need for libstdc++
Port compiler-rt to Bitrig In order to remove need for libgcc.a

[Yamagi]

Vor einiger Zeit hatten wir im IRC eine heftige Diskussion darüber, weshalb NetBSD und OpenBSD zunehmen an Boden verlieren. Ich warf zu OpenBSD ein, dass das Projekt im ganz wesentlichen Thema "SMP" die Zeit völlig verpennt hätte und untergehen wird, wenn es nicht bald den Hintern hochbekommt. Erstaunlicherweise kam aus der OpenBSD-Ecke fast nur Zustimmung. OpenBSD mag ein sehr gutes, stabiles und sicheres System sein. In den beiden Punkten vielleicht mehr, als jedes andere auf dem Markt. Aber wir leben in einer Zeit, wo die ganz großen Eisen mehr als 100 CPUs haben. Jeder Desktop hat 2 bis 8, ein Handy meist 4 und selbst Netzwerkinfrastruktur mindestens 2 Stück... Was nützt mir die beste Sicherheit, die höchste Stabilität, wenn ich einen Großteil meiner Ressourcen nicht nutzen kann, da die Software einfach nicht über mehrere CPUs skaliert? Und das wird in den nächsten Jahren mit steigenden CPU-Anzahlen eine immer relevantere Frage werden. Ein im Kern fast 40 Jahres altes System fit für das SMP-Zeitalter zu machen ist wahrlich nicht einfach und ich verstehe, dass die OpenBSD-Entwickler Angst vor den sich ergebenden Konsequenzen (massive Änderungen der Struktur und des Codes an sich notwendig, sehr hohes Risiko hunderte neue Bugs einzubauen, eine ganz neue Klasse an Fehlern, etc.) haben. FreeBSDs SMPng ist sicher das beste Argument gegen einen solchen Umbau. Aber durch den Kopf in den Sand stecken und abwarten, wird die Lage nicht auf magische Weise besser. Und es ist nur ein Punkt. Von den Herausforderungen >100GB RAM zu verwalten, >10TB Dateisysteme performant zu implementieren und so weiter reden wir noch gar nicht. So gesehen verstehe ich durchaus, dass einige Personen nicht mehr dem "Verfall" zuschauen möchten, stattdessen die Sache selbst in Hand nehmen.

Nur ist es die Lösung aller Probleme? Nein. Erstmal ist es nicht damit getan, sich ein Wochenende hinzusetzen und mal eben den GIANT rausnehmen. Das ist ein Projekt. was selbst in seiner kleinstmöglichen Umsetzung Jahre in Anspruch nehmen wird. FreeBSDs sehr umfassende Lösung hat fast 8 Jahre gebraucht, Linux (wo BKL aber nie die Auswirkungen unseres GIANTs hatte) benötigte ebenfalls >5 Jahren um nur die hauptsächlichen Codepfade zu ändern. NetBSDs "einfache" Lösung ebenfalls Jahre. Daher ist es stark zu bezweifeln, dass dieser Fork die Manpower und die notwenige Hingabe mitbringt, das Vorhaben umzusetzen. Vor allem aber wird sich dadurch in der ersten Zeit der Code ohne sichtbare Vorteile destabilisieren. Wird man die sich ergebende Durststrecke durchhalten? Man muss sich die Frage stellen, ob OpenBSD selbst den Rückstand je aufholen kann, ohne seine Nutzer zu verprellen. Das so ein Fork es schafft, ist fast ausgeschlossen. Wie Elwood andeut, wäre der umgekehrte Weg vielleicht besser. OpenBSDs "Sicherheitstechnik" auf FreeBSD portieren.

Überhaupt stehe ich nach wie vor auf dem Punkt, dass ca. 95% aller Forks mehr schaden als nützen. Sind es Entwickler des Urprojektes, die forken? Dann ziehen sie die meist eh schon stark begrenzten Ressourcen eines Projektes weiter auseinander, sodass am Ende weder Original noch Fork die notwendige Manpower haben. Gut bei ffmpeg / libav / mplayer / mplayer2 zu sehen. Das libav und ffmpeg noch nicht ganz tot sind, liegt hauptsächlich an Red Hats bezahlen Codesklaven. Bei mplayer und mplayer2 drehen sich beide seit Monaten im Kreis, keines der beiden Projekte hat was sinnvolles zustande gebracht, wenn man mal von Bugfixes absieht. Und so läuft es öfter, als die "Basar-Fraktion" wahrhaben will. Und wenn der Fork nicht aus dem Originalprojekt kommt, zieht er noch immer die Nutzerbasis auseinander, spaltet sie, treibt einen Keil ins Ökosystem. Da Nutzer aber die Basis jedes erfolgreichen Opensource-Projektes sind, kann ein Verlust eines Teils der Nutzerbasis schnell sehr problematisch werden. Dies war zum Beispiel bei X.org vs. XFree86 einer der Hauptgründe für den Niedergang des Originalprojekts. So muss man sich die Frage stellen, ob dieser Fork nicht am Ende OpenBSD mehr schadet, als insgesamt der Sache zu nützen und ob ein Engagement im Orginalprojekt - oder halt woanders - nicht insgesamt sinnvoller wäre.

[h^2]

Ich teile Yamagis Einschaetzung, deswegen auch meine Frage: was sind real Dinge in der OpenBSD-base, die siginifikant besser/neuer/schneller/sicherer sind, ausser, dass es durch geringere Komplexitaet, weniger features und weniger Veraenderung eben konservatirver ist. [ diese aufgezaehlten Punkt verliert ja jeder Fork, der versucht die Probleme zu beheben. ]

Bei DfBSD und NetBSD gibt es immerhin Innovationen, wenn auch nicht sicher ist, ob sie je allgemeine Reife erlangen. Das heisst, hier gehen Menschen immernoch neue Pfade, die sie vielleicht aus dem Research-OS-Status (Sorry, wenn ich DfBSD und NetBSD s bezeichne) irgendwann rausholen, oder zumindest anderen Betriebsystemen nutzen.

[mark05]

hi
nix fuer ungut aber , auch wenn ich einige punkte von yamagi's arrgumentation nachvollziehen
kann, so vermisse ich nix bei obenbsd und bin auch froh ueber das "konserative"

ich nutze openbsd fast nur im infrastruktur bereich , sprich firewall , router , dhcp server etc.

und da ist es einfach perfekt gerade mit den hoch verzahnten daemons zum kernel und carp.

was smp betrifft ich vermisse da nix ....... es gibt smp welches auch funktioniert.
es ist bestimmt nicht so gut wie das was es fuer freebsd und linux gibt aber es ist
funktional und stabil.

so stabil das es per default aktiv ist bei der installation.

ich weiss auch das bestimmte technologieren unter der beobachtung stehen fuer eine
implementation z.b. das neue hammerfs 2.0 kann durchaus einzu in openbsd halten
wenn es den fertig ist.

bei pf habe ich noch nie probleme gehabt was performance betrifft obwohl ich
hier mit bandbreiten von bis zu 8x !gbit im routing und packetfilter rede.

und da spielt smp eh keine rolle.

und mir kann auch keiner erzaehlen das smp im packetfilter bereich sinn macht.

von daher wozu fork .

man sollte sein os nach gestellter aufgabe waehlen und nicht nach den vorhandenen features (die im zeiwefel keiner braucht )


holger

[darktrym]

Dann schau dir mal die Baustellen an:

• SMP
• Kernelmodule
• KMS, GEM, TTM - X ohne Rootrechte (der Intel Kram zählt nicht, der ist ein ziemliches Zusammengefrickel)
• Virtualisierung
• Compilerinfrastruktur

Irgendwann machts auch dann den Entwicklern keinen Spaß mehr.

[mark05]

Zitat von darktrym

Dann schau dir mal die Baustellen an:

• SMP
• Kernelmodule
• KMS, GEM, TTM - X ohne Rootrechte (der Intel Kram zählt nicht, der ist ein ziemliches Zusammengefrickel)
• Virtualisierung
• Compilerinfrastruktur

Irgendwann machts auch dann den Entwicklern keinen Spaß mehr.

smp ist vorhanden.
kernelmodule wozu ?
X auf einem router oder firewall braucht man nicht.
virtualisierung ? ne firewall ? eine bridge ? einen openbgpd router ?
nein danke.

zu themen wie complierfrage kann ich nix sagen aber ich sehe
dsa eher aus anwendersicht und das ist mir eine gute documentation wichtiger
als virtualisierung oder comiler fragen.

virtualisierung geht mir mittlerweile eh auf den sack , weil man sich immer
mehr rechtferigien muss warum man bestimmte dinge nicht virtualisieren will.

holger

[laemodost]

Zitat von hawky

im ersten moment denkt man ja immer gleich, dass nun entwickler von openbsd abspringen und nicht mehr zur verfuegung stehen.

aber selbst wenn es so ist, dann wird die arbeit dieser leute am fork auch wieder openbsd befruchten.

Vielleicht Anfangs. Aber wenn sich beide Projekte weiterentwickeln ist wird es schon nach kurzer Zeit immer schwieriger, Code vom jeweils anderen Projekt zu übernehmen.
So werden beispielsweise auch nur noch hauptsächlich Userland-Tools zwischen den BSDs ausgetauscht, weil die Kernel längst vollkommen unterschiedlich sind. Selbst beim letzten Fork DragonFly und Väterchen FreeBSD.

[darktrym]

Zitat von mark05

smp ist vorhanden.
kernelmodule wozu ?
X auf einem router oder firewall braucht man nicht.
virtualisierung ? ne firewall ? eine bridge ? einen openbgpd router ?
nein danke.

zu themen wie complierfrage kann ich nix sagen aber ich sehe
dsa eher aus anwendersicht und das ist mir eine gute documentation wichtiger
als virtualisierung oder comiler fragen.

virtualisierung geht mir mittlerweile eh auf den sack , weil man sich immer
mehr rechtferigien muss warum man bestimmte dinge nicht virtualisieren will.

holger

SMP in Form eines BKL, dass ist schon seit einen Jahrzehnt nicht mehr Stand der Technik.
Kernelmodule um andere Lizenzen zu unterstützen, Minimalisierung des Kernel, statt irgendwelche Optionen ein- bzw. auszukommentieren und neu zu übersetzen.
OpenBSD ist nicht nur für Router interessant, auch müssen die Entwickler darauf können.
Schon alleine wegen der mangelnder UX bei Anfänger gehen denen einen Haufen Tester verloren.
Die Serverperformanz ist auch eher unterdurchschnittlich.
Der Compiler ist völlig veraltet, selbst NetBSD ist da weiter.
Und zu Virtualisierung: Gibts denn diese überhaupt bei OpenBSD, Xen, kvm, Virtualbox?

Ein OS was nur auf Nischen setzt, ist dem Untergang geweiht.

[mark05]

Zitat von darktrym

SMP in Form eines BKL, dass ist schon seit einen Jahrzehnt nicht mehr Stand der Technik.

und funktioniert ......

Kernelmodule um andere Lizenzen zu unterstützen, Minimalisierung des Kernel, statt irgendwelche Optionen ein- bzw. auszukommentieren und neu zu übersetzen.

ich haben in den letzen 5 jahren kaum einen neuen kernel bauen muessen und
wenn das nur um ipmi zu aktivieren.

OpenBSD ist nicht nur für Router interessant, auch müssen die Entwickler darauf können.
Schon alleine wegen der mangelnder UX bei Anfänger gehen denen einen Haufen Tester verloren
.

sorry aber auf diese linux juenger kann man verzichten denen ist systemd
und udev und was auch immer wichtiger als ein sichers system.

Die Serverperformanz ist auch eher unterdurchschnittlich.

das kann ich nicht viel zusagen das ich openbsd nicht als server os
nutze.
zum teil aus den hier , auch von dir , genannten punkten.

hatte das auch schon eine kontroverse diskussionen mit henning .
jedoch kommt das immer ein argument was ich gut nachvollziehen kann.

wenn openbsd was macht das richtig , auch wenn es jahre spaeter ist.

Der Compiler ist völlig veraltet, selbst NetBSD ist da weiter.

interessiert mich als anwender herzlich wenig sollange es funktioniert.

Und zu Virtualisierung: Gibts denn diese überhaupt bei OpenBSD, Xen, kvm, Virtualbox?

und auch hier wozu brauche ich das auf einem os was hauptsaechlich
im infrastruktur bereich genutzt wird und auch dort der fokus der entwicklung
liegt. ?

mir wird schlech bei dem gedanken das es menschen gibt die ihre firewall
in einer virtualisierten umgebung laufen lassen .

Ein OS was nur auf Nischen setzt, ist dem Untergang geweiht.

sehe ich nicht so , mit ist ein os was das was es macht richtig gut macht
leiber als so ne frickelbude ala linux was alles koennen soll aber davon
nix richtig.

handwerker haben auch mehere arten von schraubendreher immer passend
zur schraube.

oder wie mein meister immer gesagt hat " verwende immer das richtige werkzeug
zu dem was du vorhast. "

holger

[Kamikaze]

Zitat von mark05

smp ist vorhanden.

Userland SMP ist gerade bei Infrastukturhardware doch weniger nützlich. Wenn du mit PF einen Backbone betreiben willst, wäre SMP im Kernel wirklich sinnvoll. Und in absehbarer Zukunft unabdingbar. Sonst bleibt die Leistung die meiste Zeit Dunkel, weil nur ein Kern Pakete routen darf und die anderen sich langweilen.

[jmt]

Aus meiner Erfahrung mit OpenBSD kann ich nur sagen, dass es einfach funktioniert. Und man kann es problemlos Updaten. Wenn ich jedoch die Eigenschaften von Bitrig haben möchte, dann nehme ich halt ein NetBSD. Ich finde, dass man gerade bei DragonflyBSD sehr gut sehen kann, dass es mit ein paar neuen Features nicht getan ist. DragonflyBSD krankt daran, dass sie nur mit Mühen ihr Base-System auf einem aktuellen Stand halten können. Dabei sind die Features, die DragonflyBSD hat, bedeutender als die, die Bitrig haben will.

[mark05]

Zitat von Kamikaze

Userland SMP ist gerade bei Infrastukturhardware doch weniger nützlich. Wenn du mit PF einen Backbone betreiben willst, wäre SMP im Kernel wirklich sinnvoll. Und in absehbarer Zukunft unabdingbar. Sonst bleibt die Leistung die meiste Zeit Dunkel, weil nur ein Kern Pakete routen darf und die anderen sich langweilen.

was hest den hier userland smp ?

userland heist fuer mich anflanschloesung ala fuse-zfs bei linux

also zeug was zur laufzeit zum kernel hinzugefuegt wird.
und das ist nicht der fall beim smp von openbsd.

holger