Przejdź do głównej zawartości

Mniejszy program, to szybsze uruchomienie aplikacji

Przynajmniej w teorii. Szczególnie dla posiadaczy tradycyjnych dysków talerzowych. Na czym polega trick? Otóż aby program się uruchomił musi być wpierw wczytany do pamięci. Zanim to system uczyni musi wpierw go odczytać z dysku. Te są szybsze lub wolniejsze, jednakże nie ma jeszcze tak szybkich dysków, które dorównywałyby operacjom wykonywanym w pamięci RAM. Stąd też, gdyby program na dysku był mniejszego rozmiaru, to powinien on zostać szybciej uruchomiony. Nawet jeśli potem - już w RAM - komputer musiałby dokonać jego dekompresji. Spróbujmy zatem poddać kompresji program wykonywalny tak, jak to czynimy w przypadku różnego rodzaju dokumentów.
Narzędzia kompresujące programy wykonywalne znane są na niemal każdy system operacyjny. Od dawna jest też znane takie narzędzie dla linuksa. Mi znane jest jedno, choć nie wykluczam, że jest takich więcej. Tym programem kompresującym jest Ultimate Packer for eXecutables - w skrócie upx. Z podanej wyżej strony dowiecie się więcej, w tym również o wspieranych przez narzędzie programach. Tu zajmę się wyłącznie podstawami jego stosowania i obsługi. Zanim jednak to tego przejdę - jedna uwaga: program wykonuje operacje na plikach wykonywalnych. Nie każdy program, który zostanie "potraktowany" przez upx będzie się nadawał do użytku. Nie każdy też się potem uruchomi. Koniecznie zatem albo wykonajmy kopię zapasową takiego programu, albo liczmy się z koniecznością ponownego jego zainstalowania. Szczególną ostrożność polecam wszędzie tam, gdzie program jest inicjowany przy starcie systemu. Jeśli nie wiecie jak się dostać do systemu bez uruchomionego środowiska, to powstrzymajcie się z kompresowaniem takich programów.
W pierwszej kolejności zaopatrujemy się w upx. Prosto, albowiem znajduje się on w repozytoriach Archa:
# pacman -S upx
Teraz już przystąpić możemy do kompresowania wybranych przez nas programów. Co do zasady znajdziemy je w /usr/bin, niekiedy również w katalogach programów w /opt, jeśli macie jakieś programy instalowane lokalnie, w /home to również i tu. Składnia jest prosta, a program niemal bezobsługowy. Polecam korzystanie z przełącznika best, albowiem upx wówczas sam dobierze najlepsze  kompresowanie dla danego rodzaju programu.
upx --best nazwa_pliku_wykonalnego
Pamiętajmy przy tym, że:

  • jak wspomniałem - warto zrobić kopię, może nam to zapewnić sam program przy użyciu opcji -k lub --backup,
  • jeśli polecenie wywołujemy z katalogu, do którego zwykły użytkownik nie ma dostępu do zapisu (/usr/bin, /opt/), to wykonać je musimy z uprawnieniami administratora,
  • kompresja programu może trwać dosyć długo, zwłaszcza, gdy użyjemy przełączników uruchamiających najlepszą możliwą kompresję.
Po wykonaniu polecenia, jeśli wszystko się powiodło możemy się cieszyć mniejszym programem, który przynajmniej teoretycznie winien się szybciej uruchamiać. Zaoszczędzi nam również nieco miejsca na dysku. Niektóre programy nie skompresują się, o czym zostaniemy powiadomieni. UPX nie skompresuje nam np. zbyt małych programów. Nie ma to sensu. Jeśli program nie będzie się uruchamiał po jego skompresowaniu, wówczas należy przywrócić kopię lub go przeinstalować. Sam program również pozwala na zdekompresowanie programu:
upx -d nazwa_programu
Polecam zatem wykonać próbę uruchomienia programu bezpośrednio po jego skompresowaniu, gdy jeszcze pamiętamy, co wykonywaliśmy, albo po prostu zapisanie gdzieś dokonywanych operacji.
Oczywistym winno być, że kompresji musimy poddać program po każdej jego aktualizacji.
Na jak dużą kompresję liczyć możemy? Cóż - to zależy już od danego programu. Bodaj jednym z lepszych przykładów jest program master-pdf-editor, który dla Archa jest przebudowywany z binarki udostępnionej przez autorów tego programu. W jego przypadku kompresja (na moim komputerze, bo nie wykluczam, że na innym systemie może być inna) sięga 42%, a rozmiar pliku zmniejsza się z 19743320 do 8281320 bajtów.
Oczywiście więcej o opcjach programu dowiecie się po wydaniu polecenia:
upx --help

Popularne posty z tego bloga

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

Co naprawdę oznacza, że pacman (Arch) nie wspiera częściowej aktualizacji

Pośród osób pracujących na Arch Linux jak mantra powtarzane jest twierdzenie: pacman (Arch) nie wspiera częściowej aktualizacji. Co w istocie to oznacza? Jakie są najczęściej popełniane błędy?

1. Synchronizacja repozytoriów dla zabawy
Zdarzyło się Wam wydać polecenie pacman -Sy bądź pacman -Syy, a za jakiś czas instalować program poprzez pacman -S? Jeśli nie, to jak dowodzą świadectwa innych użytkowników tu i ówdzie rozsiane po internecie praktyka ta wcale nie jest tak rzadka. Zobaczmy zatem co się dzieje w takich przypadkach i do czego to prowadzi.
Pierwsze polecenie dokona synchronizacji informacji o dostępnych paczkach (w tym ich wersjach) w repozytoriach z informacjami lokalnie przechowywanymi w bazie pacmana. Nie jest dokonywana żadna aktualizacja systemu. Następne polecenie oczywiście zainstaluje paczkę. Paczkę w takiej wersji, jaka jest w danym momencie w repozytorium.
Zwróćmy teraz uwagę na to w jaki sposób budowane są paczki w repozytoriach Archa oraz jakie informacje przekaz…