Jeśli w środowisku graficznym mamy ustawiony polski język, nie mamy przy tym problemów z kodowaniem znaków w tekście i nasza klawiatura ma ustawiony odpowiedni układ klawiszy ale jednocześnie doświadczamy problemów jeśli chodzi o polskie znaki pod TTY, oznacza to prawdopodobnie źle skonfigurowany wirtualny terminal. Generalnie rzecz biorąc środowisko graficzne i konsola TTY, to tak jakby dwa różne światy i trzeba je konfigurować w pewnych aspektach osobno.

Gdy mamy do dyspozycji panel administracyjny jednego ze środowisk graficznych, np. GNOME, zmiana języka interfejsu aplikacji w systemie nie powinna przysporzyć problemów. Natomiast jeśli chodzi o wszelkie inne środowiska oparte jedynie o menadżery okien, np. OPENBOX, lub też i te zupełnie nie mające graficznej sesji, to przestawienie języka jest lekko utrudnione. Przede wszystkim, musimy rozróżnić dwie kwestie. Jedną z nich jest język interfejsu i wszelkie wiadomości, które wypisuje nam system, np. na terminalu. A drugą są polskie znaki, które możemy wpisywać przy pomocy klawiatury. Te dwie rzeczy są ze sobą niepowiązane w żaden sposób, tj. można mieć polski układ klawiszy i jednocześnie korzystać z angielskiej wersji systemu operacyjnego linux i vice versa. Choć automaty środowisk graficznych synchronizują te dwa elementy, co wydaje się być raczej zrozumiałe.

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 dysków HDD firmy Western Digital (WD). Maja one wprowadzony ficzer parkowania głowicy w przypadku, gdy dysk jest nieużywany (tzw. IntelliPark/IntelliPower). Ma to na celu zmniejszyć pobór prądu i, co za tym idzie, temperaturę urządzenia oraz też uodpornić nieco taki nośnik na różnego rodzaju wstrząsy/przeciążenia. Parkowanie głowicy w dyskach HDD nie działa poprawnie pod linux'em (dystrybucja Debian), tj. parametr SMART Load_Cycle_Count po krótkim czasie użytkowania takiego dysku może osiągać wartości idące w setki tysięcy. Nasuwa się więc pytanie, czy jesteśmy jakoś w stanie wyłączyć to 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.