News Linux Kernel 3.10 erhält Langzeitsupport

Cool Master schrieb:
Verbesserer HW Support sprich, bessere Kern auslastung, weniger RAM verbrauch usw usw...
Als ob... Wenn es in dem Kernel Stabilitätsprobleme gäbe, dann würden sie innerhalb des LTS gefixt. Wobei ein instabiler Kernel eben kein LTS wird.
Neue Features sind in der Serverwelt weitestgehend egal. Braucht mein auf Ext4 basierendes System besseren Support für Btrfs? Nö. Braucht mein Fileserver TRIM für SSDs im Softraid? Nö. Nutzt mir im Server Wake on WLAN was? Nö. Nutzt mir Support für Komponenten etwas, die gar nicht verbaut sind? Nö.

Keines der Kernelupdates bringt wirklich eine Verbesserung der Systemleistung, und erst recht keine Verbesserung, die das Risiko eines Upgrades wert wäre.
Und um bei deinem Ansatz zu bleiben: Deine VMs verbrennen 10x so viel Leistung, wie du mit nem Kernel-Update potentiell gewinnst.

Wie ich schon schrieb man kann alles hacken keine Frage aber deswegen updatet man ja seine Pakete immer fleisig alle 2 Wochen
Es gibt keinen Schutz vor Side Channel Attacken via CPU Cache auf VMs. Das, was VMs überhaupt erst nutzbar macht, bildet hier gleichzeitig die Achillesferse Deluxe.

Cool Master schrieb:
Stimme ich dir zu wenn neuer Code dazu kommt. Wird vorhandener Code aber optimiert sehe ich das nicht so.
Neuer Kernel - Release = neue Features und quasi gleichzeitig auch neue Bugs.
Eben dafür gibts LTS: Der bereinigt nur Fehler im alten Stable, anstatt neue Features durch neue Probleme zu erkaufen.

Wenn man wirklich mal etwas aktuelleres will, dann kann man immer noch auf Ubuntu 12.04 LTS setzen und den Raring Backport Kernel benutzen. Aber selbst der ist nicht Bleeding Edge.
 
Bei 2 Jahren von "Langzeitsupport" zu sprechen finde ich an sich schon witzig.
Ich fände es auch schöner wenn die alle 2 Jahre nen LTS-Kernel mit 4 - 5 Jahren

Ich glaube hier haben viele keinen Plan wie das in der IT praktisch läuft.
Immer die neueste Version funktioniert da einfach nicht. Da streicht man im php ne Funktion und schon läuft ggf. eine Seite nicht mehr.
Oder man hat ne 3rd party Software die mit neuen libs nicht klar kommt.
Oder der Kernel verschlimmbessert sich und macht mit Hardware XY Probleme, die es vorher nicht gab.
Alles schon gehabt.

@Cool Master:
Neue Funktionen bedeuten in Summe eher langsamere Software als schnellere.
Mag sein, dass der der ein oder andere Tweak drin ist, aber mehr Code braucht meistens schlichtweg mehr Ressourcen.

Systempflege braucht Zeit und verursacht Kosten.
Sieh es mal so:
Wenn ich einmal im Jahr ein dist-upgrade auf allen Systemen mache und dafür 1 Vollzeitkraft brauche um die Schäden zu beseitigen, dann komm ich bei nem 3-Jahres-Zyklus evtl. mit ner halben Kraft aus.

Das magst du vielleicht nicht nachvollziehen wenn du deinen Rechner @home updatest, wenn du aber 100 Systeme betreust die diverse Dienste bereitstellen und fast jeder anders ist als der vorherige, sieht die Sache schon anders aus.
 
@Blutschlumpf

Stimmt, wie das ganze in nem 100+ Mann Betrieb aussieht kann ich nicht nachvollziehen. Ich arbeite in einem 2 Mann Unternehmen und bin selber Anwendungsentwickler. Ich löse diese ganzen Probleme indem bei mir alles in einer Sandbox (virtualenv) läuft und ich das System unabhänig von den Sandboxen updaten kann und ich mir zu 100% sicher bin das nach dem Update bei uns noch immer alles läuft.

