FreeBSD & Performance - Ein Vergleich

Status
Für weitere Antworten geschlossen.
Endorphine, Du hast offenbar das Ausmaß des Problems noch nicht bis in die Spitzen begriffen. Es geht nicht darum, sich ein neues OS zu suchen, weil es auch bei FreeBSD an der einen oder anderen Stelle klemmt. Ich für meinen Teil habe mir ein anderes OS gesucht, weil FreeBSD unbenutzbar(!) auf meiner Hardware ist. Früher war das auf der gleichen Hardware mal anders, aber zuletzt habe ich während eines Portupgrades mit dem System nicht arbeiten können, weil das System regelmäßig für mehrere Sekunden/Minuten einfriert. Kommt ein neues KDE-Release raus, muss ich 30 Stunden auf die Arbeit am Computer verzichten? Bei allem Respekt und aller Liebe für FreeBSD ... das kann es nicht sein.

Ich habe jahrelang an FreeBSD festgehalten, auch wenn bei Linux vieles besser funktionierte, weil ich FreeBSD, die Community, die Kultur, und vieles mehr mochte. Und ich brauche meine Kiste nicht produktiv, es handelt sich nicht um einen Bürorechner oder gar Server. Wenn Usern im Geschäftsumfeld ein Rechner derart wegbricht, dann ist das inakzeptabel.

Davon abgesehen sind Argumente wie "Linux will ich nicht" und "die Community ist doof" irgendwie keine.
 
@Steve`:

Es ist wohl eher so, daß Leute, die FreeBSD erst seit Version 5 oder gar 6 kennen, bei dem Thema gar nicht mitreden können. :huth:
 
Das ist in der Tat ein Aspekt, den ich nicht berücksichtigt hatte. Voraussetzung für die Beurteilung der Qualitätsentwicklung ist sicher der Einstieg zu Zeiten von FreeBSD 4.x.
 
Könnten die Leute mit den Performance-Problemen mir ein vmstat -i von vor und während eines kleinen portupgrade liefern?
 
Also wenn ich so an FreeBSD 4.4 - genannt "mein Crashliesl" - zurückdenke, gab es damals auch eine Reihe übler Macken. Korrekter wäre daher zu sagen, dass man die späteren Releases der 3.x Serie und der 4.x Serie kennen sollte. Ich würde mal über den Daumen sagen, ab 3.3 und 4.5.

SCNR ;)
 
Ich bin ja erst mit 5.3 eingestiegen, aber mir persönlich fällt der Unterschied zwischen Ports-PRs und anderen PRs auf. Da liegen Welten dazwischen.
 
Yamagi schrieb:
Also wenn ich so an FreeBSD 4.4 - genannt "mein Crashliesl" - zurückdenke, gab es damals auch eine Reihe übler Macken. Korrekter wäre daher zu sagen, dass man die späteren Releases der 3.x Serie und der 4.x Serie kennen sollte. Ich würde mal über den Daumen sagen, ab 3.3 und 4.5.
Zum Vergrößern anklicken....

Ich hatte mit der 3.1 bis 3.x damals keinerlei nennenswerte Probleme und ab 4.x jede Menge, weshalb ich es erst mal in die Ecke stellte. 3.x hat bei mir damals aber auch keinen bleibenden Eindruck was die Hardwareunterstützung anging hinterlassen ... so abgekackt, wie das hier berichtet wird und wie es mir mit der 6.x jetzt ging, ist es mir allerdings nie. Allerdings mußte es auch "nur" als Server laufen und nicht als Desktop herhalten.

Jetzt halt ich wieder die Klappe und hoffe, daß ihr eure Probleme beseitigt bekommt, damit Steve wieder versöhnlicher wird und ich endlich auf 7 umsteigen kann. :p
 
Naja, FreeBSD 3 litt ein wenig unter dem neuen SMP-Support, der damit ja eingefügt wurde. Der hatte schon einige Macken, die nervten. Da sah man allerdings nur auf SMP-Hardware, die damals ja kaum jemand hatte und was das testen entsprechend erschwerte. Aber du hast recht, FreeBSD 4.x war zu beginn eine Katatrophe.

FreeBSD 6 ist bis jetzt imo der Tiefpunkt. Auch 6.2 hat noch einige Macken, die hoch gefährlich sind. Allein der Deadlock der auftreten kann, wenn man 5 Switches weiter das Kabel am Router rauszieht. Oder wenn man einen Switchkreis baut, also ein Kabel zweimal in den Switch steckt. FreeBSD 7 - ich installiere hier nebenbei gerade mein erstes produktives auf dem Laptop - wirkt da schon im RC1 viel ausgereifter. Es ist subjektiv deutlich schneller, spricht besser an als 4.x es je tat und scheint einige der von mir so gehassten Macken auch nicht mehr zu haben. Warten wir mal ab, was dabei rauskommt.

So, nun aber zurück zum Thema ;)
 
Steve` schrieb:
Endorphine, Du hast offenbar das Ausmaß des Problems noch nicht bis in die Spitzen begriffen. Es geht nicht darum, sich ein neues OS zu suchen, weil es auch bei FreeBSD an der einen oder anderen Stelle klemmt. Ich für meinen Teil habe mir ein anderes OS gesucht, weil FreeBSD unbenutzbar(!) auf meiner Hardware ist.
Zum Vergrößern anklicken....
Ja, das verstehe ich schon. Da muss man dann halt Prioritäten setzen, was einem wichtig ist. Wenn FreeBSD 6.x/5.x noch gut läuft kannst du ja zumindest 6.x noch eine ganze Weile auf bestehender Hardware supported einsetzen. Nebenbei kann man dann als User in der Community mithelfen, dass die Hardware-Probleme behoben werden. Die Mailinglisten stehen ja jedem offen. Und man kann dabei auch mal wieder Englisch schreiben/produzieren und nicht nur lesen/konsumieren. ;)

Und dann ist Hardware ja meiner Meinung nach nichts statisches. Man ändert doch irgendwie fortwährend etwas daran, oder sind hier noch Leute mit einem 486er im Forum unterwegs?

Das sind eben die Nachteile, die man bei einem Nischensystem wie *BSD in Kauf nehmen muss. Und ich behaupte weiterhin, dass sich nicht wirklich etwas geändert hat. OK, ich kenne FreeBSD erst seit 4.x, aber ich kann nicht wirklich einen großen Unterschied erkennen.

Wer keine Lust hat, am Betriebssystem zu arbeiten sollte vielleicht eher SuSE Linux Enterprise Desktop (gibt's das noch) verwenden und Geld dafür abdrücken. Wer Spaß an Unix-artigen OS hat, hat den meiner Meinung nach mit FreeBSD immer noch und genau so wie zu 4.x-Zeiten.

Nebenbei gesagt habe ich mit 6.x eigentlich gar keine schwerwiegenden Probleme, auf momentan 7 Rechnern. Es ist genau so wie früher auch: auf schlechter Hardware läuft FreeBSD weniger gut als Linux, auf brauchbarer Hardware aber sehr gut. Für all' die nForce-, VIA- und Realtek-Käufer sind andere OS vielleicht eher geeignet. </rant>

Steve` schrieb:
Davon abgesehen sind Argumente wie "Linux will ich nicht" und "die Community ist doof" irgendwie keine.
Zum Vergrößern anklicken....
Für die Arbeit kann ich mit Linux leben. Da gehe ich eben Kompromisse ein, im Sinne des Ganzen. Zu Hause privat gehe ich diese Kompromisse nicht ein. Warum sollte ich mich da zu etwas zwingen, wo ich nicht mit zufrieden bin?

Die Debian-Community geht mir eben mit ihrer Missioniererei und ihrem weltfremden Idealismus auf die Nerven. Ich könnte mich dort nicht bewegen, ohne laufend graue Haare zu bekommen. Das tue ich mir privat nicht an.

Und der ganze restliche Haufen von Linux-Distros ist für mich auch nur ein Kompromiss, wenn ich stattdessen auch ein Free- oder Open-BSD haben kann.
 
@Endorphine: Das Thema dieses Threads ist FreeBSD und seine (Performance-)Probleme!

Nicht "OS-Wechsler sind doof, Hardware ist doof, Linux ist doof, Debian ist doof" oder sonstwas.
 
jtsn schrieb:
@Endorphine: Das Thema dieses Threads ist FreeBSD und seine (Performance-)Probleme!

Nicht "OS-Wechsler sind doof, Hardware ist doof, Linux ist doof, Debian ist doof" oder sonstwas.
Zum Vergrößern anklicken....
Es ist aus meiner Sicht mehr ein "FreeBSD ist doof, ich habe gewechselt und bin jetzt glücklich" und "früher war alles besser" Thread. Und da schreibe ich eben was zu.

Off-Topic ist der Thread schon lange, auch ohne meine Postings...
 
Endorphine schrieb:
Nebenbei kann man dann als User in der Community mithelfen, dass die Hardware-Probleme behoben werden. Die Mailinglisten stehen ja jedem offen. Und man kann dabei auch mal wieder Englisch schreiben/produzieren und nicht nur lesen/konsumieren. ;)
Zum Vergrößern anklicken....
Ich würde ja gerne helfen. Ich kann nur leider schlecht bei der Fehlerbehebung helfen, wenn mein ganzes System quasi unbenutzbar ist. Für jede Informationsbeschaffung umbooten ist einfach lästig. Auf meiner alten Kiste war es nunmal so, dass diese laufend einfror und ein Arbeiten damit nicht möglich war. Da kann ich kaum Hilfe liefern. Auf meiner jetzigen Kiste ist es so, dass sie eigentlich recht performant läuft, aber meine TV-Karte ruckelt wie wild. Damit kann ich zur Not aber leben, weil man mit dem System dann trotzdem arbeiten kann.

Ich habe für FreeBSD in der Vergangenheit schon auf vieles verzichtet, was mir persönlich wichtig war (bestimmte Anwendungen, Flash, etc.) und habe mich auch mit Geldspenden am Projekt beteiligt. Ich bin immer noch interessiert und immer noch 'addicted'.

ABER: Ich bin kein Programmierer und kein BSD-Admin ... ich bin nur interessierter Anwender und wenn ich mich mit einem Problem auf einer Mailingliste melde, dann würde ich es bevorzugen, nicht ignoriert zu werden. Wenn meiner Anfrage bzw. meinem Bugreport Informationen fehlen, dann hätte ich gerne einen Mentor, der sich mir annimmt und mir in kurzen Schritten erklärt, wie ich weitere benötigte Informationen beibringen kann. So habe ich z.B. meine Performanceprobleme zunächst für CPU-Last-bedingt gehalten, bis Kamikaze mir erklärte, dass es möglicherweise an den HDD-Zugriffen liegt. Ich wäre selbst gar nicht drauf gekommen, dass bei einem portupgrade die HDD-Zugriffe ins Gewicht fallen, nicht die CPU-Last. Manchmal kann ich halt nicht so abstrakt denken, wie die Entwickler, und wenn sie möchten, dass ich mich konstruktiv beteilige, dann müssen sie mich manchmal möglicherweise in die richtige Richtung lenken.

'Ich' und 'mich' steht hier vermutlich für eine ganze Menge anderer User.
 
Edit: Bitte versteht diesen Beitrag als auf Yamagi's folgend.

Genau, Kris will die Ausgaben von vmstat -i und top -S von Systemen mit Performanceproblemen haben.
 
Es wäre mir lieb, wenn jemand diese Daten liefern könnte, bei dem sich das System richtig hinlegt. Auf meiner neuen Kiste ist das Problem nicht mehr ganz so heftig.
 
@Steve und BSD-Admin:
Hm, vielleicht gibt es das ja schon, noch mal in einer FreeBSD-Server-Only-Admin-Gruppe (für DE halt), die sich wirklich täglich in der Produktion austobt, GESCHLOSSEN AUFZUTRETEN und Eingaben bei Core vorzunehmen mit dem was gut ist, was weniger gut ist und auf jeden Fall besser werden sollte.

Vielleicht macht es ja Sinn so zu zeigen, dass nach wie vor starkes Interesse nach einem soliden Produkt im Serverbereich vorhanden ist (FreeBSD als Client ist für mich zweitrangig ) und Core ganz klar vermittelt bekommt, wirklich konstant saubere und verantwortungsvolle Arbeit im Kerngeschäft abzuliefern.

Herjeh, ich denke die Situation ist allen Seiten klar und bis jetzt ist das nur Blabla (bei mir) ohne Aktionismus dahinter. Aber vielleicht kann man sowas zum Instrument machen um zu zeigen "Hey, ihr habt das angefangen, ihr macht das freiwillig, aber wir brauchen euch weiter und ihr habt die Verantwortung dafür übernommen".

Imho ist das Malheur halt damit besiegelt, dass einfach Geld fehlt. Hätte man ein größeres, gesichertes Budget, dann könnte man sich (mehr) fulltime Entwickler leisten, aktuelle, qualitativ gute Hardware für die Entwicklung / Test anschaffen und generell auch Druck auf die Industrie ausüben mit den HW-Spezifikationen rauszurücken.

Grummel, ich glaube an BSD, ich mach weiter damit in guten als auch schlechten Tagen. Amen.
new_puppy_dog_eyes.gif
 
Hallo,

spaulding schrieb:
@Steve und BSD-Admin:
Hm, vielleicht gibt es das ja schon, noch mal in einer FreeBSD-Server-Only-Admin-Gruppe (für DE halt), die sich wirklich täglich in der Produktion austobt, GESCHLOSSEN AUFZUTRETEN und Eingaben bei Core vorzunehmen mit dem was gut ist, was weniger gut ist und auf jeden Fall besser werden sollte.

Vielleicht macht es ja Sinn so zu zeigen, dass nach wie vor starkes Interesse nach einem soliden Produkt im Serverbereich vorhanden ist (FreeBSD als Client ist für mich zweitrangig ) und Core ganz klar vermittelt bekommt, wirklich konstant saubere und verantwortungsvolle Arbeit im Kerngeschäft abzuliefern.
Zum Vergrößern anklicken....

persönlich habe ich da wenig Hoffnung. Kamikaze hat ja dankenswerter Weise ein ähnliches Statement in die Mailingliste gestellt. Es hat vielleicht drei oder vier WIRKLICH interessiert, der Rest hat sich in der üblichen Lizenzdiskussion ergötzt.

Es fehlen Leute im Core-Team, die daran interessiert sind, FreeBSD wieder zu einem erstklassigen Betriebssystem machen.

Viele Grüße

JueDan
 
Hi,

jtsn schrieb:
Wie Projektmanagement funktionieren kann, zeigen OpenBSD und Linux. Bei Linux ist die Bedingung dafür, Code in den Tree zu bekommen, diesen zu warten. Verliert der Maintainer die Lust daran, fliegt der Kram eiskalt wieder raus. Prominentes Beispiel dafür ist devfs, das die 2.4-Ära nicht überlebt hat.
Zum Vergrößern anklicken....

Das kann man nicht mit der Situation vergleichen, vor der FreeBSD momentan steht. Beides ist auch keine Sache von Projektmanagement - daqrunter versteh ich wirklich etwas Anderes. Gutes Projektmanagement gibt es da zum Beispiel bei RH, die gute Kernelhacker haben und gegen Geld den Kernel anpassen und nach Fehlern suchen.
 
Man müßte die bestehenden PRs erstmal entsprechend trennen, bzw. gruppieren. In solche, denen bereits ein Patch anhängt, in Bugfixes und Features, in wichtig und unwichtig, etc.

Einen SCSI-Controller, der schonmal funktioniert, wieder zum laufen zu bringen hat z.B. Vorrang vor dem PR, der um die Unterstützung von Multimediakeys bei USB-Tastaturen bittet. Der erste fixt ein existentes Problem, der zweite wäre ein Featurerequest.
 
Steve` schrieb:
Einen SCSI-Controller, der schonmal funktioniert, wieder zum laufen zu bringen hat z.B. Vorrang
Zum Vergrößern anklicken....
Die Konsequenz ist ganz einfach: Raus mit dem ungewarteten Code aus dem Tree, raus mit dem SCSI-Controller aus der HCL. Fertig. Dann weiß man, woran man ist. Aber Sachen in der HCL führen, wo sich keiner drum kümmert, die beim nächstbesten Problem überhaupt nicht mehr funktionieren, das geht so nicht.
 
Ich hab mal eine Frage:

Was spricht eigentlich gegen einen Freeze nach 7.x um erst mal wieder einen stabilen Unterbau ohne Fehler zu produzieren?

Die Zeit kann dann auch gleich genutzt werden um ein Entwicklungsmodell zu diskutieren, das das "sammeln" von PRs verhindert.

Am Ende würde sich ein stabiler "fehlerfreier" Unterbau auch positiv auf die weitere Entwicklung auswirken.
 
Cessel schrieb:
Was spricht eigentlich gegen einen Freeze nach 7.x um erst mal wieder einen stabilen Unterbau ohne Fehler zu produzieren?
Zum Vergrößern anklicken....
Die Idee halte ich für hervorragend, den Vorschlag habe ich auch bereits des öfteren durchdacht.

Andererseits lasse ich das Argumente gelten, ein freiwilliger Entwickler entwickelt nur das, wofür er Lust hat. Er fängt nicht an, für ihn uninteressante Bugs zu fixen, nur weil einer den Sourcetree einfriert.

Meines Erachtens ist und bleibt das eine Frage der Motivation. Es wird nichts bringen, die Entwickler zu einem Bugfixrelease zu 'zwingend', man müßte sie vielmehr motivieren. Ich kenne nun die Entwickler nicht alle persönlich, Geld wäre sicherlich nur eine Möglichkeit. Die Entwickler müßten an der FreeBSD-Base schrauben, die Anwender müßten sich mehr im Portstree engagieren. Die Motivation ist in beiden Fällen zu gering, Dank kommt von allen Seiten zu wenig.

Ich hatte vor einigen Jahren ja mal die Idee, eine Community zum Förderzweck zu gründen (BSDTeams, für die, die sich noch erinnern). Der Grundgedanke war, Klein(st)beträge zu sammeln (z.B. durch Spenden) und den Entwicklern so finanzielle Anreize zu bieten. Außerdem wäre es möglich gewesen, Anwendern eine Basiscommunity zu geben, mit der sie sich identifizieren können.

Die Jungs von BSDGroup.de haben das ansatzweise organisieren können, indem sie das Porters-Handbook übersetzt und IRC-Schnelllernkurse für neue Port-Maintainer angeboten haben. Leider hat das nur bedingt Anklang gefunden, weil alte Streitigkeiten in die Situation übernommen wurden (ich selber bin leider nicht frei davon). Meines Erachtens sollte man zumindestens der hilfsbereiten Community mehr das Gefühl geben, Teil des Teams zu sein und nicht billiger Hilfszuarbeiter.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben