Noszę się z zamiarem napisania krótkiego artykułu o sygnałach cyfrowych i kablach od HotZlotu 2011, kiedy to miły Pan z HP zasugerował, że jakość kabli (z uwzględnieniem sygnałów cyfrowych) ma bardzo duże znaczenie w przesyle obrazu. Zaprotestowałem, ktoś jeszcze z sali rzucił, iż "jak działa to działa", niestety nie wiem co dokładnie miał na myśli, ale tak - mniej więcej tak właśnie jest. Ale może od początku.

Kiedyś, w jeszcze nie tak dawnych czasów, do połączenia karty graficznej z monitorem stosowano tak zwany przewód VGA, jak pewnie wszyscy wiedzą jest to analogowy rodzaj tarnsmisji, domyślnie w zakresie 0-0,7V, potrzebujący minimum 6 przewodów. Odpowiednio: sygnału dla komponentu Czerwonego (R), komponentu Zielonego (G) i niebieskiego (B), 2 sygnałów synchronizacji (pionowej i poziomej) oraz masy.

Dawno nic tu nie pisałem, to może czas coś skrobnąć. Zastanawiałem się nad kolejną edycją zasobożerności komunikatorów testu, ale z tym poczekam na nową stabilną AQQ. Wygląda jakby dostało nowego systemu systemu skórek, co źle wpłynęło na "pożeranie".

Tymczasem w związku z jednym moim pokrętnym planem, dopadłem coś co się nazywa "Microsoft Application Verifier". To takie narzędzie, które kiedyś było fajniejsze bo miało więcej testów, a teraz jest mniej fajne bo ma mniej, no ale cóż. W każdym razie, to takie narzędzie, które współpracując z odpluskwiaczem pozwala na zlokalizowanie nieprawidłowych wywołań do funkcji systemowych, sytuacji z rodziny "double free", czy nadpisania kawałków stosu, których się nadpisywać nie powinno i tak dalej, i tym podobne. Generalnie częścią tych zadań powinien się zajmować debugger (i mózg programisty), ale jak się okazało na moim przykładzie, czasem mózg programisty potrafi tak dobrze ukryć sytuację powodującą problem, że odpluskwiaczowi wydaje się, iż wszystko jest w najlepszym porządku.

Przedwstępnie

Wpis nie ma za zadanie tłumaczenia fizykom jak działają ogniwa akumulatorów. Oni już w większości mają odpowiednią wiedzę, jest to tekst raczej dla zwykłego zjadacza chleba, dla którego świadomość, że pierwiastka nie da się wyciągnąć z liczby ujemnej, jest wystarczająca do normalnego funkcjonowania (a dać - się da). Zawiera dużo uproszczeń, uogólnień i innych podobnych rzeczy, nie jest w 100% dokładny, i nie porusza wszystkiego co mógłby poruszać. To tylko takie nakreślenie tematu ładowalnych baterii wraz z, mam nadzieję, w miarę prostym i niezbyt głębokim wytłumaczeniem paru efektów, które w ogniwach zachodzą, a są mylnie brane za coś innego. Ah i jeśli bardzo się upierasz, że nie wiem o czym piszę, skocz na wiki. Nie na polską, tam nawet tłumaczyć czasem haseł nie umieją, tylko angielską. I nie czytaj tego co tam jest napisane, skocz jednak do przypisów, dużo ciekawych tekstów. A poza tym Docent mnie ignoruje i wciąż nie dostaję powiadomień o nowych artykułach z dp na XMPP.

Wpis powstał sobie z potrzeby wytłumaczenia kliku rzeczy, prawdopodobnie tysiącom ludzi. Ileż to razy pod różnymi komunikatorami widzimy wpisy w rodzaju "a u mnie zabiera tylko 9 Mega ramu", w domyśle "pewnie masz coś nie ta z systemie skoro Tobie zjadło 60!". Problem polega jednak na tym, że takie "porównania" są dokładnie warte tyle co nic. Gdyż, ponieważ, bo: jeden użytkownik ma 10 kont protokołów dodanych, inny ma jedno, trzeci ma 4 ale za to ma włączone awatary albo sprawdzanie pisowni, które często pochłaniają spore ilości pamięci i czasu procesora. A nawet gdyby wszyscy mieli takie same ustawienia, pozostaje problem pod tytułem "komunikatory dostają różne ilości/typ danych". Rozumiemy, że tak się nie da?

Powstała zatem myśl, aby zrobić porównanie tego jak bardzo "zjadliwe" są te programy dla systemu, w miarę identycznych warunkach. Na warsztat wziąłem 5 sztuk testowych: AQQ (2.2.4.50), WTW (0.8.5.2510), Kadu (beta bodaj 11), Miranda (0.9.16) oraz Tlen7 (7.0.0.72). Dlaczego te? Bo są w większości multikomunikatorami, i potrafią spełnić warunek "jedno konto gadu i jedno xmpp".