Jedną z najczęściej komentowanych nowości podczas tegorocznej odsłony konferencji Build jest wielokrotnie podejmowany także na łamach naszego bloga temat Windows Subsystem for Linux 2. Z początku Microsoft niechętnie dzielił się szczegółami technicznymi dotyczącymi dużych zmian w architekturze subsystemu. Dziś, kiedy o WSL 2 wiemy już więcej, jasne staje się, dlaczego Microsoft był tak lakoniczny na temat technikaliów.
Na blogu deweloperskim Microsoft przedstawił odpowiedzi na najczęściej zadawane o WSL 2 pytania. Potwierdziły się nasze obawy, że implementacja pełnego jądra Linux w Windowsie odbywać się będzie po prostu za pomocą maszyny wirtualnej. Do wirtualizacji wykorzystywane będzie Hyper-V. Pełne wirtualizowane jądro będzie dostępne na wszystkich wersjach systemu, na których działa pierwsza odsłona subsystemu.
Microsoft zapewnia, że wirtualizacja nie wpłynie na wydajność subsystemu, chwali się nawet dwudziestokrotnym wzrostem w rozpakowywaniu archiwów. Dziś wiemy już jednak, że te wzrosty odbywać się będą w wirtualizowanym środowisku. Microsoft niechętnie wspomina natomiast na przykład o więcej niż prawdopodobnym wielokrotnie dłuższym czasie startu maszyny wirtualnej w porównaniu do subsystemu. A właśnie błyskawiczny start można było cenić w przypadku pierwszego WSL-a.
Nie jest to pierwszy raz, kiedy zapowiedzi i oczekiwania mogą rozminąć się z wynikami w benchmarkach. Z podobnymi obietnicami mieliśmy do czynienia w przypadki Windowsa 10 na ARM. Qualcomm jako wyłączny dostawca procesorów przekonywał wówczas, że emulacja oprogramowania Win32 nie wpłynie na wydajność i będzie ona porównywalna z natywną. Czas pokazał, że różnice w narzucie są i to znaczne, co mogło mieć wpływ na chłodną recepcję urządzeń klasy Always Connected.
Zobacz też: Więcej Linuksa w Windowsie, nie chodzi tylko o Windows Subsystem for Linux 2
Ale najlepszym dowodem na to, że WSL 2 pod wieloma względami będzie krokiem w tył w stosunku do „jedynki” jest to, że obie odsłony WSL-a będą w Windowsie 10 koegzystować. Microsoft potwierdził we FAQ, że możliwe będzie nawet korzystanie z obu subsystemów (a raczej z subsystemu i maszyny wirtualnej) obok siebie. Niemożliwe będzie natomiast jednoczesne korzystanie z WSL-a 2 oraz hipernadzorców maszyn wirtualnych firm trzecich, np. Virtualboksa.
Skoro mamy do czynienia z wirtualizacją za pomocą Hyper-V to same nasuwają się pytania o dostęp WSL-a 2 do sprzętu. Tutaj także Microsoft nie ma dobrych wieści: „początkowo” dostęp będzie ściśle ograniczony, maszyna wirtualna nie będzie widzieć natywnej grafiki czy interfejsów USB. Umożliwia to natomiast WSL 1, co dobitnie pokazuje, w jaki sposób Microsoft rozumie „rozwój” linuksowego subsystemu.
Zobacz też: Microsoft potwierdza duże zmiany w Universal Windows Platform i Microsoft Store
W zasadzie jedyną dobrą wiadomość dla zainteresowanych WSL-em 2 stanowią zmiany w obsłudze aplikacji sieciowych. Tutaj możemy mieć do czynienia z usprawnieniami, gdyż nie będzie już potrzeby tłumaczenia wywołań systemowych do Windowsowego API. WSL 2 będzie miał tutaj wszystkie cechy maszyny wirtualnej, łącznie z własnym IP. To jednak przekonuje niewielu, a entuzjazm pobudzony informacjami o wzrostach wydajności szybko stygnie po uświadomieniu sobie, że mamy do czynienia ze zwykłą VM-ką.
Bilans wad i zalet WSL-a 2 w stosunku do faktycznego subsystemu na razie jest ujemny, na podstawie komentarzy można postawić tezę, że zdają sobie z tego także sami programiści. Jako utrudnienie nie do przeskoczenia wymieniają między innymi brak możliwości równoległego korzystania z WSL-a 2 i hipernadzorców VMWare. Nie sposób także jednoznacznie odpowiedzieć na pytanie, w czym WSL 2 miałby być lepszy niż zwykła maszyna wirtualna z Ubuntu uruchamiana z poziomu galerii Hyper-V.
