Terminal, który wyręcza pulpit – praktyczny zestaw narzędzi na Raspberry Pi 4B z 1 GB RAM

Czysty Raspberry Pi OS Lite na Raspberry Pi 4B z jednym gigabajtem pamięci nie jest „okrojoną wersją komputera”. To świadomie lekka baza pod serwer, automatyzację i cichą pracę w tle. Nie ma tu pulpitu, który sam zjada pamięć, zanim zdążysz uruchomić własny program. Jest powłoka, sieć i zestaw usług, które dokładujesz dopiero wtedy, gdy naprawdę są potrzebne.

Obraz o nazwie 2026-10-06-raspios-bookworm-armhf-lite.img mówi o tej bazie więcej, niż wygląda na pierwszy rzut oka. Data w nazwie to dzień zbudowania obrazu. Bookworm oznacza, że system stoi na Debianie 12, więc pakiety, ścieżki i nawyki administracyjne są debianowe, a nie wymyślone specjalnie pod malinę. Człon armhf oznacza 32-bitowy system z hard float, czyli ze sprzętowym liczeniem liczb zmiennoprzecinkowych. Lite oznacza brak środowiska graficznego. Na płytce z 1 GB RAM taki wybór jest zwykle trafniejszy niż „pełny” system z pulpitem, który ładnie wygląda przez pięć minut, a potem zostawia zbyt mało miejsca na właściwą pracę.

Płytka ma cztery rdzenie i całkiem sprawny procesor, ale pamięć operacyjna jest tu zasobem, którego nie da się oszukać ładnym interfejsem. Dlatego sensowny zestaw na start to nie kolejny panel w przeglądarce, tylko kilka programów terminalowych: do podglądu procesów, do sesji, do plików i do dysku. Da się nimi pracować przez SSH, z innego komputera, bez podłączania monitora. I da się je dobrać tak, żeby narzędzie diagnostyczne nie było większym problemem niż usterka, którą ma pokazać.

Czym naprawdę jest ta lekka baza i dlaczego 1 GB zmienia zasady

Raspberry Pi 4B w wersji z 1 GB pamięci jest maszyną wystarczającą do wielu cichych zadań: lekki serwer plików, mały serwis WWW, bramka do czujników, harmonogram skryptów, prosty węzeł automatyzacji. Nie jest maszyną do równoległego trzymania pulpitu, przeglądarki, bazy danych i kilku kontenerów „na wszelki wypadek”. Przy tej ilości RAM każdy zbędny proces widać nie w teorii, tylko w tym, że system zaczyna sięgać po plik wymiany i całość nagle robi się ociężała.

System Lite zostawia większość pamięci Tobie. Po starcie działa jądro, kilka usług systemowych i powłoka. Nie ma menedżera okien, nie ma przeglądarki rysującej kartę graficzną w tle, nie ma zestawu programów, z których i tak korzystałbyś raz na kwartał. To jest właśnie ta „świetna, lekka baza”: pusta na tyle, żebyś sam zdecydował, co ma na niej mieszkać. Cena jest prosta. Pracujesz tekstem. Konfiguracja, podgląd i naprawy odbywają się w terminalu, najczęściej przez SSH, z laptopa albo innego komputera w tej samej sieci.

Warto od razu rozumieć konsekwencję wyboru armhf. Raspberry Pi 4 potrafi pracować w trybie 64-bitowym, ale ten obraz jest 32-bitowy. Przy 1 GB pamięci ma to pewien praktyczny sens: wskaźniki i część struktur w pamięci są mniejsze, więc niektóre usługi zużywają odrobinę mniej RAM niż ich odpowiedniki 64-bitowe. Ma to też granicę. Część nowszego oprogramowania publikowana jest już głównie na arm64, a pojedynczy proces 32-bitowy i tak nie jest tu problemem, bo cała maszyna ma tylko gigabajt. Jeśli kiedyś projekt wyrośnie z tej płytki, migracja na system 64-bitowy będzie naturalna. Na start, do serwera i automatyzacji, obraz lite w wariancie armhf jest spójnym wyborem, a nie pomyłką.

