CFT: Upcoming DragonFly Release 1.12

M

matthias_

Active Member
Hallo,

heute Nacht wurde DragonFly 1.12 gebrancht [1]. Das endgültige Release soll Ende des Monats stattfinden. Nach allgemeiner Diskussion wird das Release nicht 2.0, sondern 1.12 heißen. 2.0 wird dann Mitte des Jahres nachkommen.

Wer also DragonFly installiert hat, kann nun updaten und mithelfen, nach Bugs/Fehlern o.ä. zu suchen. Meldungen bitte an bugs @ lists.dragonflybsd.org.

[1] http://leaf.dragonflybsd.org/mailarchive/commits/2008-02/msg00124.html

Grüsse

matthias
 
Ob die Version nun 1.12 oder 2.0 ändert ja am Inhalt nichts :) Immerhin kannst du dich dann weiter auf ein 2.0 release freuen.
 
Sorry wenn ich das sage

Sollte aber nicht bald an einem amd64 port gearbeitet werden, sehe ich keine zukunft mehr in dem projekt

auch wenn es viele tolle features hat
 
Angeblich ist die amd64 Kompatibilität nur eine Kleinigkeit. Es kümmert sich bloß niemand darum, weil alle Entwickler interessantere Dinge in Anlauf nehmen.
 
Neben amd64 fehlt ja auch noch SMP. Außer die Russen implementieren es wirklich. Aber ich befürchte sie sind jetzt geschockt.

From: Michel Talon <talon@lpthe.jussieu.fr>
To: users@crater.dragonflybsd.org
Subject: Re: SMP question
Date: Sun, 27 Jan 2008 16:57:55 +0100
Sender: users-errors@crater.dragonflybsd.org
Newsgroups: dragonfly.users

Haidut wrote:


> Like I said in my first email, all I need is a rough estimate - 1
> month, 2 months, etc. Assume full-time, 40 hour week.

It may be relevant to have an idea of the time it took to get a
working SMP implementation (by working i mean, such that N
processors offer an advantage proportional to N with respect to 1
processor) for Linux and FreeBSD. It was certainly several years
for Linux (with a *lot* of developers, and several paid full time)
and about 5 years for FreeBSD. So i hope your project is not
a short term one ...

PS. By the way, FreeBSD is still not completely fine-grained locked
(for example the tty system is not) and one better take N<=8 above
to get satisfactory results. Linux is better in that domain because
it enjoys using proprietary techniques covered by patents, which have been
donated by IBM, SGI, etc. and that no BSD system can use, at least without
circumventing the patents. To take another exemple it took many years
Solaris to be considered better than the good old slowlaris system.

--
Michel Talon
Zum Vergrößern anklicken....


SMP könnte für viele BSDs das Aus auf x86 Hardware bedeuten. Welcher neue Rechner hat denn weder einen AMD64 Prozessor noch mehrere Kerne?
Das trifft insbesondere auch das Server-Segment. Dagegen ist fehlendes Flash oder DRI geradezu harmlos.

Ich befürchte DragonflyBSD wird eher zu einem Hort neuer Ideen und neuer Technologien, die später auf andere Systeme portiert werden, als zu einem konkurrenzfähigen Betriebssystem.
Das erinnert mich an OpenBSD mit openssh und pf ;-)


MfG
Michael Krauß
 
Ich bin mit der SMP-Performance zufrieden. Und da überflügelt FreeBSD in so manchem Benchmark Linux.
 
Ich denke schon, dass man sich bei DfBSD an SMP machen wird. Ich meine mal gelesen zu haben, das Spezialgebiet dieses Betriebsystem soll Distributed-Computing sein... also ich glaube da sind fast immer mehrere Prozzies im Spiel ;)
 
Mit SMP hatte ich auch nicht FreeBSD gemeint. Das ist das einzige BSD mit SMP Support. Siehe auch die zitierte Mail. FreeBSD ist hier vorbildlich.

Distributed Computing bedeutet ja auch mehrere physikalische Maschinen.
Da kommt man mit Multithreading nicht weit. Hier ist MPI angesagt. 6 Stunden habe ich damals für diesen dämlichen, parallelisierten Quick/Merge/Insertion-Sort gebraucht.
Auf den 4 einzelnen Dual-Xeon Maschinen spiele es dann keine Rolle, ob ich einen Prozess mit mehreren Threads laufen ließ oder einfach mehrere single-threaded Prozesse auf jedem Knoten erzeugt habe. (komischer Weise war der Kram am schnellsten mit doppelt so vielen Prozessen wie Prozessoren.) Das ganze System lieft unter SuSE 64bit mit pthread und MPICH.

Natürlich hoffe ich auch, daß die anderen BSDs in puncto SMP nachziehen, aber so recht daran glauben tue ich nicht. Naja, ich wollte damit ja nur sagen, daß man von Dragonfly als Gesamtsystem nicht zu viel erwarten sollte.


MfG
Michael Krauß
 
OpenBSD ist auch SMP fähig.
Ich ziehe mal meinen NetBSD Link zurück, letztes Jahr wurde auf jeden fall Andrew Doran als Full Time SMP Entwickler auf SMP angesetzt.
 
Leider läuft der Netzwerkcode immer nur auf einer CPU. Das spielt aber erst bei 10GBit Verbindungen eine Rolle. Ist also eher ein Problem für Rechenzentren.
 
d4mi4n schrieb:
OpenBSD ist auch SMP fähig.
Ich ziehe mal meinen NetBSD Link zurück, letztes Jahr wurde auf jeden fall Andrew Doran als Full Time SMP Entwickler auf SMP angesetzt.
Zum Vergrößern anklicken....

Diese Art von SMP haben natürlich alle neueren Betriebssysteme (auch NetBSD und Dragonfly). Das Problem ist aber der Kernel. Es kann immer nur ein Prozess Kernelcode ausführen. Genauer gesagt: es kann sich nur ein Prozess im Kernel-Kontext befinden.

Solange alle Prozesse nur in einer Schleife vor sich hinrechnen ist das egal. Aber wehe ein Prozess fordert eine neue Speicherseite an und ein Zweiter will Netzwerkpakete empfangen, während ein Dritter auf die Festplatte schreibt.

Man muß sämtlichen Kernelcode, sogar jeden Treiber nach kritischen Bereichen durchsuchen und mit einem mutex, einer semaphore, einem Monitor, oder was auch immer schützen. Besonders übel ist, daß Fehler nicht gescheit reproduzierbar sind : Race conditions, "Deadlock", ...
Das kocht einem das Gehirn weich.

Mal zum Vergleich die FreeBSD SMP Seite.
http://www.freebsd.org/smp/


MfG
Michael Krauß
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben