Jak widać na powyższym zdjęciu Internetowa społeczność również jest w stanie się spotkać i przy tym świetnie bawić. Pogoda była piękna, atmosfera zlotu rewelacyjna. Pomijając fakt, że na 3 czy 4 rozgrywki bilarda wygrałem może 1, naprawdę warto było tam być i grać w U7!

Poolcamp poprzedził trójmiejski odpowiednik poznańskiego barcampa - 3camp, na którym to byliśmy również w licznym gronie. 3camp opuściliśmy zaraz po przerwie z tego względu, iż mieliśmy zarezerwowane stoły w U7. Odnośnie prezentacji uczucia mam mieszane, szczerze mówiąc jeszcze wiele brakuje naszym pomorskim kolegą w porównania z poziomem obecnym na barcampie.

Galeria: http://janusz.kaliszczak.pl/images/blog/2008.06.17-3camp-poolcamp/ oraz http://www.flickr.com/photos/harnir/sets/72157605672618713/

Poniżej przedstawiam schemat sieci (made in Gimp), na której to bazie będziemy konfigurować bezprzewodowy punkt dostępu do Internetu.

Komputer, który zostanie podpięty do sieci Internet przez interfejs eth0 pełnił będzie rolę stacji udostępniającej połączenie na interfejsie ath0 a więc zarazem posłuży jako punkt dostępowy AP dla reszty maszyn w sieci.
Na komputerze udostępniającym połączenie niezbędne jest zainstalowanie pakietu madwifi oraz wpasupplicant. Pakiet z WPA jest nam potrzebny do zabezpieczenia AP przed niepożądanymi stacjami roboczymi, które ewentualnie będą chciały skorzystać z naszego dostępu do Internetu.

AP do szyfrowania transmisji wykorzystywać będzie WPA. Tak więc kolejnym krokiem będzie zainstalowanie oraz skonfigurowanie Hostapd, który będzie pełnił rolę daemona obsługującego autentykację oraz pracującego jako AP.
Konfiguracja dla Hostapd:

interface=ath0
bridge=br0
driver=madwifi
# show verbose output
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
debug=4
dump_file=/tmp/hostapd.dump
ctrl_interface=/var/run/hostapd
ctrl_interface_group=0
ssid=domowy_ap
eapol_key_index_workaround=0
eap_server=0
wpa=1
#wpa_psk_file=/etc/hostapd/wpa_psk
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
wpa_passphrase=tajneHaslo

Z czego należy zauważyć, iż hasło podawane jest w formie jawnej. Jeżeli nam to nie odpowiada, możemy odkomentować linię wpa_psk_file i tym samym zdefiniować ścieżkę do pliku z kluczem wygenerowanym przez wpa_passphrase.

Rozpoczęcie udostępniania połączenia Internetowego sprowadza się do następujących czynności:

• Uruchomienia skryptu start_ap.sh (którego kod znajduje się niżej)
• Wystartowania Hostapd (hostapd /etc/hostapd/hostapd.conf)

Ze względu, iż w konfiguracji Hostapd ustawiliśmy tryb debug na 4 (verbose mode) na konsoli zostaną wyświetlone wszystkie informacje odnośnie błędów, inicjalizacji połączeń itd:

Configuration file: /etc/hostapd/hostapd.conf
Configure bridge br0 for EAPOL traffic.
madwifi_set_privacy: enabled=0
BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits)
madwifi_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3
madwifi_set_privacy: enabled=0
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=0
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=1
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=2
madwifi_del_key: addr=00:00:00:00:00:00 key_idx=3
Using interface ath0 with hwaddr 11:11:11:11:11:11 and ssid 'domowy_ap'
.........................................................

Wyłączenie Hostapd odbywa się poprzez standardowy hotkey CTRL+C natomiast interfejsy sieciowe przywracamy do pierwotnego stanu przez uruchomienie stop_ap.sh. Skrypty start_ap i stop_ap stworzyłem na własne potrzeby z tego względu, iż ciągłe uruchamiane tych samych poleceń było strasznie uciążliwe i spowalniało cały proces.

Opis interfejsów umieszczonych we wpisie:
ath0 - bezprzewodowa karta sieciowa pracująca w trybie AP
eth0 - karta Ethernet łączącą komputer z Internetem
br0 - mostek sieciowy między ath0 i eth0
192.168.0.111 - komputer z interfejsem bezprzewodowym, który udostępnia połączenie
192.168.0.1 - bramka sieciowa (gateway)

