Co słychać we FreeBSD w 2010Q3?

Niedawno pojawił się kolejny FreeBSD Quarterly Status Report. Co tam ciekawego? A, to zależy, co dla kogo jest ciekawe. ;)

Ja zwracam uwagę np. na:

• postępy w projekcie Ringmap, o którym pisałem wcześniej
• postepy w migracji z GCC na CLANG, podobne ruchy można zresztą zaobserwować w Linuksie
• postępy w implementacji FreeBSD Services Control (fsc), odpowiednika Solaris Service Management Facility, Upstart itp. zamienników initd
• nowe moduły dla BSNMP (np. SNMPv3, WLAN)
• 5 nowych (w odniesieniu do New Reno) algorytmów unikania przeciążenia w TCP: CUBIC, HTCP, Vegas, HD and CHD (oparte o śledzenie opóźnień w transmisji, a nie tylko strat)
• framework Capsicum rozszerzający standardowe systemowe API o capabilities umożliwiające skuteczniejszy sanboxing aplikacji

PLNOG - październik 2010

W dniach 21-22 października 2010 odbyła się - tym razem w Krakowie - piąta edycja konferencji PLNOG (Polish Network Operators' Group).

Jedną z niewątpliwych polipowych sensacji (wysoki polip rating - wskaźnik użyty przez Grzegorza Paszkę) było objawienie TP IX, potencjalnego konkurenta dla PLIX i AC-X.

Autor Chefa opowiadał o tym narzędziu do automatyzacji autokonfiguracji serwerów, konkurencie Puppeta i Cfengine.

Allegro uchyliło drzwi od kuchni w prezentacji o zastosowaniach OpenSolarisa. Wydają się zbytnio nie przejmować przyszłością tego projektu. ;)

Cisco zaprezentowało koncepcję Telco 3.0, w której każdy może zostać wirtualnym operatorem - poszczególne warstwy usługi (fizyczna, tranmisja/szkielet, ostatnia mila, wreszcie obsługa użytkownika i usługi dodane) dostarczane są przez wyspecjalizowane podmioty, a całość spinana jest w usługę dzięki API interfejsów łączących tych dostawców.

Niestrudzony Łukasz Bromirski zaznajomił uczestników z koncepcjami LISP i SIDR. LISP ma zaadresować problem puchnących tablic BGP, SIDR zaś problem "porywania" prefiksów wprowadzając system podpisów cyfrowych dla par (prefiks, origin AS). Na wpis o LISP zanosiłem się od jakiegoś czasu więc pewnie jeszcze takowy popełnię.

HP zaanonsowało inny ciekawy koncept: OpenFlow. Jest to mechanizm, kóry umożliwia wyniesienie decyzji o sposobie przełączania pakietów IP do zewnętrznego systemu (kontrolera). Feature wspierają liczący się dostawcy sprzętu sieciowego, ale tylko w eksperymentalnych wersjach firmware. Biorąc uwagę rok, w którym to wymyślono, chyba wynalazek napotkał pewne opory przy wdrażaniu. ;)


Materiały z tych i innnych wykładów oraz kompromitujące zdjęcia ;) będą pewnie wkrótce dostępne na stronie PLNOG.

Terytoria IT

Kilka dni temu wysłałem IT do psychiatry. Dziś serwuję (za Just Enough Developed Infrastructure) IT wraz z otoczeniem zobrazowane na mapie - The Map is not the Territory: The IT-World Anno 2010. Klienci, użytkownicy, wielka czapa wszelkich form zarządzania, rozwój, testowanie i utrzymanie, bezpiecznicy, service desk oraz infrastruktura.
Ładnie to wygląda, ale co to oznacza w praktyce? W realnym świecie mamy np.:

1. Podział na biednych i bogatych. Jeden dział ma lepsze "przełożenie" i konsumuje pieniądze potrzebne innym działom.
2. Strefy skażenia. Nikt nie chce ich nawet dotykać (syndrom "to nie moje").
3. Wojenki. Jeden lokalny kacyk robi na złość drugiemu za nie swoje pieniądze i trzeba go jakoś obchodzić, żeby dopiąć celu.
4. Każdy sobie rzepkę skrobie. Brak zdolności współpracy w obliczu nadciągającej katastrofy.

Brzmi znajomo?

Motywowanie w IT

Polecam lekturę artykułu Radość i satysfakcja poświęconego motywowaniu pracowników branży IT.

Niestety, zwolennicy systemów motywowania bazujących na premiach finansowych wysnuli z tego błędny wniosek, że skoro brak pieniędzy demotywuje, to same pieniądze motywują. Niestety, są w błędzie. Niestety, gdyż pomysł ten szerzy się jak zaraza i doprowadza coraz częściej do tego, że informatycy zastanawiają się nad tym jak udowodnić, że efektywnie pracują, zamiast po prostu efektywnie pracować.

Wybrane spostrzeżenia:

1. Za pewną granicą pieniądze już nie motywują.
2. Praca powinna dostarczać przyjemności i być wykonywana z pasją.
3. Ważne jest poczucie realnego wpływu na projekt od momentu jego powstania.
4. Projekt powinien budować wrażenie, że robimy coś sensownego.
5. Szkolenia powinny być zgodne z oczekiwaniami pracownika, a nie tylko doraźnymi potrzebami pracodawcy.
6. Dostarczone narzędzia pracy powinny być dobrej jakości i pomagać, a nie przeszkadzać.
7. Miejsce pracy powinno zapewniać wygodę i możliwość skupienia się.

Link do artykułu znalazłem na Blogu rekrutacyjnym, który sam w sobie również wydaje się godny polecenia.

IT u psychiatry

Gdyby IT było człowiekiem, jak zdiagnozowałby go psychiatra? W prezentacji Nothing New Under the Sun: Continually Rediscovering the Good Ways to Build Software pada następujące rozpoznanie przypadłości branży IT:

1. ADHD. Nie skupiamy się na celu, rozpraszają nas technologiczne błyskotki.
2. Amnezja wsteczna. Powtarzamy te same błędy.
3. Zaburzenia obsesyjno-kompulsyjne. Powtarzamy bezmyślnie nic nie wnoszące rytuały.

Serwery lubią prad

James Hamilton, jedna z postaci stojących za Amazon Web Services, popełnił interesującą analizę kosztów utrzymania Data Center: Overall Data Center Costs. Nie chodzi tu o koszt administratorów czy sieci, lecz koszt utrzymania koniecznej infrastruktury: klimatyzacji, stacji transformatorowych itp.

It turns out that power is incredibly important but it’s not the utility kWh charge that makes power important. It’s the cost of the power distribution equipment required to consume power and the cost of the mechanical systems that take the heat away once the power is consumed.

Okazuje się, że jest to dominujący koszt - zaraz po koszcie samych serwerów (przy czym serwery amortyzują się znacznie szybciej). Autor podaje oszacowanie PUE dla ich DC na poziomie 1,45 i <1,2 dla Google, które uchodzi już za state of the art. ;)

Ciekawe, jakim PUE mogą pochwalić się serwerownie dużych instytucji oraz centrów kolokacyjnych w Polsce?

Luka międzyramkowa

Czasem człowiek myśli, że zna jakiś temat dość dobrze. Może nie bardzo dogłębnie, ale generalnie - ciężko go czymś zaskoczyć... do czasu. ;)

Pisałem w sierpniu o zmiennym narzucie stosu protokołów w ATM. Okazuje się, że podobny problem występuje w sieci Ethernet. Między ramki Ethernet wprowadzana jest luka (interframe gap) o stałym rozmiarze 96 bitów. Taka międzyramkowa luka wprowadza więc większy narzut (overhead) w przypadku, gdy w transmisji dominują małe ramki, a mniejszy, gdy w transmisji dominują większe ramki.

Pocieszam się, że inżynierów sieciowych CCIE też potrafi to zaskoczyć. ;)

Obgryzanie Wymagań

Pracuje sobie człowiek (nie)spokojnie, a tu nagle trach! - wpada nowy projekt. Trzeba coś zrobić.

W odróżnieniu od życia, kiedy pewne fundamentalne pytania człowiek zadaje sobie raczej u kresu ;) w projekcie zdecydowanie warto postawić te pytania od razu: "Dlaczego?", "Jak?", "Kiedy?", "Co?", "Gdzie?", "Kto?". Inaczej coś może przeobrazić się w skrzyżowanie meduzy z kameleonem - projekt o bardzo bardzo płynnym zakresie. ;)

Stawianie tych pytań to element zarządzania wymaganiami, a same pytania pożyczyłem z bloga "O wymaganiach". Stwierdziłem, że pomarudzę o tym, bo prześladuje mnie Potwór Zmiany Zakresu, a szczególnie jego odmiana bezkapuchowiec objawiająca się obgryzaniem zakresu do kości. Brr!

Potwora wywołuje zwykle sponsor, kiedy jego wybujałe oczekiwania zderzą się ze ścianą realnych kosztów projektu. Wywoływanie zachodzi np. na rytualnym, tajnym spotkaniu ważnych osób na szczycie, podczas którego rysuje się markerem tajemne znaki na białej tablicy. Zwykle łatwiej jest obciąć zakres projektu niż załatwić dodatkowe finansowanie. Rozpoczyna się polowanie, atmosfera absurdu tężeje jak w Misiu: "A gdyby tu było nagle przedszkole"?

Oczywiście, zakres nie jest cięty z chirurgiczną prezycją, powstają rany projektowe gryzione (choć niekoniecznie widać je w PowerPoincie). W efekcie powstaje wtórna fala nowych wymagań, kompensujących braki powstałe po cięciu zakresu. Tak, właśnie w środku projektu (albo nawet na końcu) nastąpiła zmiana wymagań. Wypełzają wszelkiej maści ohydne obejścia, których normalnie nikt nie odważyłby się nawet zaproponować.

Budżetowo wygląda to tak: klient chciał jaguara, ale nie było go stać więc zapłacił za mercedesa, tyle że funkcjonalnie dostał malucha. Ale mamy sukces, budżet został dotrzymany. ;)

Wracając do wymagań - po co nimi zarządzać? Cóż, warto wiedzieć, co właściwie robimy, jak i na kiedy ;) ale też trzeba mieć listę, którą można będzie rzucić Potworowi Zmian Zakresu na pożarcie. On na pewno kiedyś się pojawi i nie będzie z Tobą dykutował.

Czym powina być inżynieria oprogramowania?

Polecam wykład Glenna Vanderburga nt. tego, czym stała się i czym powinna być inżynieria oprogramowania: Real Software Engineering. Nie jest nudny. :)