Login
Newsletter
Werbung

Thema: DragonFly BSD setzt auf Hammer 2

2 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von kraileth am Fr, 14. Juni 2019 um 15:57 #

Ihrer Zusammenfassung stimme ich in Hinblick auf die Allgemeinheit zu. Da es sich um ein Nischen-BS handelt, sind aber sicher einige der Punkte für die potentielle Zielgruppe wichtiger als andere. Wenn ich wirklich DF will und weiß, daß Dillon gerade viel mit Ryzen-Prozessoren gemacht hat, dann beschaffe ich eventuell entsprechende Hardware. Punkt b kann man, je nach Anforderungen, bestimmt auch ignorieren. Haarig wird's bei c...

TeX auf FreeBSD ist eine ganz eigene Geschichte - und leider keine besonders gute (trotz durchaus vorhandenem „Gruselfaktor“...). Die Kurzfassung auf meiner FreeBSD-Arbeitsstation sieht so aus (Ports-Baum auf dem Stand von gestern morgen):

% cat /usr/ports/print/texlive-base/distinfo
SHA256 (TeX/texlive-20150521-source.tar.xz) = ed9bcd7bdce899c3c27c16a8c5c3017c4f09e1d7fd097038351b72497e9d4669
SIZE (TeX/texlive-20150521-source.tar.xz) = 45459552

Absolut unbefriedigend - zumal es über die Jahre immer wieder Alternativen gab, die dann aber nicht im Ports-Baum gelandet sind! Egal. Am Wochenende landet mit „zziplib“ die letzte Laufzeit-Abhängigkeit für TeXLive in Raven, versprochen. Sollte ich mich nicht vertan haben, fehlen dann nur noch zwei weitere Pakete, die ich mir auch mal anschauen will. Vielleicht wird das aus dieser Richtung ja noch was mit TeX...

Die meisten anderen Punkte sind sicherlich für den einen mehr und für den anderen weniger ausschlaggebend. Bei Punkt l stutze ich allerdings. So weit ich weiß, legt DF gerade auf die Performance extrem hohen Wert und macht dabei keine schlechte Figur.

Was ich zusätzlich noch schade finde, ist das völlige Fehlen anderer Architekturen. Natürlich ist amd64 absolut bestimmend und die Entwicklergemeinde zu klein, um i386 erfolgreich fortzuführen oder an aarch64 zu tüfteln (woran FreeBSD gerade genug zu knabbern hat). Trotzdem hätte gerade das in Bezug auf die Qualität einen großen Nutzen. Dabei bin ich ein großer Freund der Strategie von OpenBSD, die ihr System (auf echter Hardware!) auch auf Exoten am Laufen halten, weil sie argumentieren, daß so Grenzfälle und Probleme oft leichter gefunden werden, bevor sie einem richtig schmerzhaft auf die Füße fallen.

[
| Versenden | Drucken ]
  • 0
    Von klopskind am Fr, 14. Juni 2019 um 17:56 #

    Wenn ich wirklich DF will und weiß, [...]
    Ja, dann ist es zweifelsohne geeignet.

    TeX auf FreeBSD [...]
    Es war nur ein Beispiel für kostenlose, breit verfügbare, nachgefragte und zentrale OSS für Unixoide, welche in den FreeBSD (und damit auch den DPorts) derzeit nicht verfügbar ist, geschweige denn rund läuft; von proprietären Produkten gar nicht erst zu sprechen.

    Am Wochenende landet mit „zziplib“ die letzte Laufzeit-Abhängigkeit für TeXLive in Raven, versprochen. Sollte ich mich nicht vertan haben, fehlen dann nur noch zwei weitere Pakete, die ich mir auch mal anschauen will. Vielleicht wird das aus dieser Richtung ja noch was mit TeX...
    Von den Raven-Ports hatten Sie mir schon einmal berichtet. Interessante Sache. Sie verdienen sich meinen Respekt für Ihr Engagement. Bravo und viel Erfolg! :up: :)

    Bei Punkt l stutze ich allerdings. So weit ich weiß, legt DF gerade auf die Performance extrem hohen Wert und macht dabei keine schlechte Figur.
    Korrekt, DF legt großen wert auf Performance und spielt in der Regel bei den "Großen" mit.

    Zahlen und Benchmarks zur Performance hängen allerdings immer vom Workload ab. Verbreitetere Systeme haben hier im Allgemeinen den Vorteil, auf eine möglichst große Anzahl verschiedener Workloads entwickelt, getestet und optimiert zu werden, ohne andere große Abstriche machen zu müssen. Das erhöht natürlich die Systemkomplexität enorm und verbrät viele Entwicklungsressourcen, die DF derzeit fehlen.

    Natürlich kann man viel Tuning betreiben, jedenfalls auf den meisten Systemen. Häufig handelt es sich dabei aber um Tradeoffs. Derzeit ist Linux bspw. im HPC quasi unübertroffen (nicht nur wegen der absoluten Performance, sondern wegen der Möglichkeiten für Tuning und der höheren Energieeffizienz). Die Algorithmen der glibc zur Speichervergabe & -verwaltung sind enorm flexibel und skalierbar, und bieten durch eine Vielzahl an Parametern einen vergleichsweise großen Spielraum für Tuning.
    Ein weiterer Faktor ist, dass kritische Software oftmals auf/für Linux entwickelt, getestet und optimiert und dann erst portiert wird.

    Architekturen
    Ja, das ist mir glatt entfallen, ist aber eigentlich indirekt an Punkt a) gebunden. OpenBSD ist hier wirklich vorbildlich, hat aber in den vergangenen Jahren so einige Architekturen rausgeschmissen.

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung