System operacyjny dla programisty: Windows, macOS czy Linux? Problemy, na które trafisz

Pytanie „Windows, macOS czy Linux?” wraca u każdego początkującego programisty. Odpowiedź brzmi: to zależy, a zaszłości z lat, gdy Windows nie nadawał się do programowania, dziś w dużej mierze nie mają znaczenia. Prawdziwe różnice kryją się w szczegółach, które potrafią kosztować godzinę debugowania. Poniżej opisujemy je na przykładach, które uruchomiliśmy na macOS, oraz na podstawie dokumentacji Microsoftu, Dockera i Ubuntu, a na końcu bez wskazywania zwycięzcy pokazujemy, jak się w tym odnaleźć.

Czy system operacyjny ma dziś znaczenie dla programisty?

Mniejsze niż kiedyś, ale nie zerowe. Większość narzędzi, czyli Git, Node.js, Python, Docker i edytory kodu, działa na wszystkich trzech systemach. Aplikacje webowe uruchamiane są zwykle na serwerach z Linuksem, więc różnice między Twoim komputerem a serwerem są głównym źródłem problemów. Nie jest to więc kwestia „lepszego” systemu, lecz rozbieżności między środowiskiem, w którym piszesz kod, a tym, w którym on działa.

Czym są znaki końca linii i dlaczego psują skrypty?

Każda linia tekstu kończy się niewidzialnym znakiem. Linux i macOS używają jednego znaku (LF), a Windows tradycyjnie dwóch (CRLF). Zwykle nie ma to znaczenia, dopóki nie uruchomisz skryptu powłoki zapisanego z CRLF. Na macOS skrypt, który zapisano z końcami linii w stylu Windows, kończy się błędem:

./crlf.sh
# bad interpreter: /bin/bash^M: no such file or directory

Znak ^M to ukryty znak powrotu karetki doklejony do nazwy interpretera, więc system szuka programu /bin/bash^M. Polecenie file crlf.sh pokazuje to wprost („with CRLF line terminators”). Ten sam skrypt zapisany z LF działa bez problemu.

Jak ustawić Gita, żeby sam pilnował końców linii?

Git potrafi zamieniać końce linii. Przetestowaliśmy trzy ustawienia na pliku zapisanym z CRLF:

Naszym zdaniem najlepiej wpisać regułę do .gitattributes, bo wtedy każdy członek zespołu dostaje tę samą konfigurację, niezależnie od systemu. Po dodaniu pliku do istniejącego repozytorium uruchom git add --renormalize ., żeby Git ujednolicił już zapisane pliki. Pytanie o sens core.autocrlf=true ma na Stack Overflow ponad pół miliona wyświetleń, więc to powszechny kłopot i warto poświęcić na niego kilka minut na początku projektu. Pomaga też plik .editorconfig, który ustawia końce linii w edytorze.

Czy wielkość liter w nazwach plików ma znaczenie?

Zależy od systemu. Windows i macOS domyślnie nie rozróżniają wielkich i małych liter w nazwach plików, a Linux rozróżnia. Microsoft w dokumentacji radzi wprost: „Do not assume case sensitivity”.

Zobacz, jak to wygląda na macOS (system plików APFS w domyślnej konfiguracji):

echo "# test" > Readme.md
cat README.md
# # test

Polecenie z inną wielkością liter otworzyło ten sam plik. Podobnie require('./header') w Node.js załadowało plik Header.js. Co to oznacza dla serwera, opisujemy w następnej podsekcji.

Dlaczego kod działa u mnie, a na serwerze się wysypuje?

To klasyczna pułapka wielkości liter. Gdy w kodzie piszesz require('./header'), a plik nazywa się Header.js, na macOS i Windowsie wszystko działa, bo system nie rozróżnia liter (u nas na macOS zadziałało właśnie tak). Na Linuksie, na którym zwykle działa serwer i środowisko CI, plik header.js nie istnieje, więc ta sama aplikacja kończy się błędem w stylu „module not found”. Linuksa nie testowaliśmy, więc część o serwerze opiera się na dokumentacji Microsoftu i wiedzy ogólnej, ale reguła jest ta sama: błąd wychodzi dopiero po wdrożeniu. Dlatego uruchamiaj testy w CI na Linuksie, a nazwy plików i importy pisz konsekwentnie, najlepiej małymi literami.

Dlaczego Git nie widzi zmiany wielkości liter w nazwie pliku?

Po mv Readme.md README.md na macOS polecenie git status było puste, a git ls-files nadal pokazywało Readme.md (ustawienie core.ignorecase miało wartość true). Git dopasowuje się do systemu plików i nie widzi różnicy. Jak to obejść, opisujemy w osobnym artykule: Git nie ogarnia, jak zmienić wielkość liter w nazwach plików i katalogów. Microsoft ostrzega też, że ustawienie core.ignorecase=false na systemie bez rozróżniania wielkości liter „may lead to confusing errors, false conflicts, or duplicate files”.

Na Windowsie możesz włączyć rozróżnianie wielkości liter dla pojedynczego katalogu poleceniem fsutil.exe file setCaseSensitiveInfo <ścieżka> enable (w PowerShellu uruchomionym jako administrator, na pustym katalogu). Microsoft zastrzega, że część aplikacji Windows może wtedy nie działać poprawnie w takim katalogu.

Jakie jeszcze różnice w nazwach plików i ścieżkach warto znać?

Windows ma kilka pułapek, o których zwykle nikt nie mówi:

Czym jest chmod i dlaczego uprawnienia potrafią irytować?

Systemy z rodziny Unix (macOS i Linux) trzymają dla każdego pliku uprawnienia: kto może go czytać, zapisywać i uruchamiać. To model bezpieczniejszy, bo nowy plik domyślnie nie jest wykonywalny, ale bywa też „upierdliwy”, gdy o tym zapomnisz. Na przykład świeżo utworzony skrypt:

./run.sh
# permission denied
chmod +x run.sh
./run.sh
# ok

Pierwsze uruchomienie kończy się permission denied. Po chmod +x skrypt działa. Warto wiedzieć, że Git zapamiętuje to uprawnienie. W naszym teście plik wykonywalny trafił do repozytorium z trybem 100755, a zwykły plik z 100644, a po zdjęciu uprawnienia git status pokazał zmianę pliku. Na Windowsie, który nie ma takich uprawnień, możesz nadać tryb ręcznie poleceniem git update-index --chmod=+x plik.sh (w naszym teście zmieniło 100644 na 100755).

Czym różni się macOS od Linuksa, skoro oba są systemami Unix?

Oba mają powłokę i podobne polecenia, ale nie identyczne. macOS opiera się na jądrze Darwin (tak odpowiada uname -s) i używa narzędzi w wersji BSD, a Linux zwykle narzędzi GNU. Typowy przykład to polecenie sed -i do podmiany tekstu w pliku:

sed -i 's/kot/pies/' a.txt     # na macOS: błąd
sed -i '' 's/kot/pies/' a.txt  # na macOS: działa

Pierwsza wersja, popularna w poradnikach pisanych pod Linuksa, na macOS kończy się błędem. Drugą wersję trzeba napisać inaczej. Podobne różnice dotyczą kilku innych narzędzi, dlatego skrypty warto sprawdzać na docelowym systemie. Dodatkowo każdy nowy Mac z procesorem Apple (u nas arm64) działa w innej architekturze niż większość serwerów.

Jak system operacyjny wpływa na pracę z Dockerem?

Docker używa 73,8% zawodowych programistów (Stack Overflow Developer Survey 2025), więc to jedno z miejsc, w których wybór systemu ma największe skutki. Czym jest kontener i jak zacząć pracę z tym narzędziem, wyjaśniamy w artykule Czym jest Docker i jak działa. Kontenery Dockera to procesy Linuksa, więc na Windowsie i macOS działają w lekkiej maszynie wirtualnej. Z tego wynikają dwie typowe pułapki:

