Gdy projekt ma trafić na serwer Linux, a codzienna praca nadal wymaga Windows, nie trzeba już wybierać jednego systemu. W praktyce temat opisywany skrótowo jako microsoft linux obejmuje dziś WSL 2, aplikacje Microsoftu działające natywnie na Linuksie oraz wygodne połączenie narzędzi Windows i linuksowego środowiska. Pokazuję, co naprawdę działa, jak uruchomić taki zestaw i gdzie kończą się jego możliwości.
Windows i Linux mogą tworzyć jedno praktyczne środowisko pracy
- WSL 2 uruchamia dystrybucję Linux bez klasycznego dual bootu.
- WSLg pozwala otwierać wybrane aplikacje graficzne Linux obok programów Windows.
- Visual Studio Code, .NET, PowerShell i Azure CLI mają dobre wsparcie dla Linuksa.
- Microsoft 365 nadal nie oferuje oficjalnych natywnych aplikacji desktopowych dla Linux.
- Najlepszy efekt daje trzymanie kodu w linuksowym systemie plików WSL, a aplikacji biurowych po stronie Windows.
Co Microsoft faktycznie oferuje użytkownikom Linuksa
Microsoft nie stworzył jednej dystrybucji Linux przeznaczonej dla zwykłego użytkownika desktopowego. Zamiast tego rozwija kilka warstw integracji. Najważniejszą z nich jest Windows Subsystem for Linux, ale na tym oferta się nie kończy.
Na Linuksie można uruchomić między innymi Visual Studio Code, PowerShell, .NET, Azure CLI i Microsoft Edge. Są to narzędzia szczególnie istotne dla programistów, administratorów i osób pracujących z Azure. Microsoft utrzymuje także repozytorium pakietów dla systemów opartych na Debianie, Ubuntu, Fedora, Red Hat i SUSE.
| Narzędzie | Jak działa na Linuksie | Dla kogo ma największy sens |
|---|---|---|
| WSL 2 | Linux uruchomiony wewnątrz Windows | Programiści potrzebujący obu systemów |
| Visual Studio Code | Natywna aplikacja Linux lub interfejs Windows połączony z WSL | Web developerzy i twórcy aplikacji .NET |
| .NET | SDK i runtime dostępne natywnie | Programiści budujący aplikacje wieloplatformowe |
| PowerShell | Wieloplatformowa powłoka i język skryptowy | Administratorzy i zespoły DevOps |
| Microsoft Edge | Oficjalna przeglądarka dla wybranych dystrybucji Linux | Użytkownicy usług Microsoft i aplikacji webowych |
To ważne rozróżnienie. Microsoft wspiera Linux przede wszystkim jako środowisko programistyczne, serwerowe i chmurowe, a nie jako pełnoprawny zamiennik Windows na komputerze biurowym. Taki kierunek dobrze pasuje do pracy z .NET i Azure, ale nie rozwiązuje problemu wszystkich aplikacji desktopowych.
WSL 2 to najprostszy sposób na Linux obok Windows
WSL pozwala uruchomić dystrybucję Linux bez osobnego komputera, klasycznej maszyny wirtualnej i restartowania systemu przy każdym przełączeniu. WSL 2 korzysta z prawdziwego jądra Linux działającego w lekkiej warstwie wirtualizacji, dlatego zapewnia lepszą zgodność z narzędziami linuksowymi niż pierwsza wersja podsystemu.
Na współczesnym Windows 11 instalacja zwykle sprowadza się do otwarcia PowerShella jako administrator i wpisania:
wsl --install
Domyślnie instalowane jest Ubuntu, ale można wybrać inną dystrybucję, na przykład Debian albo openSUSE. Po restarcie system poprosi o utworzenie użytkownika Linux, a pierwsze uruchomienie przygotuje system plików i podstawowe komponenty.
Stan instalacji sprawdzę poleceniem wsl --list --verbose. Zobaczę wtedy, jakie dystrybucje są dostępne i czy pracują w trybie WSL 1 czy WSL 2. Do nowego środowiska deweloperskiego wybieram zwykle WSL 2, ponieważ lepiej radzi sobie z kontenerami, narzędziami Linux i aplikacjami korzystającymi z typowego jądra linuksowego.
Gdzie przechowywać kod
Najczęstszy błąd polega na trzymaniu dużego projektu w katalogu Windows, na przykład pod /mnt/c/Users/..., a następnie intensywnym przetwarzaniu go z poziomu Linux. Przy projektach Node.js, .NET lub Python może to oznaczać wolniejsze operacje na tysiącach małych plików i problemy z obserwatorami zmian.
Lepszym rozwiązaniem jest katalog w systemie plików dystrybucji, na przykład ~/projekty/aplikacja. Windows nadal może uzyskać do niego dostęp przez Eksplorator plików, a Visual Studio Code otworzy go za pomocą rozszerzenia WSL. To drobna decyzja, która w praktyce mocno wpływa na komfort pracy.
Linuxowe aplikacje graficzne działają w Windows, ale nie tworzą pełnego pulpitu
WSLg rozszerza WSL 2 o obsługę aplikacji graficznych Linux korzystających z X11 i Wayland. Po instalacji programu z użyciem menedżera pakietów może on pojawić się w menu Start Windows, działać na pasku zadań i współdzielić schowek z aplikacjami Windows.
Przykładowo można uruchomić edytor, narzędzie graficzne albo prostą aplikację testową Linux i przełączać się między nią a Windowsem za pomocą Alt+Tab. Dla programisty jest to wygodne przy testowaniu aplikacji, narzędzi GTK lub projektów, które muszą zachować linuksowe zależności.
Trzeba jednak dobrze rozumieć granicę tej funkcji. WSLg nie dostarcza kompletnego środowiska desktopowego z własnym menedżerem okien, panelem i pełną sesją użytkownika. To raczej warstwa uruchamiania pojedynczych aplikacji GUI wewnątrz pulpitu Windows.
Nie każda aplikacja zachowa się idealnie. Problemy mogą dotyczyć obsługi sprzętu, drukarek, integracji z powiadomieniami, skalowania interfejsu albo aplikacji oczekujących pełnego środowiska GNOME czy KDE. Do zwykłego programu graficznego WSLg jest wystarczający, ale do codziennego korzystania z całego pulpitu Linux lepsza będzie maszyna wirtualna albo instalacja systemu na osobnym urządzeniu.
Które aplikacje Microsoftu mają sens na Linuksie
Najlepiej wspierane są narzędzia dla programistów i administratorów. W tym obszarze Microsoft wykonał dużą pracę, dlatego Linux nie jest już dodatkiem traktowanym po macoszemu.
Visual Studio Code i praca z WSL
Najwygodniejszy model polega na zainstalowaniu Visual Studio Code po stronie Windows i rozszerzenia WSL. Interfejs edytora działa wtedy w Windows, natomiast terminal, rozszerzenia, kompilator i debugowanie mogą działać bezpośrednio w dystrybucji Linux.
Dzięki temu projekt zachowuje linuksowe ścieżki, narzędzia i wersje bibliotek, a użytkownik nie traci wygody aplikacji Windows. Rozszerzenie uruchamia serwer VS Code wewnątrz WSL, więc polecenia takie jak dotnet restore, npm install czy pytest wykonują się w tym samym środowisku, w którym aplikacja będzie później wdrażana.
.NET, PowerShell i Azure
Nowoczesny .NET jest wieloplatformowy. Na Linuksie można instalować SDK, budować aplikacje ASP.NET Core, uruchamiać testy i przygotowywać obrazy kontenerów bez Visual Studio. Do codziennej pracy wystarcza często VS Code plus terminal Linux, choć pełne Visual Studio nadal pozostaje narzędziem przeznaczonym głównie dla Windows.
PowerShell 7 działa natywnie na wielu dystrybucjach Linux. Nie należy jednak mylić go z pełnym Windows PowerShellem, który zależy od technologii dostępnych wyłącznie w Windows. W Linux PowerShell dobrze sprawdza się jako powłoka, język skryptowy i narzędzie automatyzacji, ale część modułów administrujących Windows nie będzie dostępna.
Podobnie wygląda praca z Azure CLI. Można zalogować się z terminala, zarządzać zasobami, uruchamiać skrypty wdrożeniowe i łączyć Bash z poleceniami az. Dla zespołów DevOps to często wygodniejszy układ niż instalowanie całego stosu narzędzi bezpośrednio w Windows.
Przeczytaj również: Port 3389 w RDP - jak sprawdzić i zmienić go bezpiecznie?
Edge i aplikacje Microsoft 365
Microsoft Edge ma oficjalne wydania dla wybranych 64-bitowych dystrybucji Linux. Ma to sens zwłaszcza wtedy, gdy korzystam z konta Microsoft, aplikacji webowych, testów zgodności albo firmowych usług zabezpieczonych przez Entra ID.
Inaczej wygląda sytuacja z Wordem, Excelem i PowerPointem. Microsoft 365 nie oferuje oficjalnego natywnego pakietu desktopowego dla Linux. Najbezpieczniejszą opcją pozostaje wersja webowa w przeglądarce, a gdy potrzebna jest pełna zgodność z makrami, dodatkami lub zaawansowanym formatowaniem, uruchomienie Windows w maszynie wirtualnej albo na osobnym komputerze.
Warstwy zgodności, takie jak Wine, czasem pozwalają uruchomić starsze programy Windows, ale nie traktowałbym ich jako pewnego rozwiązania dla pracy firmowej. Aktualizacje Office, sterowniki, dodatki i zabezpieczenia mogą zmienić zachowanie aplikacji bez ostrzeżenia.
Jak zbudować wygodne środowisko dla .NET, Azure i AI
W przypadku pracy deweloperskiej najpraktyczniejszy jest model hybrydowy. Windows pozostaje pulpitem, miejscem dla przeglądarki, Outlooka, komunikatorów i aplikacji biurowych, natomiast WSL przejmuje rolę środowiska Linux.
- Zainstaluj WSL 2 i wybraną dystrybucję, najlepiej Ubuntu, jeśli zależy Ci na największej liczbie poradników i pakietów.
- W Linux wykonaj aktualizację pakietów, skonfiguruj Git i zainstaluj potrzebne SDK, na przykład .NET, Node.js lub Python.
- Trzymaj kod w katalogu dystrybucji, a nie bezpośrednio na zamontowanym dysku Windows.
- Zainstaluj Visual Studio Code w Windows i otwieraj projekty poleceniem
code .z terminala WSL. - Uruchamiaj testy, narzędzia CLI i kontenery w Linux, a aplikacje desktopowe oraz przeglądarkę pozostaw po stronie Windows.
Jeżeli używasz Dockera, integracja Docker Desktop z WSL 2 może uprościć pracę, ale warto kontrolować zużycie pamięci i procesora. Kilka kontenerów, indeksowanie projektu i aplikacje GUI potrafią razem obciążyć laptop bardziej, niż sugerowałby sam rozmiar kodu.
Przy .NET zwróciłbym też uwagę na źródło pakietów. Dystrybucja Linux może mieć własne repozytorium .NET, a Microsoft prowadzi dodatkowo własny kanał pakietów. Mieszanie tych źródeł bez kontroli wersji bywa przyczyną konfliktów podczas aktualizacji, dlatego w jednym projekcie lepiej świadomie trzymać się jednej strategii instalacji.
Gdzie integracja z Linuksem przestaje wystarczać
WSL jest świetny do kodu, skryptów, narzędzi CLI i testów aplikacji serwerowych. Nie zastąpi jednak pełnego Linux w każdym scenariuszu. Jeżeli potrzebujesz własnych modułów jądra, bezpośredniego dostępu do sterowników, zaawansowanej konfiguracji sieci albo identycznego środowiska jak na fizycznym serwerze, lepsza będzie maszyna wirtualna lub osobny system.
Trzeba też rozdzielić zgodność środowiska od zgodności aplikacji. Program uruchamiany w WSL może działać tak samo jak na serwerze Linux, ale dostęp do portów, usług Windows, certyfikatów, systemu plików i zmiennych środowiskowych nadal wymaga sprawdzenia. „Działa w WSL” nie zawsze oznacza „jest gotowe do wdrożenia”.
Drugim ograniczeniem są aplikacje desktopowe. Linuxowe programy GUI uruchomione przez WSLg są użyteczne do konkretnych zadań, ale nie zapewniają pełnego doświadczenia niezależnego pulpitu. Z kolei aplikacje Windows nie stają się automatycznie programami Linux tylko dlatego, że obok działa WSL.
Najwięcej rozczarowań wynika z oczekiwania, że jedno rozwiązanie załatwi wszystko. WSL nie jest zamiennikiem Windows, nie jest też pełną instalacją Linux. To most między dwoma ekosystemami, który działa najlepiej wtedy, gdy każdemu systemowi powierzymy zadania, do których został najlepiej przygotowany.
Windows jako baza, Linux jako środowisko pracy
Jeśli potrzebuję aplikacji biurowych, wygodnego pulpitu i narzędzi firmowych, zostaję przy Windows i dokładam WSL 2. Jeśli najważniejsza jest zgodność z produkcyjnym serwerem Linux, przenoszę narzędzia do WSL, kontenera albo zdalnej maszyny i nie próbuję emulować całego systemu desktopowego.
- Wybierz WSL 2, gdy tworzysz aplikacje, pracujesz z Git, .NET, Pythonem, Node.js, Dockerem lub Azure.
- Wybierz WSLg, gdy potrzebujesz pojedynczych aplikacji GUI Linux obok programów Windows.
- Wybierz maszynę wirtualną lub dual boot, gdy potrzebujesz kompletnego pulpitu Linux albo niskopoziomowej kontroli nad systemem.
- Nie zakładaj natywnego Office na Linux, jeśli codzienna praca zależy od makr, dodatków i zaawansowanego formatowania.
Moim zdaniem największą wartością tej integracji nie jest samo uruchamianie Linux w Windows, lecz możliwość pracy na narzędziach linuksowych bez rezygnowania z aplikacji desktopowych Microsoftu. Dla programisty .NET i Azure to często najbardziej rozsądny kompromis między wygodą a zgodnością środowiska.
