Zur Meldung über die ersten nVidia-Ampere-Grafikkarten wäre noch die Ergänzung zu vermelden, das die offizielle Ankündigung der Ampere-Generation bzw. des GA104-Chips auch auf der GTC vom 26. bis 29. März in San Jose stattfinden könnte – jene Messe passt auch perfekt in den genannte Zeitfenster und ist zudem nVidias Hausmesse (und wäre damit sogar wahrscheinlicher). Zu den Fragen, was sich hinter Ampere verbirgt, welcher Fertigungs-Node wahrscheinlich ist und was man insgesamt erwarten kann, liegt dagegen derzeit nach wie vor nichts griffiges vor, dies kann man weiterhin nur gerüchtweiser betrachten. Erwartbar ist nur der generelle Ablauf der Ampere-Generation – in welcher zuerst der HighEnd-Chip GA104 kommt, danach der Midrange-Chip GA106 und später dann der neue Enthusiasten-Chip GA102. Zu einem unbestimmten Zeitpunkt gibt es dann noch den Mainstream-Chip GA107 sowie den LowCost-Chip GA108 – bei diesen besteht eine gute Chance, das nVidia auf die Verfügbarkeit der 7nm-Fertigung im nächsten Jahr wartet, damit jene vergleichsweise günstig abzugebenden Grafikchips für nVidia auch mit der kleinstmöglichen Chipfläche (und damit der niedrigsten Kostenlage) hergestellt werden können. Als kleines PS noch diese nette Spielerei, gefunden bei Reddit: "If nVidia launches "Ampere", AMD should launch "Ohm". To lead the resistance."

Gemäß WCCF Tech wird die in der letzten Roadmap für das Jahr 2020 avisierte "AMD NextGen GPU Architecture" nicht mehr dem GCN-Ansatz folgen – und die im Jahr 2019 kommende Navi-Generation somit die letzte GCN-Iteration darstellen. Ob WCCF Tech einfach nur spekuliert oder aber eine ernsthafte Quelle hierfür hat, ist unklar – gut möglich ist das ganze aber doch schon. Denn die GCN-Architektur schleppt einige Limitationen mit sich herum – jene lassen sich zwar umgehen, aber dies dürfte sicherlich auch nur bis zu einem gewissen Maßstab unter einem vertretbaren Arbeitsaufwand realisierbar sein. Nicht umsonst wurde bei früheren AMD-Roadmaps das Feature der "Skalierbarkeit" für die Navi-Generation genannt – anfänglich als neuer MultiChip-Ansatz begriffen, ist nunmehr klar, das es hierbei schlicht um eine Umgehung der Limitationen der GCN-Architektur gehen wird. Und so etwas macht man üblicherweise immer erst am Ende des Lebenszyklus einer Mikroarchitektur – insofern ist der Schluß, das danach etwas grundlegend neues kommt, durchaus folgerichtig. Ob dies gleich die Navi direkt nachfolgende Grafikchip-Generation sein wird, bleibt jedoch vorerst unbestätigt – schließlich ist das Wort "Generation" (in "next-gen") vieldeutig und muß keineswegs großartige Architektur-Änderungen bedeuten.

AMD Grafikchip-Generationen Roadmap 2017-2020 (Januar 2018)

Bei Heise wird eine schwerwiegende Verwundbarkeit von Microsofts Verschlüsselungstrojaner-Schutz im Windows Defender von Windows 10 vermeldet: Augenscheinlich sind Microsofts eigene Office-Apps dort per default als "sicher" eingestuft – was sich ein Verschlüsselungstrojaner allerdings zu Nutze machen kann und mittels der OLE-Schnittstelle einfach vorgaukelt, der Zugriff auf die schützenswerten Dateien käme eben von einer der Office-Apps. Das Problem wird seitens des Entdeckers der Sicherheitslücke in dieser default-Einstellung der (definiert) "sicheren" Office-Apps gesehen – wobei man dies bei Dr. Windows anders sieht und eher die Nichtverhinderung der Ausführung des Verschlüsselungstrojaners durch den Windows Defender anmängelt. Interessanterweise kommt keine der beiden Publikationen auf die vielleicht naive, jedoch durchaus naheliegende Idee, das hierbei eher denn der OLE-Ansatz das Problem ist – mittels welchem der Verschlüsselungstrojaner eine Office-App nutzt, um in deren Namen auf geschützte Dateien zuzugreifen und diese zu verändern, konkret zu verschlüsseln.

Hierbei liegt vielleicht viel eher der grundlegende Fehler, welchen Microsoft begeht – eine Schnittstelle zum Umgehung von Zugriffsrechten bereitzustellen, welche zudem dem normalen PC-Nutzer kaum etwas bringt (eher nur im professionellen Bereich benötigt). Das die Office-Apps als per Definition "sicher" angesehen werden, ist hingegen nicht nur korrekt, sondern auch überaus sinnvoll – denn Office-Apps werden nun einmal üblicherweise zum Bearbeiten von Benutzerdateien eingesetzt, da wäre es widersinnig, dies per default zu blockieren. Der Zweck des Verschlüsselungstrojaner-Schutzes beim Windows Defender von Windows 10 (diese Funktionalität ist beim Windows Defender von Windows 7 & 8 nicht mit dabei) ist es ja gerade, normalen Bearbeitungs-Apps den Zugriff auf die eigenen Dokumente zu gewähren, dafür diesen Zugriff aber für alle möglichen anderen Programme zu verweigern – darunter dann eben auch ganz automatisch den Verschlüsselungstrojanern. Dumm nur für Microsoft, wenn man eine Schnittstelle zum Aushebeln dieser Schutzvorrichtung gleich mit an Bord hat – noch dümmer, wenn es eine Schnittstelle ist, die eher nur für Office-Arbeiter eine gewisse, aber kaum zwingende Relevanz besitzt, für normale PC-Nutzer jedoch gar keinen Wert hat. Hier muß Microsoft sicherlich nachbessern, ansonsten ist dieses (derzeit allerdings sowieso nicht per default aktive) Schutz-Feature vollkommen zwecklos.