Systemem operacyjnym, na którym uruchamiałem Hostapd jest Debian. Bezprzewodowa karta sieciowa to Atheros AR5BMB5.

start_ap.sh - podnosi interfejs wifi, ładuje drivery, ustawia kartę w tryb Access Pointa, tworzy mostek oraz dodaje domyślną bramę.

#!/bin/sh

# unload madwifi
madwifi-unload

# load madwifi
modprobe ath_pci
modprobe wlan_scan_sta
modprobe ath_rate_sample
modprobe wlan
modprobe ath_hal

# set up wifi interface
ifconfig wifi0 up

# set card into AP mode
wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode ap

ifconfig ath0 0.0.0.0
ifconfig eth0 0.0.0.0

# create bridge
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 ath0
ifconfig br0 192.168.0.111 up

# add default gateway
route add default gw 192.168.0.1

stop_ap.sh - skrypt zatrzymujący AP. Usuwa drivery madwifi z pamięci, kładzie interfejsy oraz restartuje sieć.

#!/bin/sh

# unload madwifi
madwifi-unload

# down interfaces
ifconfig eth0 down
ifconfig br0 down

# delete bridge
brctl delif ath0
brctl delif eth0
brctl delbr br0

/etc/init.d/networking stop
/etc/init.d/networking start

Definicja triggera w MySQL wygląda następująco:

Trigger_event to zdarzenie, po którym następuje wywołanie określonego bloku instrukcji. Możliwe opcje to:

• INSERT - dodanie rekordu do tabeli
• UPDATE - uaktualnienie rekordu
• DELETE - usunięcie rekordu

Z czego triggery mogą być wywoływane przed danym zdarzeniem - BEFORE lub po wystąpieniu danego zdarzenia - AFTER.

Rozważmy następujący scenariusz:

Istnieje tabela przechowująca dane dotyczące książek, jest to system wykorzystywany w bibliotece XYZ. Dostęp do systemu ma wielu użytkowników za pośrednictwem panelu administracyjnego. Możliwe jest dodawanie, usuwanie oraz modyfikacja pozycji książkowych. Aplikacja tworzona była dość dawno i z tego też względu zapomniano o zaimplementowaniu potrzebnych dzisiaj funkcjonalności.
Pewnego dnia bibliotekarka chcąc dodać nową książkę do bazy danych, zauważyła iż ktoś z użytkowników popełnił błąd podczas edycji ostatnio dodanych pozycji i usunął jedną z książek. Chcąc powiadomić użytkownika o błędzie uświadomiła sobie, że nie jest w stanie się dowiedzieć, który z kilkunastu bywalców biblioteki dokonał błędnej modyfikacji, kiedy oraz jaka książka została usunięta. Wezwano więc informatyka aby zaimplementował mechanizm pozwalający na śledzenie historii zmian dokonywanych przez osoby z poziomu panelu administracyjnego.
System był przestarzały, tym samym w kodzie źródłowym istniały rozwiązania już nie tak popularne jak niegdyś. Programista stwierdził, iż szybciej będzie jeżeli skorzysta z udogodnień oferowanych przez MySQL w postaci triggerów, niżeli miałby tracić czas na analizę kodu źródłowego i jego modyfikację.

Struktura tabeli zawierającej pozycje książkowe przedstawia się następująco:

+---------------+------------------+------+-----+---------+----------------+
| Field         | Type             | Null | Key | Default | Extra          |
+---------------+------------------+------+-----+---------+----------------+
| id_book       | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| b_title       | varchar(45)      | NO   |     | NULL    |                |
| b_description | varchar(255)     | NO   |     | NULL    |                |
| b_datetime    | datetime         | YES  |     | NULL    |                |
+---------------+------------------+------+-----+---------+----------------+

Aby możliwe, było prowadzenie historii zmian potrzebna jest dodatkowa tabela, do której będą zapisywane logi.

+------------+------------------+------+-----+---------+----------------+
| Field      | Type             | Null | Key | Default | Extra          |
+------------+------------------+------+-----+---------+----------------+
| id_log     | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| l_bookt    | varchar(255)     | YES  |     | NULL    |                |
| l_datetime | datetime         | YES  |     | NULL    |                |
+------------+------------------+------+-----+---------+----------------+

Teraz można przejść do deklaracji wyzwalacza dla tabeli bibl_books. Podczas usuwania rekordu z tabeli zawierającej książki automatycznie dodawany będzie wpis w tabeli z logami - historia zmian.

W ten sposób wpisy usuwane z tabeli bibl_books będą lądować w tabeli bibl_logs.

Wyzwalacze w wielu sytuacjach mogą stać się bardzo przydatne, momentami zaoszczędzają nam konieczności ingerencji w kod źródłowy aplikacji aby uzyskać pożądane efekty. Możliwa jest także deklaracja zmiennych oraz przypisywanie do nich wartości w trigerrach:

Więcej informacji na temat trigerrów można znaleźć na poniższych stronach:

http://www.quest-pipelines.com/newsletter-v8/0207_D.htm
http://forge.mysql.com/wiki/Triggers

W ostatnim czasie potrzebowałem wydobyć interesujące mnie informacje ze zrzuconych danych pakietowych do plików wygenerowanych przez tsharka. Ze względu na fakt, iż nie były to czyste dane lecz też nagłówki protokołów sieciowych oraz ramki musiałem te dane odpowiednio wyłuskać.
Napisałem do tego celu skrypt w pythonie, który interesujące mnie pakiety wydobył z pliku i zapisał na wyjściu. Widać po kodzie, że pisany był w pewien sposób pod protokół gadu-gadu.

Poniżej przedstawiam przykładowy fragment danych przechwyconych przez tsharka.

radek@:~/# ./extract.py
extract.py <dumped_file> <protocol> <out_file>

Analogicznie do powyższego schematu na wejściu do skryptu podajemy nazwę pliku ze zrzuconymi pakietami, protokół który nas interesuje oraz plik wyjściowy.

Protokołem może być dla przykładu gadugadu lub też numer portu. Przykładowo:

radek@:~/# ./extract.py dumped.dmp gadugadu out.dmp

Skrypt do pobrania poniżej.

extract.py

CodeIgniter posiada wbudowany profiler oraz benchmark, dzięki któremu możemy zmierzyć czas wykonywania się danego kontrolera, czy też poszczególnych bloków kodu. http://codeigniter.com/user_guide/general/profiling.html

Miłośników systemu Windows zapewne uszczęśliwi fakt dostępności łatwego i wygodnego IDE dla PHP, które posiada wbudowany profiler, mowa tutaj o PhpED od NuSphere. Wersja podstawowa kosztuje 119$ i oczywiście pozbawiona jest Advanced PHP profiler, natomiast wersja profesjonalna z udogodnieniami, których brak w wersji podstawowej warta jest 299$ (porówanie wersji).
Wydatek nie duży w przypadku, gdy zakupujemy program do firmy, natomiast zbyt wysoki dla przeciętnego Kowalskiego, który dojeżdża do pracy rowerem. Również zwolennik Open Source nie wyda swoich ciężko zarobionych pieniędzy na Software, nie ze względu na jego wysoki koszt ale na sam fakt, że w świecie wolnego oprogramowania za programy po prostu się nie płaci.

Instalacja Xdebug

Wykorzystamy do tego celu Xdebug, narzędzie do debugowania i profilowania aplikacji stworzonych w PHP, które występuje w postaci modułu dla tegoż właśnie języka programowania. Instalacji rozszerzenia można dokonać na kilka różnych sposobów, wszystkie dokładnie opisane zostały w dokumentacji projektu. Osobiście preferuję instalację ze źródeł, najnowsze można pobrać poprzez CVS

radek@:~ cvs -d :pserver:srmread@cvs.xdebug.org:/repository login
CVS password: srmread
radek@:~ cvs -d :pserver:srmread@cvs.xdebug.org:/repository co xdebug
radek@:~ cd xdebug
radek@:~ phpize && ./configure && make clean && make
radek@:~ cp modules/xdebug.so /folder/dla/modulu/

Gdy skopiujemy już gotowy moduł do wybranego folderu możemy przystąpić do konfiguracji. Domyślnie plik konfiguracyjny PHP pod Apache2 znajduje się w /etc/php5/apache2/php.ini dodajemy do niego następujące wpisy:

zend_extension=/folder/dla/modulu/xdebug.so

