Dwa lata później mój pierwszy Sony Ericsson (któremu zostałem wierny bardzo długo) T230 – niby gorszy od Nokii, bateria trzymała krócej, ale miał w sobie to coś, że chciałem go mieć.

Rok 2007 – Sony Ericsson K310i – miał aparat (VGA, szaleństwo), sensowniejszy wyświetlacz, pierwszy telefon na którym zacząłem korzystać z mobilnego internetu (głównie z m.blip.pl ), doinstalowałem kilka javowych aplikacji i służył mi dopóki się nie zaczął rozlatywać, gubić zasięg i bateria przestała trzymać.

W 2009 roku kolejny produkt Sony Ericssona – W810i to był już duży skok technologiczny w porównaniu do poprzednich modeli jakie posiadałem: aparat 2MP, możliwość rozszerzenia dostępnej pamięci za pomocą kart Memory Stick, odtwarzacz MP3, miał już EDGE’a, więc przeglądanie mobilnego internetu było jeszcze szybsze, aczkolwiek to wciąż nie było to czego mi było potrzeba.

Nadszedł więc rok 2010 i postanowił wydać trochę więcej pieniędzy niż na poprzednie telefony, brakowało mi czegoś z dobrym dostępem do internetu, zwłaszcza za pomocą Wi-Fi, wygodniejszą klawiaturą niż standardowa w telefonach (praca na ssh w czasie awarii  serwerów nie była zbyt wygodna przy użyciu T9). Na iPhone’a nie było mnie stać, kusiła Motorola Milestone, ale jej cena wciąż była ciut za wysoka jak na moje progi. Dostępnych modeli o sensownych parametrach nie pozostało zbyt wiele. Ostatecznie wybór padł na Samsung GTi5700 znany również jako Galaxy Spica. Wi-Fi, GPS, dotykowy ekran, karty pamięci do 8GB, procesor 800MHz i czynnik najważniejszy: Android.

Jako fan linuksa i Google’a , ucieszyłem się niezmiernie, że nareszcie będę miał telefon na kernelu jaki znam, z userlandem od Google i co najważniejsze – z integracją z usługami Google’a.  Nie wiem jak gdzieś dojść w Warszawie: 3G, GPS, Google Maps. Potrzebuje z kimś pogadać na szybko – Google Talk, chcę sobie dodać do kalendarza jakieś wydarzenie – Google Calendar, a to wszystko z pełną sychronizacją z naszym kontem Google, z kontaktami włącznie. Można również dodać konto w Google Apps jeżeli mamy swoją domenę podpiętą pod usługi Google’a. Jedyne czego mi brakuje to integracji z Google Docs, ale tak na dobrą sprawę nie wyobrażam sobie edycji arkuszy kalkulacyjnych na ekranie telefonu. System ma jednak swoje wady, nie jest do końca tak stabilny jak można byłoby przypuszczać, z wydajnością również nie jest zbyt wesoło (tak, aktualizowałem do 2.1, czekam na 2.2, nie boję się eksperymentować)

Posiadając pierwszy telefon, nigdy nie wpadłbym na pomysł, że kiedyś będę oglądał filmy na YouTube na ekranie takiego formatu, korzystał z GPS gdy zgubię się w mieście (w Warszawie mieszkam od dwóch miesięcy, ale o tym jutro ), czy sprawdzał co nowego na facebooku/twitterze/blipie/mailu (o tym też  w najbliższym czasie).

Do czego cały wpis zmierzałem -  mam 20 lat, technologia mnie przeraża. Zwłaszcza postęp w jakim idzie do przodu. Niedługo nastanie czas, że będą nam wszczepiać chipy pod skórę i to wystarczy by pozbawić nas resztek prywatności. I zintegrować z Siecią.

Realizacja zamówienia trwała 2 dni, na testy mam kolejne 3. Co więc dostajemy w ramach miniCloud?
W moim przypadku jest to instancja z procesorem Intel Xeon o taktowaniu 2GHz, 2004MB pamięci operacyjnej (taką wartość wskazuje free -m ) oraz 5GB przestrzeni dyskowej (przy czym na ‘świeżej’ instalacji dostępne jest 4,2GB wolnego miejsca). Nie wiem, czy wartości te były dobierane losowo, czy jest to też jedna z opcji jakie będą dostępne (tylko w takim razie dlaczego tak mało przestrzeni?), w każdym razie informacji na ten temat, ani wyboru nie miałem. miniCloud działa pod kontrolą systemu linuks Debian w wersji 5.0.4 w podstawowej instalacji, z uruchomioną usługą sshd (dostajemy dostęp do roota).
Jeżeli chodzi o wydajność, jest przyzwoicie. Ping do serwerów sieci ovh poniżej jednej milisekudy, do Polski (onet) w granicach 35, więc normalne czasy jak na tego usługodawcę. Jeżeli chodzi o odczyt z dysku:
/dev/sda:
Timing cached reads: 8024 MB in 2.00 seconds = 4013.57 MB/sec
Timing buffered disk reads: 136 MB in 3.03 seconds = 44.92 MB/sec

