Die unendliche Geschichte vom Scheitern mit BSD

Ich schätze mal VirtualBox für FreeBSD wird nichtmehr lange auf sich warten lassen. Man hat bei Sun jedenfalls schon öfter mal davon geredet dass es demnächst kommen soll.
 
Meine curriculum vitae hinsichtlich Betriebsysteme ist leider nicht so mit Diversitäten angefüllt, wie so mancher Zeitgeist hier vorzugeben scheint. Ab 1993 war es bei bei Ultrix 4.2/4.3, danach eine Weile NetBSD (schon wegen der DECstation-Hardware). In unserer Einrichtung liefen diverse Maschinen unter OSF/1 und IRIX, wobei ich mit diesen Systemen aufgrund des Aussterbens der genialen RISC Workstations nicht sehr intensiv auseinandersetzte. Mein bisheriger Favorit aber war und ist OSF/1, auf den Alphas habe ich, gemessen am Stand der Technik, stets die schnellsten numerischen Rechnunge vollführen können. Compiler und geniale Hardware spielten mit dem ebenso genialen Betriebssystem harmonisch ein leistungsfähiges Spiel. Auf den Institutsservern kamen dann Linux und FreeBSD zum Einsatz. 1996 noch beide, weil wir ausprobieren wollten, welches der Systeme sich in unserer Landschaft besser mache. Die Entscheidung fiel zugunsten FreeBSD 2.0 - zum einen, weil die SCSI-Hardware (nicht von der Stange) unterstützt wurde und sich dieses BSD ebenso verhielt, wie ich es von BSD gewohnt war: unter hoher Netzlast war das System einfach verfügbar. Linux verabschiedete sich sang- und klanglos. Das war 'DAMALS'. Privat bin ich (leider) noch immer bei FreeBSD geblieben (7.1 PRE derzeit, 8.0-CUR wird gerade eruiert ...). Zudem habe ich mit diversen Linux-Abarten zu tun, RedHat/Centos, Suse und K/Ubuntu sowie Gentoo (2008/1). Mein Fokus, und das möchte ich an dieser Stelle besonders unterstreichen, liegt auf HPC und schnellen Serversystemen (wobei schnell nicht stabil ausschließt, um diesem Irrglauben den Hals im Vorfeld umzudrehen ...).
Serverseitig habe ich mit Centos/RedHat und Gentoo die besten Erfahrungen gemacht, Ubuntu ist Klasse, wenn es um einfache Desktopinstallationen geht. Mit FreeBSD habe ich zunehmend meine Probleme und sie scheinen derat marginaler/untergeordneter Natur zu sein, daß man sich derer nicht anzunehmen braucht. Gleich vorweg. ZFS ist derzeit einer der Gründe, weshalb FreeBSD in meiner 'wissenschaftlichen' Umgebung noch existiert, aber hier gibt es Tendenzen, sich der Wurzel zu nähern und OpenSolaris einzusetzen. Neben einigen Leistungsproblemen hinsichtlich I/O Durchsatz auf Datenträgern hat FreeBSD im Bereich HPC kaum noch etwas zu vermelden. Kein ccNUMA-aware Scheduler (weshalb bei den exorbitanten Anstrengungen um SCHED_ULE dies nicht gleich ins Auge gefaßt wurde, ist mir bis heute ein Rätsel und deklassiert diese Anstrengungen weiter als ein größtenteils sinnloses Unterfangen, um mich M. Dillons Meinung anzuschließen), kaum verfügbare Compiler (gcc/gfortran ist indiskutabel, wenn es um HPC Anforderungen geht, PGI, Pathscale und Intel bieten leider keine FreeBSD Compiler an, die NAG Compiler-Suite ist leider auch nicht besser als der gcc43).
Nun mag man meinen, FreeBSD habe ja statt des HPC/Cluster Sektors noch den Server-Kernbereich. Nun, hier gibt es leider auch einige Probleme. Die einst vielgerühmte Netzwerkstabilität und der hohe Durchsatz des BSD TCP/IP-Stacks gehören klar der Vergangenheit an, Linux 2.6 hat nicht nur in Sachen Scheduling, sondern auch in Stabilität und Geschwindigkeit massiv zugelegt! 15 - 25% Mehrleistung unter Linux bei hoher Netzlast (DNS-Anfragen, Server via NFS) sind nicht ungewöhnlich und haben mich die letzten 8 Monate mehr als nur einmal frustriert.
Nun, und dann gibt es da noch einige Problemfelder, die nicht so ganz ohne sind. Da wäre SCSI. Mitlerweile unter FreeBSD zu einem ernsten Sorgenkind avanciert. Auch heute noch ist die höchste Bandbreite mittels SCSI bzw. SAS erzielbar und wird in Servern lustig eingesetzt. USB, ein ungeliebtes Kind und einst eine Desktop-Spielerei, ist unter FreeBSD (<8.0)geradezu ein Horror. Neue DELL Hardware auspacken, USB Tastatur dran, FreeBSD 7.X starten ... keine Tastatur. Ähnliches auf einer Reihe IBM x35XX Maschinen. Server, keine Desktop-Spielzeuge, auf denen ein KDE (se es nun 2.0 oder das tolle 3.X) läuft, oder etwa Gnome. Sind diese Probleme umschifft, tauchen die nächsten auf, nämlich SCSI. Auch hier gabs Lösungen. Und dann wieder USB - nämlich, wenn man, weil es genehm und üblich ist, kleine externe Platten zum Sichern der Systempartitionen/Platten anzustöpseln.
Sind solche Kleinigkeiten dann mit Mühe und Arbeit behoben, widmet man sich PAM und anderen lustigen Kumpanen, wie zum Beispiel OpenLDAP. Ich weiß, das sind laut einigen Spezis 'Exoten' und mit Exoten hat man in der Regel so seine liebe Not. Irgendwann darf man dann auch bemerken, daß Linux ein 'netgroup' mapping via nsswitch erlaubt, was FreeBSD (noch?) fremd ist - oder fremd bleiben wird, wenn man sich diverse Trauerspiele um existente Patches betrachtet (PAM/LDAP), die seit nunmehr zwei Jahren keinen Weg in den FBSD Code gefunden haben. Aber Benutzerverwaltung etc. geht ja auch mit /etc/passwd und NIS/YP und sichere Konzepte benötigen wir Dank ECHOLON gar nicht mehr, also geht es ja auch mit rudiemntären Relikten ...
Die Zeiten, wo FreeBSD als Geheimtip gehandelt wurde, sind vorbei! Und das liegt gewiß nicht nur daran, daß man weniger Entwickler als die andere Seite hat.

ZFS und DTrace sind derzeit neben einer gemessen am Linux-Skript-Wahn einfacheren Wartung die einizgen wirklich triftigen Gründe es doch nochmals mit FreeBSD zu versuchen. Ich persönlich bleibe mit FreeBSD 'kleben', weil ich es kenne und nie ganz warm mit Linux wurde. Dennoch wird mir OpenSOLARIS schon wegen ZFS und DTRACE immer sympathischer. Auch die Konzepte der ccNUMA Architekturen, das bessere Scheduling in SMP Maschinen sind eindeutig die besseren.
Sucht man rationale Gründe, um das OS für einen HPC-Cluster oder größeren wie kleineren Server zu finden, bleibt nicht viel Gerede für FreeBSD über!

Das Thema 'mangelnde Entwickler' ist auch nicht ganz korrekt, ich denke, es liegt eher an der Qualität oder des Geniuses eines Entwickler. FreeBSD hat in den letzten Jahren zu viele seiner besten Köpfe verloren, übrig blieb eine Masse, die Fähig ist, Dinge ingenieurstechnisch handzuhaben, nicht aber um neue Konzepte und Ideen erfolgreich umzusetzen. Hier spiegeln sich auch gesellschaftliche Probleme wider.
 
die Mailinglisten kenne ich - danke fuer den Tip ;-)

Deshalb ja meine Frage, weil ich nicht nachvollziehen kann, wie Du darauf kommst. Mir ist es noch nie passiert, dass man mich da als Trottel oder Lügner bezeichnet hat.
 
Ubuntu ist für mich das bessere Debian.

Das ist wie bei den Zwergen auf den Schultern von Riesen - ein bisschen was verbessern ist halt einfacher als das Entwickeln der Grundlagen.

Wenn die Logik irgendeinen Sinn machen würde, dann wären eben auch Mint und Konsorten die besseren Ubuntus.
 
[...] hat es mich ziemlich genervt, dass das [Debian-] Team dermaßen lange braucht, um Pakete ans Laufen zu kriegen. Ich kann mich erinnern, dass Debian ziemlich lange auf KDE2 gesessen hat und FreeBSD schon längst 3.0 und 3.1 unterstützt hat
.

Ja, zu der Zeit war das noch so. Mittlerweile scheint sich das aber gewandelt zu haben - sogar und insbesondere bei Debian. Da gab es KDE 4.1 und 4.1.1 deutlich früher als in den FreeBSD-Ports. Was die Aktualität und Verfügbarkeit von Updates angeht haben die Linux-Distris die Führung übernommen.

Wenn ich neue Anwendungen oder deren Updates testen will, dann mache ich das mittlerweile wieder auf den Linuxen von Debian auf openSuse. Es ist nicht so, dass mir das bei den Ports oder bei pkgsrc zu lange dauert - aber irgendwofür müssen die Linux-Distris ja auch gut sein ;-)
 
Das ist wie bei den Zwergen auf den Schultern von Riesen - ein bisschen was verbessern ist halt einfacher als das Entwickeln der Grundlagen.

Wenn die Logik irgendeinen Sinn machen würde, dann wären eben auch Mint und Konsorten die besseren Ubuntus.

... im Bereich "FreeBSD" hat es seit langer Zeit kaum wirkliche Grundlagenentwicklungen gegeben. Das liegt daran, dass im FreeBSD Projekt kaum dazu faehige leute existieren bzw. die Strukturen keinen fruchtbaren Naehrboden zu liefern scheinen. FreeBSD inkorporiert ZFS als Dateisystem, eine SUN Entwicklung. Das viel kleinere DragonflyBSD Projekt um Matt Dillon fuehrt HAMMER als neues Dateisystem ein - eine Eigenentwicklung! FreeBSD quaelt sich seit R5.0 mit einem Hickhack des Threadingmodelles herum, adaptiert zuletzt ein O(1) Scheduling, bekannt aus der Linux-Welt. DragonflyBSD entwickelt ein komplett neues Threading-Paradigma mitsamt notwendiger Algorithmen um das Clustering-Konzept. Die Liste der innovativen Grundlagen liesse sich weiter fortfuehren. Ein Blick auf die Entwicklerkardinalitaet bei DragonflyBSD und ein Vergleich mit FreeBSD wuerde eher ein anderes Bild suggerieren. Das Argument, es seien zu wenige Entwickler vorhanden, laesst sich schnell entkraeften - es kommt eben auf die Qualitaet dieser an und, vielleicht auch noch wichtiger, die Projektstrukturen. Die scheinen im FreeBSD Projekt bereits so verharscht, dass wirklich nur noch Bestehendes soweit verbessert werden kann, wie eben der Teilueberblick eines der mitwirkenden Entwickler reicht.

GNU torpediert mit seiner restriktiven GPL3 die OpenSource Gemeinde und graebt sukzessive damit den BSD Systemen auf lange Sicht wohl den 'Markt' ab. Im Performance-Forum war zu lesen, dass der gcc 4.3 Compiler derzeit aufgrund politischer Probleme mit der GPL3 nicht ins FreeBSD 7/8 Projekt uebernommen wird. Einige der genannten alternativen BSD Projekte bedienen sich wieder des legendaeren PCC, den es schon lange unter der BSD Lizenz gibt und ca. 2 bis 10 mal schneller ist als der nun in die Jahre gekommene gcc. Gerade im Hinblick auf HPC nicht uninteressant und vor allem mit Blick auf LLVM/OpenCL ein Wegweiser, denn die Nutzung der GPU ist derzeit C-assoziativ und unterstuetzt weniger Fortran etc. Eine Renaissance des C als HPC Sprache duerfte damit etwas Auftrieb gegeben sein - aber man hat das bei FreeBSD noch nicht recht begriffen. Die "Stars" sind so von sich selber ueberzeugt, sie koennen auf einen neuen C Compiler die kommenden 25 Jahre verzichten!
 
Zuletzt bearbeitet:
Du vergisst dabei, dass FreeBSD ein laufendes System ist, während DragonFlyBSD nicht mal auf amd64 läuft. Es wurden viele tolle Grundlagen gelegt, aber die kleinen Details die das System benutzbar machen fehlen. Was man auch gut an gelegentlich veröffentlichten Benchmarks erkennt. Ich habe jedenfalls noch keinen gesehen bei dem DragonFlyBSD auch nur annähernd an FreeBSD heran käme.

Ich hege viele Hoffnungen für DragonFly, aber die erfüllen sich nur, wenn aus den vielen tollen Grundlagen auch mal tolle, unter realen Bedingungen einsetzbare, Features werden.
 
... im Bereich "FreeBSD" hat es seit langer Zeit kaum wirkliche Grundlagenentwicklungen gegeben.

Ich schlage vor, dass Du mal einen Blick in -CURRENT wirfst. Dort werden neue Technologien eingesetzt. In 2 Wochen wird der neue USB4BSD-Stack als Standard gesetzt. ARP2 wird heiß diskutiert. GPT-Support macht es möglich sehr große Festplatten (>2TB) zu unterstützen. GNU-Tools werden durch BSD-Tools ersetzt (seit längerem bsdtar). Verwaltung von Ports wurde mit portsnap und portmaster erweitert (2 richtig geile Tools).

FreeBSD inkorporiert ZFS als Dateisystem, eine SUN Entwicklung.

Die übrigens genial ist. Ich habe jetzt die neue ZFS-Version aus CURRENT auf dem Fileserver bei uns. Ein Auge für gute Sachen sollte man schon haben.

Das viel kleinere DragonflyBSD Projekt um Matt Dillon fuehrt HAMMER als neues Dateisystem ein - eine Eigenentwicklung!

DragonflyBSD ist für mich äquivalent zu FreeBSD-4.x. Das ist "nett" aber nicht viel mehr. Sie wurden gnadenlos abgehängt und werden aus Ressourcengründen den Stand der Technologie nie aufholen können.

FreeBSD quaelt sich seit R5.0 mit einem Hickhack des Threadingmodelles herum, adaptiert zuletzt ein O(1) Scheduling, bekannt aus der Linux-Welt.

Das sind zwei verschiedene Sachen, die Du hier nennst. Das feingranulare Locking ist wichtig. Du siehst es an den Benchmarks. FreeBSD ist das einzige System, das zur Zeit bzgl. SMP mit Linux konkurrieren kann. Spiel das nicht so herunter. Außerdem wage ich es mal zu behaupten, dass SCHED_ULE älter ist als der Linux-O(1)-Scheduler, der übrigens dort anscheinend durch einen O(log n)-Scheduler ersetzt worden ist.

... die Projektstrukturen. Die scheinen im FreeBSD Projekt bereits so verharscht, dass wirklich nur noch Bestehendes soweit verbessert werden kann, wie eben der Teilueberblick eines der mitwirkenden Entwickler reicht.

Schau mal wirklich hin, was da bei FreeBSD-8 abgeht. "Scheinen" ist kein wirklich objektives Argument. Wahrscheinlich hast Du gar nichts davon tatsächlich überprüft. FreeBSD entwickelt sich sehr schnell und ich habe manchmal Probleme, weil sich die Neuentwicklungen derzeit überlappen. Ich habe gerne immer 1 Risiko zu einer Zeit.

GNU torpediert mit seiner restriktiven GPL3 die OpenSource Gemeinde und graebt sukzessive damit den BSD Systemen auf lange Sicht wohl den 'Markt' ab. Im Performance-Forum war zu lesen, dass der gcc 4.3 Compiler derzeit aufgrund politischer Probleme mit der GPL3 nicht ins FreeBSD 7/8 Projekt uebernommen wird.

Ich glaube nicht, dass GNU das gleiche wie Linux ist. Sie haben ganz andere Ziele als Du das hier darlegst. Sie hätten locker BSD-Support einstellen können, wenn sie es wollten.

Einige der genannten alternativen BSD Projekte bedienen sich wieder des legendaeren PCC, den es schon lange unter der BSD Lizenz gibt und ca. 2 bis 10 mal schneller ist als der nun in die Jahre gekommene gcc.

Wieder so 2 Aussagen, die mich stören. Ich glaube, dass Du nicht weißt, wie ein Compiler entwickelt wird und ein "schneller" muss auch nicht äquivalent zu "besser" sein.

- aber man hat das bei FreeBSD noch nicht recht begriffen. Die "Stars" sind so von sich selber ueberzeugt, sie koennen auf einen neuen C Compiler die kommenden 25 Jahre verzichten!

Also, ich betrachte Dein Posting als ein Flame übelster Art. Du solltest schon etwas Zeit investieren und Nachforschungen machen, bevor Du Dich blamierst. Viele Trolle können es besser und streuen wenigstens Salz in die Wunde, wenn sie die Wunde erstmal gefunden haben.

Gegen FreeBSD kann man schon einen Rant starten. Aber ich glaube nichtmal, dass Du weißt wo die eigentlichen Probleme liegen. Das findet man aber meistens nur heraus, wenn man FreeBSD täglich einsetzt und es kennt.
 
Lieber Eisenfaust,
wenn du ein Problem mit FreeBSD hast, würde ich dir sehr stark nahe legen dein Betriebssystem zu wechseln. Ich will hier nun nicht die großen Vor- und Nachteile diverser Systeme von A wie Amoeba bis W wie Windows aufzählen, aber es gibt dort eine große Auswahl und da wird sicher das richtige unter sein. Es gibt nämlich Leute, die entscheiden sich gerade aus den von dir genannten Gründen für ein FreeBSD. Eher konservative Entwicklung, nicht nicht den neusten und meist nur halb ausgereiften Kram. Man schaut sich auch an, was andere machen. Ein neues Threadingmodell, toll. KSE war akademisch gesehen wunderbar, es hatte nur ein Problem. Die kritische Software, die Nutzer wollen, kam damit vorn und hinten nicht klar. Hätte man daran festgehalten würdest du nun darüber schreien, wie langsam doch FreeBSDs Threading mit $Datenbank ist.
Deine Aussagen über den Compiler zeugen auch nicht gerade von guter Kenntnis der Materie. FreeBSD arbeitet sehr wohl aktiv daran den GCC zumindest im Basissystem zu ersetzen. In den Ports wird es wohl nie möglich sein, denn der Ersatz müsste so ziemlich jede üble GCC-Erweiterung zwischen hier und Boston unterstützen. Aber diese Dinge brauchen Zeit, LLVM ist schlicht noch nicht so weit. Und PCC ist kaum eine Option, das Ding ist ein Design aus den 70ern, welcher sich so gut wie gar nicht in das 21te Jahrhundert bringen lässt. Möchtest du einen anderen Compiler, es hindert dich auch heute niemand daran ihn zu nutzen. Es gibt dort lang/gcc43, lang/llvm, lang/pcc, lang/cparser, etc.
Nein, was du geschrieben hast, riecht für mich sehr nach einem misslungenem Trollversuch. Den Beitrag vom 20.09.2008 können wir auch gern noch zerlegen. Zum Beispiel heißt ccNUMA "cache coherent", da die Cache Koheärenz garantiert ist. Es kann dem Betriebssystem völlig egal sein, wie die CPUs zum Speicher stehen. Nenn bisschen topologisches Scheduling, was FreeBSD lange kann, oben rauf und die Sache passt. DNS ist unter Linux schneller? Stimmt, solange du 7.0 nutzt. Aber die Zeit bleibt ja nicht stehen, schon 7.1 wird neue Locking-Pfade für UDP haben, womit Linux wieder überholt wird. Und HPC, ich kenne Personen, die wären froh, könnten sie ein FreeBSD anstelle von Linux einsetzen. Durch das harte fine-grained Locking skaliert es ein wenig besser, man kann schon ein paar mehr FLOPS rausquetschen.

Also meine Bitte, sollte es Getrolle sein, lass es. Du machst dich am Ende nur selbst unglücklich. Sollte es der Versuch von Kritik sein, ist freebsd-questions@ das Publikum und nicht wir hier. Ich kann dir aber sagen, als jemand der etliche FreeBSD-Installationen betreibt, die wirklichen Kritikpunkte, wo dir viele Personen inklusive mir zustimmen würden, hast du sehr weit umfahren. Und das wird man in anderen Medien ähnlich sehen.
 
Moin,

Ich schlage vor, dass Du mal einen Blick in -CURRENT wirfst. Dort werden neue Technologien eingesetzt. In 2 Wochen wird der neue USB4BSD-Stack als Standard gesetzt. ARP2 wird heiß diskutiert. GPT-Support macht es möglich sehr große Festplatten (>2TB) zu unterstützen. GNU-Tools werden durch BSD-Tools ersetzt (seit längerem bsdtar). Verwaltung von Ports wurde mit portsnap und portmaster erweitert (2 richtig geile Tools).
Und was ist mit der Authentifizierung gegen LDAP-Systeme wie ActiveDirectory, SunONE usw? Die bekannten Patches für passwd wurden bis heute nicht Committed. Warum nicht? Authentifizierung über NIS wird bei Neuinstallationen nicht mehr eingesetzt. LDAP ist hier das Maß der Dinge. Und FreeBSD?

Die übrigens genial ist. Ich habe jetzt die neue ZFS-Version aus CURRENT auf dem Fileserver bei uns. Ein Auge für gute Sachen sollte man schon haben.
Hat Eisenfaust auch nicht bestritten.

Das sind zwei verschiedene Sachen, die Du hier nennst. Das feingranulare Locking ist wichtig. Du siehst es an den Benchmarks. FreeBSD ist das einzige System, das zur Zeit bzgl. SMP mit Linux konkurrieren kann. Spiel das nicht so herunter. Außerdem wage ich es mal zu behaupten, dass SCHED_ULE älter ist als der Linux-O(1)-Scheduler, der übrigens dort anscheinend durch einen O(log n)-Scheduler ersetzt worden ist.
FreeBSD ist nicht das einzige OS, das mit Linux konkurrieren kann. Solaris sei hier noch genannt.

Also, ich betrachte Dein Posting als ein Flame übelster Art. Du solltest schon etwas Zeit investieren und Nachforschungen machen, bevor Du Dich blamierst.
Nu übertreib mal nicht. Ich finde Eisenfausts Kritik durchaus sachlich und getragen von Sachverstand niedergeschrieben.

Gegen FreeBSD kann man schon einen Rant starten. Aber ich glaube nichtmal, dass Du weißt wo die eigentlichen Probleme liegen. Das findet man aber meistens nur heraus, wenn man FreeBSD täglich einsetzt und es kennt.

Wenn die Kritik unangenehm wird, dann versucht man den Kritiker ins schlechte Licht zu rücken.

So long

JueDan
 
es ist schon dreist mir Dinge vorzuwerfen, derer sich die Anklaeger im gleichen Atemzuge selber schuldig machen!

Die Attackierer scheinen wohl selber nicht weiterlesen zu wollen! Die Reflexe scheinen wie einstudiert und fuer Fanboys charakteristisch.

Nun mal zu einigen Punkten. DragonflyBSD ist nicht lauffaehig - dafuer ist es faktisch zu jung, es existieren zu wenig Entwickler und das Systemparadigma hat eine auesserst innovative Wendung erfahren, die nicht im Handumdrehen implementierbar ist. Punctum. Dennoch schaffen es Dillon und seine Mannen, Innovationen aus eigener hand einzubringen, waehrend FreeBSD in den meisten Faellen aus Net- oder OpenBSD inkorporiert. Dillon schrieb in einem Posting, dass Pawel mit der ZFS-Portierung FreeBSDs Arsch gerettet habe - eine Aussage gravitativen Aussmasses, wenn man die Limitationen des 'Power to Serve'-systems im Serverumfeld kennt, die sich durch Innovationsblockaden jedweder Art ergeben haben.
Noch immer gibt es Probleme im Bereich PAM, OpenLDAP ist eine mittlere Katastrophe, der benannte simple passwd-Patch (der uebrigens nur bedingt funktioniert, was aber scheinbar an pam_ldap zu liegen scheint, in dieser Sache bin ich leider noch nicht sehr weit gekommen ...) geht nun ins dritte Jahr des Status 'pending', auch der versuch, ueber einen amerikanischen Kollegen Aufmerksamkeit zu erregen und fuer eine Revision zu sprechen scheiterte erfolgreich an der stoischen Ignoranz. Kein Kommentar, nichteinmal 'sorry, it's not a subject to change' oder aehnliches. Einfach aussitzen.
Das Compilerproblem ist gewiss auch bei FreeBSD bekannt, es ist ja mitlerweile so (er)drueckend, dass es einem Blinden auffallen muss. ich vermisse leider die aus den vergangenen Jahren bekannte innovative Aggressivitaet, die das Berkeley UNIX zu einem Innovationstraeger machte und nicht wie es heute ist, zu einem -kosumenten.
Nach nun fast 13 Jahren (Free)BSD Erfahrung in diversen Umgebungen (desktop, Server, HPC) sehe ich die teils sehr impulsiven und emotionalen Reaktionen meiner Vorredner als Bestaetigung meiner Beobachtung. Und welches System ich einsetze kann ich ganz sicher selber entscheiden. Da ich aber in einigen Faellen fuer andere entscheiden muss, wenn es um den Einsatz eines performanten und integrierbaren Serverbetriebssystemes im HPC Umfeld, ist es fuer mich auesserts schmerzhaft mich aus genannten kleinen aber stichhaltigen Gruenden gegen FreeBSD entscheiden zu muessen.
 
Zuletzt bearbeitet:
... im Bereich "FreeBSD" hat es seit langer Zeit kaum wirkliche Grundlagenentwicklungen gegeben.

Mag sein. Aber Dein Eintrag enthält ein paar Dinge, die man nicht unkommentiert stehen lassen kann. Zum einen bist Du mit der Annahme, dass ein O(1) Scheduler das Maß aller Dinge sei, einer Lüge aufgesessen. Die Komplexität bezieht sich an der Stelle auf die Anzahl der CPUs, d.h. ein O(1) Scheduler skaliert perfekt mit der Anzahl der CPUs. Das bedeutet aber nicht, dass er auch schneller oder besser ist. Auch die "Erfinder" in Linux-Land haben mittlerweile erkannt, dass ein nicht-O(1) Scheduler u.U. besser sein kann (siehe CFS).

Zum andern ist da die Sache mit den Compilern. Wenn ein Compiler "schneller" ist als ein anderer, dann kann das zwei Dinge bedeuten. Entweder der Compiler produziert schnelleren Code oder der Compiler schafft es in kürzerer Zeit, den Quelltext in Binärcode zu übersetzen. Im Fall von PCC vs. GCC ist wohl letzteres der Fall, d.h. PCC mag schneller mit dem übersetzen fertig sein. Deshalb PCC als HPC-Compiler zu bezeichnen halte ich für etwas gewagt. Tatsächlich ist es so, dass GCC (und die meisten anderen Compiler auch) die meiste Zeit mit Optimieren verbringen. Wenn mein Compiler also nicht optimierten Binärcode produziert wird er immer schneller sein, als wenn er noch zusätzlich optimieren muss.
 
Und was ist mit der Authentifizierung gegen LDAP-Systeme wie ActiveDirectory, SunONE usw? Die bekannten Patches für passwd wurden bis heute nicht Committed. Warum nicht? Authentifizierung über NIS wird bei Neuinstallationen nicht mehr eingesetzt. LDAP ist hier das Maß der Dinge. Und FreeBSD?

Also lass es mich so sagen. Ich hab mich zum ersten Mal mit LDAP-Authentifikation vor einer Woche befasst und heute läuft sich schon mit allen Systemen, die ich zentral verwalten möchte. Also wo ist das Problem?

Hat Eisenfaust auch nicht bestritten.

Er übersieht und spielt die großartige Arbeit von Pawel Jakub Dawidek herunter. Keinen Plan von Dingen, aber groß Reden schmeißen und das ohne Inhalt. Das ist Politiker-Gelaber.

FreeBSD ist nicht das einzige OS, das mit Linux konkurrieren kann. Solaris sei hier noch genannt.

Solaris kann SMP, ja. Letztes Mal, als ich Solaris verwendet habe, war ich damit nicht glücklich. Mir fehlte der Komfort von FreeBSD bezüglich Ports und grundsätzlich auch sinnvoll vorkonfiguriertem System. Ich schwanke zwischen vielen Systemen und hab schon einiges gesehen, aber kenne auch nicht alles. Mit FreeBSD bin ich erstmal für eine lange Zeit "zu Hause".

Nu übertreib mal nicht. Ich finde Eisenfausts Kritik durchaus sachlich und getragen von Sachverstand niedergeschrieben.

Sachlich ist das nicht. Hier fehlen Quellenangaben für seine Behauptungen. Ich will hier Fakten sehen, dann reden wir weiter.

Wenn die Kritik unangenehm wird, dann versucht man den Kritiker ins schlechte Licht zu rücken.

Versuchst Du meine Kritik schlecht zu reden? Ich sag Dir eins, Du kannst gerne die anderen Fragen, wie oft ich über FreeBSD meckere, aber ich zeige auch gleichzeitig die Gründe dafür auf und wie ich dazu komme, FreeBSD schlecht zu reden. Erstmal Hände dreckig machen, dann mitreden!
 
Also, wenn das mit dem Troll dortoben falsch rübergekommen ist, entschuldige ich mich dafür. Es ist aber so, dass ich in solchen Beiträgen eine Provokation sehe, da diese Aussagen in diesem Forum das falsche Publikum treffen. Hier sind nur wenige Committer unterwegs, die natürlich ihren Teilbereichen nachgehen. Kritik wie diese wird hier nie erhöhrt werden, sie führt stattdessen nur zu Unfrieden. Zudem kommen immer wieder die gleichen, bereits bis zum Exzess und weit darüber hinaus diskutierten Themen ans Tageslicht, allen voran OpenLDAP.

Es ist nicht so, dass ich FreeBSD kritiklos hinnehme. Es gibt Punkte, die mir nicht gefallen. Das beginnt bei der PR-Bearbeitung und endet damit, das meiner Meinung und meinem Einsatzfeld nach teilweise an den falschen Bereichen gearbeitet wird. ABER FreeBSD ist ein Open Source Projekt. Alle Entwickler arbeiten freiwillig daran. Selbst die bezahlten machen nur das, was ihnen Spaß macht oder wo ihre Arbeitgeber Nachholbedarf sehen. Ich bin daher gar nicht in der Position die Arbeitsweise dieser Personen zu kritisieren, im Gegenteil. Ich sollte jedem FreeBSD-Committer, egal ob Doc, Src oder Ports die Füße küssen, dass sie mit realtiv wenigen Leuten dies geniale System zustandebringen, welches mit Konkurenten mithalten kann, die über deutlich mehr Geld und Arbeitsstunden verfügen.

Und wie jedes System hat FreeBSD seine Vor- und seine Nachteile. Wenn es sich für deinen HPC-Kram nicht so gut eignet, ist es traurig. Aber vielleicht auch eine Notwendigkeit, geschuldet der Tatsache, dass niemand akut an dem Feld arbeitet. Gut und schlecht ist eine Frage der Sichtweise. Für meine Zwecke ist FreeBSD immer noch nah am Optimum, auch nach >12 Jahren noch. Selbst, nachdem sich der Fokus zum Teil verschoben hat. Aber das muss nicht für jeden so sein, es ist eine Frage des Standpunktes. Letztens sagte jemand zu mir: "Yamagi, du bist so glücklich. Ihr habt FFS, auch nach 25 Jahren immer noch das mit Abstand beste Dateisystem. Schnell und robust. Wir haben hier inzwischen 10 Stück zur Auswahl und wirklich brauchbar ist davon kein einziges." Nun, das würde ich sicher nicht so unterschreiben wollen. FFS hat auch gravierende Nachteile, aber für diese Person sind sie egal und die Vorteile sind ein Grund zu FreeBSD zu wechseln.

Ich war in der Vergangenheit auch sauer auf FreeBSD. Version 5 war Murks, 6 immerhin noch durchwachsen. Doch 7 hat versöhnt. Viele Kritikpunkte wurden ausgeräumt. FreeBSD 7.0 ist ein "dot zero"-Release und ich würde es zu den besten in der Geschichte der ganzen BSD-Familie zählen. Selbst Legenden wie FreeBSD 4 brauchten erst viele, viele Versionen, bevor sie ausgereift waren. In -CURRENT arbeitet man daran, die verbleibenden Kritikpunkte auszuräumen. Überarbeitung des VFS, Neuerungen im VM, Scheduling, USB, GPT, TTY-Layer, Userland, etc. Das Projekt ist wieder auf Kurs, nachdem es schlingerte. Aber ob der Kurs der Richtige für einen selbst ist, muss jeder für sich sehen.

Wenn der Kurs einem nicht zusagt, kann man drei Dinge tun. Man kann das Schiff verlassen, klamm und heimlich. Irgendwie scheint das bei uns BSDlern immer nicht zu klappen. Ich habe dieses Jahr mehr als 1000 Systeme von Linux, Solaris und einigen Alt-Unices auf FreeBSD migriert. Keiner dieser Kunden hat es durch die Welt gebrüllt, wie schlecht Linux doch ist. Man kann auch die Sache selbst in die Hand nehmen. Das ist natürlich leichter gesagt als getan, aber möglich. Hans-Petter Selasky war enttäuscht über die Dauerbaustelle USB, er griff in die Tasten und nun haben wir USB2 aka USB4BSD. Netapp wollte neues NFS-Locking, also bezahlten sie Doug Barton dafür. Viele Nutzer nervt es, dass man gemountete USB-Sticks nicht abziehen kann. Sie spendeten an die FreeBSD Foundation, die nun jemanden bezahlen kann, um die nötigen Änderungen vorzunehmen, die freiwillig niemand machen wollte. Und dann gibt es den letzten Weg, schreien wie Scheiße alles ist. Und das ist ehrlichgesagt asozial, weil es am Ende denen, die sich die Arbeit machen, schadet und ihnen im Weg steht.

Innovation ist ebenso eine Sache des Standpunktes. Ist FreeBSD wirklich nur Konsument? Was ist mit SCTP? VAP? GEOM? Wer schrieb die Atheros-Treiber, die heute die halbe Welt nutzt? Superpages? Die Liste könnte man fortsetzen. Was für den einen weltbewegende Dinge sind, sieht der andere nicht, da sie für ihn irrelevant sind.

Ich hoffe das stellt einiges klar.
 
Das ist wie bei den Zwergen auf den Schultern von Riesen - ein bisschen was verbessern ist halt einfacher als das Entwickeln der Grundlagen.

Wenn die Logik irgendeinen Sinn machen würde, dann wären eben auch Mint und Konsorten die besseren Ubuntus.
Ein Argument ins Extrem zu denken um es zu wiederlegen war noch nie wirklich überzeugend ;-)
Klar kommt es auf den Anwendungsfall an, aber die Popularität von Ubuntu auf dem Desktop zeigt, dass für viele User genau an den richtigen Stellen "ein bisschen verbessert" wurde.
 
Nun mal zu einigen Punkten. DragonflyBSD ist nicht lauffaehig - dafuer ist es faktisch zu jung...
Defakto ist es ein Branch der FreeBSD 4.x Linie und damit alles andere als jung.

FreeBSD wurde quasi komplett umgebaut. Die Entwicklung läuft zugegebenermaßen eher evolutionär aber geom ist in meinen Augen zum Beispiel eine ziemlich coole Entwicklung auf die ich nicht verzichten will.
 
Nun, es ist doch so, dass man immer eine Mischung aus revolutionärer und evolutionärer Entwicklung sehen wird. Die Frage ist das Verhältnis zwischen beiden. Linux ist sehr Revolutionär geprägt, es gibt kaum Hemmungen neuen Code aufzunehmen und alten auch zu eliminieren. OpenBSD ist genau das Gegenteil, sehr evolutionär. Lieber das vorhandene weiterentwickeln, ja keine großen Änderungen vornehmen. FreeBSD steht irgendwo dazwischen, aus den letzten eher revolutionären Jahren versucht man nun in wieder evolutionäre Gebiete zu steuern. Das hat alles seine Vor- und Nachteile, die man selbst gegeneinander abwiegen muss. Bei FreeBSD gab es sehr, sehr, sehr viele Beschwerden - darunter auch ich - gegen das zu aggressive, revolutionäre Entwickeln, weshalb man nun wieder eher konservativ evolutionär wird.

Und wie Kamikaze über mir schreibt, FreeBSD 7 ist mit FreeBSD 4 praktisch nicht mehr vergleichbar. Es steht zwar noch FreeBSD drauf, aber es ist was ganz anderes drin. FreeBSD 4 hat mit 7 ungefähr so viel gemeinsam wie Windows 95 mit Windows Vista (technisch gesehen). Das hat auch die Komptabilität zu anderen BSDs gebrochen. Die Integration von Code aus OpenBSD und NetBSD ist machbar, aber schwer. Aus FreeBSD in OpenBSD und NetBSD ist nicht selten aufwendiger als Neuschreiben. Schon allein aus dieser Tatsache heraus, ist der Codefluss in den letzten Jahren ziemlich einseitig geworden. Daraus ableiten, dass OpenBSD und NetBSD die tollen Entwicklungen haben und FreeBSD sie nur abkupfert, kann man allerdings nicht.
 
Gescheitert bin ich an BSD* noch nicht. Rechner sind generell nur ein Spielzeug für mich und stellen keine produktive Abhängigkeit ausser Dokumente verfasssen oder das Kommunizieren über das Internet per Email.
Warum BSD* einen hohen Stellenwert bei mir hat ist der von den Entwicklern festgelegte Aufbau, die Logistik und das Layout. Bei OpenBSD hat man z.B. einen Installer und arbeitet zielorientiert die Man Pages durch, bis der Webserver oder ein anderes Produktivsystem steht.
Persönlich gefällt mir FreeBSD. FreeBSD ist schnell, hat guten SMP-Support, ist sicherer als Linux(Distributionen) und hat gute Auswahl an Software durch die Ports. Die fbsd6/7 lassen sich ja nocht mit IBM's SSP nachpatchen, Neubau von World und Kernel und man zusätlichen Schutz gegen Ausbeutung von Pufferdingern.
Mein neuster Desktoprechner läuft mit FreeBSD 8.0 - Current/AMD64 und kommt super mit einem Q6600 zurecht.
Ein Uraltrechner Baujahr 2004 wird mit FreeBSD 8.0 - Current/i386 betrieben.
3D beschleunigung geht auch, als GPU ist ein NV43 Chip verbaut(Geforce 6200).
Daruf läuft Openarena wunderbar.
 
ich kam auch von windows zu bsd. genauer gesagt zu pc-bsd, was ich jetzt schon jahre nutze und mein produktivsystem ist. hatte mich auch zweimal an freebsd rangemacht und bin beidemal gescheitert. an was genau weiß ich sogar nicht mehr. ich bin auch eher an der zeit gescheitert, da ich noch mehrere hobbies habe die zeitinensiv sind/waren. und wenn ich dann wieder weiter machen wollte, war wieder ne neue version draußen (so ungefähr).

mein fehler damals war auch eher das ich nicht dokumentiert habe, wenn ich was falsch oder vor allem richtig gemacht habe. eine doku ist ja meist besser als ein hd-image. denn alleine das dokumentieren brennt es ja fast immer ins gehirn ein. zumindest die erkenntnis, daß man das problem schonmal hatte und nochmal nachgucken kann.

ich werde aber in den nächsten monaten dank neuer arbeitstelle wohl auch mal was beruflich mit (free)bsd zu tun haben.
 
Zuletzt bearbeitet:
Ich habe zu meiner Anfangszeit alles was ich dazu gelernt habe hier im Wiki dokumentiert. Und benutze es bis heute als persönliches Nachschlagewerk. Der Vorteil ist natürlich, dass jeder (also auch ich) von überall Zugriff auf die Infos hat.

Außerdem habe ich die Artikel an denen ich signifikante Beiträge geleistet habe auf meiner persönlichen Seite gesammelt. So finde ich sie schneller wieder.

Leider habe ich in letzter Zeit nichts mehr getan das ich in einen Artikel gießen könnte. Vielleicht sollte ich mal was über die Vermeidung von Datenverlust bei der Verwendung von fusefs schreiben.
 
Nach über einem Jahr ist FreeBSD nun von meinem Zweit-PC runter geflogen. Ich habe es erstmal aufgegeben. :( Es kamen immer wieder Probleme auf. Vieles habe ich akzeptiert oder Workarounds genutzt.

Das was mich endgültig dazu bewogen hatte FreeBSD zu verlassen (und wieder zu kommen, wenn es besser wird!), war als ich das Update von 6.3 auf 6.4 gefahren habe. Als die Config-Files gemerged werden sollten, mußte ich es manuell machen (bisher noch nichts schlimm). Aber als mir vi aufgezwungen wurde, und ich absolut nicht wusste wie ich diesen zu bedienen habe, habe ich den Reset-Taster gedrückt und Feierabend. Das war mir dann doch alles zu viel. Da war ja der BASIC 2.0 Build-in-Editor vom C64 intuitiever zu bedienen und verstehen. Das ich noch 2008 mit nem vi rummachen muß, hat mir meine ganzen Kompromisse, die ich bis dahin eingegangen bin, kaputt gemacht.

Ich habe übrigens danach mal das neue OpenSolaris ausprobiert. Und das habe ich auch aufgegeben. Weil es beim Herunterfahren einfach hängen geblieben ist. Und laut Recherche im offiziellen OpenSolaris-Forum bin ich nicht der einzige mit dem Problem. Ein Feedback gab es von SUN dazu noch nicht.
Das mein interner LAN-Onboard nicht erkannt wurde, war zwar auch peinlich, konnte ich aber durch den Kauf einer 5 EUR LAN-PCI-Karte umgehen. (ich bin wirklich bemüht, aber irgendwann ist Schluß für einen, der es zwingend nicht braucht)

Nach FreeBSD oder OpenSolaris werde ich zurück kommen, wenn diese sich irgendwann mal für die normalen User einsetzen. Bisher sind sie leider noch was für Menschen, die wirklich Windows abgrundtief hassen oder beruflich bezahlt werden, sich mit den Systemen tiefer zu beschäftigen, weil sie in dem Einsatzgebiet gut geeignet sind.

Ich habe festgestellt, das die Systeme noch nicht Mainstream-kompatibel sind.
 
Zurück
Oben