News Windows 11: Task-Manager zeigt neue Details zu Laufwerken im aktuellen Beta-Build an

PCGH-Redaktion

Kommentar-System
Teammitglied
Bislang zeigt der Task-Manager von Windows 11 im Reiter "Leistung" für Massenspeicher nur an, ob es sich um eine SSD oder eine HDD handelt. In einer Beta-Version wurde eine Funktion gesichtet, die auch den Bus-Typ anzeigt.

Was sagt die PCGH-X-Community zu Windows 11: Task-Manager zeigt neue Details zu Laufwerken im aktuellen Beta-Build an

Bitte beachten: Thema dieses Kommentar-Threads ist der Inhalt der Meldung. Kritik und allgemeine Fragen zu Online-Artikeln von PC Games Hardware werden hier gemäß der Forenregeln ohne Nachfrage entfernt, sie sind im Feedback-Unterforum besser aufgehoben.
 
Naja, nettes kleines Gadget, mehr nicht. Jedenfalls noch lange kein Grund für mich, eventuell vom Windows 10 Taskmanager auf den von Windows 11 umzusteigen.
Hat Linux auch so etwas?
 
Da ich meinen PC selber zusammengebaut habe, weiß ich auch, wo und wie ich welche SSD angeschlossen habe.
Für Leute, die ihren Fertig-PC aus'm MediaMarkt oder von Aldi analysieren wollen, mag das Feature sinnvoller sein.
Aber immerhin, kommen sie jetzt drauf, den Taskmanager auch sinnvolle Dinge anzeigen zu lassen... wenn ich da noch an Win95 bis Win7 zurückdenke... hier sehen sie die Größe ihrer Auslagerungsdatei. :klatsch:
 
Das Bild zeigt eine SSD im ATA Modus an?
Ja, ATA.
Eine andere hat SATA stehen, die Anzeige ist also nicht ein Bug, oder?
Also ich habe noch 1 oder 2 funktionierende Platten für ATA rumliegen, falls die jemand haben will. :-)
 
Ich schätze mal, dass der physische "SATA"-Anschluss hier synonym für das AHCI-Protokoll genutzt wird, während "ATA" tatsächlich ein Laufwerk gemäß ATA-Standard bezeichnet (unabhängig davon, ob physisch als IDE/PATA umgesetzt oder ein SATA ohne AHCI-Nutzung). Bei allen älteren Schnittstellen ist ein Controller im Spiel und Microsoft müsste die physische Verbindung erst auslesen respektive eine große Datenbank mit Controllerinformationen hinterlegen, um IDE/SATA/M.2/U.2/verschiedene SCSI-Generationen/... unterscheiden zu können. Für die Ansteuerung interessiert Windows nur ATA(-PI), AHCI, NVME, SCSI und ggf. direkt PCI-E via Option-ROM und proprietären Treiber.

Es bleibt zu hoffen, dass man die Bezeichnungen bis zur Veröffentlichung vereinheitlicht und nicht weiter Protokolle und Schnittstellen mischt. Andererseits reden wir hier von einer Firma, die seit rund einem Jahrzehnt keine einheitliche Oberfläche für Einstellungen hinbekommt und die seit vier Jahrzehnten mit Mebi-/Gibibyte rechnet, aber Mega-/Gigabyte hinter die Zahlen schreibt.
 
Ich schätze mal, dass der physische "SATA"-Anschluss hier synonym für das AHCI-Protokoll genutzt wird, während "ATA" tatsächlich ein Laufwerk gemäß ATA-Standard bezeichnet (unabhängig davon, ob physisch als IDE/PATA umgesetzt oder ein SATA ohne AHCI-Nutzung). Bei allen älteren Schnittstellen ist ein Controller im Spiel und Microsoft müsste die physische Verbindung erst auslesen respektive eine große Datenbank mit Controllerinformationen hinterlegen, um IDE/SATA/M.2/U.2/verschiedene SCSI-Generationen/... unterscheiden zu können. Für die Ansteuerung interessiert Windows nur ATA(-PI), AHCI, NVME, SCSI und ggf. direkt PCI-E via Option-ROM und proprietären Treiber.

Es bleibt zu hoffen, dass man die Bezeichnungen bis zur Veröffentlichung vereinheitlicht und nicht weiter Protokolle und Schnittstellen mischt. Andererseits reden wir hier von einer Firma, die seit rund einem Jahrzehnt keine einheitliche Oberfläche für Einstellungen hinbekommt und die seit vier Jahrzehnten mit Mebi-/Gibibyte rechnet, aber Mega-/Gigabyte hinter die Zahlen schreibt.
Alles halt in micro soften Schritten Stück für Stück behutsam nach vorne blicken. ^^

Dazu passt dann wohl auch, dass man schon wieder 650 Spielentwickler entlässt, um Spiele dadurch noch besser zu machen.
Das Musk man sich mal vorstellen, wie das sinnvoll und volkommen logisch erscheint. ^^
 
Andererseits reden wir hier von einer Firma, die seit rund einem Jahrzehnt keine einheitliche Oberfläche für Einstellungen hinbekommt
Die wissen halt selber nicht, wie sie aus dem Dilemma kommen sollen, dass die alte Edge-Engine für die Einstellungsoberflächen notwendig ist, aber der Browser selber gefloppt ist und auf Chromium umgestellt wurde.
Nun muss man den Unterbau des alten Edge weiter mitschleppen, um die Einstellungsapp darzustellen. Zurückrudern geht jetzt nicht mehr und weiterbasteln ist umfangreicher, als man vermutet hatte.
Selbst die vollständige Umstellung von NT auf den neuen Win95-Desktop hat inklusive aller neuen Elemente(z.B. Gerätemanager)nur 4 Jahre gedauert(bis Windows 2000 erschien).
die seit vier Jahrzehnten mit Mebi-/Gibibyte rechnet, aber Mega-/Gigabyte hinter die Zahlen schreibt.
Die meisten Informatiker gehen traditionell immer vom Binärsystem aus, wenn da von Bit oder Bytes die Rede ist, auch wenn da nur Prefixe aus dem Dezimalsystem stehen. Einzige wirkliche Ausnahme sind physikalische Aspekte, wie Datenübertragungsraten, wo man aber auch nicht mehr auf der logischen Ebene ist. Genormt wurde das ganze auch erst um den Jahrtausendwechsel, also nachdem es Jahrzehnte Usus war, da normale Dezimalprefixe zu nutzen.

Natürlich ist das unsauber, gerade wenn Laien dazustoßen(z.B. bei der Festplattenkapazität), aber es gibt da schlimmere Baustellen. Verantwortlich für den Unmut sehe ich da eher das Marketing der Speicherhersteller die wahlweise 1TB,1TiB,1024GB,1000GiB usw. drauf schreiben, je nachdem was man gerade für Chips auf der Resterampe zusammenstellen kann, Hauptsache die Zahl ist werbewirksam, groß und die Kapazität rechtssicher angegeben; den Rest regelt der Controllerchip. Dieses Verwirrspiel wird auch mit der Umbenennung im Betriebssystem wohl kaum enden. Die Speicherverkäufer können froh sein, dass der Schwarze Peter momentan bei M$ liegt.
 
Detaillierte Werte von CPU, Ram, GPU, SSDs/HDDs Auslastungen und Temperaturen wären gut. Und Lüfterdrehzahlen.
Als Echtzeitanzeige/Widget.
Ich weiß das die auch von Drittanbietern gibt.
Können aber zu Instabilitäten führen.
 
Die meisten Informatiker gehen traditionell immer vom Binärsystem aus
Und der ganze, große Rest?
Oder ganz einfach: was spricht neben der Tradition* denn dafür, dass beim aktuellen Nvidia-Treiber 659 M(fehlendes i)B (691.044.472 Bytes) geschrieben steht statt 691 MB?

*Tradition: Unfug, der nur gemacht wird, weil er schon immer so gemacht wurde. :rollen:


Darauf hoffen, dass MS eine Option einbaut, braucht man aus offensichtlichen Gründen ja auch nicht. :daumen2:
 
Die wissen halt selber nicht, wie sie aus dem Dilemma kommen sollen, dass die alte Edge-Engine für die Einstellungsoberflächen notwendig ist, aber der Browser selber gefloppt ist und auf Chromium umgestellt wurde.
Nun muss man den Unterbau des alten Edge weiter mitschleppen, um die Einstellungsapp darzustellen. Zurückrudern geht jetzt nicht mehr und weiterbasteln ist umfangreicher, als man vermutet hatte.
Selbst die vollständige Umstellung von NT auf den neuen Win95-Desktop hat inklusive aller neuen Elemente(z.B. Gerätemanager)nur 4 Jahre gedauert(bis Windows 2000 erschien).

Die Render-Engine einer Benutzeroberfläche hat doch wenig mit deren Inhalt zu tun. Sowohl Edge als auch die alte IE-Engine als auch Chromium kann alles darstellen, was für eine Systemsteuerung nötig ist. In welchem Format Microsoft diese umsetzt, ist vollkommen egal. Das Problem ist, dass sie sie gar nicht umsetzen respektive nicht wissen, was sie eigentlich darstellen wollen.

Die meisten Informatiker gehen traditionell immer vom Binärsystem aus, wenn da von Bit oder Bytes die Rede ist, auch wenn da nur Prefixe aus dem Dezimalsystem stehen. Einzige wirkliche Ausnahme sind physikalische Aspekte, wie Datenübertragungsraten, wo man aber auch nicht mehr auf der logischen Ebene ist. Genormt wurde das ganze auch erst um den Jahrtausendwechsel, also nachdem es Jahrzehnte Usus war, da normale Dezimalprefixe zu nutzen.

So einfach ist es nicht. Microsoft schreibt ja nicht nur die falsche Einheit hinter Datenspeichergrößen, sondern Microsoft schreibt auch die falsche Zahl vor andere Angaben, die tatsächlich in binärer Stückelung auftreten, beispielsweise beim RAM: Wenn die Zahl "32.768" lautet, dann ist Microsofts "32.000" oder "32 k" die falsche Anzeige. Durch Runden könnte man noch auf "~33 k" kommen, Microsoft macht aber selbst aus 65.536 GiB ein "64 GB". Dabei kennt man Nachkommastellen sehr wohl, so werden 1.440 KiB zu "1,44 MB" – obwohl 1.474.560 Byte entweder "~1,41" MiB" oder "~1,47" MB sind, aber nie "1,44". Und nein, auch in anderen Zahlensystemen ist Microsofts Größenverschleierungssystem nicht naheliegend, sondern komplex: HEX 16.8000 (DEC 1.474.560) ist nicht im geringsten mit HEX 15.F900 (=DEC 1.440.000) verwandt und es gibt keinen einfachen Weg um von HEX 8000 (DEC 32.768) auf HEX 7D00 (DEC 32.000) oder HEX 0020 (DEC 32) zu kommen. Selbst im Binärformat, wo Größenordnungsänderungen eigentliche simple Bitshifts sind, muss man einen solchen nicht nur um eine "krumme" Anzahl von Stellen (BIN 1010) durchführen, sondern dann auch noch das letzte Bit wegwerfen, um von DEX 65.536 auf DEC 64 zu kommen.

Ich kann nur spekulieren, wie sich diese Firmentradition herausbilden konnte. Entweder hat man Ende der 70er Jahre in der Bay Area große Menge Hinterlassenschaften der 69er-Ära verbrauchen müssen oder da hat jemand die Buchhaltung optimiert. Ob es nun ein Angestellter war, der sein "32 k"-Jahresgehalt in 12× 2.730,67 USD hat auszahlen lassen oder ob Bill umgekehrt abgesprochene 32.768 USD als 32-durch-12-pro-Monat hinterlegt hat, bleibt offen. Aber wer auch immer diesen Code geschrieben hat, hatte (temporär) kein Interesse an korrekten Ausgaben und wer auch immer das mitgemacht hat, hatte (temporär) kein Verständnis für Grundrechenarten. Und alle anderen haben bis heute den Salat.
 
Berechtigte Korrektur, wobei ich zwei andere Fehler gemacht habe: Wo Seattle liegt, wusste ich schon. Aber ich dachte die Arbeiten an DOS wären noch am ursprünglichen Firmensitz erfolgt. Aber Wiki sagt, der Umzug war doch schon 79, bevor QDOS eingekauft wurde (zu meinem Leidwesen in Seattle entwickelt) und selbst wenn ich mit dem Datum richtig gelegen hätte, wäre die Gründung nicht im Silicon Valley, sondern in New Mexico erfolgt. :-(
 
Zurück