Bzgl. neuen Funktionen und langsamer: Ja, das kann passieren es kommt halt auf die Software und Sprache an. In Python, meiner hauptsprache neben Django, ist es z.B. möglich recht schnell noch mal was zu optimieren wobei Python an sich schon verdammt schnell ist.
 
Cool Master schrieb:
@noxon

Und in diesen 7 Jahre auf neurungen verzichten? Wie gesagt ich mache das so:
Exakt, denn was einmal läuft, das läuft und da braucht man nichts erneuern.
Zumindest nicht in de Tempo, wie du es privat mit deinem Desktop System tust.
 
Zuletzt bearbeitet:
@Cool Master: Ich meinte weniger 100 Mann zum Betrieb als 1-2 Mann und 100 Server, die man updaten muss. Wenn man die Software selber schreibt ist das auch noch ne ganz andere Sache, dann kann man die ja zur Not noch anpassen wenns Kleinigkeiten sind (z.B. htmlentities beim Upgrade von Debian 6 auf 7).
Stell dir jetzt mal vor du betreibst die Server, die Software liegt aber nur teilweise in deiner Hand, sei es weil die uralt ist und nicht mehr weiter angeboten wird oder weil das Kundensoftware ist, die der Kunde selber schreibt und wichtigeres zu tun hat als veraltete Funktionen zu ersetzen.

Dann kannst du nicht einfach sagen "Scheiß drauf, gestern kam Debian 7 raus, lass mal schnell upgraden." Dann bist du drauf angewiesen, dass da auch mal ne alte php Version mit Updates versorgt wird oder ein System 3 Jahre lang auf Debian 3/4/5 läuft auch wenn der Nachfolger schon ne Weile raus ist.
 
Schade, hatte gehofft, dass in den LTS Kernel "Radeon DPM" kommt, aber der ist in 3.11 drin =(
 
Ich glaube hier haben viele keinen Plan wie das in der IT praktisch läuft.
Immer die neueste Version funktioniert da einfach nicht. Da streicht man im php ne Funktion und schon läuft ggf. eine Seite nicht mehr.
PHP?!? Mehr absurde Vergleiche bitte! Wie wäre es mit Autos oder Fußballplätzen - die passen immer.

"Mal eine Funktion streichen" findet bei Linux schlicht nicht statt. Punkt. Linus ist bekannt dafür, jeden persönlich zu besuchen und zu erschlagen, der im Userland sichtbare Funktionalität entfernen möchte, also Potential schafft, das Userland zu schrotten.

Neuer Kernel - Release = neue Features und quasi gleichzeitig auch neue Bugs.
Eben dafür gibts LTS: Der bereinigt nur Fehler im alten Stable, anstatt neue Features durch neue Probleme zu erkaufen.
Das ist die Theorie. Ein Wunschtraum. Die Praxis sieht doch bischen anders aus. Der Stable-Maintainer jammert ständig, daß Entwickler ihre Bugfixes enthaltenden Patches nicht für die Aufnahme in stable markieren, wenn es aus Sicht des Autors sinnvoll wäre. Da ist von LTS noch gar nicht die Rede. Die Entwickler selbst haben kaum Interesse daran, altes Zeug zu pflegen.

Es hängt deshalb an ganz wenigen Nasen zu entscheiden, welche Patches Bugfixes sind, ob der Fix in alten Serien landet, ggf. den Backport zu machen, Seiteneffekte mit anderen Patches abzuschätzen usw. Nur ein winziger Anteil Fixes gelangt in die alten Versionen. Die "groben Schnitzer", über die sich jemand beschwert hat, könnte man sie nennen.

d.h.
Wer tatsächlich Wert auf Fehlerarmut legt, sollte _keine_ _uralten_ Kernel betreiben - auch dann nicht, wenn sie ein LTS-Logo tragen. Natürlich haben neuere Kernel absolut gezählt mehr Bugs, aber diese Bugs konzentrieren sich auf Teile, die neue Features implementieren. Im "gut abgehangenen" Teil des Kernels sieht es in neueren Versionen besser aus als in den gepimpten LTS-Leichen. Das ist mein zentraler Punkt.
 
Zuletzt bearbeitet:
derGrimm schrieb:
Schade, hatte gehofft, dass in den LTS Kernel "Radeon DPM" kommt, aber der ist in 3.11 drin =(

dafür gibt es die Backports kernel

und im Netz kursiert ein Kernel mit zurückportierten Patches bereits jetzt schon

also: Hand anlegen, selber patchen und kompilieren :D


schön, dass 3.10 LTS erhält - der scheint ein besserer Wurf zu sein als 3.9 (verursachte nur Probleme bei mir), 3.8 wäre auch nicht schlecht gewesen - 3.10 + DPM läuft aber ziemlich gut ^^
 
mensch183 schrieb:
Die Entwickler selbst haben kaum Interesse daran, altes Zeug zu pflegen.

Würde ich so nicht sagen :)

Ich mein ja, alt Lasten sind bescheiden aber zum Teil helfen sie einem auch sich weiter zu entwicklen und so in Zukunft bessere Software zu schreiben :)

Wenn ich zurück schaue was ich in der Ausbildung gemacht habe und sehe wie kompliziert ich da zum Teil sachen umgesetzt habe denke ich mir echt nur was habe ich da gesoffen oO Das wäre mit meinem aktuellen Stand eine Sache von ~ 10 Stunden für was ich in dem Projekt ~ 35 gebraucht habe.
 
mensch183 schrieb:
PHP?!? Mehr absurde Vergleiche bitte! Wie wäre es mit Autos oder Fußballplätzen - die passen immer.
Vielleicht solltest du Dinge nicht aus dem Zusammenhang reißen und dir deine Argumenttion damit zusammenstricken. Hier ging es nicht speziell um den Kernel sondern ums Gesammtsystem.

Wer ein System einfach wartbar halten möchte wird den Teufel tun und anfangen sich Teile des Systems selber zu bauen oder abseits der Repositories upzudaten. Mit jeder Abweichung vom Standard steigt dein Wartungsaufwand deutlich.
Wer also sein Debian nicht updaten kann/will weil er php nicht updaten kann/will, wird in der Regel auch ne Weile länger mit nem alten Kernel leben.

Und ob du es glaubst oder nicht, auch die "abgehangenen" Teile des Kernels können Probleme machen.
Hatte letztens selber so nen Fall, 2 Systeme mit A64-X2 und ner Intel 1000PT NIC als Linux-Router. Die liefen Jahre mit 2.6.25 oder was in der Richtung.
Update auf 3.x gemacht und beide Systeme verursachten nun unerklärlichen Packetloss im Promillebereich.

Wir haben übrigens die Hardware getauscht (C2Duo rein und der loss war weg) um nicht in so ne Situation zu kommen dass wir nicht mehr updaten können. ;)
 
Also ich sehe das ähnlich wie Cool Master. Immer aktuell bleiben. Weniger aus Notwendigkeit, sondern mehr als Disziplin.

Hauptvorteil: man verliert die Angst vor dem Upgrade. Und wenn die Hardware mal kaputt ist, krieg ich keine Schweißperlen, einfach alles auf ner neuen Kiste wieder einzurichten. Dazu gehört natürlich auch eine gute Dokumentation von dem was man gemacht hat.

Alle, die hier von ihren "rockstable" Systemen sprechen, umschreiben doch damit nur ein Problem: sie haben zufällig mal eine Konstellation aus OS und Software gefunden, die stabil zu funktionieren scheint, aber sie wissen nicht, warum. Folglich mag man es es am liebsten nie wieder anfassen und upgraden. Das ist genau der Zustand, vor dem man heutzutage richtig Angst haben muss. Dadurch entstehen ja erst die altlasten, bzw. die 10 Jahre alten Server, die man eigentlich mal anfassen müsste, aber der Admin der das eingerichtet hat, ist längst tot, aber es ist ja leider unternehmenskritisch.

Wenn wirklich die Software so ist, dass mal ein Release gut, und der nächste katastrophal ist, und ich quasi mit der Angel nach stabilen Releases fischen muss, die man dann am besten nicht mehr anfasst - dann würde ich sagen, wird's Zeit, diese Software auszutauschen.

Nur meine Meinung. Sieht bestimmt jeder Admin anders.
 
Zuletzt bearbeitet:
Zurück
Oben