Granie na FreeBSD: czy da się odpalić Steam?

Linux systematycznie przebija się do mainstreamu jako system do gier. Według ankiety Steama jest już popularniejszy od macOS-a, a w marcu 2026 pierwszy raz przekroczył 5% udziału. Moim zdaniem to zdecydowanie za dużo. Zbyt popularny system, zbyt wiele gier działa, zbyt mało problemów.

Dlatego znalazłem lepszy system operacyjny. Darmowy, za zero złotych, całkowicie bezpłatny i nie musimy za niego płacić. Dziś jak prawdziwi wertykalni gracze odpalamy gry na FreeBSD.

A tak całkiem poważnie: FreeBSD to naprawdę ciekawy system, a granie na nim jest dobrym pretekstem, żeby opowiedzieć o całej rodzinie BSD. Jeśli granie na Macu albo Linuksie to jakaś forma wegetarianizmu, to granie na FreeBSD jest już hardkorowym weganizmem. Choć mogę was zaskoczyć, bo da się argumentować, że z FreeBSD i graniem miało styczność więcej ludzi niż z graniem na Linuksie. O tym na końcu.

W skrócie

• Z ośmiu gier z mojego zestawu testowego odpaliły trzy. Cyberpunk 2077, CS2 i Horizon Forbidden West działają, pozostałe pięć nie startuje.
• Największa niespodzianka: wydajność jest bardzo blisko Linuksa i Windowsa. Spodziewałem się totalnej masakry, a narzut okazał się mały.
• Z trzech firm produkujących GPU oficjalne sterowniki dla FreeBSD wydaje tylko NVIDIA. AMD i Intel nie wspierają BSD w ogóle.
• Steam działa przez Linuxulator, a gry przez natywnie skompilowanego Wine Protona. Taka hybryda rzeczywiście działa.
• Nie ma Ray Tracingu, DLSS-a ani obsługi kontrolerów. Zapisy Steam Cloud też się nie synchronizują.
• Z trzech kart graficznych, które testowałem w tym roku pod Linuksem i Windowsem, na FreeBSD ruszyła jedna.

Czym jest FreeBSD, a czym nie jest

Zacznijmy od sprostowania: FreeBSD to nie jest dystrybucja Linuksa. To zupełnie osobny system operacyjny. Na pierwszy rzut oka może wyglądać podobnie i część komend faktycznie się przenosi, ale fundamentalnie to dwie różne rzeczy.

Pierwsza wersja FreeBSD wyszła w 1993 roku, ale korzenie systemu sięgają 1969, czyli czasów powstania Uniksa. System królował na uniwersytetach i maszynach takich jak PDP-11 czy VAX, a na uniwersytecie Berkeley zaczęto dopisywać do niego kolejne elementy. Tak powstało Berkeley Software Distribution, w skrócie BSD.

Kernel kontra kompletny system

Najważniejsza różnica organizacyjna wygląda tak. Linux to samo jądro, a userland, konfigurację i resztę systemu składają różne zespoły. Stąd mamy dystrybucje, ale jądro jest prawie zawsze to samo, nie licząc drobnych modyfikacji.

FreeBSD to kompletny system: jądro, userland, dokumentacja i jeden zespół pracujący nad całością. W domyśle mniejsza fragmentacja. Inne systemy z rodziny, jak NetBSD, OpenBSD czy DragonFly BSD, mają zupełnie inne jądra i konfigurację, więc różnią się między sobą znacznie bardziej niż Debian od Archa.

Dla niedoświadczonego użytkownika FreeBSD potrafi jednak wyglądać znajomo. Podobne komendy do nawigowania po katalogach, możliwość odpalenia GNOME albo KDE, normalna instalacja Firefoksa czy Chromium. W dużej mierze umożliwia to system portów, gdzie mamy gotowe paczki do pobrania albo kompilujemy ze źródeł jak na Gentoo. Ciekawostka: Portage z Gentoo był inspirowany właśnie portami FreeBSD.

Co FreeBSD zrobiło pierwsze

FreeBSD wprowadziło w 2000 roku system Jails, czyli kontenery, trzynaście lat przed pojawieniem się Dockera. To realne pierwszeństwo i warto o nim pamiętać, bo dziś konteneryzacja kojarzy się wyłącznie z Linuksem.

Z systemem przez lata utożsamiano też ZFS, z którego sam korzystam na serwerze NAS i tym do montażu filmów. Tu jedno zastrzeżenie, bo to nie jest wynalazek FreeBSD: ZFS powstał w Sun Microsystems dla Solarisa, a FreeBSD przyjęło go w wersji 7.0 w 2008 roku i przez lata było jego najlepszym domem poza Solarisem. Linux dorobił się porządnej obsługi dopiero później, przez OpenZFS.

Wiele osób chwali też podejście FreeBSD do zarządzania siecią i do bezpieczeństwa systemu.

Czy FreeBSD ma sens w 2026 roku

Skoro i Linux, i FreeBSD są otwarte, to po co używać tego drugiego?

Uczciwa odpowiedź: jeśli macie mały homelab albo komputer do gier, Linux odhaczy wam wszystkie potrzeby. Dla jakichś 99% osób jest totalnie wystarczający i stąd jego popularność. FreeBSD to system kierowany głównie na serwery, a desktopy i laptopy są na dalszym priorytecie. Granie na nim brzmi wręcz jak proszenie się o kłopoty i zmuszanie systemu do czegoś, pod co nigdy nie był projektowany.

Z perspektywy homelabowca czy entuzjasty, poza poznaniem czegoś innego, FreeBSD ma dziś stosunkowo niewiele sensu i tyle samo rzeczy zrobicie łatwiej na pingwinie. Ale są zastosowania, w których robi pewne rzeczy lepiej, i o firmach, które z niego korzystają, opowiem na końcu.

Instalacja systemu

Potrzebujemy pendrive’a. Pobieramy obraz memstick, nagrywamy Rufusem, wrzucamy do komputera i mamy bootujący instalator.

Instalator nie jest spektakularny, ale kilka opcji zasługuje na uwagę. Wybrałem distribution sets, czyli tradycyjną metodę, a dodatkowo źródła i biblioteki 32-bitowe. Jako system plików poszedł ZFS, co okaże się później bardzo przydatne. Resztę zostawiłem domyślnie.

Po instalacji system jest kompletnym golasem. Nie ma Midnight Commandera, Vima ani htopa, o środowisku graficznym można zapomnieć. To nie błąd, tylko konsekwencja tego, że FreeBSD w założeniu jest systemem serwerowym i nie dokłada zbędnych pakietów. Zrobiłem więc update do najnowszej wersji i doinstalowałem podstawy, w tym fastfetcha.

Jaką kartę graficzną wybrać pod FreeBSD

Moim naturalnym instynktem jako linuksiarza był Radeon. Oba systemy są uniksopodobne, oba otwarte, więc AMD powinno być najlepsze, prawda?

Otóż nie. Wiecie, która z trzech firm produkujących GPU wydaje oficjalne sterowniki dla FreeBSD? NVIDIA. Serio. Tego nie miałem w swoim bingo.

AMD i Intel nie wspierają systemów BSD oficjalnie w ogóle. To, że cokolwiek da się zainstalować, jest wyłącznie zasługą społeczności portującej otwarte sterowniki z Linuksa. NVIDIA jako jedyna publikuje normalne, oficjalne sterowniki, przy czym tutaj kolejna ciekawostka: są one w pełni zamknięte, a nie półotwarte jak na Linuksie.

Skoro NVIDIA jako jedyna daje oficjalne wsparcie, poszedłem tą ścieżką. Do tego użyłem tej samej karty i platformy, na których testowałem Linuksa i Windowsa, żeby dało się porównać wydajność trzech systemów.

A co z Radeonem i Intelem?

Skoro już siedziałem w tym systemie, sprawdziłem pozostałe dwie karty z tegorocznych testów.

Mam sterownik Mesa 26.2.2, czyli całkiem nowy. Problem w tym, że porty sterowników jądra z Linuksa są mniej więcej z kernela 6.12, czyli z okolic 2024 roku. Realnie wsparcia dla RX 9060 XT tam nie było.

Sprawdziłem i tak. Dorzuciłem moduł do startu systemu, karta startuje, brakowało jej firmware’u, a po jego instalacji jest poprawnie rozpoznawana i raportuje 16 GB VRAM-u. Na końcu jednak się wysypuje, bo sterowniki są zbyt stare. To pokrywa się z doniesieniami z sieci: Radeonów z serii 9000 na FreeBSD nie da się dziś odpalić.

Z Intel Arc B580 temat jest jeszcze prostszy, bo sterownika Xe po prostu nie ma. Teoretycznie pierwsza generacja Arców powinna działać przez i915 i podobno się uruchamia, ale Battlemage’a na ten moment nie ruszycie.

Producent	Oficjalne sterowniki dla FreeBSD	Stan w praktyce
NVIDIA	Tak, w pełni zamknięte	Działa, pełna akceleracja OpenGL i Vulkan na X11
AMD	Nie	Porty społeczności z kernela 6.12, seria 9000 nie startuje
Intel	Nie	Brak sterownika Xe, Battlemage nie działa

Sterowniki, czyli pierwsza ściana

Na dzień dobry złe wieści. W repozytorium są zbudowane sterowniki NVIDIA, ale pakiety były niespójne: sam moduł pod starszą wersję 15.0, a pozostałe pakiety pod nowszą wersję sterownika, której nie mogłem zainstalować. Zostały dwie drogi: zbudować moduł samodzielnie albo zainstalować FreeBSD 15.

Poszedłem w budowanie. Warto zaznaczyć, że nie budujemy całego sterownika, tylko tę warstwę, która łączy zamknięty rdzeń sterownika z jądrem FreeBSD 15.1.

Zacząłem od drugiej strony, czyli od instalacji środowiska graficznego, żeby część pakietów była już na miejscu. Poszło KDE Plasma, co trochę trwało, bo do instalacji było ponad 700 paczek.

Zanim zacząłem psuć system, wykorzystałem jedną z zalet ZFS-a: zrobiłem migawkę. Nie jestem specjalistą od FreeBSD i szansa na wysadzenie systemu w kosmos była realna, więc możliwość cofnięcia się do stanu sprzed instalacji sterownika była bezcenna.

Potem z Gita zaciągnąłem najnowszą wersję portów, czyli przepisów na budowanie programów ze źródeł. Są podzielone na kategorie, więc można wejść na przykład w gry i zbudować Dooma, ale mnie interesował katalog graphics, gdzie leży firmware dla kart AMD i Intela oraz sterownik NVIDIA.

Wpisujemy make BATCH=yes install clean i patrzymy, jak skrypt pobiera pliki ze strony NVIDII i kompiluje moduł jądra. Ryzen 5600 miał trochę roboty. Potem trzeba było zbudować jeszcze linux-nvidia-libs, żeby Linuxulator działał jak należy, sprawdzić, czy paczki sterownika są na miejscu, i na wszelki wypadek zablokować je przed aktualizacją, żeby update nie wywalił driverów.

Chwila prawdy: dwie zmienne środowiskowe dla modułów, w tym ładowanie firmware’u GPU, potem ładowanie samego modułu. Wpisuję nvidia-smi i to faktycznie działa. Szczerze mówiąc nie sądziłem, że pójdzie tak gładko.

Odpaliłem menedżer sesji SDDM, zalogowałem się i mamy normalne środowisko graficzne na FreeBSD, z pełną akceleracją GPU na sesji X11, zarówno w OpenGL, jak i Vulkanie. Krzywa trudności jest tu zdecydowanie wyższa niż przy instalowaniu Archa czy Bazzite, ale system jest gotowy do pracy. Gdybym doinstalował Firefoksa i nic nie powiedział, wiele osób pomyślałoby, że patrzy na Linuksa.

Linuxulator, czyli hybryda Steam i Proton

Tu dochodzimy do najciekawszej architektonicznie części całej zabawy.

Linuxulator to warstwa zgodności wbudowana we FreeBSD, która pozwala uruchamiać programy skompilowane na Linuksa. To nie maszyna wirtualna, bo program wykonuje się natywnie na CPU. Trochę jak WSL1 w Windowsie, który tłumaczył wywołania systemowe Linuksa na inne jądro.

Po co nam to? Bo klient Steam nie istnieje w wersji na FreeBSD, tylko na Windowsa, macOS i Linuksa. Wychodzi z tego taka konstrukcja:

• Klient Steam chodzi jako linuksowa binarka przez Linuxlator
• Gry chodzą przez Wine Protona skompilowanego natywnie pod FreeBSD

Instalacja Linux Base’a od razu zwróciła błąd. Trzeba było doładować odpowiednie moduły jądra, włączyć usługi do autostartu dla Linuksa i jego systemu plików, ustawić kilka uprawnień zgodnie z dokumentacją i zweryfikować, czy zmiany weszły w życie.

Uruchamianie Steama

Najpierw natywny Wine Proton dla FreeBSD, potem Linux Steam Utils. Po instalacji dostajemy komunikat o ograniczeniach rozwiązania, między innymi o braku wsparcia dla kontrolerów.

Zrobiłem coś nietypowego: Steam dostał osobne konto bez uprawnień administratora. Na FreeBSD wbudowana przeglądarka Steama działa bez sandboksa, więc to konto samo w sobie jest piaskownicą zrobioną ręcznie. Jeśli coś pójdzie nie tak, szkody zostaną w jednym miejscu.

Utworzyłem więc osobnego użytkownika ze skryptem startowym, przelogowałem się, jednorazowo uruchomiłem bootstrap, który pobiera i wypakowuje pliki Steama, a potem odpaliłem skrypt startowy. Coś się pobrało, szybkie logowanie i proszę: Steam działa na FreeBSD. Widok doprawdy surrealistyczny.

Zanim odpalimy grę, jeszcze jedno. W ustawieniach, w zakładce kompatybilności, trzeba wybrać z listy wersję Wine dla FreeBSD. Protony wbudowane w Steama nie zadziałają przez Linuxlator. Jest tam też opcja LSU z Protonem 8, ale to stara wersja, a do tego rozwiązanie z definicji ma narzut, bo działa przez dodatkową warstwę Linuxlatora.

Pierwsza gra, czyli seria upokorzeń

Pobrałem Megabonka, żeby sprawdzić coś małego. Klikam Graj i gra się wywala. No, nie mogło być za łatwo.

Okazało się, że Megabonk ma natywną binarkę dla Linuksa, a ja zakładałem, że odpali się wersja windowsowa przez Protona. Trzeba więc wejść w kompatybilność konkretnej gry i wybrać jedno z dwóch:

• Linux Legacy Runtime, czyli linuksowa binarka przez Linuxlator
• FreeBSD Wine, czyli binarka windowsowa z translacją

Wybrałem Linux Legacy. Nie zadziałało. Wybrałem LSU ze Sniperem 3. Też nie zadziałało. Myślę sobie: fajnie, pół dnia stawiałem FreeBSD, żeby się okazało, że nic tu nie odpala.

Ale spokojnie. Błąd mówi, że nie może znaleźć Steam Runtime 3.0, więc może ręczna instalacja pomoże. Klikam Graj i coś się pokazuje, a potem crash. Dalej się wywala, ale jesteśmy krok dalej.

Próbowałem jeszcze różnych parametrów i zmiennych, ale z mojego doświadczenia odpalanie linuksowej binarki po prostu nie działa. Przełączam się więc na wersję windowsową przez Protona, aktualizuję grę, klikam Graj i też nie działa.

Znowu patrzę w logi i widzę, że nie zainstalował się automatycznie Proton 10. Instaluję ręcznie, klikam Graj, wyskakuje komunikat o instalacji Mono, coś mieli i w końcu gra odpala. Nie pobrało moich zapisów, ale kto by się przejmował takimi pierdołami. Wyciągamy jakieś 140 klatek na sekundę.

Podekscytowany zacząłem pobierać kolejne gry do testów. Radość nie trwała długo, bo Cyberpunk niby się odpala, ale mam czarny ekran. CS2? Czarny ekran. Horizon? Czarny ekran.

Postanowiłem siąść do tego następnego dnia ze świeżą głową. Przychodzę rano i wszystko naprawiło się samo. Nie wiem, czy mam dobre beboki w studio, czy po prostu pomógł restart, ale gry zaczęły działać. Oglądanie Cyberpunka chodzącego na FreeBSD to z technicznego punktu widzenia bardzo ciekawy obrazek.

MangoHud zepsuty od trzech lat i jak go naprawiłem

Gry działają, ale trafiłem na serię kolejnych problemów. Nie byłem w stanie skompilować z portów MangoHuda, czyli narzędzia do pomiaru FPS-ów. Trochę kłopot, gdy chce się zebrać sensowne dane do porównania.

Okazało się, że port jest zepsuty od trzech lat i nikt go nie naprawił.

Zrobiłem więc coś, czego robić nie chciałem: sięgnąłem po AI. Zapiąłem do tego Claude Code, przygotowałem PRD z trzema różnymi ścieżkami naprawy opisanymi na stronie projektu na GitHubie. I problem, którego nikt nie ruszył od trzech lat, model ogarnął w dziesięć minut. Powiem tak: AI nas zniszczy, a ja za pięć lat nie będę miał roboty.

Żarty na bok, MangoHud działa i mierzy sensownie, bo zebrane dane pokrywają się mniej więcej z wbudowanym benchmarkiem Cyberpunka. Ręki bym sobie za te wyniki nie uciął, ale wygląda to w miarę OK. Tylko w miarę, bo wartości 1% low wychodzą dziwnie wysokie, wyższe nawet niż na Windowsie, więc zwłaszcza je traktowałbym z przymrużeniem oka.

Co działa, a co nie

Do testów wybrałem te same gry, które sprawdzałem w tegorocznej edycji grania na Linuksie, bo chciałem porównać trzy systemy. Z ośmiu tytułów działają trzy.

Gra	Status	Prawdopodobna przyczyna
Cyberpunk 2077	działa	bez ray tracingu, opcja wyszarzona
CS2	działa	po przebojach z instalacją mapy benchmarkowej
Horizon Forbidden West	działa	przebieg testowy bez kombinowania
Resident Evil (najnowszy)	nie działa	podejrzenie: DRM Denuvo
Borderlands 4	nie działa	podejrzenie: DRM Denuvo
Doom: The Dark Ages	nie działa	wymaga ray tracingu, który nie działa
Forza Horizon 6	nie startuje	wymaga custom patchy dla NVIDII w Protonie
Assassin’s Creed Shadows	nie startuje	prawdopodobnie Ubisoft moment

Zanim ktoś powie, że specjalnie wybrałem gry stawiające FreeBSD w złym świetle: kompletnie nie o to chodzi. To po prostu te same tytuły, które testowałem na Linuksie i Windowsie, bo chciałem zrobić spójne porównanie. Pech, że nowe gry z różnych powodów się nie uruchamiają.

Co nie znaczy, że na FreeBSD nie da się grać. Sprawdziłem trochę mniejszych i starszych tytułów:

Gra	Status
Valheim	działa od strzału, w pełni grywalny
Minecraft (Java)	działa natywnie
Heroes 3	działa
Midnight Club 2 (32-bit)	działa, normalnie da się grać
Mugenics	działa całkiem fajnie
Hollow Knight: Silksong	działa
Megabonk	działa po walce z Protonem, około 140 FPS
Skyrim	odpala do menu, nie ładuje rozgrywki
GTA San Andreas	menu i pierwsza cutscenka, potem zawiesza się
Gothic	wywala się

Skoro działają Heroes 3 i Minecraft w wersji Java, oficjalnie uważam, że możemy nazwać FreeBSD systemem gamingowym, bo prawdziwy mężczyzna poza tymi dwiema grami nic więcej do szczęścia nie potrzebuje. Nie zapraszam do dyskusji.

Na ten moment nie ma czegoś takiego jak ProtonDB dla FreeBSD, więc trochę działa się na ślepo.

Czego brakuje

Ray tracing w ogóle nie działa. W Cyberpunku opcja jest wyszarzona, a Doom: The Dark Ages nie odpala się wcale. Próbowałem to debugować i sam Vulkan raportuje, że wspiera rozszerzenia do ray tracingu. Testowałem różne zmienne środowiskowe dla Protona, żeby wymusić DXR albo ukryć fakt użycia karty NVIDII, ale nic nie pomogło. Szukałem też w sieci, czy komukolwiek udało się odpalić ray tracing na FreeBSD, i informacji na ten temat praktycznie nie ma.

DLSS-a też nie włączymy. Pod Linuksem NVIDIA przekazuje Protonowi specjalne biblioteki DLL, a na FreeBSD albo się to nie dzieje, albo nie jest zaimplementowane po stronie tego Wine Protona, którego używam.

Kontrolery nie są obsługiwane, o czym uczciwie ostrzega sam komunikat po instalacji Linux Steam Utils.

Zapisy Steam Cloud się nie synchronizują. Podejrzewam, że Linuxlator mieszając ze ścieżkami albo uprawnieniami plików sprawia, że po prostu się nie pobierają.

Z dobrych informacji: działa Resizable BAR.

A wydajność?

Tu największa niespodzianka całego materiału. Trzy systemy leżą blisko siebie, bliżej niż bym się spodziewał. CS2 działa dokładnie tak, jak wynikałoby ze specyfikacji sprzętu. Horizon Forbidden West też chodzi porządnie i nie odbiega mocno od Linuksa.

Narzut jest niewielki, dużo mniejszy, niż zakładałem. Spodziewałem się totalnej kaszany, a wyszło doświadczenie przypominające granie na Linuksie z sześciu czy siedmiu lat temu: nie wszystko odpala, ale jak odpali, to działa porządnie.

Warto zwóricić uwagę że wartosić 1% Low są zaskakująco wysokie na FreeBSD. Nie jestem na 100% pewny pomiarów bo sam program mangohud jest zepsuty w portach od 2023 roku i do jego naprawy użyłem Claude Code z modelem Opus 5.5. Dlatego nie mogę ręczyć za wyniki 1% Low. Te średnie pokrywają się z tym co Cyberpunk i CS2 raportowały w swoich benchmarkach w grze.

FreeBSD jest bardziej gamingowy, niż myślicie

Obiecałem wrócić do tezy z początku. Otóż da się argumentować, że FreeBSD jest w gamingu popularniejszy niż macOS i Linux razem wzięte. Dlaczego? Bo systemy operacyjne PlayStation 3, 4 i 5 bazują na FreeBSD.

To oczywiście nie jest czyste FreeBSD, bo Sony wprowadziło całą masę modyfikacji, ale u podstaw jest właśnie ono i jest to udokumentowane. System PS3, znany wewnętrznie jako CellOS albo GameOS, jest forkiem FreeBSD i NetBSD. Orbis OS z PlayStation 4 to fork FreeBSD 9.0, a PS5 opiera się na nowszej gałęzi.

To kolejny dowód na to, że gdyby była chęć, czy od społeczności, czy od jakiejś firmy, FreeBSD jako system do gier mogłoby być solidną opcją. Tym bardziej, że PlayStation 4 i 5 niewiele się od zwykłych pecetów różnią.

Spotkałem się jeszcze z mitem, że Horizon z Nintendo Switch też działa pod FreeBSD. To już moim zdaniem daleka interpretacja, bo zapożyczone zostały tylko niektóre elementy stosu sieciowego z BSD, a reszta to własny wymysł Japończyków.

Licencja, która przypieczętowała losy

Skoro Sony używa FreeBSD do PlayStation, to dlaczego ten system przegrywa udziałem rynkowym z Linuksem, a nasze dzisiejsze doświadczenie było takie sobie?

FreeBSD przez lata wprowadzało ciekawe rozwiązania, a niektóre z nich, jak konteneryzacja, weszły do pingwina dopiero po latach. W gruncie rzeczy różnica wynika z licencji i to ona w dużej mierze przypieczętowała losy obu systemów.

Linux korzysta z GNU GPL2, która wymusza na firmach i osobach wprowadzających zmiany do jądra, żeby ich kod też był jawny i na tej samej licencji. Powstaje efekt kuli śnieżnej: im więcej osób pracuje nad Linuksem, tym lepszy się staje.

FreeBSD korzysta z licencji BSD, która upraszczając pozwala wziąć system i zrobić z nim co się chce, bez obowiązku publikowania zmian. Dlatego mimo że Sony aktywnie rozwija swoją gałąź FreeBSD, wszystko po ich stronie jest tajne i nie możemy ani tego zobaczyć, ani z tego skorzystać.

Ta na pozór subtelna różnica miała ogromny wpływ na rozwój obu systemów i w ostatnich latach bardzo przyspieszyła rozwój Linuksa. Mam wrażenie, że FreeBSD ma coraz mniejsze znaczenie na rynku serwerów.

Kto realnie używa FreeBSD

Żeby nie wyszło, że FreeBSD nie ma żadnego zastosowania, bo to byłby fałszywy obraz. Przykład z życia: u nas w studio główny serwer do montażu stoi na TrueNAS CORE, który pod spodem korzysta z FreeBSD. Choć pewnie już niedługo, bo wsparcie się skończyło. Wersja 13 była ostatnią na FreeBSD, a iXsystems przeniosło rozwój na linuksowego TrueNAS-a opartego na Debianie. Migracja to problem przyszłego Łukasza.

Poza tym:

• Netflix używa FreeBSD w swojej infrastrukturze CDN Open Connect. Ironicznie samego Netfliksa nie odpalicie natywnie na FreeBSD w przeglądarce, bo nie ma obsługi DRM.
• pfSense i OPNsense, czyli systemy dla routerów, o których nagrywałem osobny materiał.
• Dell oraz wspomniane wcześniej Sony.

