FreeBSD rockt!

Jedenfalls so als gesamtes System, da stimmt eigentlich alles … fast alles. Was nicht stimmt sind Dinge die importiert werden. Nennen wir mal ein paar prominente Hausnummern: dtrace, ZFS. Und ein paar Dinge unter ferner liefen wie diverse von OpenBSD/NetBSD importierte WLan-Treiber. ZFS ist in einem Zustand anhaltender Agonie — ich kann es nicht anders deuten, das Filesystem der Zukunft rockt einzig unter dem Muttersystem, sprich Sun Solaris. Klar einige haben nie Probleme damit, können alles machen — für das Gros jedoch ist es irgendwie ein Griff ins Klo. Mutet beinahe an wie hey ich überlebte 4 Promille, dir kann also gar nichts passieren.

dtrace per se ist noch jünger als Import, hat aber auch mit massiven Stabilitätsproblemen zu kämpfen — glaubt man zumindest häufigen Einträgen auf diversen Mailinglisten. Alles kein Problem, gut Ding will Weile haben. Da schauen wir also bei ZFS und dtrace vielleicht bei FreeBSD 9 oder 10 noch einmal rein — bei FreeBSD da bin ich Optimist. Sind halt nicht soviele Entwickler und auch Tester die gerne auf Produktivsystemen ihre Daten schrotten.

WLan ist ebenso in einer Art von limbus gefangen. Ural, ral, rum, wpi funktionieren mehr schlecht als recht und der in FreeBSD 8.0 importierte iwn funktioniert überhaupt nicht. wpi sowie iwl sprechen die weit verbreiteten Intel-Chipsätze an, ural, ral, rum ebenso weitverbreitete Budget-Chipsätze. Die Treiber tun unter OpenBSD beispielsweise ihre Pflicht, die Hardware funktioniert auch unter Linux einwandfrei — oft gehörtes Argument in den Reihen FreeBSDs: die Hardware ist nicht so besonders. Mag sein, aber andere haben jedoch anscheinend das bessere Knowhow mit diesen Problemen umzugehen.

Rum beispielsweise ist grausam, erst mit 7.2 konnte man diese Chipsätze wirklich nutzen ohne eine Kernelpanic zu werfen, leben muß man jedoch immer noch mit häufigen Verbindungsabbrüchen, die gelegentlich von tröpfelnder Performance versüßt werden. 8.0 geht wieder zu pre-7.2-Zeiten zurück — back to the roots der etwas anderen Art und bietet die gewohnten Kernelpanics. wpi ist einigermaßen nutzbar — /etc/rc.d/netif restart ist dein häufiger Freund. Ebenso ergeht es auch Nutzern von ral — ja man hat schon seinen Spaß mit WLan innerhalb FreeBSDs. Einzig und allein ath tut seine Pflicht, wurde auch seit jeher von Sam Leffler mit Priorität gehegt und gepflegt, glänzt also in der Regel.

Kurzum, something is rotten in the state of Denmark. Wenn man etwas importiert muß man dies auch pflegen, zumindest wenn man weiterhin gemäß dem Credo nur die höchste Qualität werkelt. Ansonsten wirkt das alles nur aufgesetzt.

Ich sags mal so, ich bin mit UFS zufrieden, ich brauche auch nicht unbedingt dtrace — ich könnte auch den x-ten WLan Stick kaufen um mein Laptop mit FreeBSD nutzen zu können. Es liegt auch weniger an den inzwischen auf Taschengeld-Niveau angelangten Preisen, sondern mehr an der Flut der Chipsätze und der Schwierigkeit zu FreeBSD kompatible ausfindig zu machen. Mir deucht WLan ist nicht das Metier von FreeBSD, die Leute mit dem Knowhow findet man eher bei OpenBSD und NetBSD und der liebe Mr. Leffler ist mehr an theoretischen Ausarbeitungen interessiert, die man mangels Treibern zwar nicht nutzen kann, deren griffige Terminologie aber richtig geil in den Release-Notes wirken. Auch mag man nicht wirklich Treiber pflegen die von diesem OpenBSD stammen, denn dessen enfant terrible Theo de Raadt verbindet eine innige Hass-Liebe zu Sam Leffler. Aber nun wirds nebulös und an der Realität ändert sich deswegen auch kein Iota.

