Hibernacja w przypadku komputerów, zwłaszcza laptopów, to bardzo użyteczny wynalazek. Na linux'ach wymaga ona czasem lekkiej konfiguracji ale generalnie można powiedzieć, że działa OOTB. Po migracji szeregu dystrybucji na systemd, proces hibernacji zdaje się przebiegać nieco inaczej niż to miało miejsce w przeszłości. Bardzo często możemy się spotkać z sytuacjami, gdzie przy próbie zahibernowania czy wyłączenia systemu, ten zwyczajnie ignoruje nasze żądanie i pracuje dalej jak gdyby nigdy nic. W tym przypadku nie mamy do czynienia z bug'iem ale ficzerem. Okazuje się bowiem, że systemd dysponuje mechanizmem zwanym inhibitor lock, który ma na celu powstrzymanie systemu od dokonania hibernacji, uśpienia lub wyłączenia w pewnych określonych sytuacjach. W tym wpisie przyjrzymy się nieco bliżej temu mechanizmowi.

Ogromna cześć lokalnych ISP zdaje się nie nadążać za ciągle zmieniającą się rzeczywistością. Problem dotyczy implementacji protokołu IPv6, który jest już z nami od bardzo wielu lat. W przypadku mojego obecnego ISP raczej nie mam co liczyć na to, by w bliżej nieokreślonej przyszłości dodał on obsługę tego protokołu. Istnieje jednak mechanizm zwany tunelowaniem pakietów protokołu IPv6 wewnątrz pakietów protokołu IPv4 (w skrócie 6to4), którym warto się zainteresować. W ogromnym skrócie, część puli adresowej IPv6 jest zarezerwowana i zmapowana na adresy protokołu IPv4. Dzięki takiemu podejściu, każdy kto posiada stały zewnętrzny adres IPv4 ma również adres w puli IPv6. Mając zatem zarezerwowany adres, możemy pokusić się o utworzenie tunelu 6to4, co aktywuje w naszej infrastrukturze ten nowszy protokół obchodząc jednocześnie ograniczenia ISP. Trzeba jednak mieć na względzie, że nie jest to natywne wsparcie dla protokołu IPv6 i jest niemal pewne, że wystąpią mniejsze lub większe problemy z wydajnością.

Rozmiary obecnych dysków twardych zwykliśmy już liczyć w TiB. Jest to dość sporo ale ciągle zdarzają się sytuacje, gdzie zaczyna nam brakować miejsca na pliki. W takich przypadkach myślimy raczej o zmianie rozmiaru istniejących już partycji czy też dokupieniu nowego dysku. Pierwsza z powyższych opcji nie zawsze może wchodzić w grę, no chyba, że zaimplementowaliśmy sobie LVM. Jeśli tak, to możemy bez większego problemu zmieniać rozmiar każdego z tych voluminów LVM. Niemniej jednak, nawet jeśli już dostosujemy sobie te wirtualne dyski, to miejsce wciąż może nam się skończyć i raczej można przyjąć za pewne, że tak się stanie w bliżej nieokreślonej przyszłości. Gdy to nastąpi, czeka nas druga opcja wymieniona wyżej, tj. zaopatrzenie się w dodatkowy nośnik danych. Przy pomocy LVM jesteśmy w stanie ten nowy dysk dodać do istniejącej grupy voluminów i zwiększyć tym wirtualnym partycjom rozmiar bez potrzeby przerywania pracy systemu, czy też wykonywania dodatkowych czynności związanych z formatowaniem i instalowaniem systemu na nowo. W tym wpisie postaramy się przebrnąć przez ten proces.

Na forum DUG'a pojawił się ciekawy post, w którym autor wątku chciał wykonać coś co określił jako "display mirroring". Poszukałem trochę informacji na temat tego zagadnienia i okazało się, że to nic innego jak tylko wyświetlenie tej samej zawartości, np. na dwóch monitorach. Nie jest to nic zaawansowanego, bo przecie Xserver jest w stanie tego typu zadanie zrealizować. Niemniej jednak, oba monitory muszą być podłączone do tego samego komputera. W tym przypadku mamy dwie maszyny i dwa osobne monitory. Celem jest przesłanie obrazu z jednej maszyny na drugą za pomocą sieci. W tym podlinkowanym wątku została poruszona kwestia przechwycenia obrazu przy pomocy ffmpeg i przesłania go przez sieć za pomocą nc (netcat). Tak bardzo zainteresowało mnie to rozwiązanie, że postanowiłem zobaczyć jak wygląda ono w praktyce.

Na forum DUG'a po raz kolejny pojawił się post dotyczący unikalnych identyfikatorów, które są nadawane partycjom dysków twardych. Nie wiem jak sprawa ma się w przypadku windowsów ale linux na podstawie tych numerów UUID i (GUID) jest w stanie identyfikować konkretne urządzenia. Czasem się zdarza tak, że dwa dyski czy partycje mają taki sam identyfikator, co prowadzi zwykle do problemów. Kolizja numerów identyfikacyjnych może być wynikiem pozostałości po procesie produkcyjnym ale może także powstać za sprawą klonowania nośnika za pomocą narzędzia dd . Tak czy inaczej, przydałoby się wiedzieć jak ustalić, poprawnie wygenerować czy też zmienić UUID wszędzie tam, gdzie jest on wykorzystywany i o tym będzie ten wpis.

Wszystko zaczęło się od pewnego posta na forum DUGa, w którym to jeden użytkownik polecał innemu, aby ten zainteresował się programem o nazwie tmux . Nie wiem czy tamta osoba to zrobiła ale ja postanowiłem się przyjrzeć temu wynalazkowi zwanemu terminal multiplekser. Po niezbyt wnikliwym przejrzeniu strony projektu rzuciło mi się w oczy dzielenie okna jednego terminala na szereg mniejszych. Ten ficzer znany był mi min. z terminala terminator. Zasadniczą różnicą tych dwóch aplikacji jest to, że tmux może być uruchomiony również pod TTY, efektywnie dzieląc obszar jednej konsoli. Nie to bym ciągle siedział w trybie tekstowym ale skoro tmux potrafi to samo co terminator oraz działa zarówno w trybie graficznym jak i tekstowym przy zaznaczeniu, że zjada także mniej pamięci RAM, to czemu nie zaimplementować sobie jego obsługi? W trakcie użytkowania tmux'a okazało, że potrafi on sporo więcej i dlatego właśnie powstał ten wpis.

Zgodnie z tym co można wyczytać na wiki Archlinux'a, mamy kilka źródeł generowania dźwięków, które trafiają do wbudowanego głośnika naszego komputera (case speaker). Te dźwięki określane mianem "beep" mogą powstać za sprawą BIOS'u płyty głównej, systemu operacyjnego, środowiska graficznego lub też różnych programów użytkowych. Najbardziej uporczywe są dźwięki generowane przez BIOS. Na dobrą sprawę, jeśli w BIOS'ie nie ma żadnych opcji dotyczących konfiguracji tego głośnika, to raczej niewiele jesteśmy w stanie zrobić w tej kwestii. Możemy zawsze ten głośnik odłączyć fizycznie. Choć nie jest to zalecane, bo na podstawie wydawanych przez niego dźwięków, jesteśmy w stanie określić czy z naszym komputerem jest wszystko w porządku. Niemniej jednak, w tych pozostałych trzech w/w punkach mamy większe pole manewru, gdzie możemy dostosować sobie szereg parametrów i o tym właśnie będzie ten wpis.

Monitory posiadają różne wymiary fizyczne i co za tym idzie mają też inne rozdzielczości. Te informacje nie są jakoś zbytnio tajne i każdy klient przed zakupem konkretnego modelu monitora jest w stanie się zapoznać z tymi parametrami. To co zwykle sprzedawcy starają się ukryć przed nami, to współczynnik PPI (pixels per inch). Zwykle też można spotkać się z terminem DPI (dots per inch). Nie są one równoznaczne, bo w monitorach LCD jeden piksel składa się z trzech podpikseli. Sprzedawcy wykorzystują ten fakt i chwalą się, że dany model monitora ma 300 DPI. W skrajnych przypadkach można nawet usłyszeć i 300 PPI. Osoby, które nie rozróżniają tych dwóch pojęć mogą bardzo łatwo zostać oszukane podczas zakupu. Problem potęguje fakt, że gdy monitor jest sporych rozmiarów i patrzymy na niego z większej odległości, to nawet nie dostrzeżemy, że nas oszukano. Na wszelki wypadek lepiej założyć, że sprzedawca ma co innego na myśli niż my i podaną wartość podzielić przez 3, a następnie skontrastować tak otrzymaną liczbę z PPI większości monitorów (100). Niemniej jednak, dobrze jest przed zakupem monitora sprawdzić jaki współczynnik PPI ma dany model i nie sugerować się tym co sprzedawca napisał w ofercie. Dlatego też w tym wpisie postaramy się ustalić faktyczną wartość PPI dla naszego obecnego lub przyszłego monitora.

Na rynku oprogramowania linux'owego mamy całą gamę różnego rodzaju pseudo terminali, które na dobrą sprawę robią za konsolę w środowiskach graficznych. Jako, że takie środowiska rozrosły się dość mocno ostatnimi czasy, to instalacja niektórych terminali może pociągać za sobą wiele zależności. To z kolei przyczynia się do wgrania zbędnego oprogramowania. Inną kwestią są zasoby systemowe, bo niektóre z terminali potrafią zjeść naprawdę sporo pamięci operacyjnej. Są oczywiście lżejsze alternatywy i w tym wpisie omówimy sobie konfigurację terminala urxvt.

Jak możemy wyczytać na wikipedii, steganografia to nauka, która ma na celu ukrycie faktu prowadzenia komunikacji. Odróżnia ją to nieco od kryptografii, gdzie wiadomość jest wprawdzie nieczytelna ale wiadome jest, że dokonywana jest wymiana informacji między dwoma punktami. W przypadku steganografii możemy ukryć pewną informację, np. w pliku graficznym maskując tym samym cały proces przekazywania danych. W taki sposób osoba, która nie ma pojęcia o fakcie ukrycia informacji, zobaczymy jedynie zwykły obrazek. Poniższy wpis ma na celu sprawdzenie jak skuteczna jest ta metoda i czy nadaje się do zastosowania dla przeciętnego zjadacza chleba.