Linuksowy subsystem pojawił się w Windowsie 10 w wersji testowej w połowie 2016 roku. Od tego czasu wyewoluował z niewiele oferującej ciekawostki, którą lepiej zastąpić maszyną wirtualną, do ciekawej propozycji dla każdego dewelopera przyzwyczajonego do linuksowych narzędzi. Czas na kolejny krok w rozwoju WSL – Microsoft podczas trwającej w Seattle konferencji Build zapowiedział Windows Subsystem for Linux 2.

Zmiany są radykalne. Aktualnie WSL korzysta z warstwy kompatybilności, która tłumaczyła wywołania systemowe. Izolowane procesy Pico z linuksowymi binarkami są przetwarzane przez LxCore/LXSS na wywołania API Windowsa. W całym procesie nigdy dotąd nie był jednak wykorzystywany kod samego jądra Linux. Już tego lata, wraz z premierą Windows Subsystem for Linux 2, się to zmieni – będziemy mieli do czynienia z pełną implementacją jądra Linux w Windowsie.

Schemat dotychczasowego działania WSL.

Co to oznacza w praktyce? Microsoft wykorzysta zmodyfikowane na potrzeby WSL jądro w wersji 4.19 (w miarę postępów prac jądro będzie aktualizowane do kolejnych wersji LTS). Aktualizacje jądra będą realizowane przez Windows Update, po premierze kolejnego wydania LTS linuksowego jądra będzie ono po prostu podmieniane. Microsoft deklaruje, że „wciąż monitoruje listy mailingowe dotyczące bezpieczeństwa Linuksa i współpracuje z kilkoma firmami utrzymującymi bazy podatności”.

Zobacz też: Windows otrzymał nowy terminal – „okienka” teraz już niemal jak na Linuksie

Implementacja autorskiego wydania jądra w Windowsie to w stosunku do mechanizmu opartego o tłumaczenie procesów Pico przez sterowniki ogromna zmiana. Nasuwają się zatem pytania, w jaki sposób się ona dokona. Na razie Microsoft jest jednak dość ogólnikowy w kwestii technikaliów – w oficjalnym komunikacie z jednej strony mowa o wykorzystaniu wirtualizacji, a z drugiej strony zaprzecza się, byśmy mieli do czynienia z „tradycyjną” wirtualizacją:

WSL 2 korzysta ze wszystkiego, co najnowsze i najlepsze w technologii wirtualizacji, by uruchomić jądro Linux wewnątrz lekkiej maszyny wirtualnej. Niemniej WSL 2 NIE będzie tradycyjną maszyną wirtualną. Kiedy myślisz o VM, najpewniej myślisz także o czymś, co wolno się uruchamia, zużywa dużo zasobów i wymaga twojego czasu. WSL 2 nie posiada tych cech. Wciąż daje ci ważne korzyści z WSL 1: wysoki poziom integracji między Windowsem i Linuksem, ekstremalnie szybki czas uruchamiania się, mały narzut na zasoby i – co najlepsze – nie wymaga konfiguracji czy zarządzania maszyną wirtualną.

Microsoft potwierdza, że w przypadku WSL 2 będziemy mieli do czynienia po prostu z wirtualizacją, a to dla wielu może stanowić krok w tył w stosunku do dotychczasowych osiągnięć na froncie linuksowego subsystemu w Windowsie. Niewykluczone, że wykorzystane zostaną mechanizmy współdzielenia zasobów z Windows Sandbox, ale czy możemy jeszcze w ogóle mówić o subsystemie, czy może już tylko o dobrze zakamuflowanej maszynie wirtualnej?

Zobacz też: WLinux na subsystemie Windowsa – jak wypada pod względem wydajności?

Znacznie chętniej niż szczegółami architektury WSL 2 Microsoft dzieli się wynikami testów wydajności. WSL 2 będzie „odczuwalnie szybciej” wykonywał polecenia klonowania repozytoriów Git, instalacji pakietów przez npm czy aktualizacji przez apt. Już teraz WSL 2 ma być w stosunku do poprzednika 20-krotnie szybszy przy rozpakowywaniu archiwum tarball i od 2 do 5 razy szybszy przy obsłudze poleceń git clone, npm install i cmake.

Społeczność Open Source na ogół sceptycznie przyjęła rewelacje z tegorocznego Builda. Jasne jest, że największym beneficjentem zmian w WSL jest sam Microsoft – pełna kompatybilność wywołań systemowych pozwoli na Windowsie na wygodne korzystanie z Dockera czy FUSE, co może skłaniać do porzucenia linuksowych dystrybucji. Narracja, według której „Microsoft kocha Linuksa” została sparafrazowana przez Abhisheka Prakasha z It's FOSS jako „Microsoft pożąda Linuksa”.

Zobacz też: Windows i Linux jeszcze bliżej – Microsoft ułatwi dostęp do plików WSL

Kolejny haczyk tkwi w deklarowanej przez Microsoft otwartości autorskiej modyfikacji jądra. Z jednej strony przedstawiciele korporacji deklarują, że kod kernela będzie ogólnodostępny, a z drugiej już teraz przestrzegają, że pewne „łatki” zapewniające kompatybilność mogą nie zostać upublicznione. A to już typowa korporacyjna praktyka – weź kod opracowany pro bono przez społeczność Open Source, dostosuj do swoich potrzeb, spieniężaj i nie oglądaj się za siebie.