Systemy live mają jedną ale za to dość dającą się odczuć wadę, mianowicie chodzi o to, że po wypaleniu takiego obrazu, nie mamy możliwości zachowania zmian. Nawet jeśli doinstalujemy nowy pakiet czy wyedytujemy jakiś plik, to zmiany wprowadzone przez nas są jedynie tymczasowe, bo dokonywane w pamięci operacyjnej RAM. W efekcie jeśli uruchomimy taki system ponownie, będziemy zmuszeni przeprowadzać raz jeszcze wszystkie poprzednie czynności pod kątem jego dostosowania. W przypadku cd/dvd nie mamy praktycznie żadnego pola manewru. Inaczej jednak ma się sprawa jeśli chodzi o pendrive, bo tutaj możemy utworzyć osobną partycję, gdzie będą przechowywane wszystkie zmiany jakich dokonamy.

System live to nic innego jak spakowany system plików jakieś zainstalowanej dystrybucji, który podczas startu maszyny jest montowany w trybie tylko do odczytu, a potrzebne pliki są wypakowywane w czasie rzeczywistym w pamięci operacyjnej RAM. Do implementacji takiego rozwiązania stosuje się squashfs i jako że jest to system plików tylko do odczytu, nie można go jako tako edytować. Nie jesteśmy też zupełnie na straconej pozycji, bo możemy skorzystać z dwóch rozwiązań: persistence lub możemy pokusić się o przepakowanie systemu plików.

Każdy z nas spotkał się już chyba w swoim życiu z systemami live. To taki wynalazek zawierający domyślne oprogramowanie, tak skonfigurowane, by system zdołał się odpalić na większość maszyn w ich pamięci operacyjnej, oczywiście zakładając, że wymagania sprzętowe zostaną zaspokojone, głównie chodzi o pamięć RAM. Takie systemy live są dostarczane w postaci kilku rodzajów obrazów: iso, hdd oraz hybryda. Pierwszy z nich zwykle wypala się na płytkach, drugi na pendrive, z kolei hybrydowy obraz można wgrać na każdy rodzaj urządzenia i nawet wykorzystać w przypadku maszyn wirtualnych i zwykle spotkamy się z tym ostatnim typem, nawet jeśli plik ma rozszerzenie .iso .

Każdy z nas dla wygody, albo raczej przez lenistwo, stara się nie używać zbyt skomplikowanych haseł. Zwykle też korzystamy z tego samego hasła do większości kont online w internecie. Jeśli zdarzyło nam się tworzyć proste, krótkie i do tego łatwe do przewidzenia hasła, np. w oparciu o datę urodzenia lub inne tego typu informacji, to przydałoby się nieco popracować nad zabezpieczeniami tych poufnych danych, tak by nie były proste do odgadnięcia czy też i złamania.

Jakiś czas temu opisywałem jak podejść do pisania reguł dla udev'a . W tamtym przypadku wykorzystywana reguła składała się tak naprawdę z dwóch mniejszych, z których jedna miała ustawioną zmienną ACTION na add , z kolei zaś druga na remove i w ten oto sposób pierwsza z nich była aplikowana podczas podłączania określonego urządzenia do komputera, a druga przy jego odłączaniu. Okazuje się jednak, że dwie reguły nie są konieczne w przypadku gdy mają one dotyczyć tego samego sprzętu i możemy zamiast nich stworzyć jedną regułę, która będzie stosowana zarówno przy podłączaniu jak i odłączeniu danego urządzenia.

Czy zadawaliście sobie kiedyś pytanie na temat tego jaka jest dokładna data instalacji aktualnie używanego przez was systemu operacyjnego? To chyba powinna być jedna z podstawowych danych, do których użytkownik powinien mieć swobodny dostęp, by wiedział kiedy instalował swój system. Jednak w przypadku linux'a z jakiegoś powodu ciężko jest ten fakt ustalić. Postaramy się zatem ocenić możliwie dokładnie to kiedy proces instalacji linux'a mógł mieć miejsce.

Jak możemy przeczytać pod tym linkiem , zróżnicowanie pod względem zapisu większych liczb jak i części dziesiętnych różni się w zależności od kraju. Jedne do oddzielania od siebie tysięcy wykorzystują kropki, inne zaś przecinki i vice versa w przypadku części niecałkowitej. Nie będę tutaj się rozpisywał na temat wyższości kropki nad przecinkiem, bo problem dotyczy zupełnie czegoś innego, mianowicie, tego jak system interpretuje znaki pochodzące z klawiatury numerycznej.

Bardzo ciężko spotkać wypasioną klawiaturę, po której podłączeniu wszystkie przyciski będą funkcjonować jak należy, a to z tego względu, że nie do końca są one wykrywane przez nasz system. Zwykle są to klawisze multimedialne lub inne niestandardowe przyciski, które nie pasują do układu 104 klawiszy. W większości przypadków odpowiednie skonfigurowanie modelu klawiatury powinno rozwiązać nasze problemy. Nie zawsze jednak posiadany przez nas model jest do wyboru. Czasami nawet i jego wskazanie nie pomaga i najzwyczajniej w świecie niektóre klawisze po prostu nie zostaną wykryte przez system.

Postanowiłem się w końcu wziąć za porządki związane z wiadomościami pocztowymi i RSS'ami, bo katalog Thunderbird'a już zajmował prawie 650 MiB. Jakby nie patrzeć, to trochę dużo, biorąc pod uwagę, że są to głównie wiadomości tekstowe. W sumie to miałem tam archiwum wszystkich maili z 4-5 ostatnich lat i trochę się tego nazbierało. Nie byłoby tego wpisu gdyby nie fakt, że nawet usunięcie 120 tyś. wiadomości praktycznie nie wpłynęło na zajmowane przez nie przestrzeni na dysku.

Klucze SSH mogą być wykorzystane jako sposób identyfikacji danej osoby przy logowaniu się do zdalnego serwera SSH. Te klucze zawsze występują w parach -- jeden prywatny, drugi publiczny. Pierwszy z nich jest znany tylko nam i powinien być trzymany w sekrecie i pilnie strzeżony. Klucz publiczny z kolei zaś jest przesyłany na każdy serwer SSH, z którym chcemy się połączyć. Gdy serwer jest w posiadaniu naszego klucza publicznego i widzi przy tym, że próbujemy nawiązać połączenie, używa on tego klucza by wysłać do nas zapytanie (challange) -- jest ono zakodowane i musi na nie zostać udzielona odpowiednia odpowiedź, a tej może dokonać ktoś, kto jest w posiadaniu klucza prywatnego. Nie ma innej opcji by rozkodować wiadomość, dlatego też nikt inny nie może udzielić na nią prawidłowej odpowiedzi. To rozwiązanie eliminuje wrażliwość na różne formy podsłuchu -- ten kto nasłuchuje nie będzie w stanie przechwycić pakietów zawierających hasło, bo ono nie jest nigdy transmitowane prze sieć. No i oczywiście jeśli chodzi o samo hasło -- odpadają nam ataki typu Brute Force pod kątem jego złamania.