1. Pliki na Windowsie. Dokumentacja Dockera zaleca trzymać kod montowany do kontenerów w systemie plików Linuksa w WSL 2 (na przykład w katalogu domowym), a nie pod /mnt/c. Ścieżka /mnt/c daje „much lower” wydajność, a kontenery otrzymują zdarzenia zmian plików (inotify), które odpowiadają np. za automatyczne odświeżanie aplikacji, tylko z systemu plików Linuksa.
2. Architektura procesora. Kontenery współdzielą jądro hosta, więc obraz zbudowany dla linux/amd64 nie uruchomi się na komputerze arm64 bez emulacji. Na Macu z procesorem Apple kończy się to często błędem exec format error (to jedno z najpopularniejszych pytań o Dockera na Stack Overflow, ponad 50 tys. wyświetleń). Rozwiązaniem jest budowanie obrazu z flagą --platform albo obrazy wieloplatformowe. Emulacja przez QEMU działa, ale według dokumentacji bywa „much slower than native”.

Jeśli pracujesz na Linuksie, Docker działa natywnie, bez maszyny wirtualnej. Jedna uwaga praktyczna: z wolumenami montowanymi z komputera mogą pojawić się problemy z uprawnieniami (kontener działa jako inny użytkownik niż Ty), co tłumaczy sporą popularność pytań o uprawnienia do montowanych katalogów. Samego Dockera na tej maszynie nie instalowaliśmy, więc ten fragment opiera się na dokumentacji i popularnych pytaniach.

Czy Windows nadaje się dziś do programowania?

Tak, i to bez dużych zastrzeżeń. WSL 2 uruchamia prawdziwe jądro Linuksa w lekkiej maszynie wirtualnej, dzięki czemu na Windowsie pracujesz w powłoce Bash, z narzędziami takimi jak grep, sed czy awk, z Node.js, Pythonem, Rustem i Go. Microsoft opisuje też uruchamianie aplikacji graficznych Linuksa i przyspieszanie obliczeń uczenia maszynowego na GPU. Jeśli wiesz, że kod powinien żyć w systemie plików Linuksa, a nie w C:\, wiele problemów z Dockerem znika. Wciąż trzeba pamiętać o różnicach w nazwach plików, długości ścieżek i końcach linii, które opisaliśmy wyżej. Windows jest też naturalnym wyborem, gdy pracujesz z technologiami z jego ekosystemu.

Czy macOS jest jedynym dobrym wyborem?

Nie. macOS jest popularny, bo ma pod spodem Unix, wygodny terminal i bardzo dobrą jakość sprzętu, a procesory Apple są energooszczędne. Ma jednak swoje koszty: wyższą cenę, narzędzia BSD różniące się od tych na serwerach oraz architekturę arm64, o której trzeba pamiętać przy Dockerze. Dla części zadań, na przykład aplikacji na iOS, jest po prostu koniecznością. Dla większości pracy webowej nie jest.

Co daje Linux i na co uważać?

Linux to system, na którym działa większość serwerów, więc środowisko lokalne jest bliskie produkcyjnemu, a Docker działa natywnie. Zwykle jest też lekki i szybko się uruchamia, choć tego nie mierzyliśmy. Cena to czasem większa praca przy konfiguracji. Najczęstszy problem to sterowniki, zwłaszcza kart graficznych. Dokumentacja Ubuntu pokazuje, że instalacja sterownika NVIDIA zwykle sprowadza się do sudo ubuntu-drivers install, ale zdarzają się niespodzianki:

• Sterowniki podpisane przez Canonical działają z Secure Boot, a sterowniki budowane lokalnie (DKMS) nie są podpisane kluczem Canonical.
• Konflikt z modułem nouveau (otwarty sterownik) objawia się komunikatem „No devices were found”; sprawdzisz go poleceniem lsmod | grep nouveau.
• Po aktualizacji możesz zobaczyć „Driver/library version mismatch”, który zwykle znika po restarcie.

Zanim kupisz laptop z myślą o Linuksie, sprawdź, czy jego karta graficzna, Wi-Fi i inne podzespoły są dobrze wspierane. Nie testowaliśmy Linuksa na własnym sprzęcie, więc traktuj to jako listę rzeczy do sprawdzenia.

Czy język programowania ma znaczenie przy wyborze systemu?

Czasem tak. W większości przypadków możesz pracować na dowolnym systemie, ale kilka obszarów ma twarde wymagania, i warto je znać przed zakupem komputera.

Dokumentacja React Native mówi to wprost: „A Mac is required to build projects with native code for iOS”. Na Windowsie i Linuksie wspiera ona tylko Androida, a jeśli nie masz Maca, możesz rozwijać aplikację na urządzeniu z iOS przez Expo Go. To nie jest pełny zamiennik, bo nie obejmuje projektów z natywnym kodem.

Wniosek jest prosty. Jeśli planujesz pracę we frontendzie lub backendzie, możesz wybierać system według wygody. Jeśli myślisz o aplikacjach na iPhone'a i iPada, najpewniej będziesz potrzebować komputera Mac, nawet gdy resztę pracy wykonujesz gdzie indziej. W przypadku gier i aplikacji desktopowych sprawdź wymagania konkretnego silnika lub frameworka, bo różnią się między narzędziami. My tego obszaru nie testowaliśmy.

Porównanie: Windows, macOS i Linux bez wskazywania zwycięzcy

Jak wybrać system i uniknąć problemów?

Prostych reguł nie ma, ale kilka pytań pomaga:

1. Co chcesz tworzyć? Aplikacje na iOS wymagają Maca (patrz sekcja o języku programowania). Technologie ekosystemu Microsoft najwygodniej uruchamia się na Windowsie. Praca webowa i backendowa działa na każdym z trzech.
2. Co masz i na co Cię stać? Najlepszy system to taki, na którym masz działający sprzęt.
3. Kogo możesz zapytać? Na początku wiele problemów rozwiązuje osoba, która zna Twój system. Jeśli uczysz się z mentorem, zapytaj go o jego środowisko.

Niezależnie od wyboru, kilka nawyków ogranicza różnice między systemami:

• Dodaj .gitattributes (* text=auto eol=lf) i .editorconfig do każdego repozytorium.
• Nazywaj pliki małymi literami, bez spacji i znaków specjalnych.
• Uruchamiaj testy w CI na Linuksie.
• Używaj Dockera lub kontenerów deweloperskich, żeby każdy w zespole miał to samo środowisko.
• Nadawaj uprawnienia wykonywalne w Gicie świadomie.

Czy spójne środowisko jest ważniejsze niż sam system?

Naszym zdaniem tak. Z testów opisanych w tym artykule wynika, że większość problemów między Windowsem, macOS i Linuksem to różnice w drobiazgach: końcach linii, wielkości liter, uprawnieniach i ścieżkach. Wszystkie da się wyłapać wspólnymi regułami zapisanymi w repozytorium (.gitattributes, .editorconfig, Docker i testy w CI) zamiast pamiętać o nich w głowie. Zespół, w którym każdy używa innego systemu, ale ma te same reguły, ma mniej kłopotów niż zespół na jednym systemie bez ustaleń. Dlatego zanim przekonasz kolegów do zmiany komputera, dodaj te pliki do repozytorium.

Czy na początku nauki warto zmienić system?

Naszym zdaniem nie: na początku używaj systemu, który już znasz. Nauka programowania sama w sobie jest pełna nowości: język, edytor, terminal, Git. Jeśli dołożysz do tego nieznany system, każdy błąd ma dwa możliwe źródła, czyli kod albo środowisko, i trudno ocenić, które z nich zawiodło. To prosta droga do problemów i szybkiego zniechęcenia, bo zamiast nad zadaniem godzinę spędzasz nad ścieżkami, uprawnieniami czy końcami linii. Znajomy system przyspiesza naukę, bo mniej rzeczy zgadujesz. Gdy podstawy masz opanowane, przesiadka na inny system staje się osobnym, kontrolowanym krokiem. Wyjątek stanowią sytuacje, w których kierunek nauki wymusza system, jak aplikacje na iOS.

Jeśli dopiero poznajesz terminal, zacznij od artykułu Terminal i wiersz poleceń dla początkujących, a o pracy w zespole z Gitem przeczytasz w pracy zespołowej nad aplikacją.