News Xeon Phi: Intel schickt erste Knights-Corner-Karten in Rente

[Piktogramm]

@Mickey Cohen

Bei dieser Hardware erledigt sich das von allein, da muss nichts zurückgekauft werden. Allein dadurch, dass Energie teurer wird und neuere Generationen an Hardware effizienter arbeiten ist die Rechnung für Anschaffung + Betrieb für Neuware oftmals wesentlich besser als für Gebrauchtgeräte. Da muss man als Hersteller kein Geld in die Hand nehmen.



@strex

Das wird bei Großrechnern, die mittlerweile eine Linuxmonokultur sind recht schwer über so ein Treiberzertifizierungskack den Neukauf neuer Hardware zu erzwingen. Abgesehen davon, bei den ganz großen Rechnern wird sowieso in die Verträge geschrieben wie lang die Hardware unterstützt werden muss. Da will keiner auf einem mehrere einhundert Millionenteuren Hardwarehaufen sitzen, bei dem durch so was der Nutzwert auf nahe 0 reduziert wurde. Selbst wenn eine Firma sowas bringen würde, damit wäre man auf einen Schlag aus allen nationalen und vielen internationalen Ausschreibungen für Großrechner raus.

 

[strex]

@Piktogramm

Da geht es auch nicht um Großrechner oder Cluster die schon schlüsselfertig etwa von Cray geliefert werden, sondern um Standard Pizzaschachteln oder 2 HE Boxen ala DL380 Gx. Die werden bis heute nur in bestimmten Konstellationen zertifiziert und auch nur in einem bestimmen zeitlichen Rahmen. Die passende Konfiguration findet man dann in den Guides etwa für VMware mit 5.5 oder 6.0. Updates der Zertifizierung gibt es aber nach dem EOL nicht mehr. Sieht man doch schön bei DL380 G6 oder G7, die für neuere Versionen von VMware keine Einträge mehr haben aber damit auch noch bestens laufen. Neue Versionen von Ubuntu mit DL380 G6, nö, nämlich EOL.

Das ist auch kein Zeritfizierungskack, HP hat nur keinen Bock jede Generation mit jedem Update unzähliger Software wieder neu zu zertifizieren. Das wäre in der Laufzeit von 5 Jahren aber tausende von Versionen und somit verständlich..und 5 Jahre für einen Server ist schon hart am Limit. Die Pizzaboxen fliegen nach 3 Jahren, also nach der gesetzlichen Abschreibung wieder raus, weil der Energieverbrauch und anfallende Kosten für Ersatzteile zu hoch sind. Für die Kosten kann ich mir eine neue Pizzaschachtel hinstellen, die erstens weit effizienter ist, kaum Ausfallwahrscheinlichkeit zeigen durch neue Hardware und ich mit der Mehrleistung die Anzahl weiter konsolidieren kann.

 

[ascer]

Also GPU Programmierung findet oftmals soweit abstrahiert statt, dass das nicht zwingend ein Problem darstellt. Ob da nun OpenCL, CUDA oder CILK Plus genommen wird interessiert kaum. Meist ist das ganze C++ bzw. ähnlich. Im Zweifelsfall muss da ein bisschen was angepasst werden um eine gute Performance rauszuholen, aber das ist recht unabhängig von x86 oder GPU-Architektur. Dafür ist es zu weit abstrahiert.

Auf jeden Fall, aber unsere Bioinformatiker nutzen z.B. Libraries die am performantesten (laut deren Papern) auf CUDA laufen. Als KI-Heini bin ich mit Theano und Tensorflow beschäftigt und abgesehen von anderen bei uns, die OpenCL nutzen, ergab ein kurzer Ausflug zu Xeon Phi bei uns auch nur: nett, weil schnell lauffähig, insgesamt aber schlecht von den großen Libraries unterstützt, da einfach langsamer als Grafikkarten und weniger Speicher.

Die aktuellen Dual K80 bei uns im Cluster kommen seit 2015, wo die angeschafft wurden, auf 3 TFlops Double-Precision Leistung bei 24GB GDDR5. Da kann man seit letztem Jahr schon einiges mit anfangen in Simulationen.

*Wahrscheinlich* gibt es 2017 die nächsten neuen GPU-Nodes und wer die Slides von NVIDIA kennt, weiß, dass sie enorme Performancesprünge und ich glaube bis zu 64GB waren es veranschlagt haben, für die HPC-Ableger von Pascal.

Noch ist Knights Landing ja nur ein Papiertroll und er ist halt schon jetzt maximal gleichschnell bei *weniger* RAM im Vergleich zu den NVIDIA HPC Karten, die Anfang letztes Jahr beschafft wurden. Wie soll der denn auch nur minimal interessant sein, wenn sicherlich nicht erheblich später die Pascal HPC-Karten kommen?

Was die Leistung der XeonPhi Karten angeht. Double Prescision schafft Knights Corner theoretisch 1Tflop und Knights Landing soll 3TFlops schaffen.

Wie gesagt, das haben unsere Dual K80 halt seit Anfang letzten Jahres und das bei 24GB GDDR5 und nicht 16GB.

Unabhängig davon ist die Single Precision Leistung deutlich höher und tatsächlich häufig gar nicht so uninteressant: bevor ein großes Experiment eine Woche oder länger läuft im DP-Mode abstrahieren wir häufig auf kleinere Probleme mit SP, die dann nur ein paar Stunden laufen. Einfach um zu optimieren und zu interpretieren, damit man das große Experiment mit DP besser planen kann und nicht 1 Woche oder mehr Rechenzeit für mittelmäßige Ergebnisse aufwendet.

Also diese Phi sind nicht die teuerste, langsamste Alternative sondern gehören derzeit zum "geilen Scheiß" den man als Rechenzentrumbetreiber haben möchte.

Finde ich halt wie gesagt nicht, erst der Knights Landing wird vielleicht gerade mal so ebenbürtig zu den 2015 Dual K80 NVIDIA Karten von uns. Und wenn die großen Xeon Phi wieder 3k aufwärts kosten, waren unsere Dual K80 in 2015 sogar deutlich billiger.

 

[Piktogramm]

Wenn der Support und Zertifizierung so lang laufen wie die typische Nutzungsdauer ist doch aber alles in Ordnung. Intel wird die XeonPhi Generationen auch nicht ewig unterstützen. Aber selbst wenn EOL erreicht ist, sind die Treiber im Kernel, die Optimierungen in der Gnu Compiler Collection und um Zertifikate usw. kümmert sich da keiner. Zumindest sind irgendwelche zertifizierten Komponenten nicht für den Betrieb zwingend erforderlich!
Meine letzte Erfahrung mit Zertifizierungskack war eher, dass 2Jahre vor dem Ende von Win XP nur XP unterstützt wurde und Win7 nur mit neuer Hardware + zertifizierter Treiber funktioniert. Bei Hardware die >10Jahre betrieben wird, extrem teuer ist und wenn Win7 ausläuft muss nochmal Geld drauf geworden werden, denn Win 8 und 10 werden noch immer nicht unterstützt. Wobei die kritische Komponente eigentlich nichts anderes macht als ein proprietäres, serielles Interface bereitzustellen. Da reden wir über 4-stellige Beträge für eine Technik die ein Raspberry 1 vollständig abbilden kann.

 

[ascer]

Da reden wir über 4-stellige Beträge für eine Technik die ein Raspberry 1 vollständig abbilden kann.

Bei sowas frage ich mich immer, warum nicht, wie bei Universitäten gefühlt deutlich öfter der Fall, freie Software eingesetzt wird. Sicher nicht bei allen, aber durchaus bei manchen, Anwendungsszenarien habe ich mir schon öfters gedacht: das, was das Unternehmen gerade für Lizenzen & Co raushaut, wäre mit 2-3 Linux-Admins und 2-3 ordentlichen Informatikern auch als Individuallösung drin. Vielleicht wäre es nicht direkt bei der Erstanschaffung günstiger, aber spätestens über Jahre im laufenden Betrieb.

 

[Piktogramm]

@ascer

2x K80 gegen 1x XeonPhi ist ein merkwürdiger Vergleich. Hier sollte man schon einzelne Einheiten vergleichen und nicht schon mit der Anzahl skalieren, denn das kann der XeonPhi auch.

Was den Speicher angeht. Die 16GB sind nur die Limitierung des OnPackage Speichers. Sonstiger Speicher kann in der Größe von 384GB je Einheit adressiert werden. Das dürfte auch in diesem Bereich für viele Anwendungen ausreichen.

Was Single Precision angeht, wie du schon sagst, solche Modelle laufen wenige Stunden im Vergleich zu DP mit Laufzeiten von Tagen-Wochen. Da liegen in der Auslastung in der Regel 1-2 Größenordnungen dazwischen, weshalb dann meist doch auf DP hin optimiert wird. Je nach Anwendungsfall kann das natürlich streuen.