Ciekaw jestem jak będzie z ceną za tą usługę, ale podejrzewam, że tanio nie będzie znając ceny usług OVH. Jeżeli będą naliczać opłaty za godziny działania (jak ma to miejsce w przypadku Amazon EC2) i będzie to w groszach, czy nawet złotówkach, może opłacać się przy potrzebie wykorzystania mocy obliczeniowej na krótką metę (aczkolwiek 2GHz to szczyt nie jest). Na chwilę obecną nie widzę kompletnie zastosowania dla tej usługi, mam jednak nadzieję, że ktoś wpadnie na pomysł jak rozsądnie to wykorzystać.
Na dzień dzisiejszy napisać więcej nie mogę, po dłuższym czasie napiszę wnioski ze stabilności usługi (należy pamiętać, że to wciąż beta) przy pracy z czymś obciążającym instancję.

Co jednak jeżeli mamy np debiana? Tu trzeba sobie trochę pomóc: doinstalowujemy demona rsyncd (w debianie: aptitude install rsync)  oraz dopisać do konfigu jak następuje (/etc/rsyncd.conf) :

[gentoo-portage]
#modern versions of portage use this entry
path = /home/rsync
comment = Gentoo Linux Portage tree mirror

gdzie path to ściezka do repozytorium, które synchronizujemy sobie następującym skryptem:


#!/bin/bash
RSYNC="/usr/bin/rsync"
OPTS="--quiet --recursive --links --perms --times -D --delete --timeout=300"
#Uncomment the following line only if you have been granted access to rsync1.us.gentoo.org
#SRC="rsync://rsync1.us.gentoo.org/gentoo-portage"
#If you are waiting for access to our master mirror, select one of our mirrors to mirror from:
SRC="rsync://rsync.de.gentoo.org/gentoo-portage"
DST="/home/rsync/"
echo "Started update at" `date` >> $0.log 2>&1
logger -t rsync "re-rsyncing the gentoo-portage tree"
${RSYNC} ${OPTS} ${SRC} ${DST} >> $0.log 2>&1
echo "End: "`date` >> $0.log 2>&1

Skrypcik wystarczy wrzucić do crona co powiedzmy 12h i maszyny w LANie pracujące pod gentoo mogą synchronizować się z nazzym własnym mirrorem. w make.conf  zmienna SYN powinna wyglądać podobnie:
SYNC="rsync://192.168.0.1/gentoo-portage"

feedback mile widziany.

IMO, BSD jest prostsze w konfiguracji/obsłudze, i gdybym miał moim rodzicom składać i konfigurować komputer do zadań typu przeglądanie sieci/obsługa poczty/obejrzenie filmu nie wahałbym się zainstalować FreeBSD, czy DragonFlyBSD.

Warto przeczytać informacje jakie emerge wyświetli po zainstalowaniu laymana.
Teraz listę dostępnych overlay’ów możemy wylistować za pomocą

layman -L

Dodajemy overlay welp’a:

layman -a welp

Teraz możemy normalnie zainstalować gajima, i cieszyć się z jego najnowszej wersji:

gajim_about

Przy następnym zamówieniu koniecznie muszę o tym pamiętać.
To z takich prywatnych przemyśleń trochę na dziś

Co więc skłoniło mnie do napisania o Boxee? Ano dziś rano (no, powiedzmy około południa ) sprawdzając skrzynkę pocztową, zauważyłem mail o mało spodziewanym temacie – „boxee is waiting for you”

No ok,  klik w link aktywacyjny i już jesteśmy na stronie służącej dokończeniu rejestracji. Po szybkim wypełnieniu kilku pól formularza, zostałem zalogowany. Ok, ale jak z tego korzystać… W panelu via www dostajemy możliwość szukania i zapraszania znajomych, dodania feeda RSS z multimediami oraz standartowo edycji profilu oraz opcji konta.

Zauważając link „Download”, zastanawiałem się, jak wygląda ichnia aplikacja (która jest sercem całości).
I w tym momencie moje rozczarowanie i myśl „Fail”. Do pobrania dostępne jedynie 3 wersje z czego 2 na Ubuntu  w różnych wersjach (8.04 & 8.10) , a trzecia na Mac OSX (10.4 i 10.5). Zdziwiło mnie bardzo, że nie przygotowali binarki ald Windowsa, ale może to i lepiej, w końcu z założenia ma to być produkt na *nixy wszelakie.
Tylko cóż ja biedny user gentoo mam począć? Na całe szczęście niżej znajduję się link  opatrzony tytułem „Download source”  – kolejne zdziwienie  – źródła programu ważą trochę ponad 140 mega, w dodatku wymagany jest flashlib.

Próbowałem sobie soft skompilować własnoręcznie. Poddałem się pod 3h prób, poczekam na gotowe buildy, lub aż pojawi się (być może kiedyś) w portage gentoo, tymczasem warto zainteresować się XBMC (Xbox Media Center), które zostało udostępnione na wszystkie platformy

Posiadając nieszczególnie mocną maszynę (powiedzmy PCta za 900zł, ze zintegrowaną intelowską grafiką), możemy niskim kosztem dostać fajny Media Center

Zaiste, gdy load average serwera z procesorem Intel Core2Duo o taktowaniu rzędu 2GHz z 8GB ramu i terabajtowym storagiem w postaci raidu osiąga ponad 120, czy nawet ponad 200, ewidentnie coś musi być nie tak.

W dzisiejszych czasach, gdy domowe stacje robocze posiadają grubo ponad 1GB pamięci (średnio pewnie koło 3GB),  4 rdzeniowe procesory (Intel Quad2Core czy AMD Phenom),  nie wspominając o maszynach stricte serwerowych, tak naprawdę wąskim gardłem są przepustowości jakie oferują nam dyski twarde (i wiem, że ameryki tutaj nie odkryłem)
Zdecydowanie większość serwerów dedykowanych jakie są obecnie stosowane przy hostowaniu wszelkich stron WWW posiada dyski na interfejsie SATA-2. Co jednak w sytuacji, gdy te 70 czy 80MB/s jest mocno niewystarczające?
Są dyski SAS (Serial Attached SCSI), które są trochę szybsze, czy SSD (które wszystkie obecne rozwiązania biją na głowę), jednak za 140GB dysk SAS zapłacimy około 900zl, SSD też nie są tanie. Jest jednak lekarstwo i na ten problem.

Pamięć RAM w chwili obecnej kosztuje grosze, ładując więc do serwera 8, 16 czy nawet 32 GB tego rodzaju „nośnika” danych (który będzie służył i tak tylko tymczasowemu ich przechowywaniu ) możemy dużo zaoszczędzić.

Jak więc zmniejszyć obciążenie maszyny, wykorzystać dostępną pamięć operacyjną, oraz przyspieszyć proces ładowania się stron?
Serwer httpd (załóżmy najpopularniejszy obecnie Apache), przy każdym requeście odczytuje plik jakiego żąda klient. Jeżeli do jednego pliku odnosi się 50 czy 100 requestów jednocześnie, plik jest odczytywany z dysku właśnie tyle razy, czyste marnotrastwo zasobów. A co gdyby klient łączył się z oprogramowaniem, które sprawdzi czy dany plik nie był już wysyłany w ostatnim czasie? (powiedzmy 1 minuty) Jeżeli plik nie znajdował by się w pamięci operacyjnej systemu, bądź istniał tam, a na dysku znajdowała by się jego zmieniona wersja, byłby odczytywany z dysku i do niej wrzucany. Przy kolejnym odpytaniu o ten plik, nie czytamy go już z dysku, a jedynie wysyłamy prosto z pamięci operacyjnej. Dzięki temu zmniejsza się liczba odwołań do dysku, apache zużywa mniej zasobów, a pamięć RAM (której w serwerach zazwyczaj wiele z czego większosć nie wykorzystana)  znalazłaby wykorzystanie.

Do tego celu służy takie oprogramowanie jak  squid w trybie reverse-proxy (który jednak do najlżejszych nie należy i którego nie polecam, jednak wypada o nim wspomnieć), moduł mod_mem_cache w Apache, czy dedykowany do takiego właśnie zastosowania varnish.

Cache’ować w ten sposób możemy pliki, których jest dużo, są małe, i zwiększają zapotrzebowanie na I/O dysku (obrazy jpg,png,gif, pliki css czy javascript, a nawet lekkie swf), nie polecam za to serwowania w ten sposób danych wynikowych plików php, gdyż zbyt często się zmieniają (w końcu mówimy tutaj o serwisach ze sporym ruchem i dużą ilością danych).

Skoro jesteśmy już przy kwestii cache, warto wspomnieć, że można w ten sposób również odciążyć serwery bazodanowe, w końcu to one zazwyczaj są najbardziej obciążone. Po co mamy odwoływać się za każdym razem bezpośrednio do MySQL’a, jeżeli wyniki zwracane przez zapytania (_zwracane_, nie bierzemy pod uwagę danych wprowadzanych) pozostają  bez zmian przez jakiś okres czasu (nawet jeśli jest to 30 sekund). Do tego celu służy genialne wręcz narzędzie o nazwie memcache, od strony administratora wystarczy instalacja daemona memcached, bibliotek do jego obsługi, krótka konfiguracja całości, a resztę pozostawiamy programistom. Z moich obserwacji wynika, że implementacja w kodzie obsługi tego mechanizmu keszowanie nie jest zbyt wielkim problemem.

Całość tekstu poparta jest moimi własnymi doświadczeniami. Dzięki zastosowaniu opisanych mechanizmów load spadł z ponad 100 do max 15 w godzinach największej oglądalności (Core2Duo 2GHz, 8GB ram, 2 dyski 500GB w RAID0), a czas ładowania się strony spadł z 20-30 sekund do 6 sekund. Na przykładzie szafa.pl