Świeży obraz nie jest jeszcze „Twoim serwerem”. W aktualnych wydaniach Raspberry Pi OS nie ma dawnego, ogólnie znanego konta z hasłem wpisanym w każdej instrukcji sprzed lat. Użytkownika, dostęp przez SSH i ewentualnie sieć bezprzewodową ustawia się przy wgrywaniu karty, zwykle w programie do przygotowania obrazu, albo plikami na partycji rozruchowej. Dopiero po pierwszym wejściu na powłokę zaczyna się właściwa praca: aktualizacja pakietów i dołożenie narzędzi, których system celowo nie wciska na siłę.

Zanim cokolwiek doinstalujesz, system powinien znać aktualny spis pakietów. Wystarczy zwykłe odświeżenie, a potem instalacja tego, co naprawdę wejdzie do codziennego zestawu:

sudo apt update
sudo apt install htop btop glances tmux mc ncdu iotop

Te siedem nazw pokrywa większość sytuacji, w których na małej malinie trzeba szybko odpowiedzieć na trzy pytania: co zjada procesor i pamięć, czy sesja przeżyje zerwanie łącza oraz co dzieje się z kartą pamięci. Nie trzeba ich wszystkich trzymać otwartych naraz. Trzeba wiedzieć, po które sięgnąć i czego od niego nie wymagać.

Jest jeszcze jedna rzecz, o której łatwo zapomnieć, patrząc tylko na megabajty RAM. W tej maszynie wąskim gardłem bywa nie procesor, tylko karta SD. Jest wolniejsza niż dysk w zwykłym komputerze, gorzej znosi ciągły zapis i staje się jedynym dyskiem systemu, pliku wymiany oraz logów. Narzędzia z tego zestawu są więc nie tylko „do podglądu wykresów”. Są do tego, żeby w porę zauważyć, że jakiś proces spokojnie zużywa kartę, zanim zacznie zgłaszać błędy zapisu.

Trzy spojrzenia na procesy – od spokojnego htop do szerokiego glances

Klasyczne polecenie top jest wszędzie i na tym jego zaleta się kończy. Działa, ale jest toporne: słabo prowadzi wzrok, niepokojąco łatwo w nim przeoczyć proces, który właśnie urósł, a sortowanie i filtrowanie wymagają pamiętania skrótów, których używa się raz na miesiąc. Na maszynie z 1 GB RAM chcesz czegoś, co w kilka sekund pokaże cztery rdzenie, pamięć, plik wymiany i listę procesów, bez uruchamiania czegokolwiek ciężkiego. Od tego jest htop.

htop jest interaktywnym podglądem procesów w bibliotece ncurses. Po uruchomieniu samym poleceniem htop widzisz u góry paski obciążenia rdzeni, zużycie pamięci i swap, a niżej listę procesów, którą da się przewijać, sortować i przeszukiwać. To nadal klasyk, bo robi jedną rzecz bardzo dobrze i prawie nie kosztuje. Sam program zajmuje mało pamięci, startuje natychmiast i nie dokłada zauważalnego obciążenia na Raspberry Pi, które i tak ledwo dyszy. Przy 1 GB to nie jest drobiazg. Narzędzie diagnostyczne, które samo domaga się dziesiątek megabajtów, potrafi zakłamać obraz, który właśnie oglądasz.

W codziennej pracy wystarcza kilka odruchów. F6 zmienia kryterium sortowania, więc raz patrzysz na procesor, raz na pamięć. F5 przełącza widok drzewa, co na malinie bywa ważniejsze niż surowa lista: widać, który proces jest rodzicem, a który tylko dzieckiem usługi uruchomionej przez system. F4 filtruje po nazwie, gdy szukasz jednej konkretnej usługi wśród wątków. F9 pozwala zakończyć proces, ale na serwerze lepiej traktować to jako ostateczność, nie jako sposób „sprzątania”. Zabicie procesu nie tłumaczy, dlaczego urósł. Najpierw nazwa, użytkownik, czas działania, zużycie pamięci. Dopiero potem decyzja.

htop dobrze pokazuje też stan, którego na tej płytce nie wolno ignorować: sięganie po swap. Raspberry Pi OS potrafi trzymać plik wymiany na karcie SD. Gdy pamięć się kończy, system nie staje od razu. Zaczyna przepisywać kawałki RAM na kartę. Z zewnątrz wygląda to jak „nagle wszystko muli”, choć procesor wcale nie jest zajęty w stu procentach. W htop widać wtedy rosnący pasek wymiany i procesy, które trzymają pamięć. To jest moment, w którym nie dokładasz kolejnej usługi, tylko sprawdzasz, co już działa i czy da się to odchudzić.

Gdy obraz z htop przestaje wystarczać, sięga się po btop. To nowszy podgląd tej samej maszyny, rysowany dużo śmielej: wykresy procesora, pamięci, dysku i sieci na jednym ekranie, czytelne kolory, obsługa myszy w terminalu, który ją potrafi przekazać. Nie jest już tylko listą procesów. Jest skrótem stanu całego komputera. Na łączu SSH wygląda efektownie i często szybciej odpowiada na pytanie „czy to procesor, pamięć, dysk, czy sieć”, bo te cztery rzeczy widać bez przełączania programów.

Ta efektowność ma koszt. btop jest cięższy od htop. Sam w sobie nie przewróci Raspberry Pi 4B, ale częste odświeżanie wykresów bierze trochę procesora, a program zajmuje więcej pamięci niż stary klasyk. Na płytce z 1 GB używa się go świadomie: do przeglądu, do chwili diagnostyki, do pokazania sobie, jak maszyna wygląda pod obciążeniem. Nie zostawia się go odpalonego na stałe w tle „bo ładnie mruga”. Jeśli potrzebujesz tylko listy procesów i pasków pamięci, htop nadal wygrywa. Jeśli chcesz jednym spojrzeniem zobaczyć, że sieć stoi, dysk pisze, a jeden rdzeń jest zajęty przez pojedynczy proces, btop oddaje ten obraz czytelniej.

Trzecie narzędzie, glances, jest już innym gatunkiem programu. To kombajn monitorujący napisany w Pythonie. W jednym widoku zbiera procesor, pamięć, obciążenie, dyski, sieć, czujniki, listę procesów i sporo informacji, które w mniejszych narzędziach trzeba by składać z kilku poleceń. Da się go uruchomić lokalnie w terminalu, da się też wystawić w trybie klienta i serwera albo podejrzeć przez prosty widok w przeglądarce. Na większej maszynie jest wygodny właśnie dlatego, że nie każe wybierać: pokazuje prawie wszystko.

Na Raspberry Pi z 1 GB ta szerokość jest jednocześnie zaletą i ostrzeżeniem. glances dociąga zależności Pythona i sam potrafi zająć zauważalny kawałek pamięci, zwłaszcza gdy włączysz dodatkowe wtyczki. Uruchomiony „na chwilę” jest bardzo pomocny. Uruchomiony na stałe, z krótkim czasem odświeżania, sam staje się usługą, którą trzeba uwzględnić w budżecie RAM. Do tego widok bywa gęsty. Przy pierwszym kontakcie łatwo zgubić się w liczbach, które dla tej płytki nic nie zmieniają. Sensowny nawyk jest taki: htop na co dzień, btop gdy chcesz zobaczyć dysk i sieć razem z procesami, glances gdy szukasz szerokiego rzutu i jesteś gotów zapłacić za niego odrobiną pamięci.

Jest też różnica w tym, co które narzędzie mówi o sieci. htop prawie jej nie dotyczy. btop pokazuje liczniki i wykres ruchu, więc przy zwykłym pytaniu „czy w ogóle coś płynie” zwykle wystarcza. glances schodzi niżej i zestawia sieć z resztą maszyny, co przydaje się, gdy nie wiesz, czy wąskim gardłem jest łącze, dysk, czy proces. Osobnego, ciężkiego monitora sieci nie potrzeba w pierwszym zestawie. Przy 1 GB lepiej mieć jedno narzędzie, które już umie pokazać interfejsy, niż dokładać kolejne usługi „profilaktycznie”.

Wspólna zasada dla całej trójki jest nudna i bardzo praktyczna. Monitor nie jest ozdobą pulpitu, którego zresztą nie ma. Otwierasz go, czytasz, zamykasz. Zostawiony na wiele godzin w sesji, z agresywnym odświeżaniem, sam dopisuje się do obciążenia, które miałeś zmierzyć. Na dużej maszynie tego nie widać. Na tej widać.

Sesja i pliki – tmux oraz Midnight Commander jako codzienne oparcie

Praca przez SSH ma jedną wadę, która prędzej czy później spotyka każdego. Łącze pada, laptop zasypia, domowy router na chwilę gubi adres, a razem z sesją znika to, co właśnie robiłeś w powłoce. Jeśli w tym momencie szła aktualizacja, długie kopiowanie albo skan dysku, nie masz już pewności, czy proces żyje. tmux rozwiązuje dokładnie ten problem i przy okazji porządkuje pracę na małym ekranie terminala.

tmux jest multiplekserem terminala. Mówiąc po ludzku: stawia na malinie sesję, która żyje niezależnie od tego, czy Twoje SSH jeszcze trwa. Wchodzisz na płytkę, uruchamiasz tmux, pracujesz, a gdy chcesz odejść, odłączasz sesję skrótem poprzedzonym prefiksem Ctrl-b, a potem d. Procesy w środku pracują dalej. Po ponownym zalogowaniu wracasz poleceniem tmux attach i zastajesz ten sam ekran, te same okna, ten sam stan. To nie jest wygoda dla zaawansowanych. To podstawowe zabezpieczenie przed głupią utratą pracy na łączu, które nie jest wieczne.

W środku sesji da się dzielić przestrzeń bez uruchamiania drugiego logowania. Nowe okno, podział na panele, przełączanie się między powłoką z logiem a powłoką z edytorem: wszystko zostaje na płytce, nie na laptopie. Przy 1 GB RAM ma to jeszcze jeden, cichszy sens. Zamiast otwierać kilka równoległych połączeń SSH i w każdym trzymać własne środowisko, trzymasz jedną sesję i kilka widoków. Narzędzia takie jak htop mogą wisieć w jednym panelu, a w drugim zostaje wolna powłoka do poleceń. Gdy diagnostyka się kończy, zamykasz panel, a nie całą sesję.

Warto nauczyć się tylko małego rdzenia, a resztę doczytywać z pomocy, gdy naprawdę będzie potrzebna. Nową sesję tworzysz gołym tmux albo tmux new -s nazwa, jeśli chcesz ją później rozpoznać po nazwie. Powrót to tmux attach -t nazwa. Lista sesji to tmux ls. Prefiks Ctrl-b poprzedza polecenia samego tmux: nowe okno, podział pionowy, podział poziomy, przejście między panelami. Na początku łatwo o konflikt z programami, które też chcą używać sterowania z klawiatury. To normalne. Po kilku dniach prefiks wchodzi w palce i przestaje być rytuałem.

Na serwerze tmux przydaje się jeszcze do rzeczy, których nie widać w samouczkach. Długie zadanie, które nie powinno zależeć od laptopa, uruchamiasz w sesji i odłączasz się świadomie, zamiast liczyć na to, że terminal „jakoś wytrzyma”. Aktualizacja systemu, przebudowa małego projektu, import danych, pierwsze uruchomienie usługi, która lubi wypisać długi log: wszystko to lepiej przeżywa w sesji niż w gołym SSH. Nie zastępuje to usługi systemowej. Rzeczy, które mają działać po restarcie płytki, i tak powinny być usługami. tmux jest na pracę człowieka, nie na ciche życie demona.

Do plików tradycyjna powłoka wystarcza, dopóki dobrze pamiętasz ścieżki i nie musisz co chwilę porównywać dwóch katalogów. Na karcie SD pełnej logów, kopii, katalogów usług i resztek po testach szybciej pracuje się dwupanelowym menedżerem. Midnight Commander, uruchamiany poleceniem mc, jest właśnie tym: klasycznym, tekstowym menedżerem plików, który nie udaje Eksploratora, ale oddaje jego najważniejszą rzecz. Dwa panele, podgląd, kopiowanie, przenoszenie, katalogi i prosta nawigacja bez składania długich poleceń za każdym razem.

mc jest lekki, działa czysto przez SSH i nie wymaga pulpitu. Klawisze funkcyjne, jeśli terminal je poprawnie przekazuje, robią to, co podpowiada dolny pasek: podgląd, edycja, kopiowanie, przenoszenie, założenie katalogu, usunięcie. Tabulator przełącza panele. W środku jest też prosty edytor i podgląd plików, więc drobną poprawkę konfiguracji da się zrobić bez wychodzenia do osobnego programu. Na małej malinie to wygodne zwłaszcza wtedy, gdy nie chcesz uczyć się przy każdej drobnostce, czy dany plik otwierać w nano, czy w innym edytorze. Do większej edycji i tak lepiej użyć narzędzia, które znasz. Do rozejrzenia się po dysku mc jest często szybszy niż seria ls i cd.

Oba programy dobrze się uzupełniają i nie warto ich stawiać przeciwko sobie. tmux pilnuje sesji i układu pracy. Midnight Commander pilnuje plików. Typowy, spokojny układ na tej płytce wygląda tak, że po zalogowaniu wracasz do sesji, w jednym panelu masz podgląd procesów, w drugim menedżer plików albo zwykłą powłokę, a po skończonej robocie odłączasz się i zostawiasz maszynę w spokoju. Nic z tego nie wymaga interfejsu graficznego. Nic z tego nie rezerwuje sobie setek megabajtów „na później”.

Jest tylko jeden nawyk, który warto sobie wpoić wcześniej. mc ułatwia kasowanie. Na serwerze łatwość nie jest zawsze zaletą. Zanim potwierdzisz usunięcie katalogu, który wygląda na śmieci, sprawdź, czy nie jest to dane usługi, katalog roboczy automatyzacji albo jedyna kopia konfiguracji. Menedżer plików skraca drogę do porządku. Nie skraca odpowiedzialności za to, co właśnie znika z karty.

Karta pamięci pod lupą – ncdu pokazuje miejsce, iotop pokazuje ruch

Na Raspberry Pi z systemem na karcie SD dwa pytania wracają częściej niż wykresy procesora. Pierwsze: co zajęło miejsce. Drugie: co właśnie pisze albo czyta, nawet jeśli miejsca jeszcze formalnie nie brakuje. Tradycyjne df odpowie tylko na połowę pierwszego pytania. Powie, że partycja jest pełna w 90 procentach, i na tym się skończy. Nie powie, który katalog urósł. Do tego służy ncdu.

ncdu skanuje wskazane drzewo katalogów i pokazuje je jako interaktywną listę rozmiarów, od największych pozycji. Uruchomione jako ncdu / przechodzi przez cały system. Uruchomione jako ncdu /var albo ncdu /home jest często mądrzejsze, bo od razu zawęża podejrzenie. Po skanie poruszasz się strzałkami, wchodzisz w katalogi i widzisz, czy miejsce zjadły logi, pamięć podręczna pakietów, stare kopie, katalog usługi, czy może jeden zapomniany plik z danymi. To jest narzędzie, które na małej karcie zwraca się przy pierwszym użyciu. Pełna karta na Raspberry Pi nie kończy się eleganckim komunikatem. Kończy się dziwnym zachowaniem usług, przerwaniem zapisu i czasem systemem, który nie potrafi już dopisać nawet własnego dziennika.

Skan nie jest darmowy. ncdu musi odczytać metadane plików, a na dużej strukturze katalogów robi sporo odczytów. Na wolnej karcie pierwszy przebieg przez / potrafi potrwać i w tym czasie dysk jest zajęty. Lepiej uruchamiać go świadomie, najlepiej w sesji tmux, niż przerywać w połowie i zaczynać od nowa. Po skanie program pozwala też usuwać pozycje z poziomu interfejsu. To wygodne i właśnie dlatego niebezpieczne. Dobrą praktyką jest najpierw tylko oglądać, zapisać sobie ścieżkę winowajcy i dopiero potem zdecydować, czy to śmieć. Katalog pamięci podręcznej menedżera pakietów da się zwykle odtworzyć. Katalog z danymi automatyzacji już nie.

Typowe miejsca, które na tej płytce puchną bez Twojej winy, są dość powtarzalne. Dzienniki systemowe potrafią urosnąć, gdy jakaś usługa wpada w pętlę błędów i pisze ten sam komunikat tysiące razy. Pamięć podręczna apt zostaje po instalacjach. Katalog domowy zbiera testowe pliki, zrzuty i kopie konfiguracji. Czasem miejsce znika w katalogu tymczasowym, czasem w danych programu, który „tylko przez chwilę” zapisywał obrazki albo pomiary. ncdu nie naprawia przyczyny. Odsłania ją na tyle konkretnie, że nie musisz zgadywać.

