Spora większość środowisk graficznych rozrosła się obecnie nieco i ich instalacja na maszynach wyposażonych w niewiele pamięci RAM może nie wchodzić w grę. Nie jesteśmy też skazani na życie w konsoli, ani na kupno nowego sprzętu. Możemy nieco odchudzić instalację pozbywając się zbędnych usług, których tak naprawdę nie potrzebujemy. Poza tym, praktycznie każde z graficznych narzędzi, przy pomocy których chcemy konfigurować linux'a, ma tekstowe zamienniki, lub też o wiele lżejsze alternatywy. Jednak w przypadku, gdy korzystamy z takich rozbudowanych środowisk jak GNOME, to nie koniecznie da się usunąć szereg tych zasobożernych komponentów. Pozostaje nam zwykle jedna opcja, którą jest usunięcie całego środowiska graficznego i zainstalowanie potrzebnych nam komponentów osobno. Jako, że mamy już opisanyproces instalacji debiana przy pomocy debootstrap, instalację i konfigurację Xserver'a, jak i również menadżera okien LightDM, to przyszedł czas na omówienie niezbędnego w sesji graficznej menadżera okien. W tym wpisie skupimy się głównie na instalacji i konfiguracji Openbox'a.

Istnieje kilka sposobów na to, by uruchomić sesję graficzną Xserver'a. W przypadku, gdy nie wykorzystujemy zaawansowanych środowisk graficznych, zwykle korzystamy z polecenia startx wydawanego zaraz po zalogowaniu się na konsolę TTY. Niemniej jednak, nawet w tych najprostszych środowiskach graficznych możemy pokusić się o instalację lekkiego menadżera okien, tak by nie musieć konfigurować samodzielnie szeregu opcji sesji. Menadżery logowania (display managers) mają na celu zrobienie dokładnie tego samego co pliki ~/.xinitrc i ~/.xserverrc , z tym, że w nieco bardziej przyjaznej dla użytkownika formie. W tym wpisie przyjrzymy się nieco dokładniej menadżerowi LightDM. Zostanie także omówiony sposób blokowania aktywnej sesji Xserver'a bez potrzeby jej zamykania przy pomocy narzędzia light-locker.

Dzięki takiemu wynalazkowi jak Xserver (Xorg) mamy możliwość odpalania aplikacji graficznych. Bez niego wszystko musielibyśmy robić w czarnej konsoli, przez co funkcjonalność naszej maszyny w dość znacznym stopniu ucierpiałaby. Oczywiście tryb graficzny ma też swoje wady. Niemniej jednak, Xserver leży póki co u podstaw każdego środowiska graficznego i jeśli chcemy mieć możliwość odpalania, np. Firefox'a, czy oglądania filmów w VLC, to nie ma innego wyjścia jak skonfigurować sobie Xserver. W tym wpisie się zajmiemy tym zagadnieniem, przy czym, chcę uprzedzić, że nie będziemy korzystać z żadnych automatów, które można znaleźć w tych wszystkich zaawansowanych środowiskach graficznych. A to z tego względu, że ustawienia tych środowisk zwykle nadpisują ustawienia samego Xserver'a.

Mysz, zaraz obok klawiatury, to jedno z tych narzędzi, z których korzystamy praktycznie bez przerwy ilekroć tylko siadamy przed komputerem. Z reguły działa ona prawidłowo, nawet pod linux'em, z tym, że dla jednych użytkowników standardowe ustawienia nie są zbyt zadowalające. Nawet jeśli wszystkie przyciski zostaną rozpoznane poprawnie, to zawsze pozostaje, np. kwestia dostosowania szybkości przemieszczania się kursora po ekranie. Oczywiście, istnieje także szereg innych aspektów, które możemy sobie dostosować i tym właśnie się zajmiemy w niniejszym wpisie.

Obecnie w linux'ach spora cześć sprzętu jest rozpoznawana prawidłowo, a my nie musimy poświęcać czasu na dodatkową konfigurację. Domyślne ustawienia sprawdzają się praktycznie za każdym razem, gdy w grę nie wchodzi nic bardziej zaawansowanego. W tym wpisie rzucimy okiem na konfigurację Xserver'a, która dotyczyć będzie wyświetlanego obrazu na monitorze. Pośrednio też będziemy musieli skonfigurować sobie kartę graficzną, bo to ona jest odpowiedzialna w dużej mierze za to, co jest odbierane przez nasz monitor.

W artykule poświęconym konfiguracji sieci WiFi na Debianie z wykorzystaniem narzędzia wpa_supplicant wspomniałem parę słów na temat interfejsu bond. Bonding na linux wykorzystywany jest w zasadzie do spięcia kilku interfejsów sieciowych, w tym przewodowych ( eth0 ) i bezprzewodowych ( wlan0 ) w jeden (zwykle bond0 ). Takie rozwiązanie sprawia, że w przypadku awarii któregoś z podpiętych interfejsów, my nie tracimy połączenia z siecią i nie musimy nic nigdzie przełączać, by to połączenie przywrócić. To rozwiązanie jest o tyle użyteczne, że w przypadku, gdy podepniemy przewód do gniazda RJ-45 w naszym laptopie, to komunikacja będzie odbywać się po kablu. Natomiast jeśli przewód zostanie odłączony, to system automatycznie przejdzie na komunikację bezprzewodową. W tym wpisie spróbujemy zaprojektować sobie właśnie tego typu mechanizm zarówno za sprawą pakietu ifupdown , gdzie konfiguracja interfejsów sieciowych jest zarządzana przez plik /etc/network/interfaces , jak i przy pomocy natywnego rozwiązania jakie oferuje systemd/networkd.

Instalowanie debiana z wykorzystaniem debootstrap trochę się różni od instalacji z wykorzystaniem instalatora. Chodzi generalnie o to, że wszystkie kroki instalacyjne trzeba przeprowadzać ręcznie. Poza tym, cała konfiguracja będzie wymagać manualnego dostosowania. Plus tego rozwiązania jest oczywisty, albowiem mamy całkowitą władzę nad tym co się w systemie znajdzie oraz jak będzie on skonfigurowany. By mieć możliwość przeprowadzenia tego typu instalacji potrzebny będzie nam działający system. Może to być płytka lub pendrive live z Debianem czy Ubuntu. Można też wykorzystać już zainstalowany system operacyjny. Ważne jest tylko to, aby była możliwość zainstalowania w takim systemie pakietu debootstrap , no i oczywiście wymagany jest dostęp do internetu. W przeciwieństwie do instalatora debiana, mamy dostęp do graficznego środowiska, a w nim do przeglądarki i w przypadku utknięcia gdzieś po drodze podczas instalacji, możemy sobie wygooglać napotkane problemy nie przerywając przy tym prac instalacyjnych.

Debian posiada bardzo rozbudowany system robienia pakietów. Generalnie rzecz biorąc, to wszystkie z nich musiały przejść przez ten proces zanim trafiły do głównego repozytorium dystrybucji. Dzięki takiemu stanu rzeczy, nie musimy ręcznie powielać pracy szeregu innych osób i odpada nam własnoręczna kompilacja pakietów, a wszyscy wiemy, że zajmuje ona cenny czas i zasoby. Paczki .deb są tworzone ze źródeł i instalowane przy pomocy menadżera pakietów aptitude/apt/dpkg . Nic jednak nie stoi na przeszkodzie by daną aplikację skompilować sobie ręcznie i zainstalować ją przy pomocy make install . Problem w tym, że w taki sposób robi się śmietnik w naszym systemie i śledzenie wszystkich zainstalowanych w ten sposób pakietów w pewnym momencie stanie się wręcz niemożliwe. Dlatego też przydałby nam się mechanizm, który ułatwiłby nam nieco to zadanie. Debian udostępnia szereg narzędzi, które są w stanie w pełni zautomatyzować cały ten proces budowy pakietów. Ten poradnik zaś ma na celu zebranie wszystkich istotniejszych informacji związanych z obsługą narzędzi takich jak dh_make , dpkg-buildpackage , pbuilder , quilt czy lintian , tak by tworzyć pakiety w prosty sposób i przy tym równając do najwyższych standardów debiana.

Aktualizacje systemu niosą ze sobą nowsze wersje pakietów. Czasami mają one błędy, które wychodzą na jaw po jakimś czasie korzystania z danej aplikacji. W takiej sytuacji zwykle zachodzi potrzeba cofnięcia wersji kilku pakietów. Jest jednak wielce prawdopodobne, że akurat tej wersji pakietu, której potrzebujemy, nie znajdziemy z repozytorium debiana. Pobieranie pojedynczych pakietów z internetu przez klikanie w pierwszy lepszy link, który zostanie nam zwrócony przez wyszukiwarkę, nie jest dobrym pomysłem. Na szczęście w przypadku debiana nie musimy się aż tak narażać. A to z tego względu, że debian robi migawki (shapshots) swoich repozytoriów 4 razy dziennie (co 6 godzin). W ten sposób mamy dostęp do różnych stanów repozytoriów, w tym też tych, które zawierają pakiety aktualnie niedostępne w repozytoriach. W tym wpisie postaramy się pobrać i zainstalować nieistniejące pakiety z takich snapshot'ów.

Posiadając nowszej klasy procesor, jesteśmy w stanie korzystać z 64 bitowego systemu operacyjnego. W przypadku windowsów uruchamianie aplikacji 32 czy 64 bitowych nie stanowi większego problemu. W na debianie sprawa wygląda nieco inaczej. Gdy mamy wgranego 64 bitowego debiana, aplikacje 32 bitowe nie będą chciały się nam odpalić. Wszystkiemu winne są biblioteki 32 bitowe, które są wykorzystywane przez dany program, a bez nich on zwyczajnie nie może działać. Jednym z rozwiązań tego problemu może być kontener LXC, gdzie jesteśmy w stanie zainstalować 32 bitowy system wewnątrz środowiska 64 bitowego i to z tego systemu możemy uruchamiać 32 bitowe aplikacje. Skonfigurowanie takiego kontenera może być nieco skomplikowane, dlatego też dużo lepszym rozwiązaniem jest przerobienie naszego 64 bitowego systemu na muliarch, czyli taki, który jest w stanie obsługiwać wiele architektur (multiarch).