System ma więc realne zastosowania i jest w użyciu. Chciałbym, żebyście to zapamiętali.

Podsumowanie

Co zaskoczyło pozytywnie

• Wydajność bardzo blisko Linuksa i Windowsa, o ile gra w ogóle odpali
• Pełna akceleracja GPU w OpenGL i Vulkanie na sesji X11, plus działający Resizable BAR
• Budowanie modułu sterownika NVIDII poszło gładko, wbrew moim obawom
• Starsze gry i produkcje niezależne często działają od strzału
• Migawki ZFS ratują skórę, gdy eksperymentujemy ze sterownikami

Co boli

• Pięć z ośmiu nowych gier AAA nie startuje, a Denuvo wygląda na jedną z przyczyn
• Brak ray tracingu, DLSS-a i obsługi kontrolerów
• Zapisy Steam Cloud się nie synchronizują
• Sterowniki AMD i Intela to porty społeczności z kernela sprzed dwóch lat, więc nowe karty nie działają
• Brak odpowiednika ProtonDB, więc kompatybilność sprawdza się metodą prób i błędów
• Narzędzia diagnostyczne bywają zepsute w portach latami

Werdykt

Jeśli ktoś bardzo by chciał grać na FreeBSD, to się da. Może nie w najnowsze tytuły AAA, ale starsze gry i produkcje niezależne działają, a narzut na wydajność jest znacznie mniejszy, niż się spodziewałem.

I tu wniosek, którego nie przewidywałem: gdyby popracować trochę bardziej nad sterownikami i Wine Protonem na FreeBSD, mógłby to być realnie kolejny sensowny system do gier. Zakładałem, że jeśli cokolwiek odpalę, wydajność będzie wyraźnie gorsza. Na tych kilku przykładach jest raczej podobna.

Jasne, nie działa wiele rzeczy. Ale hej, gdzieś trzeba zacząć.

Najczęstsze pytania

Czy da się grać na FreeBSD?

Tak, ale z zastrzeżeniami. Steam działa przez warstwę zgodności Linuxulator, a gry przez natywnie skompilowanego Wine Protona. Starsze tytuły i produkcje niezależne często działają od razu, nowe gry AAA znacznie rzadziej. Z ośmiu tytułów z mojego zestawu testowego odpaliły trzy.

Czy FreeBSD to dystrybucja Linuksa?

Nie. To zupełnie osobny system operacyjny z własnym jądrem, wywodzący się z Uniksa i prac uniwersytetu Berkeley. Podobieństwo komend i możliwość uruchomienia GNOME czy KDE bywa mylące, ale pod spodem jest inna architektura.

Jaka karta graficzna do FreeBSD?

NVIDIA, bo jako jedyna z trzech firm wydaje oficjalne sterowniki dla tego systemu. AMD i Intel nie wspierają BSD oficjalnie, a dostępne sterowniki są portami społeczności z kernela Linuksa 6.12, więc nowsze karty, takie jak Radeon RX 9060 XT czy Intel Arc B580, nie działają.

Czy PlayStation faktycznie działa na FreeBSD?

Tak. Systemy PlayStation 3, 4 i 5 bazują na FreeBSD, choć z ogromną liczbą modyfikacji Sony. Orbis OS z PS4 to fork FreeBSD 9.0. Ponieważ licencja BSD nie wymusza publikowania zmian, kod Sony pozostaje zamknięty.

Czy warto używać FreeBSD w 2026 roku?

Do homelabu albo komputera do gier Linux odhaczy wszystkie potrzeby i dla większości osób będzie wystarczający. FreeBSD ma sens tam, gdzie liczą się jego mocne strony: sieć, bezpieczeństwo, ZFS, Jails. Realnie używają go Netflix w CDN Open Connect, systemy routerów pfSense i OPNsense oraz Sony w konsolach.

Czy ray tracing działa na FreeBSD?

W moich testach nie. Vulkan raportuje wsparcie dla odpowiednich rozszerzeń, ale w Cyberpunku opcja jest wyszarzona, a gry wymagające ray tracingu, takie jak Doom: The Dark Ages, nie startują. Informacji o działającym ray tracingu na FreeBSD praktycznie nie ma w sieci.