Ich nutze Kernel 3.10.0-693.5.2.el7.x86_64 und bin mir ganz sicher, dass ich noch viele Updates erhalten werde. Gepflegt wird der Kernel durch Redhat, da hat der Willy leider nur seine kleine Welt und die von kernel.org gesehen.
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
Falsch, in der kleinen (RedHat)Welt lebst DU! Was nutz einem Debian - Arch - sonstwas - User, das RedHat noch Updates für den 3.10er Kernel produziert, wenn sie nicht zum Distri-Kernel passen?
Falsch ich nutze durchaus primär die Technik von Redhat und dessen Ableger aber bin absolut gegenüber anderen Distributionen aufgeschlossen und nutze diese auch. Also meine Distriwelt ist alles nur nicht klein. Ich versteht mich auch nicht, Willy unterstellt anderen eine gewisse Fahrlässigkeit und das kritisiere ich am Beispiel von Redhat. Ich hätte auch Debian nehmen können, durch LTS Support 5 Jahre Unterstützung richtig? Unterstellt ihr hier auch den Machern bei der Pflege des Kernels Fahrlässigkeit? Ich denke wir sind uns einig das natürlich sauber gearbeitet werden muss, aber bitte es gibt da draußen viele Entwickler die das echt gut können. Also ein wenig Vertrauen in die Leistung dieser wäre schon angebracht, oder?
Von Verfluchtnochmal am Mo, 6. November 2017 um 20:37 #
Nein ist es nicht - Punkt
Und es wird auch erklärt warum von wegen gar nicht als sicherheitsrelevant erkannt und du kannst darauf gift nehmen dass redhat trotz aller Sorgfalt nicht jeden Upstream commit übernimmt wenn er unwichtig erscheint weil sie gleichzeitig einen riesigen Patch pflegen der bewusst nicht aufgesplittet wird um während der GPL zu genügen Nachbauten wie oracle nicht mehr als nötig Vorarbeit zu leisten
VERDAMMT NOCHMAL JETZT wäre der Zeitpunkt 3.10 zu forken und selbst weiter zu pflegen, bis jetzt gab es dazu keinen TECHNISCHEN Grund
Du hast einen rotzfrechen und saudummen Post abgelassen wo du der Welt erklären wolltest was Willy alles nicht weiß - Ah glaubst du ernsthaft dass es auch nur einen Kernel Entwickler gibt der von den RHEL Kernelversionen nicht mehr weiss als du kleines Licht jemals wissen wirst
Boah, du bist ein Held. Als Auto fährst du einen Trabi, deine Wohnung beleuchtest du mit Kerzen und dein Essen bereitest du am offenen Feuer zu. Und es hat dir immer noch keiner gesagt, dass der Zweite Weltkrieg vorbei ist.
Von Verfluchtnochmal am Mo, 6. November 2017 um 20:44 #
Erde an Depp: Die ABI Kompatibilität hätte auch der bist jetzt upstream mit point releases gepflegte kernel der gleichen Version gehabt
Und jede Nachfolger version auch wenn es rein um die Fachanwendungen geht weil Linus eine strikte "if it breaks userspace it needs to be reverted" Politik fährt
Es geht dir rein um offiziellen Support und sonst nichts, technisch gibt es keinen Grund warum ein RHEL nicht einen aktuellen Kernel fahren könnte, gibt ja sogar fertige binaries, aber halt abseits des supports
Von blablabla233 am Mo, 6. November 2017 um 21:06 #
Sieht aus als hast Du keinerlei Ahnung, es gibt durchaus Fachanwendungen die nur auf älteren Kernel arbeitet (hier ein CAM-Prog das nur mit 2.6.32 geht), der Deppen-Award geht an DICH....und bitte wisch Dir den Schaum von den Mundwinkeln, selten so einen Deppen gesehen...Projektleiter?
Von Verfluchtnochmal am Mo, 6. November 2017 um 21:20 #
Ausnahmen bestätigen die Regel und selbst da ist der Grund normalerweise dass irgendein Trottel eine Abfrage eingebaut hat sowie genug Software beim "make configure" ausgestiegen ist als es nach Jahren 2.6.x plötzlich 3.0 gab weil vermeintlich unbekanntes OS
Fedora hat den deswegen als 2.6.40 gebaut für N-1, aber wozu sollten Leute wie du auch tatsächliches technisches wissen besitzen wenn es doch nur Perlen vor die Säue ist
Trifft die Aussage in dem Artikel nicht ohnehin nur auf den sog. Vanilla-Kernel zu?
Für distributionseigene Kernel, wie der von dir genannte, übernehmen eben jene Distributoren die Verantwortung und portieren die Sicherheitsflicken für aktuelle Kernel zurück.
Wie sicher oder fahrlässig das ist, ist dann Vertrauenssache. Wenn man seinem Distributionsanbieter aber nicht vertraut, sollte man sich nach Alternativen umsehen.
ist halt so hier auf PL: einer motzt zu einem Artikel oder Thema (oder dran vorbei) los und alle steigen auf den Duktus ein. Je konfrontativer, umso weniger Erkenntnisgewinn für alle natürlich. Irgendwann rutscht der Artikel in der Leiste runter und es findet sich das nächste Reizthema, wo sie sich raufen können. Wahlweise kommen dann Worte wie "Keller", "ungewaschen", "Frickelei" usw. zum Einsatz.
Beliebteste Streithammelthemen:
- KDE oder Gnome - systemd oder nicht - welches ist die schlechteste Dristri - welches ist die überflüssigste Distri
Mal eine Verständnisfrage. Ist davon dann auch der Kernel im jeweiligen Android betroffen? Gerade im Hinblick auf LineageOS kommen zwar neue Android Version für alte Handy heraus, die Kernel bleiben aber meist für das Handy gleich.
Von Verfluchtnochmal am Di, 7. November 2017 um 23:01 #
Bla - Der Kernel ist immer exakt der gleiche weil sonst die ganzen BLOB Treiber die noch nicht mal der Hersteller des Smartphones an eine neuere Version anpassen konnte weil er von Qualcomm und Freunden halt nicht mehr bekommen hat als ein Stück Hardware und einen BLOB dazu
Und der Anroid Kernel hat mit dem von kernel.org seit vielen Jahren recht wenig zu tun - Aber in einigen Jahren wird das vielleicht wieder besser
Unter Android ist ein veralteter Kernel auch kein gravierendes Sicherheitsproblem da Google aus dem genannten und bekannten BLOB-Grund die Sicherheitspatchebene aus dem Kernel raus verlagert hat. Und die wird bei LineageOS meist noch schneller aktualisiert als von Google selbst auf den eigenen Geräten ...oder gar ausgebaut (Heartbleed, Krack usw.)
Ich nutze Kernel 3.10.0-693.5.2.el7.x86_64 und bin mir ganz sicher, dass ich noch viele Updates erhalten werde. Gepflegt wird der Kernel durch Redhat, da hat der Willy leider nur seine kleine Welt und die von kernel.org gesehen.
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
Falsch, in der kleinen (RedHat)Welt lebst DU!
Was nutz einem Debian - Arch - sonstwas - User, das RedHat noch Updates für den 3.10er Kernel produziert, wenn sie nicht zum Distri-Kernel passen?
-> Erst denken, dann reden ( schreiben)!
Falsch ich nutze durchaus primär die Technik von Redhat und dessen Ableger aber bin absolut gegenüber anderen Distributionen aufgeschlossen und nutze diese auch. Also meine Distriwelt ist alles nur nicht klein. Ich versteht mich auch nicht, Willy unterstellt anderen eine gewisse Fahrlässigkeit und das kritisiere ich am Beispiel von Redhat. Ich hätte auch Debian nehmen können, durch LTS Support 5 Jahre Unterstützung richtig? Unterstellt ihr hier auch den Machern bei der Pflege des Kernels Fahrlässigkeit? Ich denke wir sind uns einig das natürlich sauber gearbeitet werden muss, aber bitte es gibt da draußen viele Entwickler die das echt gut können. Also ein wenig Vertrauen in die Leistung dieser wäre schon angebracht, oder?
Nein ist es nicht - Punkt
Und es wird auch erklärt warum von wegen gar nicht als sicherheitsrelevant erkannt und du kannst darauf gift nehmen dass redhat trotz aller Sorgfalt nicht jeden Upstream commit übernimmt wenn er unwichtig erscheint weil sie gleichzeitig einen riesigen Patch pflegen der bewusst nicht aufgesplittet wird um während der GPL zu genügen Nachbauten wie oracle nicht mehr als nötig Vorarbeit zu leisten
VERDAMMT NOCHMAL JETZT wäre der Zeitpunkt 3.10 zu forken und selbst weiter zu pflegen, bis jetzt gab es dazu keinen TECHNISCHEN Grund
Du hast einen rotzfrechen und saudummen Post abgelassen wo du der Welt erklären wolltest was Willy alles nicht weiß - Ah glaubst du ernsthaft dass es auch nur einen Kernel Entwickler gibt der von den RHEL Kernelversionen nicht mehr weiss als du kleines Licht jemals wissen wirst
Boah, du bist ein Held. Als Auto fährst du einen Trabi, deine Wohnung beleuchtest du mit Kerzen und dein Essen bereitest du am offenen Feuer zu. Und es hat dir immer noch keiner gesagt, dass der Zweite Weltkrieg vorbei ist.
Wie jetzt?? Der zweite Weltkrieg ist vorbei?Echt jetzt?
Glaub ich nicht...der ist immer noch da...der hat bestimmt nur einen anderen Namen!
Warum genau nutzt du diese Version noch?
Langzeitsupport und Fachanwendungen.
Erde an Depp: Die ABI Kompatibilität hätte auch der bist jetzt upstream mit point releases gepflegte kernel der gleichen Version gehabt
Und jede Nachfolger version auch wenn es rein um die Fachanwendungen geht weil Linus eine strikte "if it breaks userspace it needs to be reverted" Politik fährt
Es geht dir rein um offiziellen Support und sonst nichts, technisch gibt es keinen Grund warum ein RHEL nicht einen aktuellen Kernel fahren könnte, gibt ja sogar fertige binaries, aber halt abseits des supports
Sieht aus als hast Du keinerlei Ahnung, es gibt durchaus Fachanwendungen die nur auf älteren Kernel arbeitet (hier ein CAM-Prog das nur mit 2.6.32 geht), der Deppen-Award geht an DICH....und bitte wisch Dir den Schaum von den Mundwinkeln, selten so einen Deppen gesehen...Projektleiter?
Ausnahmen bestätigen die Regel und selbst da ist der Grund normalerweise dass irgendein Trottel eine Abfrage eingebaut hat sowie genug Software beim "make configure" ausgestiegen ist als es nach Jahren 2.6.x plötzlich 3.0 gab weil vermeintlich unbekanntes OS
Fedora hat den deswegen als 2.6.40 gebaut für N-1, aber wozu sollten Leute wie du auch tatsächliches technisches wissen besitzen wenn es doch nur Perlen vor die Säue ist
Genau und das nicht zu knapp, aber das verstehen viele nicht.
Trifft die Aussage in dem Artikel nicht ohnehin nur auf den sog. Vanilla-Kernel zu?
Für distributionseigene Kernel, wie der von dir genannte, übernehmen eben jene Distributoren die Verantwortung und portieren die Sicherheitsflicken für aktuelle Kernel zurück.
Wie sicher oder fahrlässig das ist, ist dann Vertrauenssache. Wenn man seinem Distributionsanbieter aber nicht vertraut, sollte man sich nach Alternativen umsehen.
Genau du sagst es, deshalb habe ich mich so gegen die Aussage der Fahrlässigkeit gewehrt.
Und da haben wirs. Also ich vertraue niemanden und backe lieber alles selbst zusammen. http://www.linuxfromscratch.org/
Darf man fragen wieso ihr euch streitet ?
Irgendwann hört jeder Support auf.
ist halt so hier auf PL: einer motzt zu einem Artikel oder Thema (oder dran vorbei) los und alle steigen auf den Duktus ein. Je konfrontativer, umso weniger Erkenntnisgewinn für alle natürlich. Irgendwann rutscht der Artikel in der Leiste runter und es findet sich das nächste Reizthema, wo sie sich raufen können.
Wahlweise kommen dann Worte wie "Keller", "ungewaschen", "Frickelei" usw. zum Einsatz.
Beliebteste Streithammelthemen:
- KDE oder Gnome
- systemd oder nicht
- welches ist die schlechteste Dristri
- welches ist die überflüssigste Distri
usw. - Popcorn halt.
Nix oder! Keines von beiden!
Die sind alle Trottel und ich bin der Superheld.
Mal eine Verständnisfrage. Ist davon dann auch der Kernel im jeweiligen Android betroffen? Gerade im Hinblick auf LineageOS kommen zwar neue Android Version für alte Handy heraus, die Kernel bleiben aber meist für das Handy gleich.
Bla - Der Kernel ist immer exakt der gleiche weil sonst die ganzen BLOB Treiber die noch nicht mal der Hersteller des Smartphones an eine neuere Version anpassen konnte weil er von Qualcomm und Freunden halt nicht mehr bekommen hat als ein Stück Hardware und einen BLOB dazu
Und der Anroid Kernel hat mit dem von kernel.org seit vielen Jahren recht wenig zu tun - Aber in einigen Jahren wird das vielleicht wieder besser
Unter Android ist ein veralteter Kernel auch kein gravierendes Sicherheitsproblem da Google aus dem genannten und bekannten BLOB-Grund die Sicherheitspatchebene aus dem Kernel raus verlagert hat. Und die wird bei LineageOS meist noch schneller aktualisiert als von Google selbst auf den eigenen Geräten ...oder gar ausgebaut (Heartbleed, Krack usw.)
Besten Dank für die Antwort! Das war mir so noch nicht bewusst.