FreeBSD rockt, aber man muß seine Hardware schon mit Bedacht wählen — keineswegs sollte man die Release-Notes zu Rate ziehen, die Praxis tut es eher. Dort greift dann per aspera ad astra :-)

, , , , , , , , , , ,

3 Antworten zu “FreeBSD rockt!”

  1. Solarix sagt:

    Das hört sich ja nicht so dolle an.
    Allerdings kann ich zumindest sagen das mein Webserver mit ZFS Pools stabil läuft.

    Allerdings kann ich aufgrund kürzlicher Erlebnisse mit ZFS unter dem Muttersystem Solaris sagen. Das ZFS noch eine echte Baustelle ist, die einem auch unter Solaris den letzten Nerv rauben kann und ohne Mission Critical Hilfe von Sun selbst fast in den Wahnsinn treiben kann.

    WLAN ist nach wie vor ein leidiges Thema nicht nur bei FreeBSD, auch beim Redmond System kann man sich da die Zähne ausbeissen. Zumindest hat es mich letzte Woche meinen Sonntag nachmittag auf dem Notebook einer bekannten funktionierendes Wlan zum laufen zu kriegen.

    Nach meinen Erfahrungen tut es unter FreeBSD wenn der Chip unterstütz wird meistens schmerzfrei, ich hab mich da aber meistens an Atheros oder Ralink Chipsätze und IBM Thinkpads gehalten. Von daher ist dies sicher auch nicht repräsentativ. Damit gab es aber zumindest bei mir nie Probleme, auf meinem aktuellen HP Brett hab ich es aber wegen Broadcom Chipsatz nie probiert und bin bei SuSI geblieben.

    Was UFS/FFS angeht, kann man doch eigentlich ganz zufrieden sein. Mit GEOM hat man doch ein starkes Framework das dem zickigen mdadm locker das Wasser abgräbt und fast mit dem Sun Volume Manager mithalten kann. :-)

    Von daher hat FreeBSD doch immer noch starke Argumente besonders im Serverbetrieb, nur bei den Clients sieht es leider etwas mau aus. :-(

    Ansonsten finde ich FreeBSD immer noch eine starke Plattform, das einzige was mir fehlt ist eine starke Clusterlösung. Das wäre mein Traum, eine Clusterlösung für FreeBSD vergleichbar zu Solaris. OK jetzt bin ich etwas vom Thema abgekommen.

    Einer der stärksten Punkte für FreeBSD ist für mich immer noch das patchen, selten kann so schmerzfrei gepatcht werden. Was ich bei Solaris, Linux und Konsorten schon so alles erlebt habe tut teilweise richtig weh.

  2. Oliver sagt:

    >Einer der stärksten Punkte für FreeBSD ist für mich immer noch das patchen, selten kann so schmerzfrei gepatcht werden.

    Imho das einzige System das man wirklich schmerzfrei als «rolling release» betreiben kann. Ich kenne einige Server dort ist das seit Ende der 90er usus.

  3. Martin sagt:

    Ich bin mit Free-BDSM auch nicht besonders zufrieden. Auch mein xl-Stick scheint nicht wirklich kompatibel zu sein. Ich denke letzlich ist das immer eine Geschmacksfrage und wie weit man eigentlich gehen möchte.
    Es gibt slaves, die wirklich aus dem letzten Loch pfeifen. Und DOM{ina}s sind meist recht zickig im Umgang. Eine starke Clusterlösung? Derzeit nicht in Sicht.

RSS-Feed abonnieren