; General
xdebug.default_enable=on
xdebug.extended_info=1

; Profiling
xdebug.profiler_enable=1
xdebug.profiler_output_dir=/tmp/xdebug_profiler
xdebug.profiler_output_name=cachegrind.out.%p

Wyniki profilowania w postaci plików wyjściowych będą zapisywane w folderze /tmp/xdebug_profiler/ Upewnijmy się, czy taki folder aby na pewno istnieje i posiada prawa do zapisu (chmod 777). To tyle z procesu instalacji, możemy teraz zrestartować demona Apache i sprawdzić czy profilowanie działa.

Możemy tego dokonać poprzez wyświetlenie dowolnego pliku php na naszym lokalnym serwerze i sprawdzeniu czy analiza z uruchomienia została zapisana w /tmp/xdebug_profiler.

radek@:/ ls /tmp/xdebug_profiler/
-rw-r–r–  1 www-data www-data 1,8K 2008-02-03 14:24 cachegrind.out.7144

Wyniki Profilowania

Dzięki Xdebug jesteśmy w stanie wyłapać błędy w naszej aplikacji w postaci niezoptymalizowanego kodu, który jest przyczyną spadku wydajności. Obserwując wygenerowane wyniki w KCachegrind lub WinCacheGrind możemy w prosty sposób zlokalizować te warstwy aplikacji, które wykonują się najdłużej czy też te, które najczęściej były wywoływane. Mamy także możliwość poruszania się po wygenerowanym grafie (KCachegrind), który przedstawia strukturę odwołań.

KCachegrind

WinCacheGrind

Z powyższego zestawienia wynika, że trzema najdłużej wykonującymi się metodami w projekcie są kolejno:

1. konstruktor klasy Welcome - 1,7ms
2. konstruktor klasy Controller - 1,7ms
3. metoda _ci_initialize klasy Controller - 1,7ms

Tuż za nimi plasuje się z numerem czwartym metoda _run_hook z klasy CI_hooks z czasem 1,4ms.

Zlokalizowanie miejsca występowania anomalii zapewnia nam możliwość jej zlikwidowania oraz przywrócenia aplikacji właściwego stanu wydajności. Należy przy tym pamiętać o zagnieżdżonych odwołaniach do zewnętrznych modułów czy też implementacjach np. zapytań sql, przy których może okazać się konieczna ich optymalizacja aby uzyskać interesujące nas efekty optymalizacji. Profilowanie aplikacji jest rzeczą bardzo ważną, zależy od tego późniejsze funkcjonowanie naszego systemu, który powinien być niezawodny i przede wszystkim szybki.

Mowa tutaj o Introspekcji (ang. Reflection), a właściwie to interfejsie funkcji API pozwalający nam na pobieranie kompletnych informacji odnośnie:

• klas (ang. classes)
• interfejsów (ang. interfaces)
• metod (ang. methods)

To nie wszystko, automatycznie otrzymujemy także dostęp do dokumentacji tychże klas/funkcji/interfejsów (ang. doc comments). Poniżej podaję wybrane metody obiektów (nie wszystkie), które posłużą w dalszej pracy.

Przepuśćmy, że istnieje taki scenariusz:

Zbudowaliśmy system, działający pod obsługą PHP 5, naszym celem jest poszerzenie jego funkcjonalności o interfejs, którym pozwoli nam na dołączanie zewnętrznych rozszerzeń naszej aplikacji (ang. Plugins). Wtyczki w tym wypadku to pliki php zaprojektowane w odpowiedni sposób, tak aby implementowały odpowiednie metody i posiadały sprecyzowane wartości. Przeanalizujmy po kolei kroki, które musimy wykonać:

1. wczytanie plików *.php z wybranej lokalizacji tj. folderu z wtyczkami
2. iteracja na każdym pliku
3. weryfikacja pliku jako w pełni funkcjonalnego rozszerzenia

• istnienie klasy o nazwie równej nazwie pliku (bez rozszerzenia)
• klasa dziedziczy po obiekcie Plugins
• zaimplementowane są następujące metody: load(), unload(), display()
• powyższe metody nie są ani chronione ani prywatne - muszą być publiczne
• w dokumentacji klasy zawarta jest informacja o autorze oraz wersji

Jeżeli powyższe kroki zostaną wykonane a warunki spełnione oraz plugin przejdzie pomyślnie proces weryfikacji, możemy załadować go do systemu. Wczytywanie plików z lokalizacji oraz iteracji po każdym z nich nie będę opisywał ze względu na łatwość implementacji oraz dostępność podobnych rozwiązań, podam jedynie przykładowy kod:

Blok kodu umieszczony w foreach będzie sercem naszej implementacji, to w nim będą następować operacje na obiektach zaimplementowanych przez wtyczki.

Reverse Engineering

Wykorzystamy do tego celu wspomniany wcześniej obiekt ReflectionClass oraz ReflectionMethod, fragment kodu, który sprawdza czy podany plik spełnia wszystkie wcześniej wymienione warunki aby być poprawnym rozszerzeniem.

Mam nadzieję, że powyższy praktyczny przykład rzucił więcej światła na problem związany z wykorzystaniem jednej z technologi oferowanych przez PHP 5. Kod był pisany od ręki mimo to mam nadzieję, że ustrzegłem się od jakichkolwiek uchybień i błędów.

Czy podczas czytania tego tekstu były rzeczy dla Ciebie nie zrozumiałe, zdające się być niepoprawne, masz jakiekolwiek zastrzeżenia? Zostaw informację w komentarzach lub skontaktuj się ze mną poprzez e-mail.

Pozostałe metody (nie dotyczy użycia Introspekcji)

Wykorzystanie Reflection API nie jest jedyną metodą na uzyskanie informacji z pliku odnośnie zawartych w nim klas, funkcji, metod danych klas czy też zmiennych. Można tego dokonać również przy użyciu standardowych metod, mam na myśli tutaj kwestie możliwe do wykonania także przy użyciu PHP 4.

Nie jestem tego w stanie lepiej przedstawić niż podając konkrety.

No dobrze, wszystko zdaję się działać? Mamy już nazwę klasy, wiemy czy dziedziczy ona po klasie ‘Plugins’, jesteśmy również w posiadaniu tablicy z metodami danego obiektu. Pozostało nam sprawdzenie czy posiada zadane 3 metody i czy są one publiczne… i tutaj zaczynają się schody. Trzeba to zrobić trochę na około używając wyrażeń regularnych.
Zrobiłem to według kilku punktów:

1. Usuwam z pliku wszystkie komentarze, aby wyeliminować ewentualne funkcje, klasy, które są ukryte w komentarzach a mogłyby zostać błędnie rozpoznane i załadowane w dalszej części.
2. Następnie gdy już usunąłem 3 typy komentarzy (// # /**/) mogę dopasować funkcje do wzorca
3. Sprawdzam również czy po nazwie obiektu następuje słowo “extends” i pobieram nazwę klasy, po której dziedziczy

Poniżej niezbędna lista wzorców:

Metoda nie wykorzystująca Introspekcji jest czasochłonna, przede wszystkim dlatego, iż dużo jest manipulacji z obrabianiem zawartości pliku. Problem mogą sprawić także niedociągnięcia we wzorcach wykorzystywanych jak widać na każdym kroku. Stanowczo polecam migrację z PHP 4 do 5. Projektując i tworząc aplikacje liczy się wydajność i łatwość rozbudowy, tak więc to od Ciebie zależy czy kod, który stworzyłeś będzie czytelny i łatwy w rozbudowie dla potencjalnych następców. Jeżeli zdecydowałeś się wykorzystać drugą metodę związaną z wyrażeniami regularnymi, radzę dodać komentarze do wzorców - odpowiednio opisane będą łatwe do zrozumienia nawet dla laika.

Przedstawiony tekst nie wyczerpuje całego tematu związanego z Introspekcją, po więcej informacji odsyłam pod adres http://php.net/manual/en/language.oop5.reflection.php do manuala PHP.

Życzę przyjemnej i owocnej pracy.

Wszystko zaczęło się od “Mordercy Laptopów”, jak niespodziewana lawina pociągnął za sobą kolejne linki… wyszukiwane frazy… opinie ekspertów… Gdy już zebrałem wymagane dane, przystąpiłem do analizy.

Możliwe jest iż przy niewłaściwych ustawieniach Zaawansowanego Zarządzania Energią dla dysku twardego, jest on w stanie zużyć się w czasie wielokrotnie krótszym, niżeli przy poprawnych ustawieniach.

Pobrałem pakiet potrzebny do zdiagnozowania problemu, właściwie to zrobiło to za mnie Aptitude.

root@~ / aptitude search smartmontools
p   smartmontools     - control and monitor storage systems using S.M.A.R.T.
root@~ / aptitude install smartmontools

Narzędziem zawartym w wyżej pobranej i zainstalowanej paczce, potrzebnym do diagnostyki jest smartctl, korzystamy z niego w następujący sposób:

root@~ / smartctl -d ata -a /dev/sda | grep Load_Cycle_Count

ATA - typ naszego dysku może być również SCSI, SAT (skrót od SATA)
/dev/sda - lokalizacja naszego urządzenia

Wartość, której szukamy to Load_Cycle_Count

193 Load_Cycle_Count 0×0032 099 099 000 Old_age Always - 17541

Jak widać z powyższego wpisu wartość Load_Cycle_Count dla mojego dysku twardego wynosi 17541 - dużo? Raczej nie, biorąc pod uwagę fakt, że laptop na baterii pracuje sporadycznie no i przede wszystkim jest nowy, nabyłem go zaledwie 4 miesiące temu.
Liczba cykli wzrasta u mnie wolno, tak więc nie przejmuję się tym problem, w końcu dysk nie ma nawet kiedy przełączyć się w tryb oszczędzania energii, więc nie ma czynnika, który mógłby powodować diametralny wzrost tej wartości.
Jednakże ten problem jest poważny mimo, że na taki nie wygląda, przykładem może być wpis Stefano Rivers’a u którego to owa magiczna wartość sięgnęła rzędu 160 000 w zaledwie trzy miesiące - imponujące nieprawdaż?

Jeżeli poniższe symptomy występują u Ciebie powinieneś zacząć się martwić i przeciwdziałać temu problemowi zanim stanie się na tyle poważny, że jego likwidacja nie przyniesie żadnych korzyści, ze względu na spóźnioną reakcję.

Symptoms of this bug are:
* frequent HD clicks — more than one per 3 minutes while idle, louder than the typical access sounds. Often more than twice per minute.
* Rapidly Increasing Load_Cycle_Count as displayed in the final number in “sudo smartctl -a /dev/hda | grep Load_Cycle_Count” (where /dev/hda is replaced with your own hard disk device)
* Early hard disk failure — some disks are cut down to less than a year of actual uptime.The problem seems to be caused by:
* Hardware defaults to aggressive power management, causing heads to park.
* Disk is touched often, causing heads to unpark.
* Most laptop drives handle up to 600,000 such cycles.Reasonable Limits / Criteria for a fix:
* There should be fewer than ~15 load cycles per hour, except during heavy usage while on battery.

No i oczywiście tymczasowe obejście problemu:

hdparm -B 254

-B set Advanced Power Management setting (1-255)

bug: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695

Na pierwszy rzut oka wszystko działało, FlashFXP uruchamiał się bezproblemowo, działały zakładki, okna… jednakże po chwili dostrzegłem, że realizacja połączenia z serwerem jest niemożliwa - FlashFXP nadzwyczajnie w świecie zawieszał się. Wina leżała po stronie obsługi kontrolki listy, która była odpowiedzialna za wyświetlanie plików zawartych na serwerze.

Znalazłem informacje na temat tego błędu w bugtrack-u Wine:

http://bugs.winehq.org/show_bug.cgi?id=5131
“The issue is caused by a message loop between the app and the
comctl32 listview code, when the listview is virtual (LVS_OWNERDATA).”

Błąd istnieje w comctl32/listview.c pobrałem patcha i zastosowałem go wedle zaleceń:

http://bugs.winehq.org/attachment.cgi?id=5518

Poprawiłem błędny kod listview.c oraz skompilowałem Wine raz jeszcze:

patch dlls/comctl32/listview.c < patch
./configure
make && make install

Po tych zabiegach wszystko działa bezproblemowo z Wine w wersji: 0.9.49

Korzystanie z komercyjnego oprogramowania trochę się kłóci z ideologią open-source propagowaną wraz z Linuksem, ale co zrobić gdy czasami nie można znaleźć alternatywy a ja osobiście lepszego klienta FTP jak do tej pory nie widziałem. Jeżeli posiadasz alternatywę, która według Ciebie mnie zainteresuje, pozostaw informację w komentarzach.