Ptak:(

Napisał bym coś interesującego, ale dopadła mnie wielomiesięczna niemoc twórcza. Skomentuję ten straszny obraz. Przedstawia zamordowanego z premedytacją gołębia na parkingu. Sprawca nieznany.

Centralizacja

"Przetwarzanie w chmurze", czyli nowy-stary model klient-serwer. Same zalety, tylko jedna mała wada: nie działa:)

Z życia korpoludka, Irlandia, Kick Off

Kolejne slajdowisko. Wokół mnie twarze znudzonych, ziewających ludzi. Szczerze - uważam, że nasi prapraprzodkowie mieli bardziej wyrafinowane, na pewno ciekawsze widowiska typu ścinanie głowy za pomoca gilotyny. Tłumy przychodziły to oglądać! Nas, biednych korpoludków, spedza się siłą do pomieszczeń bez okien i zapomina najpierw nakarmić! Ludzkość jak nic zdąża ku zagładzie.

Moje MTBF

Okazuje się, że moja niezawodność jest nieco mniejsza niż ostatnio zacząłem wierzyć. Awaria gardła, minimalny czas bez stanu uśpienia poniżej 48h, słowem jestem trochę rozczarowany swoją niezawodnością.

Tytułowy MTBF, to czym musimy się niebawem zająć (musimy, bo chodzi o około 3. osoby). Na całe szczęście prawdopodobnie nikt nie czyta tego posta, więc nie czuje się w obowiązku wyjaśniać o co chodzi - zresztą wszystko w swoim czasie.

Cały ten problem z niezawodnością, jest dość trudny do rozwiązania bo nie zależy tylko od nas, a od całej drabinki zależności, od których się uzależnimy. Załóżmy, że chodzi o niezawodność sprzętu komputerowego, zależy od niezawodności każdego elementu, a nie tylko od elementu najsłabszego (zasilacz, dyski, układ chłodzenia). Ale co mi z tej niezawodności sprzętu? To coś ma wykonywać jakieś przydatne zadanie, a nie tylko ocieplać - bezskutecznie jak widać - klimat na Ziemi! Potrzebujemy jakiegoś programu, który oczywiście zawierać będzie błędy, w:

1. naszym kodzie źródłowym,
2. kodzie wynikowym (może kompilator mieć jakieś błędy),
3. niepoprawne wykonanie programu przez sprzęt.

Oczywiście punkt 1. jest jedynym prawdopodobnym. Czyli zwykle to nasza wina:), możemy dla pewności użyć prostszego języka (asembler, C), mniejszej liczby bibliotek, co może pomóc jeśli nasz program nie jest szczególnie trudny (p. ,,Hello World'' i podobne). W przypadku nieco trudniejszych problemów jeśli nie jesteśmy uzbrojeni w armię hackerów, chyba lepiej założyć, że języki ,,wyższego'' poziomu, wspaniałe biblioteki, są dobrze przetestowane i porządnie napisane.

Program, programem, ale w związku z tym, że jesteśmy z natury bardzo leniwi, uruchamiamy nasz wspaniały program, na jakimś systemie operacyjnym. Czyli niezawodność naszego programiku, zależy jeszcze od środowiska kontrolującego jego pracę i udostępniającego mu interfejs do urządzeń we/wy i parę innych bajer, na których się nie znam. Wszystko jest oczywiście ciągle testowane, dobrze napisane, więc teoretycznie nie ma się co przejmować... a teraz pojadę po bandzie i zaproponuję eksperyment. Napiszmy najprostszy program na mikrokontroler/PC etc. który kontroluje małą prasę;), lub inne narzędzie "tortur", i pomyślmy, że mamy zaufać maszynie wciskając tam gdzie nie powinniśmy swoją dłoń. Program, właściwie nie musiałby nawet umieć kontrolować urządzenia, czy być nawet do niego podłączony, żebym nie miał specjalnej ochoty testować niezawodności systemu w ten sposób. Na szczęście zwykle nie potrzeba, a jak będzie taka potrzeba to zaryzykujemy, jak podobno robią architekci testując zbudowany most.