News Windows-Subsystem für Linux: Kompatibilitätsschicht und deren GUI erhalten ein Update

LEDs schrieb:
@Dark Soul das ist doch genau das was ich meinte man möchte die Entwickler bei M$ halten.
Jeder Entwickler nutzt sein bevorzugtes OS - egal für was er entwickelt. Bei mir ist es halt Windows, und das obwohl ich meistens für Linux entwickle ;) Und das eben nun per WSL.

Es ist ja auch nicht so, dass man sich einen Windows Server anschafft, WSL laufen lässt und dann Linux Programme ausführt - wäre ja total unsinnig. Man entwickelt also schön für einen Linux Server auf der eigenen Windows Kiste. So braucht man keine SSH Verbindung zu einem Testserver ;) Und das egal ob kompiliert: C, C++ --> VS + remote gcc mit gdb als debugger oder interpretiert zb Python in einem Linux conda environment --> VSCode & WSL Integration für den Interpreter :)

0xffffffff schrieb:
WSL (besser gesagt WSL2) ist super, nutze das im Beruf seit Jahren. Privat aber nicht, denn:

Kennt jemand zufällig Benchmarks o.ä. inwieweit man bei der Aktivierung von WSL2 Geschwindigkeitseinbußen bei Spielen hinnehmen muss? Wenn man WSL2 nutzen möchte, wird Hyper-V aktiviert und damit auch das Windows-System quasi über eine Virtualisierungssicht ausgeführt.

Verhält sich Windows 10 da wie Windows 11 mit aktivem "Hypervisor-Protected Code Integrity" (HVCI)? Weiß das zufällig wer?
Dave Plummer - ehemaliger Entwickler von MS und der Vater des Task Manager und der ZIP integration im Windows Explorer - hat vor kurzem Benchmarks gemacht :)
Daves Garage - Win vs Linux
 
  • Gefällt mir
Reaktionen: IllusionOn, 0xffffffff und DerMonte
Steiner111 schrieb:
Lohnt sich programme vob linux auf Windows laufen?
Es lohnt sicher sicherlich nicht Firefox als Linux App auf Windows 11 zu installieren - auch wenn das natürlich geht.
Aber gerade bei Entwickler-Tools liefert Linux oft bessere Tools oder zumindest angenehm zu nutzende also die Windows Pendats - obwohl das auch schon besser wurde.

Ich erinner emich noch an Zeiten wo ich für GIT und SSH unterschiedliche Terminal offen haben musste, weil das in Windows integrierte Terminal nicht konnte und beides Drittanbieteranwendungen waren.
sikarr schrieb:
Aber da wird man wohl kaum WSL einsetzten, da kann man direkt nativ zur Linux-VM greifen wenn man das braucht?
Der Vorteil von WSL ist halt, dass du innerhalb von dem Linux direkt Zugriff auf die Dateien vom Host System hast.
Und das z.b. die App Icons von Linux-Apps direkt im Startmenü sind, etc
Bei einer klassischen Virtualisierung ist das kaum möglich oder nur mit massiv grossem Konfigurationsaufwand.
Der Puritaner schrieb:
Wie wäre denn mal ein Windows-Subsystem für Linux, oh hört auf mich steinigen zu wollen :grr:
Wäre Cool.
jonderson schrieb:
Ich finde diese Frage gar nicht so Gagartig, da ich tat sächlich nicht verstehe wieso man WSL so feiert.
Alle Nachteile von Windows nimmt man mit WSL mit.
Aber auch alle Vorteile. Wenn du z.b. eine GUI Entwickeln musst die in Adobe XD Design wurde oder du mit Visual Studio arbeiten musst, etc - so kannst du das direkt auf dem Rechner öffnen und nutzen.
mae schrieb:
Ich denke, die koennten das genauso gut (oder besser) als Libraries auf einem Linux-Kernel implementieren, so wie das auch Wine macht.
ist im Grunde ein bisschen das, was WSL1 war und auch das hatte einige Probleme ähnlich wie Wine sie hat. Virtualisierung braucht zwar mehr Ressourcen, hat aber den Vorteil das es funktioniert.
 
mae schrieb:
Offenbar sieht Microsoft einen Wert im eigenen Kernel, der die Kosten rechtfertigt.
Die Architektur von Linux und Windows passt einfach nicht zusammen.

Das sieht man daran, dass WSL1 einige Macken hat, manches sehr langsam (anderes dafür schneller) ist und manches nicht funktioniert.
 
@kim88 also eher für entwickler gedacht, als für endnutzer gedacht?
Mir fällt jetzt keine anwendung/Programm ein, was ich von Linux auf Windows laufen lassen möchte, aber sehr viele Anwendungen/Programme von Windows auf Linux
 
kim88 schrieb:
ist im Grunde ein bisschen das, was WSL1 war und auch das hatte einige Probleme ähnlich wie Wine sie hat.

