FreeBSD & Performance - Ein Vergleich

Status
Für weitere Antworten geschlossen.
soul_rebel schrieb:
Na den Anspruch kannst du haben und den habe ich auch an Software, aber trotzdem schuldet keiner der Devs dir irgendwas!
Zum Vergrößern anklicken....

In sehr vielen Fällen werden Entwickler für Arbeiten von ihren Arbeitgebern freigestellt, auch wenn es nur zeitlich eng begrenzte Kontingente sind. Sobald aber die öffentliche Hand Zahlmeister ist, habe ich als Steuerzahler mehr noch als sonst das Recht, mich an der Entwicklung per Eingabe mitzuwirken! Die neuzeitliche Egomanieschiene zieht nicht!

Ok, das war mir neu. Wenn das tatsächlich der Fall ist, wäre es durchaus zu beduaern.
Kann ich nicht beurteilen... Ich hänge nicht auf den Listen rum, und hatte nie Performance-Probleme.
Zum Vergrößern anklicken....

Die wenigsten von uns, die sich ernsthaft mit Betriebssystemen und unter anderem FreeBSD beschäftigen 'hängen' (oder lungern) auf irgendwelchen Listen diesbetreffend herum!

Alle PRs die ich bis jetzt geschrieben hatte wurden *irgendwann* beanwortet. Das hat manchmal 4 Wochen gedauert und nicht alle Probleme konnten behoben werden, aber untergegagnen ist keiner bis jetzt.
Ich hätte auch keine Lust mich mit proprietärer Software rumzuschlagen... Da finde ich es unverständlicher warum die dokumentierten 3D-Karten von den anderen BSDs nicht unterstützt werden.
Zum Vergrößern anklicken....

Löblich, daß auch Du PRs schreibst, um so der Entwicklung beizutragen, sehr löblich.

Wie gesagt, du solltest nicht von dir auf andere schließen. Alle Desktops die ich aufgesetzt habe laufen und haben keine der genannten Probleme.
Soso, wer ist den dieser "man" der sich auf welches Geschäft konzentrieren soll? FreeBSD ist ein Projekt.
Zum Vergrößern anklicken....

Reflexiv? ;-)

Inwieweit es überhaupt eine Hierarchie gibt ist mir unbekannt, dass da superzentrale Entscheidungen getroffen werden oder dass es einen grandiosen Plan gibt wage ich zu bezweifeln. Also bleibt es so:
Jeder der beitragen kann und will tut es. Wenn einer zufällig nicht das macht was du möchtest ist, ist das dein Problem.
Zum Vergrößern anklicken....

Wie ich sehe, kennst Du Dich ganz offensichtlich mit der Organisationsstruktur von FreeBSD gut aus. Jetzt erst verstehe ich die Tragweite und das Gewicht Deiner Argumente.
Zum Vergrößern anklicken....

Das ist wie gesagt nicht bös gemeint. Ich hab auch mehr als ein Jahr gewartet bis meine WLankarte unterstützt wurde. Aber ich bin trotzdem dankbar den Leuten die letztendlich die Arbeit gemacht haben.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
Zu den Patches, die nicht eingespielt werden, habe ich folgenden Senf beizusteuern. Zur Zeit FreeBSD 4.5 - 4.8/11 habe ich ein kleines Rechensystem in einem Institut betreut. Das Backupsystem lief seinerzeit tadellos, dann plötzlich gab es Fehler auf Bändern. Ich weiß nicht wie viele PRs ich abgesetzt habe, es kamen diverse Fragen, aber keine Lösungen, geschweige denn Warnungen! Dann schrieb mir eines Tages der Entwickler der eingesetzten Backupsoftware, daß es Probleme unter FreeBSD 4 mit der Thread-Bibliothek in Verbindung mit EOT auf Bändern gäbe. Nachfragen in diversen FreeBSD-lIsten, teils gar mit gezielten Anfragen auf das Problem, wurden von den tragenden Entwicklern mit Stillschweigen beantwortet! Als bei uns dann der GAU eintrat, fand ich beim Studium der BACULA Website (ich hatte nach wie vor das backupprogramm in Verdacht, unberechtigterweise) dann den definitiven Beweis dafür, daß über mehr als drei Minor-Revisions(!!!) ein bekannter und gefährlicher Bug mitgeschleppt wurde, der bei Verwendung von Threads dazu führte, daß die Summe der am Ende eines Bandes herausgeschriebenen Blöcke um ein paar Bytes zu groß angeben wurde - mit fatalen Folgen für Backups, die große dateien auf mehrere Bänder verteilten!

Und wem das nicht genug ist: Wer von den hier mitlesenden verwaltet seine Benutzer unter LDAP? Wenn man ein System einsetzt, das mit 'The Power to serve' wirbt, darf man erwarten, daß die Defizite im Desktopbereich durch Stärken im Serverbereich kompensiert werden. Und zum Serverbereich zähle ich nach wie vor auch Stärken im Umgang mit massiver Anzahl Benutzer und Abilitäten im Umgang mit gängigen Managementsystemen. Und OpenLDAP ist nun weiß der teufel keine marginale Größe im Geschäft, sei es in der Wissenschaft oder in der Wirtschaft. Während mit SAMBA etc. alles wunderbar klappt, sollte man dann doch mal versuchen, sein lokales UNIX Konto, das auf einem LDAP-Backend residiert, mit einem neuen Paßwort zu versorgen. Die überwiegende Mherheit meines Klientels griff sofort und intuitiv nach 'passwd' - und erlebte eine herbe Enttäuschung (das möge jeder selber probieren). Und nun das Lustige (oder weniger Lustige) an der Geschichte: Mit ein paar Handgriffen kann man eher klobig als elegegant in Zeile 126 den Quellcode von passwd.c (/usr/src/usr.bin/passwd/passwd.c) so patchen, daß passwd() via PAM mit LDAP kommuniziert und das Paßwort auf dem LDAP-Server ändert. Angeblich gibt es hierzu Patches - und das wurde mir vor wenigen Wochen von der Liste auch bestätigt!, aber dieser Patch oder diese Patches werden nicht eingepflegt bzw. man erachtet es als Marginalität! Bitte? Unter Linux kann ich mit dem passwd() via PAM (wie es definiert ist) das Paßwort auch auf dem LDAP-Backend (da via PAM) ändern! Bei FreeBSD hört die Serverwelt wohl im Archaikum 'NIS/YP' auf, wie mir scheint.
Meine 'Verschwörungstheorien' korrelieren sehr gut mit Beobachtungen unter den hiesigen Studenten, angewandt auf das verhalten von Entwicklern: Solange es ganz offensichtliche und für das Ego werbewirksame Meriten zu verdienen gilt und gibt, wird fast schon krankhafter Aktionismus an den tag gelegt. Sobald aber der Fokus, oder besser das Rampenlicht, woanders zu fokusieren beginnt, wird alles stehen und liegen lassen, quasi das Messer in der Sau stecken gelassen (um es im etwas ruralen Jargon ausdrücklich zu machen). Und so geht es offenbar auch mit FreeBSD (denn die Entwickler sind nunmehr fast alles jüngere Leute, Hubbard, Scheifler, McKusick, Dillon etc. sind älteren Jahrgangs oder gehören einer anderen Menschengattung an).

Und noch ein weiterer 'Spot', der schon lange in BSD-Kreisen diskutiert wird, von den FreeBSDlern ignoriert und erst jüngst von Dillon in DragonFly implementiert wurde: Man untersuche einfach mal wie oft die Funktion memcpy() und Artverwandte aufgerufen werden! Dann überlege man sich am Beispiel der AMD64-Architektur, was eine CPU minimal kann, wenn sie unter dem TAG 'amd64' compiliert wird. Einer der gemeinsamen Nenner sind die SSE2-Register, MMX, MMX2. Wenn man diese Register nun für das Kopieren und verschieben von Speicher verwendet, 'holt' man im schlechtesten Fall 15%, im besten Falle sogar 300% Geschwindigkeitszuwachs heraus. Deshalb sind diese Features in Linux mitlerweile zuhause, DragonFly-BSD implementiert dies sogar unter i386 und meines Wissens nach wird unter FreeBSD davon nichts(!) verwendet, obwohl diskutiert und wieder diskutiert. Ich interpretiere dieses Verhalten weniger als "nicht wollen", ich glaube eher, daß es an "nicht können" liegt. Und nicht können bedeutet auch schon, wenn man es nicht einmal schafft, sich Gedanken um eine potentielle Lösung des Problems zu machen.

Die BSD-Systeme haben eine phantastische, weil akademische Basis, die viel Raum für Innovationen lieferte (und noch liefern könnte). Systeme, die wie Linux zunehmend den Bedürfnissen gewisser industrieller Sparten per Distribution zugeschnitten werden, enden wie das aus meiner Sicht furchtbare SVR4. Oder AIX. Solaris bildet da eine Ausnahme, aber SUN hat bis jetzt immer großen Wert auf Innovation gelegt und ZFS beweist einmal mehr, wer Kopf und wer nicht Kopf hat. Leider wird aber diese Basis nicht weiter ausgebaut, sondern nur noch abgegrast. Die unsägliche Diskussion um SCHED_4BSD vs. SCHED_ULE, in der mehr als einmal Formulierungen wie 'offensichtlich legt der alte 4BSD Scheduler eine höhere Wichtung auf dies oder das' legt mir den Verdacht nahe, daß das Prinzip nicht vollends verstanden wurde. Und so kommt es dann ... oh, es ist mühselig ...
 
Yamagi schrieb:
So sehr es mir weh tut, im Moment ist aufgrund der Chipsätze AMD keine Alternative mehr. Und ich hoffe und bete, dass AMD das mit ihren eigenen Chipsätzen in Griff bekommt. Und dann auch FreeBSD wieder besser drauf läuft.
Zum Vergrößern anklicken....

Du sprichst mir aus der Seele! Vorab, man sollte das Gebaren der Chiphersteller und der hiesigen Politik im Lande der Bananen einmal unter folgendem Aspekt sehen: Wenn zunehmend Regierungen, Verwaltungen und privatwirtschaftliche Einrichtungen OpenSource-Systeme einsetzen, ist es entweder völlig absurd oder sträflich gezielt, wenn Chiphersteller ihre Chipsätze undokumentiert anbieten. nVidia ist leider diesbezüglich ein schlechtes Paradebeispiel und über den Erfolg ihres ersten nForce-Chipsatzes hat das Unternehmen wohl auch am eigenen Größenwahn zu leiden. Wäre da nicht SLI, so wäre der nForce500 oder nForce600 schon längst keine Alternative mehr! Bis heute ist rätselhaft, warum unter nVidias Chipsätzen nForce4x16, nForce590 bei Schaltung eines RAID 0 ein Supremum der Übertragungsrate gibt, das bei ziemlich genau 120 MB/s liegt - egal ob zwei schnelle oder gar vier schnelle Platten angeschlossen sind. Ein Intel ICH7/8R schafft etwas mehr als 300 MB/s mit entsprechenden Platten (das war entweder auf Anandtech oder techReport zu lesen). nVidia hält sich bedeckt! Auch hat nVidia clamheimlich das Boost-Feature des nF590 zurückgezogen, das, wenn zwei G70 GPUs minimal im SLI Verband eingesteckt sind, den PEG um 20 oder 30 % übertaktet. Funktionierte wohl nicht ... Aber dafür kann ja nun der Entwickler nichts ... Wie man bei TechReport nachlesen durfte, taugen AMDs neuen Chipsätze aus der 790FX Reihe ebnsowenig, vor allem ihre Paradedisziplin, PCIe 2.0, enttäuschte. Und der Einsatz einer betagten Southbridge aus dem Neolithikum der Computertechnik sagt eigentlich schon genug über den Zustand dieser Architektur. Aber zurück zum eigentlichen Thema, Doku und Treiber und FreeBSD. Durch einen dummen Umstand habe ich mein ersteres Mainboard für meinen Heimrechner, ein ASUS A8N-Deluxe, zerstört. Auf diesem System habe ich mit einer AMD 3500+ CPU Modellrechnungen durchgeführt und hatte etwa im Gefühl, wie schnell die Maschine war. da ich fast wöchentlich bis hin zur heißen Phase der Rechnungen das OS (FreeBSD 6.1/2) übersetzt habe, hatte ich auch ein Gefühl dafür, wie lange es etwa dauert. Nachdem das Board nach ca. 7 Monaten abgeraucht war, kam ein tolles A8N32-SLI Deluxe ins Haus. Mehr PCIe Lanes, größere Flexibilität, das war mein Argument. Schon mit dem A8N-Premium hatte man die Leiterbahnen zum Speicher so optimiert (verkürzt), daß DDR400 Speicher auch mit 4 GB mit DDR400 betrieben werden konnte, wenn der Speicher gut war. Das war ein Argument, das woh viel. Nun ja, nun zu FreeBSD. FreeBSD einmal auf dem alten Mobo, dann auf dem neuen Mobo - und sofort fiel mir eine Leistungsreduktion auf, die bis heute quasi anhält (weil der CK804 Chipsatz zu viele undokumentierte Features inne hat). Der Ärger mit den Netzkarten war erst der Auftakt ...
In einem Unternehmen betreue ich nebenher noch mehrere Server, die auf nForce 3600 Chipsätzen aufbauen. Seit FreeBSD 7.0 gibt es hier keine Probleme mehr mit den MCP55-Netzwerkinterfaces und die 6 SATA Ports scheinen auch ordentlich schnell zu sein - solange man kein ChipsatzRAID0 verwendet. Aber dann kam nun der erste Intel Server hinzu, der auf einem recht simplen P35-Mainboard aufgebaut ist. Und unter FreeBSD ist dieser Kasten gerade beim Plattendurchsatz eine Rakete! Ich habe zwei Hitachi T7K500 250 GB Laufwerke je auf der Intel und auf der AMD Plattform, es ist das neueste FBSD 7.0 eingespielt und ansonsten sind beide Systeme bis auf die Hardware identisch. Im Plattendurchsatz liegt die Intelplatine im Schnitt 10 - 15 MB/s vorne und ich bezweifle, daß das an der CPU liegt (einmal AMD 5600 und einmal Q6600, also Dual gegen Quad ... aber beide CPUs können mehr Daten schaufeln als die Platte schafft ...). Seit jenem tag ist die Hemmschwelle, auch Intel einzusetzen, weitaus tiefer ...

So, verzeiht bitte den Sermon ...
 
Moin,

  • Thema: (Open)LDAP und passwd: Es stellt sich immer mehr die Frage, warum das PAM-Framework implementiert wurde, wenn es nicht vollständig benutzt wird. Das gilt genauso für NSS. Bei FreeBSD 7 ist es nicht besser geworden. Ich weiß, wovon ich schreibe, da ich es für mein Buch recherchiert habe und beim Testen bestimmter Dinge gerade bei FreeBSD mit LDAP immer auf die Schnauze gefallen bin.
    Außerdem gehen bei einem Update alle gemachten Patches verlohren und man darf sich wieder tagelang hinsetzen und diesen Patch einpflegen und ausgiebig testen.
  • Thema: Desktop-Ausrichtung: Es stimmt das FreeBSD ein Projekt ist. Aber ein Projekt braucht eine Ausrichtung. Vor längerer Zeit wurde in BSDForen.de schon mal eine Diskussion zum Thema geführt, die letztlich die Strategie bestätigt hat.
  • Thema: PRs und Beantwortung derselben: Ich selber habe zum sym-Treiber (LSI-SCSI-HBAs) mehrere PRs geschrieben, weil der Treiber seit FreeBSD 6 das System nicht mehr booten läßt (FreeBSD 5.5 läuft sauber damit!). In der Beantwortung des PRs merkt man deutlich, dass Null Interesse besteht.
    Eine Nachfrage, wer denn der Treiberentwickler sei, wurde mir jemand genannt, der das schon lange nicht mehr macht. Auf eine weitere Nachfrage habe ich folgende Antwort erhalten (kein Witz): Nun ja, ich weiß jetzt auch nicht, wer da noch was dran macht, aber frag mal den. Antwort von "dem": Eigentlich kümmere ich mich ja nicht um den Treiber, aber ich kann es mir ja mal ansehen.
    Das ging ewig hin und her. Schließlich hatte ich mich aufgerafft und trotz Zeitmangels eine Lösung für das Problem gefunden und ausprogrammiert. Das habe ich in der Mailingliste bekannt gegeben. Reaktion? Ha, keine! Bei den Verantwortlichen habe nachgehakt und die Antwort war: Das ist eine Linux-Lösung.:confused:. Ich weiß trotz mehrmaliger Nachfragen nicht, warum das eine "Linux-Lösung" sein soll.
    Mein Gesprächspartner meinte schließlich noch: Der Treiber ist in Ordnung, weil er seit vier Jahren nicht mehr angefaßt wurde.:eek:. Eine Email früher wurde mir vom gleichen Entwickler aber geschrieben, dass sich am Framework etwas geändert hat. Wie paßt das zusammen?
  • Thema: alte Zeiten: Ja, es stimmt, dass solche Dinge zu Dillons-Zeiten nicht gegeben hat!
  • Thema: ZFS: ZFS ist in meinen Augen eine Spielerei und ein Resourcenfraß ohne Ende. Da wäre es besser gewesen, Ausfallsicherheit in UFS zu implementieren (hot spare areas siehe HPFS/HPFS386) oder auf 128Bit zu erweitern.

