--- title: "Sterowniki dla sprzętu, którego nie znamy" url: "https://kyberlinux.com/pl/blog/sterowniki-dla-sprzetu-ktorego-nie-znamy" description: "Własny deck to sprzęt, którego autorzy systemu nigdy nie testowali. Jak system z charakterem uczciwie traktuje nieznane płytki i czego nie chce wysłać." --- # Sterowniki dla sprzętu, którego nie znamy 20 października 2026·4 min czytania·Redakcja Komputer jednopłytkowy w zaokrąglonej otwartej ramie z trzema modułami czujników na krótkich kablach, dwa podłączone, jeden odłożony obok płytki Wyobraź sobie małą firmę inżynierską, która buduje własny terminal terenowy. Komputer jednopłytkowy od jednego producenta, wyświetlacz od drugiego, modem komórkowy kupiony, bo akurat był na stanie, i płytka z czujnikami, którą kolega zaprojektował przez kilka wieczorów. Obudowa wydrukowana na zapleczu. Taka maszyna nie istnieje nigdzie indziej. Osoba, która ją złożyła, nagrywa klucz instalacyjny, wkłada go i czeka. System wstaje, wyświetlacz działa, modem nie. Na ekranie nie ma błędu, jest tylko sieć, która nigdy się nie pojawia. Dwa dni później okazuje się, że przyczyną jest sterownik ściągnięty z wątku na forum, skompilowany pod jądro, którego nikt już nie zaktualizuje, i trzymający całą płytkę jako zakładnika pliku, którego nikt nie potrafi przeczytać. To zwykła historia wgrywania systemu na sprzęt, którego jego autorzy nigdy nie dotknęli. Sprzęt jest w porządku. Problemem jest to, jak system traktuje to, czego nie zna. ## Prawdziwa przyczyna Dystrybucja ogólnego przeznaczenia obiecuje, że zadziała na wszystkim, i dotrzymuje tej obietnicy, wysyłając wszystko: dziesiątki tysięcy sterowników, z których większość jest nieistotna dla jakiejkolwiek konkretnej maszyny, a część to binarne bloby, których nikt spoza producenta nie może obejrzeć. System z charakterem nie może złożyć takiej obietnicy. Musi powiedzieć, za jakim sprzętem stoi, jaki jedynie toleruje i co się dzieje, gdy spotyka płytkę, której nigdy nie widział. Większość systemów tego nie mówi, a lukę wypełnia zgadywanie. ## Gdzie nieznany sprzęt psuje się najczęściej **Lista zgodności jest domyślna.** „Działa na ARM i x86” brzmi jak lista, ale nią nie jest. Bez zadeklarowanego zestawu przetestowanych płytek każda instalacja jest eksperymentem, którego wynik użytkownik odkrywa sam, a system nie odróżnia konfiguracji wspieranej od szczęśliwej. **Sterowniki przychodzą jako bloby.** Binarny sterownik od producenta to kod na poziomie jądra, którego nikt nie może przejrzeć, przypięty do jednej wersji jądra, z licencją, która może zabraniać dalszej dystrybucji. W systemie, który ma być czytelny od jądra w górę, jeden blob czyni to twierdzenie fałszywym. **Jeden brakujący sterownik zatrzymuje rozruch.** System, który traktuje każdy element sprzętu jako niezbędny, zawodzi w całości, gdy jednego brakuje. Brak modemu powinien oznaczać brak sieci, a nie maszynę, która nigdy nie dochodzi do ekranu logowania. **Obejścia żyją poza systemem.** Moduł jądra zbudowany ręcznie, skrypt w katalogu domowym, łatka spoza drzewa. Działają do następnej aktualizacji i nie zostawiają śladu, który pozwoliłby komukolwiek odtworzyć tę konfigurację, co niweczy sens powtarzalnego builda. **Awaria jest cicha.** Sprzęt, który nie wstał, nie pojawia się nigdzie. Żadna linia statusu nie mówi „ten czujnik jest nieznany”, więc właściciel dowiaduje się o tym z braku danych, kilka tygodni później. **Producent staje się opiekunem.** Gdy płytka zależy od kodu, który może aktualizować tylko jej producent, historia aktualizacji systemu kończy się na tej płytce. Harmonogram producenta staje się harmonogramem bezpieczeństwa. ## Jak KyberLinux ma traktować sprzęt, którego nie zna Plan dla [KyberLinux](https://kyberlinux.com/pl) nie polega na tym, by działał na wszystkim. Polega na uczciwości co do tego, na czym działa, i na tym, by nieznane było stanem widocznym, możliwym do przejrzenia i do odwrócenia. **Mały wspierany rdzeń.** Krótka lista platform referencyjnych, każda faktycznie uruchomiona, każda ze sprawdzonym łańcuchem od firmware do środowiska uruchomieniowego. Krótka celowo: obietnica, której możemy dotrzymać, jest warta więcej niż długa lista, której nie możemy. **Zadeklarowana lista zgodności ze statusem.** Każda płytka, o której mamy zdanie, dostaje jeden z kilku prostych stanów: wspierana, buduje się, ale nieprzetestowana, wiadomo, że nie działa. Lista jest jawnym plikiem, więc status płytki to fakt, który każdy może przeczytać, a nie plotka z forum. **Sterowniki jako przejrzane pakiety.** Sterownik trafia do obrazu tak jak każdy inny element: jako źródło, w zmianie, którą każdy może przeczytać, zbudowany powtarzalnie, podpisany razem z resztą. To ta sama zasada, przez którą [powtarzalne buildy są argumentem o łańcuchu dostaw](https://kyberlinux.com/pl/blog/powtarzalne-buildy-to-argument-o-lancuchu-dostaw). Sterownik, który nie spełnia tej poprzeczki, nie wchodzi do obrazu bazowego. **Degradować, nie umierać.** Obraz bazowy uruchamia się z rdzeniem, którego płytka potrzebuje, i nic poza tym nie jest oznaczone jako niezbędne. Czujnik, którego brakuje, który jest nieznany albo odmawia inicjalizacji, pojawia się jako brakujący czujnik we własnym statusie systemu, gdzie widzą go i właściciel, i SI. Maszyna nadal wstaje, nadal się aktualizuje i nadal potrafi się wycofać. **Fork jest pełnoprawną ścieżką.** Płytka, której nigdy nie widzieliśmy, to zmiana w jawnej definicji obrazu, a nie prośba do nas. Jeśli budujesz własny deck, system jest pomyślany tak, by Twoja platforma mogła żyć w Twoim forku z tym samym buildem, tą samą weryfikacją i tym samym mechanizmem aktualizacji co nasza. ## Czego opiekunowie nie chcą wysyłać **Binarnych blobów w obrazie bazowym.** Jeśli jedyny sposób, by płytka działała, to sterownik, którego nikt nie może przeczytać, obraz bazowy go nie niesie. Płytka może nadal działać w forku, który zdecyduje się przyjąć blob; wtedy wybór należy do właściciela, na piśmie, a nie do nas, domyślnie. **Łatek spoza drzewa bez drogi w górę.** Łatka, którą trzeba będzie nieść wiecznie przy każdym nowym jądrze, to dług, który spłaca cały system. Przyjmujemy łatkę wtedy, gdy jest plan, by przestać jej potrzebować. **Deklaracji zgodności bez rozruchu.** Nic nie trafia na listę wspieranych, bo karta katalogowa wygląda dobrze. Płytka jest wspierana, gdy ktoś ją uruchomił, zaktualizował, wycofał aktualizację i zweryfikował na niej obraz. **Sprzętu, który wyłącza weryfikację.** Platforma, która działa tylko z wyłączonym zweryfikowanym rozruchem, może uruchomić system, ale nie może być oznaczona jako wspierana, a jej status mówi to na samej maszynie. Granica jest prosta: dziś żadna płytka nie jest wspierana, bo system nie jest wydany. Powyższe to zasady, które zamierzamy stosować, a nie lista sprzętu, do którego zostały zastosowane. Żaden producent sprzętu nie jest partnerem, a to, że jakaś płytka pojawia się w tym tekście, nie znaczy, że ją widzieliśmy. ## Test, który możesz zrobić dziś Weź płytkę, wokół której budowałbyś swój deck, i wypisz każdy układ, który potrzebuje sterownika: SoC, łączność bezprzewodową, modem, kontroler wyświetlacza, każdy czujnik. Dla każdego odpowiedz na piśmie na dwa pytania. Czy sterownik jest w głównym drzewie jądra, jako źródło? Jeśli nie, kto go publikuje i kiedy ostatnio go zaktualizował? Potem podziel listę na trzy kupki: główne drzewo jądra, źródło od producenta, binarka od producenta. Pierwsza kupka to ta część Twojego decka, za którą może stanąć każdy czytelny system. Druga to praca, którą ktoś może przejrzeć. Trzecia to część Twojej maszyny, która zawsze będzie należeć do producenta, niezależnie od systemu, jaki na nią wgrasz. Jeśli na trzeciej kupce leży modem albo SoC, deck jeszcze nie jest Twój i żaden klucz instalacyjny tego nie zmieni. System może natomiast powiedzieć Ci prawdę o każdej kupce, pracować dalej, gdy jedna z nich jest pusta, i zapisać, co zobaczył. Ta ostatnia część to temat następnego wpisu: [logi, które agent czyta, a człowiek rozumie](https://kyberlinux.com/pl/blog/logi-ktore-agent-czyta-a-czlowiek-rozumie). A jeśli chodzi o płytkę, którą już masz, zacznij od [KyberLinux na sprzęcie, który już masz](https://kyberlinux.com/pl/blog/kyberlinux-na-twoim-sprzecie). - sterowniki - zgodność - komputery jednopłytkowe - otwarte oprogramowanie - KyberDeck ## Czytaj dalej - [Logi, które agent czyta, a człowiek rozumie](https://kyberlinux.com/pl/blog/logi-ktore-agent-czyta-a-czlowiek-rozumie) - [Android XR to Linux pod spodem. To jeszcze nie otwartość](https://kyberlinux.com/pl/blog/android-xr-to-linux-pod-spodem)