Ein grosses Problem von WSL1 und Wine ist (bzw. war), dass sie einem sich bewegenden Ziel hinterherhecheln muessen, noch dazu einem, das aufgrund von mehr Resourcen (Windows im Vergleich zu Wine) und/oder geringerer Buerokratie (Linux im Vergleich zu WSL1) schneller weiterentwickelt werden kann. Wenn Microsoft Windows als Libraries auf einem Linux-Unterbau aufbaut, haette es das Problem nicht, denn Microsoft definiert, was das Ziel ist. Allerhoechstens das anfaengliche Ziel (bug-for-bug-compatibility mit dem VMS-basierten Windows) koennte dann noch ein Problem sein.
 
Nore Ply schrieb:
Und? Was kam dabei heraus?
Klick das Video an? So faul kann man wohl gar nicht sein?😅
Aber naja, für alle faulen: WSL2 schlägt sich (in den gewählten Benchmarks) tatsächlich sehr gut! - wenn man genauere Infos will muss man halt das Video schauen😁 der wichtige Teil fängt bei 10:14 an ;)
jonderson schrieb:
Diese Benchmarks haben aber nichts mit WSL(2) am Hut? Da geht es um die Nativperformance.

Dave Plummer hingegen testet Windows+WSL2 vs. Windows+DockerMitLinuxImg vs. NativesLinux
 
mae schrieb:
Ich denke, die koennten das genauso gut (oder besser) als Libraries auf einem Linux-Kernel implementieren, so wie das auch Wine macht.
Niemand der noch alle Tassen im Schrank hat würde sich langfristig mit Wine herumschlagen, wenn der NT-Kernel und sein Ökosystem nicht seine enorme Bedeutung hätte. Der Aufwand wäre total absurd bei einem Posix kompatiblen Unterbau irgendwelche Abstraktionsschichten einzuziehen um von Posix abzuweichen.
Zudem würde Mircosoft seinen goldenen Käfig deutlich durchlässiger machen müssen.

Statt Active Directory würde dazu gezwungen werden die Windows Spezifika aufzugeben und sauber Ldap/Kerberos zu sprechen.
Damit DirectX auf Linux/Mesa laufen kann wäre dieses komplett zu öffnen.

Mit einem Linuxunterbau müsste Microsoft zu viel vom eigenem Ökosystem öffnen und viel zu viel Kundenbindung aufgeben. Das wird nicht zeitnah auf keinen Fall passieren! Dazu müsste Microsoft erst einmal neue Ökosysteme mit hoher Bindung etablieren, die auf NT und unixoider Basis gleichermaßen funktionieren. Darin ist Microsoft jedoch sehr langsam bzw. scheitert grundlegend.

Android demonstriert sehr schoen, wie undurchlaessig so ein Kaefig sein kann, selbst wenn grosse Teile (nicht nur der Kernel) freie Software sind.
Und Android demonstriert auch, wie durchlässig das Ganze ist. Sodass sich in China ein Markt an Telefonen gibt, die AOSP (Android Open Source Project) als Unterbau haben und statt Google Play Services Eigentwicklungen nutzen. Zusätzlich hat Ms das "Problem", dass das Fundament ihres goldenen Käfigs der NT-Kernel ist und bedingt Abwärtskompatiblität bis in die Urzeiten von DOS.

Aber Android baut eben auf einem Linux-Kernel auf. Genau sowas hatte ich auch fuer Windows erwartet.
Was Google ja auch etwas nervt, dass der Konzern Ressourcen auf "Fuchsia" wirft kommt ja nicht von ungefähr.



Dark Soul schrieb:
Klick das Video an? So faul kann man wohl gar nicht sein?😅
Das Video ist lang und das Vorlesen von Benchmarks ohne Analyse dazu hat wirklich wenig Informationsgehalt.

Aber naja, für alle faulen: WSL2 schlägt sich (in den gewählten Benchmarks) tatsächlich sehr gut! - wenn man genauere Infos will muss man halt das Video schauen😁 der wichtige Teil fängt bei 10:14 an ;)
Die Benchmarks sind dadurch geprägt, dass sie CPU-lastig sind wobei kaum Kontextwechsel, kaum I/O gefordert sind. Entsprechend kommt raus was herauskommen muss: Moderne Hypervisor bedingen nur minimalen CPU Overhead und das OS spielt nahezu keine Rolle, wie schnell CPU-Befehle ausgeführt werden.
Im schlimmsten Fall werden auf verschiedenen Betriebssystemen verschiedene Compiler und Bibliotheken genutzt, und da testet man dann eher Compiler und Bibliotheken als Spezfika der Betriebssysteme.

Diese Benchmarks haben aber nichts mit WSL(2) am Hut? Da geht es um die Nativperformance.

Dave Plummer hingegen testet Windows+WSL2 vs. Windows+DockerMitLinuxImg vs. NativesLinux
Naja Phoronix benchmarkt tendenziell auch Szenarien wo Betriebssysteme eine Rolle spielen können. Also Sachen wo Kontextwechsel, Interprozesskommunikation, I/O eine Rolle spielen. Wobei versucht wird transparent zu machen mit welchen Compilern und Settings die Software kompiliert wurde um da halbwegs Normalisierung hinzubekommen. Phoronix geizt aber genauso mit der genauen Analyse woran die Differenzen nun wirklich liegen könnten. Der Raum für Spekulation ist entsprechend groß und die Flut an Benchmarks eigentlich nutzlos.
 
Zuletzt bearbeitet: (typo)
  • Gefällt mir
Reaktionen: nan1bot und Nore Ply
@jonderson
Ms könnte auch versuchen einen GPL Kernel zu nutzen und mit proprietären Erweiterungen zu arbeiten. Die Entwickler von Linux und Mesa nehmen darauf aber überhaupt keine Rücksicht bzw torpedieren es aktiv, wenn es ihnen am Horizont auch nur minimalen Mehraufwand bedeutet.
Es bleibt also die Wahl proprietäre Sonderwege unter hohem Aufwand zu gehen oder einen halbwegs offenen Ansatz zu wählen. Im ersten Fall kann Ms auch gleich den NT-Kernel mit mehr Kontrolle weiter pflegen und im zweiten Fall öffnet man Mitbewerbern die Möglichkeit zu Forks.
 
Dark Soul schrieb:
Klick das Video an? So faul kann man wohl gar nicht sein?😅
Doch doch, wenn ich in Computerbase in einem Diskussionsthread bin und dann ohne für mich ersichtlichen Nutzen auf irgendeine externe Quelle wechseln soll dann werde ich schlagartig enorm faul.
Bitte nicht falsch verstehen, das geht nicht gegen Dich. Aber die Diskussion führen wir nunmal hier und hier sollten Argumente zur Diskussion stehen.

Dark Soul schrieb:
Aber naja, für alle faulen: WSL2 schlägt sich (in den gewählten Benchmarks) tatsächlich sehr gut!
Das reicht mir schon. Danke Dir!
 
Piktogramm schrieb:
Niemand der noch alle Tassen im Schrank hat würde sich langfristig mit Wine herumschlagen, wenn der NT-Kernel und sein Ökosystem nicht seine enorme Bedeutung hätte.

Der WNT-Kernel hat keine Bedeutung, die verschiedenen Windows-APIs und die Software, die dafuer geschrieben wurden, haben eine. Wenn der WNT-Kernel eine Bedeutung haette, waere Wine hoffnungslos.

Der Aufwand wäre total absurd bei einem Posix kompatiblen Unterbau irgendwelche Abstraktionsschichten einzuziehen um von Posix abzuweichen.

Abstraktionsschichten darueber werden staendig gemacht, und Libraries, die nicht in POSIX beschrieben wurden, auch, und auch Dinge, die von POSIX ueberhaupt nicht erfasst werden (z.B. JDK, GTK, Wayland).

Statt Active Directory würde dazu gezwungen werden die Windows Spezifika aufzugeben und sauber Ldap/Kerberos zu sprechen.

Nur weil Du den Linux-Kernel verwendest, bist Du nicht zu LDAP/Kerberos gezwungen. Das machen schon die meisten GNU/Linux-Systeme nicht, ein Windows/Linux-System waere genausowenig dazu gezwungen. Die koennten Active Directory schoen im User-Space implementieren, so wie sie's wohl auch auf dem WNT-Kernel machen.

Damit DirectX auf Linux/Mesa laufen kann wäre dieses komplett zu öffnen.

Warum sollte DirectX auf Mesa laufen? Die ganze Grafik koennte im Userspace laufen, so wie das mit X unter Linux urspruenglich ging. Oder sie koennten die existierenden Kernel-Interfaces fuer das Bildschirmsetup verwenden, so wie das X und Wayland jetzt machen (wo m.W. noch immer das meiste im Userspace laeuft). Und wenn sie doch eine Kernel-Erweiterung brauchen, koennen sie die ja zum Kernel beitragen (und in der Zwischenzeit einen modifizierten Kernel mit Windows liefern, so wie das Google bei Android auch macht).

Mit einem Linuxunterbau müsste Microsoft zu viel vom eigenem Ökosystem öffnen und viel zu viel Kundenbindung aufgeben.

Glaube ich nicht. Google zeigt, wie's geht.

Und Android demonstriert auch, wie durchlässig das Ganze ist. Sodass sich in China ein Markt an Telefonen gibt, die AOSP (Android Open Source Project) als Unterbau haben und statt Google Play Services Eigentwicklungen nutzen.

Das funktioniert nur, weil 1) Huawei (und WIMRE andere) Android nicht benutzen darf und daher notgezwungen etwas anderes brauchen, und 2) Google einen grossen Teil des User-Space von Android als freie Software hergegeben hat. Wenn die nur den Linux-Kernel haetten, braeuchte Huawei noch ein paar Jahre mehr, um etwas auf die Beine zu stellen. Und wenn das, was die machen, Konkurrenz durch Android zu befuerchten haette, dann wuerde es nie konkurrenzfaehig werden.

Wenn die USA die Lizensierung von Windows nach China verbieten wuerden, dann wuerde Wine einen Schub bekommen: Chinesische Hardwarehersteller wuerden Leute zur Weiterentwicklung von Wine einsetzten und Softwarefirmen wuerden darauf schauen, dass ihre Windows-Software auch auf Wine laeuft. Und auf einmal waere Wine eine ernsthafte Konkurrenz zu Windows.

Zusätzlich hat Ms das "Problem", dass das Fundament ihres goldenen Käfigs der NT-Kernel ist und bedingt Abwärtskompatiblität bis in die Urzeiten von DOS.

Abwaertskompatibiliaet ist ihnen wichtig, aber so weitreichende Kompatibiliaet ist ihnen nicht wichtig. So kann die 64-bit-Version von Windows 10 und 11 keine DOS-Programme ausfuehren. Aber jedenfalls gibt's unter Linux fuer DOS-Programme schon die DOSbox.

Wenn sie die Windows-APIs in Libraries implementieren, dann haben sie die Kompatibilitaet fuer alle Windows-Programme, und das (nicht der WNT-Kernel) ist das Fundament ihres goldenen Kaefigs.
 
0xffffffff schrieb:
Kennt jemand zufällig Benchmarks o.ä. inwieweit man bei der Aktivierung von WSL2 Geschwindigkeitseinbußen bei Spielen hinnehmen muss? Wenn man WSL2 nutzen möchte, wird Hyper-V aktiviert und damit auch das Windows-System quasi über eine Virtualisierungssicht ausgeführt.
Also ich habe nie die WSL verwendet, aber hatte irgendwann Hyper-V aktiviert um ein paar VMs laufen zu lassen.
Mir ist kein Performanceunterschied in Spielen aufgefallen, allerdings bin ich niemand der auf den letzten FPS achtet. Nur Anno 1800 mit seinem RAM Hunger hatte Probleme wenn ich verpennt habe meine VMs herunterzufahren :D
 
  • Gefällt mir
Reaktionen: Nore Ply
0xffffffff schrieb:
Wenn man WSL2 nutzen möchte, wird Hyper-V aktiviert
Das ist richtig.

0xffffffff schrieb:
und damit auch das Windows-System quasi über eine Virtualisierungssicht ausgeführt.
Und das ist Unfug. Virtualisiert wird der Guest, nicht der Host.

Wo hast Du das her?
 
  • Gefällt mir
Reaktionen: KitKat::new()
Uh..da ist mein Wissen veraltet. Danke für die freundliche Korrektur!
 
Für den professionellen IT-Bereich ist das ja alles eine recht erfreuliche Entwicklung.
Warum ich aber WSL einer nativen Linux-Installation vorziehen sollte, erschließt sich mir nicht.
Wenn überhaupt, hier auch nur der umgekehrte Weg. Aber Dualboot oder VM mit Windows tut es hier auch.
 
Piktogramm schrieb:
Mit einem Linuxunterbau müsste Microsoft zu viel vom eigenem Ökosystem öffnen und viel zu viel Kundenbindung aufgeben.
Piktogramm schrieb:
Damit DirectX auf Linux/Mesa laufen kann wäre dieses komplett zu öffnen.
Piktogramm schrieb:
Ms könnte auch versuchen einen GPL Kernel zu nutzen und mit proprietären Erweiterungen zu arbeiten. Die Entwickler von Linux und Mesa nehmen darauf aber überhaupt keine Rücksicht bzw torpedieren es aktiv, wenn es ihnen am Horizont auch nur minimalen Mehraufwand bedeutet.

jonderson schrieb:
Warum wäre man dazu gezwungen?
Das ist eine gute Frage, das es anders geht hat Apple gezeigt. Mit Metal haben sie auch eine eigene Grafik-Api usw. Geht also ohne Kundenbindung aufgeben zu müssen und ohne sich und das Ökosystem öffnen zu müssen, natürlich würde das ein Kraftakt ohne Frage der viel Geld und Ressourcen verschlingen würde und ich denke das ist auch genau der Grund warum das noch nicht passiert ist.

Ausserdem gilt bei M$ ja eh zur Zeit eher die "function follows form" Regel als andersrum.
 
Zurück
Oben