Ansonsten, ja klar wenn man immer Produkte aus der Zukunft herannimmt, wird das Produkt besser dastehen, welches in weiterer Zukunft liegt. Aktuelle Quadro gegen bald erscheinender XeonPhi vs. Pascal Quadro im Jahre 2017 gegen Xeon Phi Knights Hill in noch weiterer Zukunft im Vergleich zum Smartphonesoc des Jahres 2025...
Auf das hier und jetzt bezogen würde ich jedoch behaupten, dass die XeonPhi von Intel konkurrenzfähig sind (und sei es durch den Preis). Ansonsten gäbe es keine knapp 40% Marktanteil in der Top500 Liste.


Nachtrag zu Proprietärem Lizenskack:
In diesem Fall fordert der Staat für eine Betriebserlaubnis der Maschinerie so etwas. Wobei es für andere Maschinen dann das Modell gibt, dass man die Zertifikate im Abomodell vertreibt (weniger hundert € im Quartal *), schlicht weil der Staat es vorschreibt und der freie Wettbewerb regelt es dann auch so, dass wenn einer einen neuen Weg findet die Kunden zu schröpfen, alle anderen nachziehen!

*Die Zertifikate laufen nach 3 Monaten aus, die kryptografische Sicherheit ist mau und Updates werden über plain FTP gezogen und natürlich ohne Überprüfung ob die Quelle jene ist, die sie sein sollte.

 

[ascer]

2x K80 gegen 1x XeonPhi ist ein merkwürdiger Vergleich. Hier sollte man schon einzelne Einheiten vergleichen und nicht schon mit der Anzahl skalieren, denn das kann der XeonPhi auch.

Das tat ich deshalb, weil es eben 2 Dies auf einer Karte sind, also eine Erweiterungskarte. Und weil der Preis davon marginal unterhalb von dem Vollausbau der XeonPhi liegt/lag. Insofern wollte ich (Preis-/)Leistung von jeweils einer Erweiterungskarte vergleichen. Auf wie viele Karten sich die Performance verteilt ist ja auch nicht gänzlich unerheblich.

Die 16GB sind nur die Limitierung des OnPackage Speichers. Sonstiger Speicher kann in der Größe von 384GB je Einheit adressiert werden.

...aber der Speicher auf der Karte ist doch schon recht ausschlaggebend. Natürlich kann ich innerhalb eines Nodes mehr RAM dazukleben oder ihn gleich aus dem kompletten verteilten System Daten laden lassen, aber da kreiert man sich doch unnötig Flaschenhälse.

Ansonsten, ja klar wenn man immer Produkte aus der Zukunft herannimmt, wird das Produkt besser dastehen, welches in weiterer Zukunft liegt. Aktuelle Quadro gegen bald erscheinender XeonPhi vs. Pascal Quadro im Jahre 2017 gegen Xeon Phi Knights Hill in noch weiterer Zukunft im Vergleich zum Smartphonesoc des Jahres 2025...

Den Vergleich finde ich unpassend. Noch ist Knights Landing doch ein Papiertiger und 2017 ist nicht mehr so lange hin. Paperlaunch von NVIDIA ist meine ich sogar auch 2016 für die HPC-Pascal-Ableger. Von daher würde ich schon sagen das Knights Landing's Gegner die Pascal-HPC-Variante sein wird und nicht die seit ich glaube 2014Q3 gelaunchten Dual-K80 als aktuelles Flagschliff - deren direkter Konkurrent war doch Knights Corner.

 

[Piktogramm]

Zum Speicher, XeonPhi kann als Karte betrieben werden und da GDDR5 anbinden oder aber als gesockelte Variante DDR4 Speicher. Wobei da in beiden Fällen das Maximum besagte 384GB sind. Das ist für die allermeisten Anwendungen auch im HPC-Bereich weit weg von Flaschenhals. 16GB "HMC-Cache" + 384GB Ram...

Was die Kosten bzw. Preis/Leistung angeht. Der Marktanteil der Dinger ist zu groß, als dass die Nvidia Systeme derart besser sein können als du es beschreibst. Ansonsten, mein Kommentar zur Betrachtung zukünftiger Produkte schneist du fast schon mit Absicht falsch zu verstehen. Es liegt in der Natur der Sache, dass sich bei halbwegs gesundem Wettbewerb die Produkte im zeitlichen Wechsel überbieten. Ist halt so, wird sich auch in Zukunft von Anwendungsfall zu Anwendungsfall wohl auch weiterhin unterscheiden. Eindeutige Sieger sollte es da hoffentlich nicht geben.

 