Sam rozmiar to jednak nie cała historia karty. Proces może zajmować mało miejsca na dysku, a mimo to ciągle pisać: dopisywać krótkie linie do logu, przepłukiwać bazę, aktualizować plik stanu, sięgać po swap. Tego ncdu nie pokaże, bo patrzy na to, ile jest zajęte, a nie na to, kto w tej sekundzie rusza nośnikiem. Od bieżącego ruchu jest iotop.

iotop pokazuje operacje wejścia i wyjścia według procesów. Potrzebuje uprawnień administratora, więc uruchamia się go jako sudo iotop. Wariant sudo iotop -o jest zwykle przyjemniejszy, bo zostawia na ekranie głównie te procesy, które właśnie coś czytają albo piszą, zamiast długiej listy ciszy. Widzisz tempo odczytu i zapisu oraz to, który program jest źródłem ruchu. Na Raspberry Pi to jedno z najbardziej praktycznych narzędzi diagnostycznych, jakie można dołożyć do lekkiego systemu. „Zjadacz karty” rzadko wygląda groźnie w liście procesów. Często jest to spokojna usługa, która pisze mało, ale bez przerwy.

Są sytuacje, w których iotop po poprawnej instalacji i tak nie pokaże danych. Potrzebuje informacji rozliczanych przez jądro. Jeśli jądro nie udostępnia tego rozliczenia, program powie o tym wprost, zamiast udawać wynik. To nie jest wtedy zepsuty pakiet i nie leczy się tego losowym dokładaniem modułów. W takiej sytuacji bieżący obraz dysku i tak da się częściowo zobaczyć w btop albo w glances, a do pytania „co zajmuje miejsce” zostaje ncdu. Na typowym, aktualnym jądrze Raspberry Pi OS narzędzie jednak zwykle robi to, do czego zostało wzięte: wskazuje proces, który właśnie obciąża nośnik.

Warto rozróżnić te dwa spojrzenia, bo łatwo je pomylić. ncdu odpowiada na pytanie o stan: gdzie jest miejsce. iotop odpowiada na pytanie o chwilę: kto teraz rusza kartą. Pełna karta i zajeżdżona karta to nie to samo. Karta może mieć jeszcze sporo wolnego miejsca i jednocześnie dostawać stały strumień zapisów, który skraca jej życie i spowalnia system. Odwrotnie, karta może być prawie pełna, a w danej chwili żaden proces nie musi intensywnie pisać. Dlatego te programy stoją obok siebie, a nie zamiast siebie.

Na płytce z 1 GB do tego obrazu dokłada się plik wymiany. Gdy pamięć się kończy, system zaczyna zapisywać jej kawałki na karcie. W htop widać rosnący swap, w iotop widać ruch, a całość sprawia wrażenie, jakby dysk nagle stał się wąskim gardłem wszystkiego. Czasem tak jest. Czasem dysk jest tylko ofiarą braku RAM. Zanim zaczniesz szukać „uszkodzonej karty”, sprawdź, czy maszyna po prostu nie dostała za dużo usług naraz. Lekki system nie obroni się sam przed ciężkim pomysłem.

Z tego samego powodu nie warto traktować karty SD jak taniego, nieskończonego dysku na logi. Usługa, która pisze pomiar co sekundę, kamera, która zrzuca pliki bez limitu, albo dziennik, którego nikt nie przycina, potrafią wykończyć nośnik szybciej niż sam wiek sprzętu. iotop jest tu sygnalizatorem, nie naprawą. Jeśli jakiś proces regularnie siedzi na szczycie zapisu, to on jest kandydatem do ograniczenia, przeniesienia danych albo wygaszenia, a nie „normalnym szumem małego komputera”.

Spokojny rytm pracy, gdy pamięci jest naprawdę mało

Sam zestaw programów nie zrobi z tej płytki dobrego serwera. Zrobi to sposób, w jaki się ich używa. Przy 1 GB RAM dobra praca wygląda niepozornie. Po zalogowaniu przez SSH wracasz do sesji tmux, jeśli jakaś została. Rzucasz okiem na htop, ale tylko wtedy, gdy coś budzi niepokój albo właśnie dokładasz nową usługę. btop otwierasz, gdy chcesz zobaczyć dysk i sieć w jednym kadrze. glances zostawiasz na trudniejszą diagnostykę, a nie na stały widok w tle. Pliki ogarniasz w mc, gdy katalogów jest za dużo, żeby żonglować ścieżkami. Po miejsce sięgasz ncdu, po bieżący zapis iotop. Resztę czasu system ma być cicho i zajmować się tym, do czego go postawiłeś.

Aktualizacje i instalacje rób w sesji, nie w gołym połączeniu, które może paść w połowie. Przed dołożeniem kolejnego programu warto przez chwilę popatrzeć, ile pamięci zostaje przy normalnym obciążeniu, a nie przy pustym systemie tuż po restarcie. Liczba „wolne 700 MB” nic nie znaczy, jeśli wieczorem dochodzi harmonogram, baza i usługa sieciowa. Na tej płytce budżet liczy się w setkach megabajtów, nie w gigabajtach zapasu. Program napisany w Pythonie, dodatkowy panel, drugi kombajn monitorujący „dla pewności” — każdy z nich jest mały z osobna i razem potrafią zepchnąć system w wymianę.

Warto też nie mylić lekkości obrazu z lekkością dowolnego oprogramowania, które da się na nim zainstalować. Lite oznacza brak pulpitu, nie magiczne zmniejszenie każdej usługi. Baza danych, system kolejkowy, rozpoznawanie obrazu, spory serwer WWW z wtyczkami: to wszystko może być legalnym celem tej płytki, ale nie jednocześnie i nie bez pomiaru. Najuczciwszy test jest nudny. Uruchom usługę, podejrzyj ją w htop po kilku minutach, a nie tylko tuż po starcie, i sprawdź w iotop, czy nie pisze bez przerwy. Jeśli po godzinie pamięć rosła, a karta była ciągle ruszana, to nie jest „charakterystyka Raspberry Pi”. To znak, że ta konkretna usługa nie mieści się w tym konkretnym budżecie.

32-bitowy Bookworm w wariancie lite sprzyja takiemu podejściu, bo nie kusi pulpitem. Nie znaczy to, że każdy pakiet z repozytorium jest tu dobrym pomysłem. Przy wyborze oprogramowania patrz na dwa kryteria, zanim zachwycisz się listą funkcji: ile bierze pamięci na spokojnym biegu i czy musi ciągle pisać na kartę. Narzędzia z tego artykułu same wypadają w tym teście dobrze, pod warunkiem że nie zostawiasz najcięższego z nich włączonego bez powodu. htop, tmux, mc, ncdu i iotop są lekkie. btop jest cięższy, ale nadal rozsądny jako podgląd. glances jest najszerszy i właśnie dlatego najłatwiej przesadzić z jego stałą obecnością.

Jest jeszcze kwestia porządku po instalacji. Pakiety diagnostyczne nie muszą startować razem z systemem i nie powinny. Odpalasz je ręcznie, gdy są potrzebne. Usługi, które mają przeżyć restart, konfigurujesz osobno, świadomie, z limitem tego, co naprawdę musi działać po włączeniu zasilania. Mała płytka uruchomiona w szafie albo przy biurku bywa włączona miesiącami. Każdy zbędny start to nie tylko megabajty. To też kolejny dziennik, kolejny timer i kolejna rzecz, która może zacząć pisać na kartę w najmniej ciekawym momencie.

Gdy system już stoi, nie musisz zaglądać do niego rytualnie co godzinę. Wystarczy kilka sytuacji, w których ten zestaw naprawdę się przydaje. Po dołożeniu nowej usługi. Po aktualizacji, która zachowała się inaczej, niż zakładałeś. Gdy karta nagle robi się pełna. Gdy łączę SSH zaczyna odpowiadać z opóźnieniem, choć sieć wygląda normalnie. Gdy automatyzacja „czasem” przestaje wyrabiać się w czasie. W każdej z tych chwil masz już pod ręką program, który nie wymaga pulpitu i nie każe zgadywać. To jest cały sens lekkiej bazy: nie żeby była pusta, tylko żebyś w razie potrzeby widział, co się na niej dzieje, zanim 1 GB pamięci i jedna karta SD przestaną wystarczać.