News Windows K2: Microsoft plant grundlegende Änderungen für Windows 11

Im Mittelpunkt stehen drei Bereiche: Leistung, Zuverlässigkeit und Bedienung.
Die Leistung an sich ist nicht schlecht. Die Leistung der Komponenten. Ja. Der Explorer ist eine Katastrophe. Hausgemacht. Lazy Loading löst nicht das Problem, dass es langsam ist. Das Startmenü ist eine Katastrophe. Dieses blöde Laden von Einträgen. Ich will nicht warten. Ich eine bekannte Anwendung starten.
Der Taskmanager hat inzwischen auch Ladezeiten. Früher mal als Tool entwickelt, um ein ohnehin sehr gestresstes Betriebssystem nicht noch mehr zu belasten, ist es er heute quälend langsam.
Die Zuverlässigkeit... naja im normalen Betrieb schmiert mir am häufigsten der Grafiktreiber ab. Das OS läuft weiter. Aber die Geschichten mit den kaputten Updates oder optimistischen Buttons, die erst mal bestätigen, was man wollte und dann doch wieder zurückspringen, geht mir wirklich auf den Nerv.
Bedienung... Gewollt versteckt man ja immer mehr vor dem Benutzer. Gewollt macht man alles einfacher. Diese zerrissene Konfiguration von Netzwerkgeräten ist von der Bedienung her auch wieder eine Katastrophe. Das Netzwerk und Freigabecenter wird gefühlt immer schwieriger über das Startmenü auffindbar. So ganz glücklich bin ich darüber nicht. Es gibt Vorteile mit den neuen Netzwerkprofilen, aber irgendwie gehen auch Möglichkeiten verloren.
Microsoft setzt verstärkt auf WinUI 3, um Systembereiche zu vereinheitlichen und Eingaben schneller zu verarbeiten. Davon könnten vor allem Startmenü und Taskleiste profitieren.
Wie gerade schon diskutiert, ist WinUI sicherlich nicht die Rettung. Es mag mächtig sein, native Skalierung unterstützen usw. Aber wir haben mit Windows Forms auch ewig gearbeitet und gute und mächtige Anwendungen gehabt. Dieses ganze Spacing und Touch Freundlichkeit sind ein Balanceakt zwischen Informationsmenge und Touchfreundlichkeit.

Diese sollen künftig die Entwicklung stärker bestimmen als neue Funktionen in kurzen Abständen.
Features! Features! Features! Ich kenne es eigentlich kaum noch anders. Aus Scrum und anderen agilen Vorgehen habe ich schon entnommen, dass Entwickler Probleme bekommen, Dinge vorzustellen, die für nicht-Tech Leute und Geldgeber verständlich oder sinnvoll erscheinen. Ständig Diskussionen, dass man sich erst einmal seinen Arbeitsort und sein Werkzeug herrichten, warten und auch reinigen muss. Ein universelles Problem: Wartung und Reinigung. Egal ob Fahrzeuge oder Werkzeuge. Das gibt es auch für Software. Sonst müllt man sich zu und blickt nicht mehr durch.
Solche Phrasen, dass die Entwickler mehr Einfluss bekommen, haben sich meines Wissens immer nur als kurzweilige Lösung dargestellt. Oftmals wird man dann doch wieder bedrängt oder es wird anderweitig Kontrolle ausgeübt, weil etwas nicht passt. Habe ich alles schon erlebt. Dass ein Vorgehensmodell final gescheitert ist, merkt man daran, dass eine Sonderrolle geschaffen wird, die einfach alles andere überstimmen kann. "Qualität" passt nicht. "Tja, eure Features müssen warten. Entwickler macht mal Qualität!" Naja. So könnte es klingen. Aber man kann ja nicht die Leute verprellen, nur weil der Betrieb brennt. Wir müssen ja Feature X abliefern. Also nur ein bisschen mit dem Hammer schlagen und es ist immer noch alles scheiße.

Ein Schwerpunkt liegt auf der Systemleistung. Interne Analysen sollen gezeigt haben, dass zentrale Komponenten wie Datei-Explorer und Teile der Oberfläche nicht durchgehend die erwartete Reaktionsgeschwindigkeit erreichen.
Durchaus angenehm zu lesen. Schlecht für meine Argumentation, dass die Administration das System mit irgendwelchen Bloat verlangsamt, aber immer hin gute Munition um die Performance anzusprechen.


Zusammengefasst: Leere Worthülse. Nichts wird sich ändern. Man versucht nur die Leute/Admins wieder einzufangen, die nach alternativen Suchen und vielleicht auch finden. Ein "Microsoft hat gesagt, die machen es jetzt besser" mag vielleicht noch mal etwas Zeit verschaffen mehr M365 in die Unternehmen zu drücken, damit man weiterhin Geld scheffeln kann, auch wenn die Leute dem Betriebssystem gerne den Rücken kehren (würden).
 
Wie synchronisiert das die Framebuffer?

Ich hoffe mein Text bringt etwas Klarheit :ugly:

TLDR: Kurz gesagt: Shared Memory über PCIe mit digitaler handshake-sync

Die Nvidia-Karte oder AMD-Karte rendert das Bild in einen geteilten Speicherbereich (DMA-BUF). Über den PCIe-Bus wird dieser Puffer mit der Intel-iGPU synchronisiert. Ein System aus digitalen Wartesignalen (Fences) sorgt dafür, dass die Intel-iGPU erst dann auf den Speicher zugreift, wenn die Nvidia-Karte den Schreibvorgang abgeschlossen hat, die gibt quasi bescheid, bild fertig, kannste haben. Der Compositor setzt das Ganze dann am Ende auf dem Bildschirm zusammen. Kompliziert, daher auch so schwer hinzubekommen :-)


1. Rendering auf der GPU
Wenn ein Spiel startest (z. B. via __NV_PRIME_RENDER_OFFLOAD=1), erstellt die Nvidia-GPU das Bild in ihrem eigenen VRAM. Da sie aber keinen "Ausgang" zum Monitor nutzt und expliziet ein VERBOT hat, ein Bild auszugeben (das muss verboten werden sonst krallt sich der Desktop, oder die Apps sofort die schnelle GPU) fungiert sie rein als Render-Offload-Device!

2. Rendering Export in den Buffer
Anstatt das fertige Bild mühsam über die CPU von einem Speicher in den anderen zu kopieren (was extrem langsam wäre), nutzt Linux das DMA-BUF-Framework.
- Die Nvidia-Karte schreibt den Frame in einen Puffer.
- Dieser Puffer wird direkt im Kernel als "File Descriptor" freigegeben.
- Die Intel iGPU kann nun direkt auf diesen freigebeben Speicherbereich zugreifen, ohne dass die Daten den erst den Umweg über die CPU machen müssen.

3. Sync
Damit die Intel oder AMD CPU iGPU nicht versucht, ein Bild anzuzeigen, das die Nvidia-Karte noch nicht fertig berechnet hat, kommen Sync-Fences (Zäune) zum Einsatz (da bin ich aber nicht so Tief in der Materie)
- Implicit/Explicit Sync: Die Nvidia-GPU setzt ein Signal ("Fence"), wenn der Frame fertig ist.

Erst wenn dieses Signal "signaled" ist, greift die Intel/AMD-iGPU (der Display Controller) zu und schickt die Daten an deinen Monitor.

4. Ausgabe
Es gibt zwei Standard-Display-Server, X-Org (veraltet) und Wayland (Neu aber oft Problematisch).
Der Display Server sorgt dafür dass du ein Bild bekommst, ohne das gibt es keine Grafische Oberfläche.

Vereinfacht gesagt, der Compositor (z. B. Mutter (gnome) oder KWin (KDE)) weiß genau, dass das Fenster von der Nvidia-Karte kommt. Er nimmt den DMA-BUF der Nvidia-Karte und "komponiert" ihn zusammen mit deinen restlichen Fenstern (die von der Intel iGPU gerendert werden) in den finalen Framebuffer.
 
@Terence-Hill verstanden ... das war schon immer der Plan für meinen 7800X3D, unter Windows ist das aber nicht ganz trivial! Bzw war es als ich den Rechner aufgebaut hatte (2023)

Wie taktet deine 4090, wenn kein Display angeschlossen ist? Geht die komplett in Standby (0W) oder ist das eher ein Idle bei 30W?
 
Breaking News

Sie werden es nicht für möglich halten. Eine Firma arbeitet daran, ihr Produkt zu verbessern.

1777559712922.jpeg
 
Warum nehmen die nicht einfach nen Linux Kernel und passen KDE entsprechend an? Da man den Windows Kernel ja kennt, könnte man eine entsprechende Wine oder Proton Schicht einbauen, mit der sämtliche Windows Programme von mir aus exklusiv funktionieren.

Was die jetzt vorhaben ist sicher nicht weniger aufwändig und wird eh nicht funktionieren. Die Altlasten sind einfach zu groß und der Windows Kernel nicht sauber strukturiert.
 
@Terence-Hill verstanden ... das war schon immer der Plan für meinen 7800X3D, unter Windows ist das aber nicht ganz trivial! Bzw war es als ich den Rechner aufgebaut hatte (2023)

Wie taktet deine 4090, wenn kein Display angeschlossen ist? Geht die komplett in Standby (0W) oder ist das eher ein Idle bei 30W?

Die schwankt zwischen min: 18 und max:28 Watt (die MSI hat einen sehr hohe Idle verbrauch) ASUS und andere Karten liegen bei 8-18 Watt.

Leider geht 0 Watt nicht (nie) da die Grafikkarte immer mit Stromversorgt wird sobald sie im PCIe Slot stecjt (PCIe-Subsystem)

Sie befindet sich im Powerstate 8, bedeutet GPU ist im Leerlauf und wartet.

Wie du im Screenshot sehen kannst, hat sie nichts zu tun, kein Prozess ist ihr zugeordnet

nvidia_4090_smi_Screenshot_20260430_181553.png
 
Es klingt erstmal so als ob man tatsächlich aus den Fehlern lernen will. Bin aber skeptisch ob das wirklich was wird.
Die Suchfunktion in der Taskleiste ist richtig schlecht, im Explorer unfassbar langsam und findet auch nicht immer alles. Hoffe dass das besser wird.
Ich hoffe dass die mit vereinheitlichung der Systembereiche auch endlich mal die Systemsteuerung und Einstellungen konsolidieren. Es ist mir ein Rätsel wie das Win10 überleben und dann noch in den Nachfolger schaffen konnte.
 
Etwas späte Einsicht von Microsoft, da Windows 11 schon seinen zeitlichen Zenit überschritten hat.
Windows K2, alles klar: Der Berg ruft...😜
 
So etwas gibt es bereits bspw. unter Linux Mint. Nicht nur kann mensch dort manuell den Zeitpunkt von Updates bestimmen sondern mensch kann per Mausklick auch einzeln auswählen, was geupdated werden soll. Desweiteren helfen die Anzeige von Namen der Programmteile und Updateart (Versionsupgrade oder Sicherheitsupdate) bei der Einordnung. So können fremdbestimmte Neustarts inmitten der Nutzung vermieden werden. Alles also kein Neuland und keine Raketentechnik. :daumen:
Um ehrlich zu sein, wusste ich das bisher nicht, aber ich kann mit Linux noch nicht viel anfangen. Das könnte sich jedoch ändern, wenn valve mit ihrem Betriebssystem startet, da ich sehr viel Multiplayer spiele. :)

lg
 
Es freut mich wiederum, Dir etwas neues mitgeteilt zu haben. :) Für mich ist das seit 2018 unter Linux Mint Standard. Windows hatte ich zu der Zeit parallel noch genutzt. Es trieb mich anhand der Upgrades manchmal fast zur Weißglut, wenn bspw. Einstellungen verändert waren oder deinstallierte Programme wieder installiert waren.
 
Das könnte sich jedoch ändern, wenn valve mit ihrem Betriebssystem startet, da ich sehr viel Multiplayer spiele.
Ich verstehe nicht warum du hier auf SteamOS für den PC warten willst, das Kernel Level AntiCheat Problem wird wohl auch nicht Valve beheben das liegt an den Herstellern selbst und selbst wenn es eine Lösung dafür geben wird so wird es wohl nicht SteamOS exklusiv sein.
 
Ich verstehe nicht warum du hier auf SteamOS für den PC warten willst, das Kernel Level AntiCheat Problem wird wohl auch nicht Valve beheben das liegt an den Herstellern selbst und selbst wenn es eine Lösung dafür geben wird so wird es wohl nicht SteamOS exklusiv sein.
Anti-Cheat soll darauf laufen, hatte ich mal gelesen. Müsste mal schauen, wo genau. Wenn ich es finde, poste ich es hier sehr gerne.

LG
 
Anti-Cheat läuft auch unter jedem anderen Linux. Nur eben die Kernelbasierten Anti-Cheats nicht. Und die werden dann auch unter Steam-OS nicht funzen, da auch Steam-OS ein Linux ist.
 
Zurück