W środowiskach graficznych, np. GNOME czy KDE, nie musimy zbytnio się zastanawiać nad tym jak skonfigurować klawiaturę, bo wszystko możemy sobie szybko i w prosty sposób wyklikać z graficznego panelu administracyjnego systemu. Natomiast jeśli korzystamy jedynie z odchudzonych instalacji linux'a zawierających jedynie jakiś menadżer okien, np. OPENBOX, to sami musimy zadbać o skonfigurowanie klawiatury, tak by układ się zgadzał, by były dostępne polskie znaki, no i oczywiście by system potrafił rozpoznać ewentualne klawisze multimedialne.

Przerabiając analizę pakietów sieciowych, dotarłem w końcu do sieci bezprzewodowych, a te różnią się nieco od tych swoich przewodowych kuzynów. Generalnie rzecz biorąc nie będę tutaj opisywał samej analizy pakietów, które sobie przemierzają eter w pobliżu naszych urządzeń WiFi, a jedynie poruszę kwestię pakietów Beacon, które są rozsyłane przez punkty dostępowe w pewnych odstępach czasu.

Jakiś czas temu pewien człowiek miał dziwaczny problem. Jak możemy wyczytać w przytoczonym linku, system tego użytkownika lekko mówiąc nie zachowywał się tak jak powinien. Objawiało się to przez dość ekstensywne wykorzystywanie pamięci operacyjnej RAM przy zwykłym listowaniu plików via ls w pewnych określonych katalogach. Struktura systemu plików zdaje się być porządku, bo program fsck nie zwraca żadnych błędów. Zatem w czym problem?

Przez cały czas korzystania z internetu, robiłem to za pomocą przeglądarki Opera. Nawet po tym jak przeszedłem na linuxa, to wciąż nie mogłem się z nią rozstać i to pomimo faktu, że nie była ona przecież opensource, przez co nie była także dostępna w repozytoriach debiana. Gdy deweloperzy z zespołu Opery przestali rozwijać tę przeglądarkę dla linuxa, musiałem poszukać sobie czegoś innego. Wybór padł na Firefox'a ale każdy kto używał tych dwóch przeglądarek wie, że różniły się one dość znacznie parę lat temu i jedną z tych bardziej odczuwalnych różnic była inna obsługa klawisza Backspace .

Dziś postanowiłem sprawdzić jak wygląda struktura plików mojego dysku. Chodzi oczywiście o ich fragmentację. Zgodnie z tym co pokazał mi fsck , pofragmentowanych plików jest 350. Po zapuszczeniu defragmentacji via e4defrag ilość tych plików spadła do nieco ponad 100 i jeśli by się przyjrzeć procesowi defragmentacji, to można było zauważyć linijki mające extents: 100 -> 10 . Wychodzi na to, że plik dalej jest w kawałkach i nie idzie go zdefragmentować. Jak rozumieć taki zapis?

Dyski zużywają się z różnych powodów. Jednak najczęstszą przyczyną są nowe wynalazki, które producent w nich implementuje, bo te niezbyt dobrze działają w określonych warunkach, czy też pod kontrolą pewnych systemów operacyjnych. Tak właśnie jest w przypadku nowszych dysków firmy Western Digital (WD). Maja one wprowadzony ficzer parkowania głowicy w przypadku, gdy dysk jest nieużywany. Ma to na celu zmniejszyć pobór prądu i, co za tym idzie, temperaturę urządzenia. Jako, że parkowanie głowicy w dyskach WD nie działa poprawnie pod moim linux'em (dystrybucja Debian), to nasuwa się pytanie: jak wyłączyć parkowanie głowicy by wydłużyć żywotność dysku twardego?

Wolny start jest wynikiem braku zaufania maszyny nadawczej do utworzonego kanału przesyłowego -- połączenia. Nie wie ona czy to łącze jest bowiem w stanie obsłużyć taką porcję danych, którą ma zamiar przesłać bez czekania na pakiet ACK . W przypadku bufora odbiorczego, wszystko jest proste, bo dane dotyczące wielkości okien są zdefiniowane w nagłówku pakietów, do których ma wgląd druga ze stron. W przypadku gdy nadawca przesyła dane, prędkość z jaką to robi zależy głównie od niego.

Wraz ze zwiększaniem zapotrzebowania na szybsze łącza internetowe, ograniczenia wynikające z protokółu TCP zaczęły powoli dawać się ludziom we znaki. Problemem była bariera prędkości, którą ciężko było pokonać mając do dyspozycji domyślną formę nagłówka protokołu TCP. Było w nim zwyczajnie za mało miejsca, co zapoczątkowało jego rozbudowę kosztem ilości danych, które można było przesłać w pojedynczym segmencie. W tym wpisie skupię się głównie na dwóch opcjach jakie zostały dodane do nagłówka TCP, tj. dynamiczne skalowanie okien oraz znaczniki czasu, bo te dwa parametry nie mogą wręcz bez siebie istnieć, zwłaszcza gdy rozmawiamy o łączach pokroju 1 czy 10 gbit/s.

Protokół TCP jest tak zbudowany by zapewnić rzetelny transfer danych między dwoma komunikującymi się punktami. Z początku jednak, ta cecha tego protokołu powodowała marnowanie dość sporych ilości zasobów jeśli chodzi o przepustowość łącza. Stało się to widoczne przy większych prędkościach połączeń, gdzie skalowany był bufor (okno) TCP, co umożliwiło przesyłanie szeregu segmentów bez potrzeby czekania na ich potwierdzenie przez odbiorcę. To zwiększyło, co prawda, transfer danych ale pojawił się problem z zagubionymi pakietami.

Stawiając sobie środowisko testowe pod wireshark'a w celu analizy pakietów sieciowych, zauważyłem, że coś mi się nie zgadza odnośnie wielkości przesyłanych pakietów między interfejsami kontenerów LXC. Jakby nie patrzeć, środowisko testowe ma być odwzorowaniem środowiska produkcyjnego i w tym przypadku wszelkie zasady dotyczące, np. podziału danych na segmenty, muszą być takie same. Generalnie rzecz biorąc rozmiar pakietu powinien wynosić 1514 bajtów, a był parokrotnie większy. Okazało się, że jest to za sprawą odciążenia segmentacji w protokole TCP (TCP Segmentation Offload).