[Müs Lee]

Bietet AMD eigentlich vergleichbare Lösungen an? Auf der HP finden sich nur gesockelte Serverprozessoren.

 

[ascer]

Zum Speicher, XeonPhi kann als Karte betrieben werden und da GDDR5 anbinden oder aber als gesockelte Variante DDR4 Speicher. Wobei da in beiden Fällen das Maximum besagte 384GB sind. Das ist für die allermeisten Anwendungen auch im HPC-Bereich weit weg von Flaschenhals. 16GB "HMC-Cache" + 384GB Ram...

Da hast du mich falsch verstanden. Ich meinte, dass 16GB für eine Karte sehr wenig ist (besonders für eine, die erst in Zukunft erscheinen wird). Natürlich kann man zu dem OnPackage Speicher mehr - wie du ja schon beschrieben hast - "dazupacken": hier meinte ich auch nicht den Flaschenhals "zu wenig RAM" sondern vielmehr "zu langsamer RAM".
Zugegebenermaßen kenn ich die Transferraten nicht, aber zwischen RAM <-> Grafikkarte ist das nicht besonders doll, trotz zahlreicher Optimierungen von NVIDIA. Deshalb arbeiten die meisten Libraries, die ich kenne, immer mit dem Speicher auf der Erweiterungskarte. Sprich du lädst deine Daten auf die Karte, lässt sie crunchen, und schaufelst dann erst die Ergebnisse zurück.
Wenn dir dein Speicher auf der Karte voll läuft und auf den RAM ausgelagert werden muss, geht die Performance deutlich spürbar zurück. Ich kann mir kaum vorstellen, dass Intel diese Problematik irgendwie umgehen kann und NVIDIA nicht.

Was die Kosten bzw. Preis/Leistung angeht. Der Marktanteil der Dinger ist zu groß, als dass die Nvidia Systeme derart besser sein können als du es beschreibst.

Das mag sein. Obwohl ich mir in einigen Fällen auch einfach Software/Libraries vorstellen könnte, die nicht oder nicht performant zu CUDA portiert wurden (sodass x86 Kerne auf einem Xeon Phi attraktiver sind, damit man nicht ewig viel zu CUDA porten und dann noch optimieren muss).

Es liegt in der Natur der Sache, dass sich bei halbwegs gesundem Wettbewerb die Produkte im zeitlichen Wechsel überbieten.

Natürlich und klar war Knights Corner zuerst da und dann die aktuellen K80 HPC-Ableger und voraussichtlich wird ja Knights Landing auch wieder vor dem Pascal-HPC-Ableger erscheinen. Ich meinte damit nur, dass der direkte Gegner von Knights Corner ja eben der K80 war und bei Knights Landing wiederum Pascal.
Außerdem finde ich nicht, da zwischen Knights Landing und dem Pascal-HPC-Ableger wahrscheinlich nur ein paar Monate liegen werden, dass man da von einem großen zeitlichen Vorteil für NVIDIA sprechen könnte.

 

[Piktogramm]

@ascer

Die 384GB sind NATIV angebundener Speicher. Also Bis zu 384GB GDDR5 Speicher auf der Erweiterungskarte (wird nicht vorkommen, da zu teuer aber möglich ist es) oder aber wenn der XeonPhi in der gesockelten Variante zum Einsatz kommt DDR4 Speicher in gleicher Menge. Es geht an keiner Stelle um die Nutzung von "shared Memory". In einer solchen Konfiguration sind die 16GB HMC Speicher eher sowas wie ein sehr großer Cache, bei dem fast nur mit Gewalt Cachemisses zu erzwingen sind.
Also nochmal, wo ist da der Flaschenhals, außer bei deinem Verständnis meiner Texte :/


Was das Optimieren von Bibliotheken angeht. Für die Bewertung der Produkte geht der Softwaresupport mit ein. Wenn Intel zur Hardware mehr bzw. bessere Bibliotheken anbietet oder umgekehrt Nvidia dann ist das Produkt als Paket halt besser. Wenn das Ergebnis so zu gunsten evtl. schwächere Hardware ausfällt weil ein Hersteller besser optimiert ist das dem Kunden egal. Hauptsache es performt.

 

[ascer]

Die 384GB sind NATIV angebundener Speicher. Also Bis zu 384GB GDDR5 Speicher auf der Erweiterungskarte (...) Es geht an keiner Stelle um die Nutzung von "shared Memory". (...)
Also nochmal, wo ist da der Flaschenhals, außer bei deinem Verständnis meiner Texte :/

Vorab: ich finde jetzt nicht, dass dieser Sachverhalt direkt aus deinen Texten hervorging.
Ansonsten: Sorry für das Missverständnis. Man kann also direkt "Erweiterungsspeicher" auf die Erweiterungskarte packen? Das war mir nicht bewusst - dann nehme ich den Einwand natürlich zurück. Ich dachte tatsächlich es geht bei den Xeon Phi's nur wie bei NVIDIA -> API Zeug um z.B. auf den RAM des Systems zuzugreifen, wenn der Kartenspeicher nicht ausreicht (und da hat man dann natürlich einen Flaschenhals).

 

[Carsten]

Nein, das geht nicht. Die gesockelten Phis können den Hauptspeicher nutzen und den MCDRAM als riesigen Cache zwischenschalten. Die Steckkarten müssen den Hauptspeicher über PCIe ansprechen, wie andere Beschleuniger/Co-Prozessoren auch.

Was ich aber eigentlich noch anfügen wollte: Die Mär vom leicht programmierbaren Xeon Phi. Es stimmt, dass x86-Code drauf läuft, aber bis der performant läuft ohne das zweistellige Prozente liegengelassen werden, kann man auch gleich auf GPU portieren, das ist dann nicht mehr soo viel Mehraufwand.

 

[Piktogramm]

Öhm, ich habe mich (mehrfach :/ ) verlesen. GDDR5 kann Knights Landing nicht, das Ding hat nur 2x3 DDR4 Kanäle nach außen und die gesteckten Karten werden nur mit bis zu 16GB On Package angegeben.

Bitte ascer, entschuldige, dass obwohl ich falsch lag dich so angegangen bin.

 

[ascer]

@Piktogramm: Alles klar, kein Problem. Dann lag ich doch richtig und sobald die 16GB OnPackage voll sind, kommt der Flaschenhals Erweiterungskarte <-> System-RAM zu tragen...dann finde ich das nach wie vor recht wenig^^

 

[Holt]

das ist das was du denkst und zum warum: na um den gebrauchtmarkt zu eliminieren, so dass immer schön neu gekauft werden muss

Google mal Xeon Phi 150$, die kleinsten Karten gab es nämlich auch mal eine Zeitlang in den USA zu dem Preis, nur weiß ich nicht mehr zu welche genauen Bedingungen, also es Studentenrabatt oder sowas war. Kein ernsthaftes Rechenzentrum setzt gebraucht HW ein, wenn die alten Karten also danach günstig zu haben sind, wäre es das besten was Intel sich wünschen kann um die Verbreitung bei Studenten und Hobbyprogrammierern zu fördern und so die SW-Basis zu erweitern.

Kommt dann ein VMware Update des ESX, funktionieren in der Regel die alten Treiber noch aber es gibt für die neue Version keine Zertifizierung mehr.

Das ist aber das Problem weniger die HW als das neuere OS welches darauf laufen soll. Das geht halt schlecht, da sind die Hersteller gerade der Betriebssysteme sehr restriktiv und man muss so einen Server meist die ganze Zeit mit dem OS laufen lassen für das er ursprünglich gekauft und ausgelegt war, oder eben früher als erwartet HW austauschen. Never change a running system!

In CUDA oder was immer geht ja eine Menge, aber wie viele Entwickler kennen es und können es wirklich beherrschen, also auch Programme debuggen? Das sind nun einmal weniger als für x86er Code und da liegt die Stärke des Xeon Phi, denn wenn man nun einen Algorithmus hat, womöglich nicht in C sondern einer noch weniger aktuellen und damit unterstützten Sprache, dann ist die Chance den fehlerfrei auf aktuellen x86er CPU zum laufen zu bringen ungleich besser als dies auf GPUs zu machen, außer man hat eben gerade den Freak frei der die GPU Programmierung wirklich beherrscht, aber die sind halt selten, viel seltener als gute Programmierer die auch gut parallele Programme schreiben können sowieso schon sind.

 

[strex]

Meine letzte Erfahrung mit Zertifizierungskack war eher, dass 2Jahre vor dem Ende von Win XP nur XP unterstützt wurde und Win7 nur mit neuer Hardware + zertifizierter Treiber funktioniert. Bei Hardware die >10Jahre betrieben wird, extrem teuer ist und wenn Win7 ausläuft muss nochmal Geld drauf geworden werden, denn Win 8 und 10 werden noch immer nicht unterstützt. Wobei die kritische Komponente eigentlich nichts anderes macht als ein proprietäres, serielles Interface bereitzustellen. Da reden wir über 4-stellige Beträge für eine Technik die ein Raspberry 1 vollständig abbilden kann.

Wer spricht denn hier von WinXP und lausiger Software oder co..Hier geht es um Systeme wie SAP, Hana oder Oracle DBs. Wer da Zuverlässigkeit und Stabilität haben möchte, kommt nicht rum auf Zertifizierung zu setzen. Alleine deshalb, weil es sonst kein Support vom Hersteller gibt. Im Enterprise-Umfeld nicht wegzudenken. VMware lacht dich aus, wenn du mit Hardware kommst die nicht in der HCL ist und du Support möchtest.

Was den Speicher angeht. Die 16GB sind nur die Limitierung des OnPackage Speichers. Sonstiger Speicher kann in der Größe von 384GB je Einheit adressiert werden. Das dürfte auch in diesem Bereich für viele Anwendungen ausreichen.

Genauer spricht Intel von >16GB als maximum. Aktuell sind nur 16GB geplant, hindert Intel aber nicht mehr zu verbauen wenn es gefordert der wird.

Zugegebenermaßen kenn ich die Transferraten nicht, aber zwischen RAM <-> Grafikkarte ist das nicht besonders doll, trotz zahlreicher Optimierungen von NVIDIA. Deshalb arbeiten die meisten Libraries, die ich kenne, immer mit dem Speicher auf der Erweiterungskarte. Sprich du lädst deine Daten auf die Karte, lässt sie crunchen, und schaufelst dann erst die Ergebnisse zurück.

Die kommt auf 90GB/s mit DDR4 und 384GB RAM im Host Mode, also ohne weitere CPU.

@Piktogramm: Alles klar, kein Problem. Dann lag ich doch richtig und sobald die 16GB OnPackage voll sind, kommt der Flaschenhals Erweiterungskarte <-> System-RAM zu tragen...dann finde ich das nach wie vor recht wenig^^

Nur wenn die Karte nicht im Host Mode läuft. Aber wo ist das Problem, aktuell Beschleuniger haben auch nur max. 32GB aber noch GDDR5. In den meisten Fällen sogar nur 16GB. Auch in Zukunft wird nur mit 32GB und HBM gerechnet. Da macht das den Kohl nicht fett. Warum man das bei der Phi als Nachteil sehen will, aber bei AMD oder NV nicht ist mir ein Rätsel..

Das ist aber das Problem weniger die HW als das neuere OS welches darauf laufen soll. Das geht halt schlecht, da sind die Hersteller gerade der Betriebssysteme sehr restriktiv und man muss so einen Server meist die ganze Zeit mit dem OS laufen lassen für das er ursprünglich gekauft und ausgelegt war, oder eben früher als erwartet HW austauschen. Never change a running system!

Na klar ist das ein Problem des HW Herstellers. Er ist ja für den Support, also Treiber, zuständig. Das OS kann welche mitliefern, ist aber nicht zuständig dafür. VMware juckt das nicht ob jetzt Firma XY von NICs im Package Treiber enthalten sind oder auch nicht. Da muss der Hersteller liefern. Hier geht es nicht um ein neues großes Release von VMware, sondern die liefern Security Patches oder Stablitätsverbesserungen in diesen Varianten aus. Man braucht sich nur die Versionen und entfernte Treiber zwischen 5 und 5.5 ansehen. Wer da nicht aktualisiert handelt sich schnell mal eine Dicke Finte ein. Da erinnere ich nur einmal an das NTP Leck oder von XenServer den Ausbruch vom Gast in den Host..Heute werden in virtualisierten Umgebungen häufiger aktualisiert als man denkt, das Potenzial für Lücken und Performance ist dort über drei Jahre einfach zu hoch.

Never change a running system!

Dafür gibt es ja die Zertifizierung, man springt von stabilen Zustand zum nächsten. Tests und Validierung vorausgesetzt. Das Statement darf man aber heute getrost als veraltet ansehen. Bei der Geschwindigkeit mit der Sicherheitsprobleme veröffentlich werden und der breiten Vernetzung, ist es grobfahrlässig nicht zu aktualisieren. Kein Wunder das es heute so oft einen trifft, wenn jeder dieses Statement immer noch nachplappert und beherzigt.