Bitrig - ein neuer OpenBSD-Fork

[namor]

Zitat von mark05

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

Gemeint war denke ich, dass du zwar SMP support hast, der aufgrund des BKL aber keine Kernelfunktionen wie PF beschleunigen kann. "Userland" bedeutet nicht gleich "fuse", sondern allgemein Threads und Prozesse, die du auf dem System startest (ausgenommen syscalls).

[mark05]

moin

zum glueck muss man pf nicht beschlaeunigen ... das ist so schon schnell
genug das du mit der richtigen hardware auch mehrere GBit abfakteln kannst.

und prograemmchen wie ftp-porxy etc funktionieren gut mit dem smp

zumindestens sieht man schoen in top die sich die cpu aendert.

wi schon gesagt ich vermisse nix.

und wenn irgendwann die jungs um theo der meinung sind smp umzubauen
dann machen sie es auch gleich richtig.
( die wissen selber das das smp nicht der grosse bringer ist )

sollten die forker sich ihre energie doch lieber darauf konzentrieren .....
es wird mit sicherheit keiner sagen "macht das nicht"

holger

[Athaba]

Ich hatte es auf OSNews gelesen, aber habe es dann hier nicht gepostet, weil es sich nicht wirklich so anhörte als würde es Leute hier groß interessieren.

OpenBSD mit weniger Plattformen, das schneller ist und weniger sicher ist wirklich nicht eine allzutolle Featureliste. Ein ernsthafter OpenBSD-User nimmt doch OpenBSD genau, weil er ein konservatives System will. Ansonsten hat er ja andere BSDs und auch noch andere Unices und unixartige Systeme, die das abdecken was gewünscht ist.

Um OpenBSD auszubessern muss man das Projekt wohl nicht forken. Andererseits kann man auch nicht ausschließen, dass es frischen Wind bringt und natürlich kann jeder mit seiner Zeit anfangen, was er oder sie will. Allerdings sieht es für mich ein wenig so aus, als würde ein Projekt mit derartigen Zielen es schwer haben User und Entwickler zu finden.

Wenn, dann wird es noch etwas dauern. DragonFly hat ja auch lange gebraucht, bis es in den letzten Versionen dann auch mit Sachen, wie Performance, etc aufschließen konnte (was die Stabilität, Dinge wie Treiber angeht habe ich mich schon immer gefragt wie das so gut zustande bekommen, dass FreeBSD und Co. ständig zurückportieren). Mittlerweile ist es ja ein System, das auch für mehr als Entwickler und Enthusiasten interessant ist. Aber dahinter steht auch ein Matt Dillon, mit viel Erfahrung, der sein ja durchaus erfolgreiches FreeBSD 4 fortsetzen wollte, Geld, Zeit und Durchhaltevermögen besitzt. Damit und mit einem Konzept, das gute Entwickler anlocken konnte ist es ja durchaus zu etwas geworden.

Ich weiß zwar nicht allzu viel über OpenBSD, aber die haben wie es aussieht eine Reihe anderer NetBSD-Entwickler mit sich ziehen können.

Wie sich Bitrig entwickelt wird sich zeigen, aber auch wenn LLVM/clang cool ist, ist es wohl weniger etwas, was Entwickler dazu bringen wird da mitzubasteln, sondern eher OpenBSD da lauffähig zu machen.

Oder übersehe ich da etwas? Ich weiß wirklich nicht, was in der OpenBSD-Welt so los ist, also bitte klärt mich auf, falls es ein Drama gibt und/oder solche Projekte, wie clang-support aus irgendeinem Grund OpenBSD widersprechen.

[crotchmaster]

Ich möchte auch meinen Senf dazugeben.

Leider gibt es keinen Danke-Button, sonst hätte ich diesen bei Yamagis Posts ganz sicher gedrückt. Dann eben zwei FACKs.

Ich persönlich halte Bitrig für eine Totgeburt. Wenn ich ein 'OpenBSD' will, nehme ich das Original, mit all seinen Vor- und Nachteilen. mark05 verteidigt OpenBSD wacker, offenbart damit aber auch in meinen Augen, dass es schon eine sehr spezielle Anwendung ist, wo er es einsetzt, eben kein general purpose.

Im Moment sprechen wir bei Hardware noch von multi core Systemen, aber es werden definitiv in einigen Jahren many cores im Einsatz sein. Ob das sinnvoll ist, sei mal dahingestellt. Aber da muss OpenBSD was tun. Bei Bitrig bin ich im Zweifel, ob die das, was sie sich auf die Fahnen geschrieben haben, wuppen können. Ich bin da sehr skeptisch.

Gruß c.

[jmt]

Ich weiß, dass es hier wieder etwas off-topic wird, aber ihr schreibt hier immer, dass OpenBSD kein general purpose OS sei. Das kann ich überhaupt nicht nachvollziehen. Das SMP-Verfahren ist, wie schon mehrfach beschrieben, einfach. Für 2-4 CPU Systeme ist diese Einschränkung in der Regel marginal. Ich selbst verwende OpenBSD als All-round-System und genieße die diversen Vorteile dieses OS, wie z.B. die hervorragende Dokumentation. Kein mir bekanntes OS ist so gut dokumentiert. Das führt auch dazu, dass ich noch nie Probleme bei einem Versionswechsel mit OpenBSD hatte. Selbst wenn man ein System nur Remote bedienen kann ist ein Upgrade kein Problem. Und wie mark05 schon bemerkte, wenn sie bei OpenBSD etwas machen, dann richtig. Das bedeutet nichts anderes, als dass Features erst in das OS einfließen, wenn sie ausgiebig getestet wurden. Über das ausgezeichnete Packaging-System könnte ich auch noch Seitenweise schwärmen. Auch das halte ich für eins der Besten.

Kurzum, wenn ich einen Service wirklich brauche und das System nach der Installation einfach nur sicher arbeiten soll, dann ist OpenBSD für mich die erste Wahl.

[mark05]

hi

mal ein interressanter post von theo zu dem thema

>On Wed, Jun 13, 2012 at 7:44 PM, Dominguez, Roland
><Roland.Dominguez@tamucc.edu> wrote:
>> I just came across this article and was wondering if it's legit:
>> http://www.h-online.com/open/news/it...-Bitrig-161695
>> 4.html
>
>Yes, it's legit and it reflects the reality of the facts

Except for the fact that it is bullshit.

They started the fork because they got kicked out because one
developer (Marco) hired 5 other developers for his startup company,
and attempted to hire around 10 other developers in a sneaky and
underhanded way. They were told, oh i forget they were "asked", to
not tell anyone else in OpenBSD that this was happening, probably
because people "including Theo" would be upset.

Funny thing is, I've never been upset about the 20+ OpenBSD and
ex-OpenBSD developers who now work for google.

Previously, many of those developers were in critical positions in the
development team. As they were suddenly hired with such terms and
conditions, they became more scarce in OpenBSD -- perhaps because they
suddenly got real busy with work, but also to avoid telling others
that this was happening. Various projects lagged. To avoid telling a
lie, they instead chose to not tell the truth. It had effects. It
was dishonest of them to not tell their co-developers that they were
creating vacuums in the development process.

So because of those decisions, they are now gone from OpenBSD. And
now they miss it. So now, all these guys who work for the same
company have started a fork. And it is directed by the guy who hired
them in the first place.

From where I stand, that is the truth.

Yet none of that is in that article, because the truth hurts,
doesn't it guys?

quelle ML openbsd-misc

holger

[darktrym]

Lustig, da kommen Erinnerungen hoch, wie damals Theo bei NetBSD rausgewurfen wurde.

[h^2]

Verstehe ich jetzt nicht. Sie sind gekickt worden, weil sie unehrlich waren und keine Zeit mehr haben. Eigentlich wollen sie aber so viel an OpenBSD arbeiten, dass sie glauben einen Fork alleine auf die Beine stellen zu können. Irgendwas stimmt da nicht

[darktrym]

Es gibt ein Forum, dort kannst du die meisten beteiligten inkl. Marco antreffen.

[h^2]

Einen der Slashdot Kommentare fand ich auf jeden Fall gut: Das einzige was man über Bitrig mit Sicherheit sagen kann, ist dass es ein Achtel von einem Byterig ist [sinngemäß]

[zyon]

Da hier, ja in jedem ganzen Beitrag von SMP zu lesen ist. Muss ich wirklich mal fragen: Verfolgt den überhaupt jemand, von den Leute die hier schreiben, die SMP Entwicklung in OpenBSD?

Zitat von Athaba

Ich weiß zwar nicht allzu viel über OpenBSD,....

Geht wohl viele so hier! Leider reflektiert das nicht in der Seitenzahl

[darktrym]

Ich verfolge seit Jahren die OpenBSD-Subseite plus, bisher tut sich im Bereich SMP nicht wirklich viel. Und wenn ich derzeit die Nachrichten im BSD-Umfeld sehe, pf(FreeBSD) mit feingranularen Locking, die Bestrebungen bei NetBSD brauchbares SMP im Netzwerkstack zu bringen oder npf, stehen bei OpenBSD lediglich kleinere Änderungen bei Threading und SMP für SGI zu Buche. Ist ja schon verdächtig das NetBSD einen eignen Paketfilter entwickelt, weil pf nicht deren Ansprüchen hinsichtlich performanten SMP entspricht.
Dahingehend könnte Theo schon rechthaben, bei vielen Subprojekten tut sich nicht wirklich viel. Vom Hocker gerissen haben mich die letzten Versionen jedenfalls nicht.

[zyon]

Zitat von darktrym

wirklich viel. Vom Hocker gerissen haben mich die letzten Versionen jedenfalls nicht.

Dann wird es sicherlich die nächste Version tun Ein Versprechen ohne Gewähr

[makenoob]

Zitat von darktrym

Ich verfolge seit Jahren die OpenBSD-Subseite plus, bisher tut sich im Bereich SMP nicht wirklich viel. Und wenn ich derzeit die Nachrichten im BSD-Umfeld sehe, pf(FreeBSD) mit feingranularen Locking, die Bestrebungen bei NetBSD brauchbares SMP im Netzwerkstack zu bringen oder npf, stehen bei OpenBSD lediglich kleinere Änderungen bei Threading und SMP für SGI zu Buche. Ist ja schon verdächtig das NetBSD einen eignen Paketfilter entwickelt, weil pf nicht deren Ansprüchen hinsichtlich performanten SMP entspricht.
Dahingehend könnte Theo schon rechthaben, bei vielen Subprojekten tut sich nicht wirklich viel. Vom Hocker gerissen haben mich die letzten Versionen jedenfalls nicht.

Ryab McBride schrieb dazu (heute auf der misc-liste):

My personal preference would be to go with a lockless or lock-on-write RB
tree for the state table, but without an SMP-safe network stack there's little motivation to work on such things (though it remains somewhere on my todo list).

[hawky]

... in dem zusammenhang (was ich immer schon mal wissen wollte ;-) ... wieviele leute arbeiten derzeit hauptberuflich bei/an openbsd ? weiss das jemand ?

--hawky