Von Verfluchtnochmal am Mo, 6. November 2017 um 17:14 #
Und weiter?
Fällt im Zweifel unter:
Die meisten Fehler im Kernel sind potentiell sicherheitsrelevant. Manchmal wird dies gleich erkannt, oft aber auch erst viel später. Genauso fahrlässig handelt, wer die Patches aus den einzelnen Aktualisierungen handverliest und somit seinen eigenen Fork des LTS-Kernels erstellt
Von Verfluchtnochmal am Mo, 6. November 2017 um 17:45 #
Kann sein, kann auch nicht sein - Bis JETZT war es allerdings eher fahrlässig einen fork zu pflegen wenn es upstream offiziell bugfix releases gibt
Ändert aber generell nichts daran dass du ein Laberkopf bist der von einer kleinen Welt spricht dabei aber aus einer noch viel kleineren weil distributions spezifisch in die grosse raus ruft
Da ist nichts aber auch gar nichts fahrlässig - PUNKT
Willst du im erst Redhat ein Stück weit Fahrlässigkeit unterstellen, ich lach mich schlapp. Du kennst aber schon die Gründe warum man bei Redhat bei der gleichen Kernelversion bleibt?
Von Verfluchtnochmal am Mo, 6. November 2017 um 20:27 #
Erstens benutze ich Redhat vermutlich seit Tagen wo du noch mit einer Kinderrassel um den Christbaum gelaufen bist, zweitens beschäftige ich mich lange genug im Detail und deswegen kann ich mir drittens mit gutem Gewissen erlauben nicht alles wie ein Lemming gut finden zu müssen
Gerade weil ich die Gründe kenne (und du nicht) und weiss wie die upstream TLS Pflege läuft ist es BRUNZDUMM die Upstream point releases nicht zu benutzen solange selbige verfügbar sind und du kannst dein Leben verwetten dass eigene Patches von redhat ohne Anpassungen auf jedes point release anwendbar sind
Einer der Hauptgründe warum RHEL einen riesigen monolitischen undokumentierten Patch hat ist Oracle Linux, die können damit wesentlich schwerer Anpassungen vornehmen und wie CentOS den Kernel nur 1:1 aus dem src.rpm bauen während im Falle von einzelnen Patches kein Problem wäre eigene Anpassungen hinzuzufügen und auch langfristig zu pflegen - Gegen einen Kernel mit einem grossen Patch der sowohl Upstream fixes als auch customization zusammen rührt macht das keinen Spass
Und jetzt geh wieder spielen du blöder Bub der Richtung upstream was von eigener kleiner Welt blubbert und dabei in seiner weit kleineren festsitzt und es noch nicht einmal merkt
Ich bin schon verdammt lange dabei, da gab es noch kein Redhat.
Schon erstaunlich das du scheinbar Kenntnis davon hast was ich fachlich kann oder halt nicht.
Dann deine Tonlage. Die ist so abartig das du scheinbar ein sogenannter Eimerscheißer bist. Das sind die im Keller ständig am Rechner sitzen, sich 4 Tage alte Pizza reindrücken und ihr Geschäft naja in den Eimer machen. Soziale Kompetenz geht da Richtung Null. Sorry du, ich kann mit Kritik ganz gut, oft genug sind auch verschiedene Ansichten richtig oder falsch, damit habe ich absolut kein Problem. Man kann mit mir auch problemlos Irrtümer besprechen alles kein Ding. Aber das was du hier verbal ablieferst geht mal gar nicht! Entspann mal.
Zum Fachlichen:
Dieser undokumentierten Patch ist mir bekannt. Aber gab es den nicht schon vor Oracle Linux? Dieser wurde auch oft scharf kritisiert und wie du es auch richtig ansprichst sind dann Anpassungen schwer. Da bin ich ja absolut deiner Meinung. Mir ging es doch darum, nur weil Willy die Pflege nicht weiterführt, das da draußen fähige Leute gibt die auch Wissen was sie tun und man einfach nicht so von Fahrlässigkeit sprechen kann.
Von Verfluchtnochmal am Mo, 6. November 2017 um 21:46 #
Dein Einstiegspost war halt "Huch was faselt der von 3.10.108 während ich ein Stecher mit .693 bin" und ja es ist im Zweifel immer fahrlässig sich schlauer als die Upstream Entwickler vorzukommen und cherry picking zu machen oder gar auf eigene Faust code den man nicht geschrieben hat auf anderen code den man auch nicht geschrieben hat anzupassen
Kann gut gehen aber auch verdammt schnell ins Auge wenn beim cherry picking ein für nicht relevant befundener Patch weggelassen wurde der irgendeine Kleinigkeit prüft und deswegen eines der übernommen codefragmente nicht davon ausgeht sich darum kümmern zu müssen - Das geht ganz schnell trotz aller Sorgfalt und schon hast du mit deinem cherry picking ggf. nicht nur eine Sicherheitslücke nicht vollständig gestopft sondern eine noch grössere zusätzlich aufgerissen
Und weiter?
Fällt im Zweifel unter:
Die meisten Fehler im Kernel sind potentiell sicherheitsrelevant. Manchmal wird dies gleich erkannt, oft aber auch erst viel später. Genauso fahrlässig handelt, wer die Patches aus den einzelnen Aktualisierungen handverliest und somit seinen eigenen Fork des LTS-Kernels erstellt
Also ich glaube schon das Redhat das alles im Griff hat und nicht fahrlässig handelt. Da bin ich mir aber sowas von sicher!
Kann sein, kann auch nicht sein - Bis JETZT war es allerdings eher fahrlässig einen fork zu pflegen wenn es upstream offiziell bugfix releases gibt
Ändert aber generell nichts daran dass du ein Laberkopf bist der von einer kleinen Welt spricht dabei aber aus einer noch viel kleineren weil distributions spezifisch in die grosse raus ruft
Da ist nichts aber auch gar nichts fahrlässig - PUNKT
Willst du im erst Redhat ein Stück weit Fahrlässigkeit unterstellen, ich lach mich schlapp. Du kennst aber schon die Gründe warum man bei Redhat bei der gleichen Kernelversion bleibt?
Erstens benutze ich Redhat vermutlich seit Tagen wo du noch mit einer Kinderrassel um den Christbaum gelaufen bist, zweitens beschäftige ich mich lange genug im Detail und deswegen kann ich mir drittens mit gutem Gewissen erlauben nicht alles wie ein Lemming gut finden zu müssen
Gerade weil ich die Gründe kenne (und du nicht) und weiss wie die upstream TLS Pflege läuft ist es BRUNZDUMM die Upstream point releases nicht zu benutzen solange selbige verfügbar sind und du kannst dein Leben verwetten dass eigene Patches von redhat ohne Anpassungen auf jedes point release anwendbar sind
Einer der Hauptgründe warum RHEL einen riesigen monolitischen undokumentierten Patch hat ist Oracle Linux, die können damit wesentlich schwerer Anpassungen vornehmen und wie CentOS den Kernel nur 1:1 aus dem src.rpm bauen während im Falle von einzelnen Patches kein Problem wäre eigene Anpassungen hinzuzufügen und auch langfristig zu pflegen - Gegen einen Kernel mit einem grossen Patch der sowohl Upstream fixes als auch customization zusammen rührt macht das keinen Spass
Und jetzt geh wieder spielen du blöder Bub der Richtung upstream was von eigener kleiner Welt blubbert und dabei in seiner weit kleineren festsitzt und es noch nicht einmal merkt
Ich bin schon verdammt lange dabei, da gab es noch kein Redhat.
Schon erstaunlich das du scheinbar Kenntnis davon hast was ich fachlich kann oder halt nicht.
Dann deine Tonlage. Die ist so abartig das du scheinbar ein sogenannter Eimerscheißer bist. Das sind die im Keller ständig am Rechner sitzen, sich 4 Tage alte Pizza reindrücken und ihr Geschäft naja in den Eimer machen. Soziale Kompetenz geht da Richtung Null. Sorry du, ich kann mit Kritik ganz gut, oft genug sind auch verschiedene Ansichten richtig oder falsch, damit habe ich absolut kein Problem. Man kann mit mir auch problemlos Irrtümer besprechen alles kein Ding. Aber das was du hier verbal ablieferst geht mal gar nicht! Entspann mal.
Zum Fachlichen:
Dieser undokumentierten Patch ist mir bekannt. Aber gab es den nicht schon vor Oracle Linux? Dieser wurde auch oft scharf kritisiert und wie du es auch richtig ansprichst sind dann Anpassungen schwer. Da bin ich ja absolut deiner Meinung. Mir ging es doch darum, nur weil Willy die Pflege nicht weiterführt, das da draußen fähige Leute gibt die auch Wissen was sie tun und man einfach nicht so von Fahrlässigkeit sprechen kann.
Dein Einstiegspost war halt "Huch was faselt der von 3.10.108 während ich ein Stecher mit .693 bin" und ja es ist im Zweifel immer fahrlässig sich schlauer als die Upstream Entwickler vorzukommen und cherry picking zu machen oder gar auf eigene Faust code den man nicht geschrieben hat auf anderen code den man auch nicht geschrieben hat anzupassen
Kann gut gehen aber auch verdammt schnell ins Auge wenn beim cherry picking ein für nicht relevant befundener Patch weggelassen wurde der irgendeine Kleinigkeit prüft und deswegen eines der übernommen codefragmente nicht davon ausgeht sich darum kümmern zu müssen - Das geht ganz schnell trotz aller Sorgfalt und schon hast du mit deinem cherry picking ggf. nicht nur eine Sicherheitslücke nicht vollständig gestopft sondern eine noch grössere zusätzlich aufgerissen