Schließlich haben diese und einige andere Fehlentwicklungen uns als Firma dazu bewegt, unseren Kunden FreeBSD nicht mehr zu empfehlen und migrieren alle FreeBSD benutzenden Kunden im Moment zu Linux bzw. Solaris. 600 Lizenzen wandern einfach so nach /dev/null und es wird kein Zurück geben.
Das Hauptargument war und ist leider, dass immer mehr Features eingebaut werden, aber alte Fehler nicht oder nur unzureichend behoben werden.
Genauso wird mein persönliches Engagement in Sachen FreeBSD auch beendet werden. Es wird in der FreeX von mir zum Thema FBSD nix mehr erscheinen.

So viel dazu.

JueDan
 
juedans Entscheidung kann ich gut nachvollziehen. Ich habe es bereits 2000 aufgegeben FreeBSD bei der Arbeit einzusetzten. Konkret: es ist mir nicht gelungen FreeBSD auf IBM-Servern zu installieren. Ich mußte erst ein Minimalsystem mit RedHat installieren um dann Debian draufzubringen, weil dessen Installationskernel den RAID-Controller nicht unterstützt hat.
Bis zur Version 3 war FreeBSD im Vergleich mit Linux klar besser.
Ich habe den Eindruck die FreeBSD-Entwickler betrachten es als akademische Spielwiese und verhalten sich wie der Teil der bildenden Künstler, die ihre Werke für sich selbst schaffen.
Das war mein letzter Beitrag in diesem Forum. Ich betrachte es als Zeitverschwendung hier zu posten.

PS: der letzte Satz muß nicht kommentiert werden, er beginnt mit "ich betrachte ..." und nicht mit "es ist Zeitverschwendung ...".
 
Zuletzt bearbeitet:
@juedan:

Ich danke Dir sehr für Deinen Beitrag. Warum? Weil ich mich bis heute als unfähig gesehen habe! Und das ist mein ernst. Du beschreibst Probleme, die keine sein dürfen. PAM ist ein Standard, der funktionieren muß. NSS ist ein Standard, der viel zu spät in FreeBSD eingebaut wurde und immer noch nicht sauber arbeitet. Weiterhin scheint sich mein Verdacht zu bestätigen, daß an der FreeBSD Spitze zur Zeit profilneurotische Selbstdarsteller sitzen, die eine Chance haben, ihre mittelmäßigen Abilitäten ins Rampenlicht zu setzen. Es gilt nicht, die Sache, den Auftrag zur Perfektion zu bringen, nein, es geht vielmehr darum, sich und seinen Namen möglichst schnell und ohne großen Aufwand populär zu machen - wohl in der Hoffnung, ein lukratives Angebot aus der Industrie oder gar Forschung(?) zu erhalten.

Ich sehe mich auch durch die Art und Weise, wie Patches aus der Gemeinde behandelt werden, bestätigt. Es gibt eine etablierte 'Clique', die Patches posten und einpflegen kann und darf, deren namen sind in den Listen allgegenwärtig. Viele kleinere wichtigere Patches und Vorschläge aus der Peripherie gehen schlichtweg unter bzw. werden ignoriert. Ein weiteres Beispiel: OpenOffice. Wie lange konnte wegen eines Fehlers in den binutils OO nicht compiliert werden? Ein Patch, der gcopy durch das bordeigene cp ersetze (gcpy respektiert ACLs, die aber unter FreeBSD mit OO keine Relevanz besizten!). Es war ein einfacher Patch, der lediglich eine weitere .if-Abfrage im Makefile machte. Pflegte man diesen Patch selber ein (nachdem man stundelang mühevoll danach gegoogelt hatte, denn je älter eine Info wird, desto größer die Wahrscheinlichkeit, daß sie durch ähnliche oder gleiche Schlagworte überdeckt wird), klappt die Übersetzung. Gerade bei einer solchen trivialität kann man sich nicht auf den Standpunkt zurückziehen, man orientiere sich am Servermarkt (und wenn, dann stellt sich die PAM/passwd/LDAP-Frage erneut).

Zum Thema Projket folgendes: Es ist srichtig, daß FreeBSd ein Projekt ist. Allerdings leben Projekte nicht von Luft und Liebe, von irgendwoher muß Geld her. Dieses Geld kommt in der Regel aus der Forschung oder Industrie. Dazu muß sich das 'Projekt' aber dort ersteinmal etablieren und einen Namen machen. Das heißt letztlich für die Initiatoren, daß sie mit dem notwendigen Weitblick eine Balance zwischen Instabilität und den Bedürfnissen derer, die das Projekt einsetzen, halten. Das ist leider im Moment durch die oben genannte Verhaltensnormalität der 'Macher' nicht mehr gewährleistet, wie mir scheint.

ZFS: Es ist wohl wahr, daß ZFS resourcenhungrig ist, allerdings hat ZFS einen riesigen Vorteil: die einfache Migrationsfähigkeit! zpool export/import hat es mir in der letzten Zeit vielfach sehr einfach gemacht, ein Array von einer Maschine zur nächsten zu schleppen - unabhängig vom laufenden OS. Aber ich gebe Dir Recht, man hätte vielleicht vielmehr UFS2 verbessern sollen. Mich ärgert immer noch, daß gpt() nicht richtig funktioniert und die Tools in FreeBSD recht mißverständlich benutzbar sind. Entweder stelle ich mich zu blöd an, oder aber es gibt wirklich ein Problem mit der Handhabung. Wie oft komme ich mit fdisk() und gpt() durcheinander. Wie oft ärgert es mich, daß ich nur Partitionen a-h anlegen kann, wenn ich mich auf die traditionellen Werkzeuge beschränke, wie oft läuft nix mehr, wenn mir das System die GPT durch einen MBR zerplückt und alles für die Katz' war. Ärgerlich ist das schon lange nicht mehr, sondern nur noch traurig.

Bedauern möchte ich auch über die Entscheidung äußern, daß in FreeX zukünftig nichts mehr bezüglich FreeBSD erscheinen wird. Wenn diese Entscheidung unumstößlich ist, würde ich mich doch sehr freuen, wenn dies mit einem Artikel, der die Mißstände ankreidet, geschehen würde. Wenn der deutschsprachige Raum von den Angloamerikanern ignoriert wird, wird nichts weiter passieren und damit kann man getrost dieses OS hierzulande zu Grabe tragen. Aber bitte nicht lautlos, das würde die verzweifelten Bemühungen all derer, die sich bemühten, nur weiter diskreditieren.

Schönen Sonntag

P.S.

Man schaue mal hier ... Das war Mitte 2006 und zielte auf einen 'Bug', der bis dahin schon ein Jahr alt war ...
http://lists.freebsd.org/pipermail/freebsd-bugs/2006-July/019492.html
 
Zuletzt bearbeitet:
In Anbetracht der in diesem Thread gesammelten Erfahrungen und Darstellungen muss ich mich langsam aber sicher fragen, wie man sich noch guten Gewissens hinstellen und hundertfach kostenlose CDs unters Volk werfen kann. Bestimmte Leute pushen ja bevorzugt den BSD-Auftritt auf Messen, aber unter Berücksichtigung der sich hier offenbarenden Fehler kann der Schuss nur nach hinten losgehen.

Die normalen Heimanwender kommen vermutlich über ein mildes Lächeln nicht hinaus und - wie sich jetzt herausstellt - die professionellen Anwender werden in Fallen trappen, die in professionellen und bekannten Systemen nichts zu suchen haben. Bugreports sind mehr oder minder sinnlos, weil die Fähigkeit oder der Willen fehlt, diese auch zeitnah und fachgerecht zu behandeln.

Die logische Schlussfolgerug ist, dass jeder Versuch, FreeBSD zu pushen, zwangsläufig nach hinten losgehen muss und FreeBSD nur noch schneller in die Bedeutungslosig- und Lächerlichkeit treibt.
 
@juedan:

Ich danke Dir sehr für Deinen Beitrag. Warum? Weil ich mich bis heute als unfähig gesehen habe! Und das ist mein ernst. Du beschreibst Probleme, die keine sein dürfen. PAM ist ein Standard, der funktionieren muß. NSS ist ein Standard, der viel zu spät in FreeBSD eingebaut wurde und immer noch nicht sauber arbeitet. Weiterhin scheint sich mein Verdacht zu bestätigen, daß an der FreeBSD Spitze zur Zeit profilneurotische Selbstdarsteller sitzen, die eine Chance haben, ihre mittelmäßigen Abilitäten ins Rampenlicht zu setzen. Es gilt nicht, die Sache, den Auftrag zur Perfektion zu bringen, nein, es geht vielmehr darum, sich und seinen Namen möglichst schnell und ohne großen Aufwand populär zu machen - wohl in der Hoffnung, ein lukratives Angebot aus der Industrie oder gar Forschung(?) zu erhalten.

Ich sehe mich auch durch die Art und Weise, wie Patches aus der Gemeinde behandelt werden, bestätigt. Es gibt eine etablierte 'Clique', die Patches posten und einpflegen kann und darf, deren namen sind in den Listen allgegenwärtig. Viele kleinere wichtigere Patches und Vorschläge aus der Peripherie gehen schlichtweg unter bzw. werden ignoriert. Ein weiteres Beispiel: OpenOffice. Wie lange konnte wegen eines Fehlers in den binutils OO nicht compiliert werden? Ein Patch, der gcopy durch das bordeigene cp ersetze (gcpy respektiert ACLs, die aber unter FreeBSD mit OO keine Relevanz besizten!). Es war ein einfacher Patch, der lediglich eine weitere .if-Abfrage im Makefile machte. Pflegte man diesen Patch selber ein (nachdem man stundelang mühevoll danach gegoogelt hatte, denn je älter eine Info wird, desto größer die Wahrscheinlichkeit, daß sie durch ähnliche oder gleiche Schlagworte überdeckt wird), klappt die Übersetzung. Gerade bei einer solchen trivialität kann man sich nicht auf den Standpunkt zurückziehen, man orientiere sich am Servermarkt (und wenn, dann stellt sich die PAM/passwd/LDAP-Frage erneut).

Zum Thema Projket folgendes: Es ist srichtig, daß FreeBSd ein Projekt ist. Allerdings leben Projekte nicht von Luft und Liebe, von irgendwoher muß Geld her. Dieses Geld kommt in der Regel aus der Forschung oder Industrie. Dazu muß sich das 'Projekt' aber dort ersteinmal etablieren und einen Namen machen. Das heißt letztlich für die Initiatoren, daß sie mit dem notwendigen Weitblick eine Balance zwischen Instabilität und den Bedürfnissen derer, die das Projekt einsetzen, halten. Das ist leider im Moment durch die oben genannte Verhaltensnormalität der 'Macher' nicht mehr gewährleistet, wie mir scheint.

ZFS: Es ist wohl wahr, daß ZFS resourcenhungrig ist, allerdings hat ZFS einen riesigen Vorteil: die einfache Migrationsfähigkeit! zpool export/import hat es mir in der letzten Zeit vielfach sehr einfach gemacht, ein Array von einer Maschine zur nächsten zu schleppen - unabhängig vom laufenden OS. Aber ich gebe Dir Recht, man hätte vielleicht vielmehr UFS2 verbessern sollen. Mich ärgert immer noch, daß gpt() nicht richtig funktioniert und die Tools in FreeBSD recht mißverständlich benutzbar sind. Entweder stelle ich mich zu blöd an, oder aber es gibt wirklich ein Problem mit der Handhabung. Wie oft komme ich mit fdisk() und gpt() durcheinander. Wie oft ärgert es mich, daß ich nur Partitionen a-h anlegen kann, wenn ich mich auf die traditionellen Werkzeuge beschränke, wie oft läuft nix mehr, wenn mir das System die GPT durch einen MBR zerplückt und alles für die Katz' war. Ärgerlich ist das schon lange nicht mehr, sondern nur noch traurig.

Bedauern möchte ich auch über die Entscheidung äußern, daß in FreeX zukünftig nichts mehr bezüglich FreeBSD erscheinen wird. Wenn diese Entscheidung unumstößlich ist, würde ich mich doch sehr freuen, wenn dies mit einem Artikel, der die Mißstände ankreidet, geschehen würde. Wenn der deutschsprachige Raum von den Angloamerikanern ignoriert wird, wird nichts weiter passieren und damit kann man getrost dieses OS hierzulande zu Grabe tragen. Aber bitte nicht lautlos, das würde die verzweifelten Bemühungen all derer, die sich bemühten, nur weiter diskreditieren.

Schönen Sonntag
 
Steve` schrieb:
In Anbetracht der in diesem Thread gesammelten Erfahrungen und Darstellungen muss ich mich langsam aber sicher fragen, wie man sich noch guten Gewissens hinstellen und hundertfach kostenlose CDs unters Volk werfen kann. Bestimmte Leute pushen ja bevorzugt den BSD-Auftritt auf Messen, aber unter Berücksichtigung der sich hier offenbarenden Fehler kann der Schuss nur nach hinten losgehen.

Die normalen Heimanwender kommen vermutlich über ein mildes Lächeln nicht hinaus und - wie sich jetzt herausstellt - die professionellen Anwender werden in Fallen trappen, die in professionellen und bekannten Systemen nichts zu suchen haben. Bugreports sind mehr oder minder sinnlos, weil die Fähigkeit oder der Willen fehlt, diese auch zeitnah und fachgerecht zu behandeln.

Die logische Schlussfolgerug ist, dass jeder Versuch, FreeBSD zu pushen, zwangsläufig nach hinten losgehen muss und FreeBSD nur noch schneller in die Bedeutungslosig- und Lächerlichkeit treibt.
Zum Vergrößern anklicken....

Ganz so furchtbar ist es nicht. Wie stellen allgemein einen Niedergang der Qualität fest - auch wenn sich die Funktionalität erweitert, so bleibt deren Qualität nachweislich auf der Strecke. Leider legt der Zeitgeist mehr Augenmerk auf Masse statt Klasse.
Gestern habe ich mit einem Kollegen ein paar Probleme diskutiert, die ich seit einiger Zeit auf meinem Single-Core AMD 3500+ System habe. Es betraf Stockungen des Betriebsablaufes, wenn auf den SATA Platten hohe Last auftrat. Dieses Problem habe ich bis heute mit jedwedem Scheduler, vermehrt aber mit ULE. Meine Abkehr von der AMD Plattform hat mir nun im Labor einen sattsam ausgebauten QuadCore Q6600 mit P35-Chipsatz beschert, den ich jetzt unter FreeNSD 7 quäle. Auch hier treten bei hoher SATA- und Netzlast Stockungen beim HDA auf, wenn man Musik abspielt. Fenster unter X11 sind flüssig, auch wenn sie ab und an zu hakeln beginnen. Mit dem Single-Core ist das sehr viel schlimmer. Nun, ich war doch froh zu sehen, daß ein funkelnagelneues Linux/Gentoo 2007.0 oder .1 genau dieselben Probleme auf einem Q6600 System hatte. Ein Pentium M mit 1,6 GHz (Single Core) hatte keine Probleme. Das läßt den Schluß zu, daß es sich um ein Treiberproblem bzw. Scheduler Problem handelt. Auch diverse Einstellungen im Kernel (Scheduler Prioritäten etc.) haben unter Gentoo das Problem nicht gelöst.

Ich erinnere mich, daß ich mich sehr oft über einen stetig nach unten korrigierten Leistungsumfang meines Heimrechners in der Mailing-Liste beschwerte. Das wurde eher mit einem Achselzucken abgetan. Auffällig sind eben die Verzögerungen am ehesten mit X11. Es hieß dann, es läge am X-Server. Nun, da gab es Probleme, aber wenn man sich dann ohne X11 mal die Pinglatenzen unter einem Lastszenario anschaut, dann stellt man fest, daß auch das Netzinterface unter FreeBSD ins Stocken gerät. Der Durchsatz der Netzinterfaces geht in den Keller, sobald massiv Last auf dem SATA Subsystem erzeugt wird. Also nicht bloß ein X11 Phänomen - man sieht es beim Desktop-System nur eher als bei einem Server.
Nun, unter Linux war das nun gleichermaßen! Beide Systeme mit Q6600, eines mit 2 GB, eines mit 8GB RAM, eines unter Linux, eines unter FreeBSD, ein Mainboard von GigaByte, eines von ASUS ... und dennoch ähnliche Probleme? Vielleicht liegen diese Probleme auch in einem grundlegenden Fehlkonzept?
 
Ich würds ja so gerne bestätigen, aber alle Probleme, die ich unter FreeBSD habe, sind unter Linux nicht existent - völlig unabhängig von der verwendeten Linuxdistribution, versteht sich. Für meine Probleme und Unpäßlichkeiten mit FreeBSD liegt die Fehlervermutung ganz klar auf Seiten FreeBSDs; da bin ich mir sicher, ich habe immerhin 3 Jahre Testzyklen hinter mir. :)
 
Steve` schrieb:
Ich würds ja so gerne bestätigen, aber alle Probleme, die ich unter FreeBSD habe, sind unter Linux nicht existent - völlig unabhängig von der verwendeten Linuxdistribution, versteht sich. Für meine Probleme und Unpäßlichkeiten mit FreeBSD liegt die Fehlervermutung ganz klar auf Seiten FreeBSDs; da bin ich mir sicher, ich habe immerhin 3 Jahre Testzyklen hinter mir. :)
Zum Vergrößern anklicken....
Das kann ich leider genauso unterschreiben. Ich wuenschte mir auch, dass es auch anders waere. :(
 
Hallo Eisenfaust,

Bedauern möchte ich auch über die Entscheidung äußern, daß in FreeX zukünftig nichts mehr bezüglich FreeBSD erscheinen wird. Wenn diese Entscheidung unumstößlich ist, würde ich mich doch sehr freuen, wenn dies mit einem Artikel, der die Mißstände ankreidet, geschehen würde. Wenn der deutschsprachige Raum von den Angloamerikanern ignoriert wird, wird nichts weiter passieren und damit kann man getrost dieses OS hierzulande zu Grabe tragen. Aber bitte nicht lautlos, das würde die verzweifelten Bemühungen all derer, die sich bemühten, nur weiter diskreditieren.
Zum Vergrößern anklicken....
Ob es dann noch Artikel zu *BSD in der FreeX geben wird, weiß ich nicht. Von mir persönlich wird da jedenfalls nix mehr kommen. Ich werde auch keinen Artikel schreiben, der die Mißstände aufzeigt. So etwas habe ich vor ca. 2 Jahren hier im Forum gemacht und wurde dafür verbal verkloppt und als Depp und Lügner hingestellt. Den Leuten, die damals am lautesten aufgejault haben, wollte ich die komplette Korrespondenz mit den zuständigen Leuten per Email zukommen lassen. Es hat die Jauler nicht interessiert. Und deshalb werde ich meine eh sehr knapp bemessene Freizeit nicht dafür verschwenden. Mögen sie in ihrem Elfenbeinturm fernab der realen Welt weiterhin der Desktopstrategie nachlaufen.
 
Nana, da hört sich ja mittlerweile wie ein Abgesang an. So schlimm es ist nun auch wieder nicht.
Jedes OS hat seine Probleme, wenn ich mir die SLES bei uns ansehe auf dem Blade, dann rennt da FBSD (auch wenn ich nur die 6.1 installieren kann) besser drauf. Inklusive gmirror. Da macht die SLES mehr Probleme. Und dann war da Debian, neuste Version. Wenn ich mich recht entsinne bootet das Teil nen 2.4 Kernel installiert dann aber einen 2.6 und bei dem wiederum fehlen diverse Module für den Betrieb auf dem Blade. Heureka. Bekomme das nicht mehr alles zusammen, soll aber heissen, auch hier "stinkt" es an manchen Ecken.

Warum sollte in der FreeX nichts mehr zum Thema FBSD kommen?
 
Sarge konnte man mit 2.4 oder 2.6 starten, Etch unterstützt nur 2.6 beim Start.


stimmt irgendwo, nicht umsonst ist Ubuntu entstanden
 
Ich habe diesen Thread genau gelesen, und verfolge die Entwickelung bestimmter Komponenten mit, und sehe die Situation nicht so drastisch. Wie ich das sehe, fehlt dem Projekt ein Leader, der sagt wo es lang geht. Wenn 10 Leute jeweils allein an einem Privatprojekt arbeiten um ihre Vision von Programmierkunst zu verwirklichen kann FreeBSD auf längere Sicht kein intergeres Projekt bleiben.

Die Strategieen, namentlich "Desktop-Strategie" und "Server-Strategie", haben beide ihre Vorteile, aber da FreeBSDs Zuhause im Dämonensektor liegt könnten die desktopischen Bestrebungen zu Gunsten der Intigrität und Qualität eingeschränkt werden. Ich selbst habe von den Entwickelungen profitiert, aber sehe den Wert dessen nidriger.

Abgesehen davon sollte das Projekt sich durch Stabilität, Durchdachtheit und Ausreifung auszeichnen statt sich unter hohem Aufwand und Verlusten an die leuchtende Kante zu befördern.

Ich gebe FreeBSD noch ein oder zwei Chancen.

PS: Mein Athlon X2 auf nem Asus mit Nvidia570SLI rennt wunderbar bei IO-Last.
 
asg schrieb:
Jedes OS hat seine Probleme, wenn ich mir die SLES bei uns ansehe auf dem Blade, dann rennt da FBSD (auch wenn ich nur die 6.1 installieren kann) besser drauf. Inklusive gmirror. Da macht die SLES mehr Probleme. Und dann war da Debian, neuste Version. Wenn ich mich recht entsinne bootet das Teil nen 2.4 Kernel installiert dann aber einen 2.6 und bei dem wiederum fehlen diverse Module für den Betrieb auf dem Blade.
Zum Vergrößern anklicken....
Es ist weder ein Pluspunkt für FreeBSD, dass irgendwo da draußen Systeme existieren, die noch schlechter laufen als FreeBSD, noch ist es hilfreich, irgendwelche Einzelfälle aus jahrelang vergangenen Zeiten von Debian auszugraben. Im Gegensatz zu FreeBSD bekommen die Jungs bei Linux den Großteil solcher Probleme zeitnah in den Griff.

Und Abgesang? Ja, möglich, und ja, ich finde es auch so schlimm. Und wenn eine ganze "Forengeneration" die gleichen Probleme erlebt und viele alte Hasen mittlerweile FreeBSD entnervt den Rücken zugewandt haben, dann kommt sowas nicht von ungefähr.
 
> Im Gegensatz zu FreeBSD bekommen die Jungs bei Linux den Großteil solcher Probleme zeitnah in den Griff.

Naja... Grade bei Debian hat es in der Vergangenheit immer wieder Probleme wegen Personalmangels gegeben.

Nichts ist perfekt - aber wenn ich mir die Beiträge hier im Forum anschaue, frage ich mich, warum diese Zeit nicht besser in die Behebung einiger der angesprochenen Probleme fliesst.

Nur um meine 2 Eurocent dazuzugeben...

Der Indy
 
Steht ja da, weil Patches die man weitergibt oft trotzdem nicht einfließen.

Ich habe da beide Erfahrungen gemacht. Wenn gerade jemand an etwas arbeitet und sich deshalb für Code verantwortlich fühlt, werden sowohl Feedback als auch Patches gern' genommen. Wenn der Code aber schon eine Weile liegt will sich niemand darum kümmern, wahrscheinlich weil man sich damit die Verantwortung auflädt und man ja eigentlich gerade an etwas anderem arbeitet.
 
bei Debian hatte das Personal keine Zeit um sich um Debian zu kümmern und hat eben lieber auch Kindergarten gemacht....Probs mit dem Nvidia-Kram ist vielleicht auch für AMD selbst ein Probs..keine ordentliche Chipsätze im Gegensatz zu Intel, stromsparende CPU's und keine Boards und irgendwo hat AMD das einfach verpennt und ist auf Fremdhersteller und seine Probs angewiesen. AMD muß wohl sowieso weil ja Via aussteigt und nur Nvidia wird auch nicht gutgehen. Ich versteh nicht warum man damals die AMD-Chipsätze eingestellt hat, Intel verdient damit das meiste Geld.
 
Moin indy,

Nichts ist perfekt - aber wenn ich mir die Beiträge hier im Forum anschaue, frage ich mich, warum diese Zeit nicht besser in die Behebung einiger der angesprochenen Probleme fliesst.
Zum Vergrößern anklicken....
wenn Du die Threads wirklich gelesen hättest und nicht angesehen, hättest Du wahrscheinlich auch bemerkt, dass es sehr Patches gab und sich die Poster sehr wohl um die Lösungen bemüht hatten.
Wenn aber die Zuständigen nichts lieber machen als ignorieren, darf man sich nicht wundern, dass immer mehr entnervt aufgeben.

So viel dazu.
 
Moin asg,

bei Dir sind es vielleicht ein oder zwei Rechner bei Dir.
Wenn Du aber mehrere Rechner - noch dazu von Kunden!!!! - hast, die unter den neuen Versionen von FreeBSD nicht mehr funktionieren, dann sieht die Sache leider anders aus. Der Kunde legt nun einal Wert auf funktionierende Systeme!

Viele Grüße

JueDan
 
Steve` schrieb:
Es ist weder ein Pluspunkt für FreeBSD, dass irgendwo da draußen Systeme existieren, die noch schlechter laufen als FreeBSD, noch ist es hilfreich, irgendwelche Einzelfälle aus jahrelang vergangenen Zeiten von Debian auszugraben. Im Gegensatz zu FreeBSD bekommen die Jungs bei Linux den Großteil solcher Probleme zeitnah in den Griff.
Zum Vergrößern anklicken....

Sicher ist es nicht hilfreich, aber auch anderswo wird nur mit Wasser gekocht. Das war meine Aussage.
Und das mit Debian war und ist aktuell.

Und Abgesang? Ja, möglich, und ja, ich finde es auch so schlimm. Und wenn eine ganze "Forengeneration" die gleichen Probleme erlebt und viele alte Hasen mittlerweile FreeBSD entnervt den Rücken zugewandt haben, dann kommt sowas nicht von ungefähr.
Zum Vergrößern anklicken....

Dann muss ich mal pro FBSD sprechen: Hier rennt es auf meiner Workstation mit KDE irgendwas und es ist mehr als ausreichend für das bisschen Desktopgedöns.
Auf diversen Server rennt es auch ohne Probleme.
 
juedan schrieb:
Moin asg,

bei Dir sind es vielleicht ein oder zwei Rechner bei Dir.
Wenn Du aber mehrere Rechner - noch dazu von Kunden!!!! - hast, die unter den neuen Versionen von FreeBSD nicht mehr funktionieren, dann sieht die Sache leider anders aus. Der Kunde legt nun einal Wert auf funktionierende Systeme!
Zum Vergrößern anklicken....

Mitnichten ein oder zwei Rechner.
Überschlagen sind es mehr als 10 Server die im produktiven Umfeld laufen.
Ich weiss um Deine Probleme mit SCSI ;-). Ich weiss auch aus eigener Erfahrung das ich hier noch keiner dieser Probleme hatte und es rund läuft. IBM x345, Desktophobel, und auch IBM HS20 Blade. FreeBSD rennt. Mehr will ich nicht und es rennt so gut, das ich mich nicht gross drum kümmern muss. Bis auf "Probleme" die man mit jedem OS haben könnte.

Ich sage nicht, dass FBSD alles rund läuft, ich halte aber auch nichts von einem Abgesang. Ich kann nur sagen das es hier rennt, und, das ich dabei auf dem Blade, mit 6.1, weniger Probleme hatte (nachdem ich den Kniff raus hatte ;-)), als mit SLES9 oder Debian.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben