Windows 10 v1809 - Installation in Slo-Mo

fishmac

Active member
Registriert
27 Apr. 2007
Beiträge
5.353
Size gerade an einer Maschine mit Xeon E3-1245v6 (3.70 GHz), 32 GB RAM und NVMe SSD. Warum schlecht die Installation (nicht der Download) mit einer Auslastung von CPU, RAM und SSD bei ca. 10% herum?
 
Vermutlich läuft da ein Teil in nur einem Thread ab. Wenn das die CPU voll auslastet, dann eben nur auf einem Kern bzw. einem virtuellen Kern (dank Hyperthreading hast du virtuell ja doppelt so viele Kerne wie "echte"). Deine CPU hat 4 Kerne, 8 virtuelle Kerne (also zum Abarbeiten von 8 Threads). Von letzteren wird einer voll ausgelastet, während die anderen vor sich hin idlen, das macht dann 12,5% maximale Aulastung, also ca. 10%.

Das wäre zumindest meine Vermutung.
 
Deine CPU hat 4 Kerne, 8 virtuelle Kerne (also zum Abarbeiten von 8 Threads). Von letzteren wird einer voll ausgelastet, während die anderen vor sich hin idlen, das macht dann 12,5% maximale Aulastung, also ca. 10%.

Interessanter Denkansatz. Würde auch den Erfahrungen mit Microsoft entsprechen. Da sind aber noch diese Aussagen von Microsoft selbst:

Ressourcenintensive Anwendungen erfordern ein Betriebssystem, das große Datenmengen mühelos und ohne merkliche Leistungseinbußen verarbeiten kann. Was Sie brauchen, ist ein System, das Sie während der Dateispeicherung oder einem Datentransfer nicht warten lässt, das weniger CPU-Zyklen benötigt und so mehr Kapazitäten für die gleichzeitige Ausführung mehrerer Anwendungen bietet, und eines, das schon heute für die Hardware der nächsten Generation ausgelegt ist. Freuen Sie sich auf Windows 10 Pro für Workstations.
Quelle

Also werde ich in Sachen Performance schon bei der Installation im Stich gelassen... :mad:
 
Interessanter Denkansatz. Würde auch den Erfahrungen mit Microsoft entsprechen. Da sind aber noch diese Aussagen von Microsoft selbst:


Quelle

Also werde ich in Sachen Performance schon bei der Installation im Stich gelassen... :mad:


Naja, der Installationsvorgang läuft ja bei den Updates meistens ohne Zutun des Benutzer im Hintergrund und am Ende wird angezeigt, dass für die nächste Nacht ein Neustart geplant ist (mit der Möglichkeit direkt neu zu starten).
Wenn man also davon ausgeht, dass der Benutzer möglichst unbehelligt weiterarbeiten soll während im Hintergrund installiert wird, ist es gar nicht so verkehrt, nur einen Thread zu verwenden, dadurch bleibt die restliche Prozessorkapazität frei für den Benutzer.

Oder wäre es Dir lieber, wenn der Rechner während eines Updates komplett blockiert, nur damit das Update schneller durch ist?
 
Naja, der Installationsvorgang läuft ja bei den Updates meistens ohne Zutun des Benutzer im Hintergrund und am Ende wird angezeigt, dass für die nächste Nacht ein Neustart geplant ist (mit der Möglichkeit direkt neu zu starten).
Wenn man also davon ausgeht, dass der Benutzer möglichst unbehelligt weiterarbeiten soll während im Hintergrund installiert wird, ist es gar nicht so verkehrt, nur einen Thread zu verwenden, dadurch bleibt die restliche Prozessorkapazität frei für den Benutzer.
Nope. Dafür gibt es die Priority... Eine Lösung aus der Zeit vor Einführung der Multiprozessor- und Multi-Core-Technologie.

Oder wäre es Dir lieber, wenn der Rechner während eines Updates komplett blockiert, nur damit das Update schneller durch ist?
Allerdings. Wie Du in dem anderen Windows-Update-Thread sehen kannst, gibt es durchaus Leute bei den das Update suboptimal durchlief. Damit Du also nicht am nächsten Morgen vor eine dysfunktionalen Kiste stehst, musst Du das Update am Vorabend unter Aufsicht durchlaufen lassen. Wenn Du der Kiste dann alle Ressourcen zur Verfügung stellst, erwartest Du sicherlich dass diese auch entsprechend genutzt werden.
 
Zuletzt bearbeitet:
Interessanter Denkansatz. Würde auch den Erfahrungen mit Microsoft entsprechen.
Wie meinst du das?

Da sind aber noch diese Aussagen von Microsoft selbst:
[Zitat]
Quelle
Das Zitat sagt nun aber mal wirklich gar nichts darüber aus, ob der Update-Vorgang von Windows mit nur einem Thread oder mit mehr Threads arbeitet...
Also werde ich in Sachen Performance schon bei der Installation im Stich gelassen... :mad:
Wenn du das so für dich definieren möchtest, von mir aus... Ich sehe da noch keine Belege, ehrlich gesagt wissen wir noch gar nichts, denn die einzige Sache, die du uns bisher verraten hast, ist die ca. 10% CPU Auslastung. Dass das nur eine einzelne Stichprobe ist und da deine Angabe "Slo-Mo" auch schwer vergleichbar bzw. in Werte zu fassen ist, können wir hier nur raten.

Naja, der Installationsvorgang läuft ja bei den Updates meistens ohne Zutun des Benutzer im Hintergrund und am Ende wird angezeigt, dass für die nächste Nacht ein Neustart geplant ist (mit der Möglichkeit direkt neu zu starten).
Wenn man also davon ausgeht, dass der Benutzer möglichst unbehelligt weiterarbeiten soll während im Hintergrund installiert wird, ist es gar nicht so verkehrt, nur einen Thread zu verwenden, dadurch bleibt die restliche Prozessorkapazität frei für den Benutzer.

Oder wäre es Dir lieber, wenn der Rechner während eines Updates komplett blockiert, nur damit das Update schneller durch ist?
Nope. Dafür gibt es die Priority... Eine Lösung aus der Zeit vor Einführung der Multiprozessor- und Multi-Core-Technologie.
Auch das hängt dann aber sehr stark vom Sheduling ab und auch ein Prozess auf geringster Priorität wird nicht komplett abgehängt, sondern eben nur geringer priorisiert. Soll heißen: Selbst wenn der Update-Vorgang auf geringster Priorität steht - wenn er gerne alle Kerne voll auslasten möchte, bekommt er trotz niedrigster Priorität noch gar nicht mal so wenig Rechenleistung ab.

Ist aber natürlich alles nur Theorie so.

Allerdings. Wie Du in dem anderen Windows-Update-Thread sehen kannst, gibt es durchaus Leute bei den das Update suboptimal durchlief. Damit Du also nicht am nächsten Morgen vor eine dysfunktionalen Kiste stehst, musst Du das Update am Vorabend unter Aufsicht durchlaufen lassen. Wenn Du der Kiste dann alle Ressourcen zur Verfügung stellst, erwartest Du sicherlich dass diese auch entsprechend genutzt werden.
Und was möchtest du dabei beaufsichtigen? Währenddessen kannst du eh nichts ändern. Nur hinterher, falls was "kaputt geht".
 
Ist die Installation nun durchgelaufen?

Bisher sieht es bei mir nach eher unproblematischen Updates aus. Das hat sogar einige Wehwehchen behoben und soweit ich sehe keine neue verursacht.
 
Ist die Installation nun durchgelaufen?
Ja.

Das Zitat sagt nun aber mal wirklich gar nichts darüber aus, ob der Update-Vorgang von Windows mit nur einem Thread oder mit mehr Threads arbeitet...
Lies es einfach solange, bis Du es verstanden hast: Microsoft verspricht Leistung, wenn man sie braucht!


Ich sehe da noch keine Belege, ehrlich gesagt wissen wir noch gar nichts, denn die einzige Sache, die du uns bisher verraten hast, ist die ca. 10% CPU Auslastung. Dass das nur eine einzelne Stichprobe ist und da deine Angabe "Slo-Mo" auch schwer vergleichbar bzw. in Werte zu fassen ist, können wir hier nur raten.
Die Hardware brauchst Du nicht zu erraten, denn die wurde bereits oben angegeben. Für die Messwerte reicht der Taskmanager - bevor Windows anfängt mit den Murmeln zu spielen.


