Am Mit, 2002-10-23 um 19.14 schrieb Philipp Thomas:
Ralf Corsepius
[23 Okt 2002 10:07:53 +0200]: Mit anderen Worten: Der Verantwortliche.
Jein, immer im Zusammenspiel mit unseren Kernel-Spezialisten wie Andrea Archangeli, Andi Kleen, Chris Mason und Jens Axboe (um jetzt nur ein paar zu nennen). Wenn Leute wie Andrea sagen, dass ein Patch in Ordnung ist, wird jemand wie Hubert das akzeptieren.
Scheint so. Ich habe das IDE-Problem seit SuSE-8.0 und Hubert war seither nicht in der Lage einen bei mir funktionsfähigen Kernel zu liefern
Das Problem ist auch alles andere als trivial, gegeben die Menge an Patches, die wir zusätzlich einpflegen. Weniger wäre mehr?
"Release early and often" statt "release seldom and wanna-be-stable and pie-on-your-customers-if-not" ? Oder wie David schon schrieb: Kreis der Beta-Tester ausbauen?
Der LSB-Kernel läuft, die RedHat-Kernel-2.4.18-14 und 2.4.18-17.8.0 ebenfalls.
Dafür fehlt dem RedHat Kernel die Unterstützung für ACPI 2.0 (zwingend nötig, damit einige aktuelle Rechner überhaupt booten), es gibt Bugs im aio Code, etc. Ich will aber gar nicht mit dem Finger auf Konkurrenten weisen sondern nur andeuten, dass alle Kernel irgendwo ihre Macken haben (vanilla eingeschlossen) und es dann nur eine Frage der Schnittmengen ist. Für dich funktioniert der vanilla Kernel, einige brandaktuelle Rechner booten nicht einmal vernünftig damit. Tja, such is life ;) Will sagen, alles andere zu erwarten wäre naiv, alles lamentieren (auf beiden Seiten) hilft nicht - Es muss was getan werden!
(Auch ich habe ein System auf dem SuSE-8.1 bislang stabil läuft. Die Installation darauf war zwar Opfer andere Probleme, aber das wäre ein weiterer Thread ... [4])
IMNSHO sollte Hubert nun die Konsequenzen ziehen ...
Alles in allem hat Hubert seine Aufgabe erstaunlich gut gemacht, gemessen an der schieren Menge an Patches. Nun, "Konsequenzen ziehen" heisst ja nicht, dass ich seinen Kopf fordere. Ich würde aber erwarten, dass er als Verantwortlicher dafür sorgt, dass etwas getan wird - Für mich sieht es so aus, als ob er dies bisher nicht getan hat.
Habe ich vor Monaten schon getan, doch anders als in der Vergangenheit (in der sich Hubert sehr kooperativ gezeigt hatte), ...
Du hast nicht den Stress erlebt, der hier Dank SL 8.1 und United Linux 1.0 herrschte. Da können die Nerven schon mal blank liegen, zumal wenn dann haufenweise Leute mit Bitte um Hilfe für Probleme mit dem Kernel aus mantel/next kommen, für die es ausdrücklich keinen Support gibt. Nun, den Stress kann ich nachvollziehen (Dass SuSE-8.0 und SuSE-8.1 jeweils unter Zeitdruck entstanden sind lässt sich auch kaum verheimlichen).
Doch mein Report an Hubert bezog sich auf meine Probleme mit dem SuSE-Standard-Kernel aus 8.0, von dem offensichtlich nicht nur ich allein betroffen war und der augenscheinlich in 8.1 nicht behoben wurde. D.h. aus meiner Sicht auf einen augenscheinlichen Produktmangel an SuSE-8.x auf den nicht angemessen reagiert wurde und wird. Die Mantel-Kernel habe ich nur deshalb verwendet, eben weil der "Standard-Kernel" bisher nicht funktioniert. Würde ein offizieller SuSE-Kernel funktionieren, oder hätte SuSE/Hubert einen gefixten Kernel herausgebracht, gäbe es diesen Thread vermutlich nicht, würde ich diese Mail nicht schreiben und mich jetzt nicht mit RH-8.0 auseinandersetzen.
Um es klar zu sagen: Der funktionsunfähige SuSE-Kernel ist ein Hauptgrund für mich es jetzt sehr ernsthaft in Erwägung zu ziehen jetzt die Distribution zu wechseln - Das mir dieser Entschluss nach ca. 8 Jahren SuSE nicht leicht fällt brauche ich ja wohl nicht zu betonen.
Verstehe ich voll und ganz, zumal auch ich seit SuSE 4.2.1 (zumindest AFAIR :) dabei bin. IIRC, bei mir SuSE-April94 (??).
Jens Axboe, der ja nun ein ausgewiesener IDE-Spezialist ist, hat gerade eine Maschine im direkten Zugriff, die genau diese Probleme mit zwei Platten am gleichen Strang aufweist. Ich hoffe, dass er das Problem einkreisen kann. ;)
(Es gibt noch weitere (für mich fatale) Bugs in SuSE-8.1, die für mich derart fatal sind, dass eine weitere Verwendung von SuSE-8.1 für mich kaum noch in Frage kommen dürfte, es sei denn SuSE würde sie in Kürze beheben.)
Als da wären? Nun, ich habe eine ganze Reihe (ca. 10-15) von Bugs gemailt - Reaktion bisher: NULL.
Der GLwM-Bug darunter ist neben dem Kernelbug für mich DER Showstopper[1], von eurem faktisch unbrauchbaren Gnome[2] und den vielen kleinen Nicklichkeiten allerorts[3] mal ganz zu schweigen.
Ich werde Dir die Mail, die ich schon im Mai an Hubert geschickt hatte per PM forwarden.
Ich werde das morgen mal sammeln und dann in Übersetzung ( die meisten unserer Kernelspezialisten sprechen kein deutsch) zur Verfügung stellen. Feel free to do so. I'd volunteer for testing ;)
Ralf [1] Fehlender Motif-Support in libGLw (GLwM), U.a. entwickle ich mit SW die auf GLwM basiert. [2] Ich war verblüfft, feststellen zu müssen, dass RH-8.0 einen nicht unerheblichen Vorsprung zu SuSE-8.1 in der Desktop-Integration aufweist. Ich hätte das Gegenteil erwartet. Unter der bunten Haube haben beide Distris jeweils andere Vor- und Nachteile, bzw. Probleme und Bugs. SuSE-8.1's Haupt-Vorsprung gegenüber RH-8.0 besteht in der deutlich einfacheren Installation/Konfiguration (Anfängern kann ich nur sehr bedingt zu RH raten - Für fortgeschrittene User sind die Unterschiede weniger gravierend, in der Summe mit leichtem Vorsprung für RH). Erschreckend finde ich die Anzahl der an vielen Stellen vorhandenen, teilweise vermutlich mutwilligen Inkompatibilitäten. [3] Die List wäre länglich :( Nur ein (recht übles) Beispiel: Mittels YaST2 von Lilo auf Grub umzustellen (Ja, ich kenne den sdb-Artikel, ja, ich hatte alle notwendigen yast2-Updates eingespielt und bin nach sdb-Anleitung vorgegangen,) Ergebnis: Eine defekte, unbrauchbare grub-Konfiguration und danach ein nicht bootbares System. Nun versuch das System von CD mittels rescue-System zu restaurieren und stell Dir vor das Rescue-System "dumps core", weil der Kernel defekt ist - Ich hoffe Du erkennst die Tragweite des Kernelbugs (Ist mir passiert - Glücklicherweise gibt's Bootdisketten.). [4] Reines SCSI-System. Nur bedingt von CD bootbar (Devicemapping im SCSI-BIOS erforderlich, YaST verschluckt sich daran). Automatische Installation hängt sich in USB-Detektion auf. Automatische Installation falschen SCSI-Treiber (NCR statt SYM - SCSI-Karte läuft nur mit SYM-Treiber). Abhilfe: Manelle Installation von Disketten mit explizitem Treiber laden und Abwählen von USB.