Auch das hängt dann aber sehr stark vom Sheduling ab und auch ein Prozess auf geringster Priorität wird nicht komplett abgehängt, sondern eben nur geringer priorisiert. Soll heißen: Selbst wenn der Update-Vorgang auf geringster Priorität steht - wenn er gerne alle Kerne voll auslasten möchte, bekommt er trotz niedrigster Priorität noch gar nicht mal so wenig Rechenleistung ab.
Wenn die CPU von Prozessen mit höherer Priorität nicht beansprucht wird, bekommen Prozesse mit niedriger Priorität eben die Ressourcen.

Ist aber natürlich alles nur Theorie so.
Genau. Tun wir einfach mal so als gäbe es kein Multitasking.


Und was möchtest du dabei beaufsichtigen? Währenddessen kannst du eh nichts ändern. Nur hinterher, falls was "kaputt geht".
:facepalm: Echt jetzt? - Da kannst den Update-Krimskrams nochmal neu starten oder musst ggf. ein Backup zurück sichern oder glaubst Du die Kiste heilt sich selbst während Du Dir am Morgen Deinen Kaffee reinziehst?
 
Lies es einfach solange, bis Du es verstanden hast: Microsoft verspricht Leistung, wenn man sie braucht!
Ja, und was hat der Updateprozess damit zu tun, dass das System beliebigen Anwendungen Leistung geben kann, wenn Anwendungen sie anfordern? Richtig: Nix.
Mal abgesehen davon dass der Absatz auch reinstes Marketing-Sprech ist und im Kern nahezu keine Aussage liefert.

Die Hardware brauchst Du nicht zu erraten, denn die wurde bereits oben angegeben. Für die Messwerte reicht der Taskmanager - bevor Windows anfängt mit den Murmeln zu spielen.
Ich will auch keine Hardware raten. Aber die Angabe, dass die Installation in Slo-Mo durchläuft, sagt halt nix aus. Was ist Slo-Mo? Dauert sie Tage? Stunden? Minuten? Vielleicht ist das, was du also Slo-Mo empfindest, die ganz normale Dauer und alles läuft sauber durch?


Wenn die CPU von Prozessen mit höherer Priorität nicht beansprucht wird, bekommen Prozesse mit niedriger Priorität eben die Ressourcen.
Und wenn sowohl Prozesse mit hoher als auch mit niedriger Priorität gleichzeitig Ressourcen anfordern, dann bekommt auch der Prozess mit niedriger Priorität noch Ressourcen. Weniger als normal, aber er bekommt sie. Diese Ressourcen fehlen natürlich dem Prozess höherer Priorität. Auch wenn es weniger ist, als wenn der andere Prozess eine höhere Priorität hätte.

Genau. Tun wir einfach mal so als gäbe es kein Multitasking.
:facepalm: Klar haben wir hier Multitasking und Multithreading. Aber deswegen können wir nicht die Eigenschaften des Schedulers über Board werfen und nur weil wir mehr CPU-Kerne haben, kann ein Prozess nicht schneller rechnen. Dessen Aufgaben müssen dafür zwangsläufig im Algorithmus auf mehr Kerne aufgeteilt werden. Und das wiederum geht nicht mit jedem Algorithmus. Schon rein mathematisch kann man nicht alles parallelisieren.

:facepalm: Echt jetzt? - Da kannst den Update-Krimskrams nochmal neu starten oder musst ggf. ein Backup zurück sichern oder glaubst Du die Kiste heilt sich selbst während Du Dir am Morgen Deinen Kaffee reinziehst?
Ich wollte damit sagen, dass es egal ist, ob ich dabei sitze oder nicht. Entweder geht's hinterher oder nicht. Wenn nicht, muss ich mein Backup einspielen. Dafür ist es aber unerheblich, ob ich den Prozess beaufsichtigt habe.


Aber jetzt muss ich mal nachhaken: Was möchtest du eigentlich mit diesem Thread bewirken? Was ist die Antwort, die du dir erhoffst?
Ob 10% CPU-Last (waren sie nun auf Dauer so während des gesamten Vorgangs?) während des Upgrades normal sind? Ob dein Update zu langsam durchläuft (dafür müsstest du uns aber mal sagen, wie schnell es nun ging)? Oder möchtest du dich nur beschweren?
 
Ja, und was hat der Updateprozess damit zu tun, dass das System beliebigen Anwendungen Leistung geben kann, wenn Anwendungen sie anfordern? Richtig: Nix.
Der Updateprozess ist ein Prozess und wird daher durch das OS verwaltet.
Mal abgesehen davon dass der Absatz auch reinstes Marketing-Sprech ist und im Kern nahezu keine Aussage liefert.
Mal davon abgesehen sind gewisse Werbeaussagen einklagbar.

Ich will auch keine Hardware raten. Aber die Angabe, dass die Installation in Slo-Mo durchläuft, sagt halt nix aus.
Wenn Du mit den Angaben der Hardware und der Auslastung nix anfangen kannst, kann ich nichts dafür.


Und wenn sowohl Prozesse mit hoher als auch mit niedriger Priorität gleichzeitig Ressourcen anfordern, dann bekommt auch der Prozess mit niedriger Priorität noch Ressourcen. Weniger als normal, aber er bekommt sie. Diese Ressourcen fehlen natürlich dem Prozess höherer Priorität. Auch wenn es weniger ist, als wenn der andere Prozess eine höhere Priorität hätte.
Spul doch bitte nochmal zu der Stelle zurück, wo Du erklärst warum der Scheduler dem Update-Prozess keinen eigenen Kern zuweist. Sollte doch gehen, selbst wenn der Updateprozess zu 0% parallelisierbar ist oder?



Dessen Aufgaben müssen dafür zwangsläufig im Algorithmus auf mehr Kerne aufgeteilt werden. Und das wiederum geht nicht mit jedem Algorithmus. Schon rein mathematisch kann man nicht alles parallelisieren.
Es geht hier aber nicht um Notepad.exe sondern um ein Megabyte-großes File mit Dekompressionsalgorithmen.


Ich wollte damit sagen, dass es egal ist, ob ich dabei sitze oder nicht. Entweder geht's hinterher oder nicht. Wenn nicht, muss ich mein Backup einspielen. Dafür ist es aber unerheblich, ob ich den Prozess beaufsichtigt habe.
Also wenn Du am nächsten Morgen die Kiste nutzen musst, schiebst Du abends das Update an um Dich dann kurz vor Produktionsbeginn von dem Zustand der Kiste überraschen zu lassen anstatt am Vorabend sicherzustellen, dass das Update glatt durchgerlaufen ist?

Aber jetzt muss ich mal nachhaken: Was möchtest du eigentlich mit diesem Thread bewirken? Was ist die Antwort, die du dir erhoffst?
Wenn Du das Thema "Scheduler" bewältigt hast, kannst Du gern nochmal nachfragen.
 
Zuletzt bearbeitet:
Die Installationsvorbereitung läuft im Hintergrund ab und sicherlich absichtlich nicht mit vollster Priorität. Schließlich soll man nebenbei ja normal weiterarbeiten können. Die Zeit dieser Vorbereitung ist mittlerweile länger, um die Offline-Zeit zu verkürzen. Diese ist dann auf moderner Hardware mit den aktuellen Builds wirklich sehr kurz. Hier auf einem recht neuen System war das System fürs eigentliche Update acht Minuten offline.

Die Zeit zur Vorbereitung sollte daher eigentlich irrelevant sein, da man im Idealfall wenig davon mitbekommt. Ich hab nicht daneben gesessen und auf den Taskmanager gestarrt, um zu schauen, was das System genau macht, bzw. wie viele Kerne da in Benutzung sind. Weil es im Hintergrund lief, hab ich auch keine Idee, wie lange es tatsächlich gedauert hat. Generell ist zu dem Zeitpunkt aber eher I/O Last angesagt. Aufwändige Berechnungen finden bei so einem Upgrade nicht wirklich statt.

Interessant wäre an sich jetzt also nur, wie lange die tatsächliche Installation, d.h. die Offline-Zeit gedauert hat, was du ja bisher nicht verraten wolltest. Ob da nun irgendwas "schleicht" oder nicht, lässt sich sonst ja nur schlecht beurteilen. Interessant wäre es auch, wenn du während der Installation einen Blick im Taskmanager oder Ressource Monitor drauf geworfen hättest, welcher Task genau denn Last auf CPU oder Disk verursacht hat. Es soll ja auch Nicht-Microsoft-Prozesse auf solchen Systemen geben, die evtl. mal bremsen können.

Wenn ich auf meine Maschine angewiesen bin, schiebe ich Updates zumindest nicht am Release-Tag an, solange ich nicht aus irgendwelchen Gründen vom Update abhängig bin. Insofern wundert mich das Vorgehen sowieso ein wenig. Die automatische Verteilung beginnt schließlich erst ab nächster Woche und läuft dann über einen Zeitraum von Wochen oder sogar Monaten. Je nachdem, ob Probleme oder Fehler auftauchen, wird dann ja schneller oder langsamer verteilt.
 
Falsch!
Ich bin der Letzte, der Updates machen muss, aber diesmal kam das Autoupdate
schon am Release-tag.
Und abwählen geht ja nun mal nicht bei allen, zB. beim Home- Version.
 
Die Installationsvorbereitung läuft im Hintergrund ab und sicherlich absichtlich nicht mit vollster Priorität.
Also Bevormundung...?

Schließlich soll man nebenbei ja normal weiterarbeiten können.
Noe. Feierabend.

Die Zeit dieser Vorbereitung ist mittlerweile länger, um die Offline-Zeit zu verkürzen. Diese ist dann auf moderner Hardware mit den aktuellen Builds wirklich sehr kurz.
Schon mal ein Update unter Linux gemacht? - Offlinezeit = Dauer des EINES Reboots. Da gibt es keine Murmelspiele und mehrere Reboots zwischendurch.[/Quote]
Hier auf einem recht neuen System war das System fürs eigentliche Update acht Minuten offline. [/quote]
Mich interessiert nur die Gesamtzeit, da diese im Fehlerfall erneut anfällt.

Die Zeit zur Vorbereitung sollte daher eigentlich irrelevant sein, da man im Idealfall wenig davon mitbekommt. Ich hab nicht daneben gesessen und auf den Taskmanager gestarrt, um zu schauen, was das System genau macht, bzw. wie viele Kerne da in Benutzung sind. Weil es im Hintergrund lief, hab ich auch keine Idee, wie lange es tatsächlich gedauert hat. Generell ist zu dem Zeitpunkt aber eher I/O Last angesagt. Aufwändige Berechnungen finden bei so einem Upgrade nicht wirklich statt.
Hättest Du mal daneben gesessen und den Taskmanager beobachtet: Auf der Kiste bei mir lief sonst nichts. Das Update hatte die komplette Kiste für sich. Auslastung: RAM 4% (von 32GB), CPU ca. 10% (Xeon mit 4 Kernen und 3.7GHz), SSD (NVMe) 2 Bursts, sonst bei ca. 2%.

Interessant wäre an sich jetzt also nur, wie lange die tatsächliche Installation, d.h. die Offline-Zeit gedauert hat, was du ja bisher nicht verraten wolltest.
Wie bereits oben geschrieben ist die reine Offlinezeit irrelevant.

Ob da nun irgendwas "schleicht" oder nicht, lässt sich sonst ja nur schlecht beurteilen.
Mehr als die Uhr kannst Du also nicht ablesen oder warum kannst Du mit der Auslastung nichts anfangen?

Interessant wäre es auch, wenn du während der Installation einen Blick im Taskmanager oder Ressource Monitor drauf geworfen hättest, welcher Task genau denn Last auf CPU oder Disk verursacht hat. Es soll ja auch Nicht-Microsoft-Prozesse auf solchen Systemen geben, die evtl. mal bremsen können.
Es soll auch Leute mit Schwierigkeiten beim Textverständnis haben - sowohl online als auch offline: Es waren Kerne frei.

Wenn ich auf meine Maschine angewiesen bin, schiebe ich Updates zumindest nicht am Release-Tag an, solange ich nicht aus irgendwelchen Gründen vom Update abhängig bin. Insofern wundert mich das Vorgehen sowieso ein wenig. Die automatische Verteilung beginnt schließlich erst ab nächster Woche und läuft dann über einen Zeitraum von Wochen oder sogar Monaten. Je nachdem, ob Probleme oder Fehler auftauchen, wird dann ja schneller oder langsamer verteilt.
Wie wirkt sich das auf die Zeit für die Installation aus?
 
Also Bevormundung...?
Nö, schlicht und einfach eine pragmatische Geschäftsentscheidung von Microsoft, um möglichst wenig Beschwerde-Calls zu bekommen.
Die paar einzelnen Benutzer, denen das nicht schnell genug geht, waren hier wohl weniger relevant.
 
Die paar einzelnen Benutzer, denen das nicht schnell genug geht, waren hier wohl weniger relevant.
"Geduld ist eine Zier, doch weiter kommt man ohne ihr" - leider scheinen das zu viele zu ihrem Lebensinhalt zu machen.

Aber warten wir mal ab: MS hat sich ja eine zweite Chance gegeben, da das Upgrade auf 1809 zurück eben gezogen wurde.
 
Ach, das 1809 den Ordner "Eigene Dateien" löscht war ein Bug und kein Feature? ;-)
Das Update lief glatt durch, die Files waren glatt weg. Das ist besonders praktisch wenn man das erst kurz vor Arbeitsbeginn feststellt (weil die Kram über nacht lief) und der Schaden aus der eigenen Tasche finanziert werden muss.

Nicht nur dass QM bei Mickeysoft einen Bug hat, auch die Windows-Anhänger, die für diesen Sh*t nicht nur bezahlen, sondern sich neuerdings auch noch Werbung auf's Auge drücken lassen.
 
Wenn Windows für Dich so schrecklich ist, dann installiere halt ein Linux oder kaufe einen Mac oder ein Chromebook.

Alternativ könntest Du auch etwas warten, bevor Du ein Update installierst - es gibt ja keine Notwendigkeit gleich an Tag 1 zu installieren, und auf die Weise sinkt die Wahrscheinlichkeit, Opfer eines vorher übersehenen Bugs zu werden.

Wenn Du nicht auf die Installation warten willst, dann starte sie eben zu einem Zeitpunkt, wo es egal ist wie lange es dauert.

Und vor einem größeren Update ein Backup zu machen war auch noch nie eine schlechte Idee.
 
Zuletzt bearbeitet:
Generell gibt mir Windows Update Rätsel auf.

Warum dauert das so lange? Wenn ich da mit Linux vergleiche, wundere ich mich wie man eine Sache so vermasseln kann. Liste aller verfügbaren Updates herunterladen, sie mit den installierten Paketen vergleichen und die fehlenden plus zusätzlich notwendig gewordenen Abhängigkeiten herunterladen.

Ich erinnere mich noch an Windows 7 Installation. Windows 7 in weniger als einer Stunde neu aufgesetzt, einen Tag bis alle Updates gefunden und installiert wurden. Am nächsten Tag muss man evtl. weitere Updatedurchgang ausführen weil die Updates weiter Updates benötigen.

Oder man startet eine Anwendung, sieht, dass sich das hinzieht, lässt den Rechner an und geht nach Hause/Urlaub/Wochenende... Dann kommt man wieder und bemerkt, dass der Rechner im Leerlauf dahindümpelt weil er nach Update neu gestartet ist evtl. sogar nachdem man gesagt hat, nein, ich will nicht wg. Update neu starten.

Ich sehe ja, dass Windows nicht ohne Grund seinen Marktanteil erkämpft hat. Aber tragen diese Unzulänglichkeiten wirklich zum angenehmeren Nutzererlebnis bei oder ist dieser Mechanismus einfach kaputt?

Kurzum, wenn es keine zwingenden Gründen gibt, dann wünsche ich mir auch ähnlich angenehme Updateerfahrung wie bei Linux.

So schnell, dass man nicht mit Jobscheduler herumfummeln muss, um den Rechner dabei nutzbar zu halten.
 
Das Thema gibt's bei Windows 10 so nicht mehr - die aktuelle Basisversion ist max 0,5 Jahre alt, die Anzahl der zu installierenden Updates hält sich entsprechend in Grenzen. Und im Normalfall sieht es so aus, dass einem der Rechner irgendwann sagt, dass Updates vorbereitet sind und für die nächste Nacht ein Neustart eingeplant wurde. Viel hat man damit nicht zu tun, und vom nächtlichen Neustart bekommt normalerweise auch nicht viel mit, insofern halte ich das nicht für ein großes Problem.

Bei Windows 7 war es tatsächlich nervig, aber das zumindest für mich Schnee von (vor)gestern.

Außerdem muss man auch dazu sagen, dass man mit Windows 7 einen Rechner von 2009 bis heute ohne Neuinstallation nur mit Updates betreiben konnte und bis heute supported ist und so gut wie alle Software verwenden kann - ich bin mir nicht sicher, ob das mit einem Linux so problemlos gegangen wäre.
 
Zuletzt bearbeitet:
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben