Święta za pasem, a tu nagle wyfrunęły jaskółki wieszczące Internet Nowej Generacji: NGA i LTE. TP i Netia poinformowały o pilotażowych wdrożeniach VDSL2. Kolejny fiber power upchnięty w miedzianym drucie? ;)
Chwilę wcześniej UPC połyka Astera, zrównując się pod względem liczby abonentów usług internetowych z Netią. Operatorzy mobilni także nie zasypiają gruszek w popiele i wstrząsają powietrze falami LTE. Mi to pasuje, zarobiłem na akcjach Cyfrowego. ;) Ba, okazało się nawet, że 4G jest u nas od dawna. Powiększył się także elitarny klub dostawców triple play, przynajmniej na papierze. ;)
Spokojnych Świąt bez komputerów. :)
piątek, 24 grudnia 2010
piątek, 17 grudnia 2010
Diagram jak malowany
Jeden obraz potrafi czasem wyjaśnić więcej, niż tysiąc słów, dlatego skomplikowane opisy warto ilustrować diagramami, schematami lub wykresami.
Istnieje wiele narzędzi wspomagających rysowanie diagramów i schematów, jak również wiele typów diagramów: sformalizowane jak UML, BPMN, nieco swobodniejsze (np. schemat sieci komputerowej, schemat organizacyjny) oraz zupełnie dowolne. Pokaźną listę typów diagramów można znaleźć w Wikipedii — o wielu nigdy nie słyszałem. ;-)
Najprostsze narzędzia do rysowania to oczywiście MS Paint i MS Word. Inżynierowie sieciowi oraz biznes lubią np. MS Visio. Projektanci systemów IT sięgają po narzędzia CASE, np. Enterprise Architect — gdzie modeluje się rozwiązanie, a diagram to tylko wizualizacja projektowanego modelu.
Czasem chcielibyśmy jednak szybko i prosto sporządzić diagram do wykorzystania w prezentacji lub na stronie WWW. Przedstawiam kilka narzędzi, które mogą się okazać pomocne.
yUML
"Cool diagrams", do osadzania w wiki (istnieją wtyczki do popularnych implementacji), forach itp. Rysowany diagram kodujemy w postaci URL-a i osadzamy bezpośrednio na stronie lub zapisujemy wygenerowany obrazek. Bardzo proste i przyjemne.
websequencediagrams
Diagram sekwencji można stworzyć na stronie korzystając z palety elementów lub poprzez API. Dostępne są różne wizualne style diagramów.
UML Graph
MetaUML
yED i Graphity
Violet UML Editor
UMLet
Aplikacja Java. Eksport: grafika bitmapowa i wektorowa. Całkiem rozbudowana.
Graphviz
Deklaratywne programowanie grafów w języku DOT. Dojrzałe narzędzie, dostępne różne nakładki, wykorzystywane także w roli silnika w różnych aplikacjach.
Dia
Kolejny klasyk. Prosta alternatywa dla Visio, wielką zaletą jest szereg gotowych bibliotek z ikonami do rysowania np. schematów sieci Cisco, schematów obwodów elektrycznych itp.
Istnieje wiele narzędzi wspomagających rysowanie diagramów i schematów, jak również wiele typów diagramów: sformalizowane jak UML, BPMN, nieco swobodniejsze (np. schemat sieci komputerowej, schemat organizacyjny) oraz zupełnie dowolne. Pokaźną listę typów diagramów można znaleźć w Wikipedii — o wielu nigdy nie słyszałem. ;-)
Najprostsze narzędzia do rysowania to oczywiście MS Paint i MS Word. Inżynierowie sieciowi oraz biznes lubią np. MS Visio. Projektanci systemów IT sięgają po narzędzia CASE, np. Enterprise Architect — gdzie modeluje się rozwiązanie, a diagram to tylko wizualizacja projektowanego modelu.
Czasem chcielibyśmy jednak szybko i prosto sporządzić diagram do wykorzystania w prezentacji lub na stronie WWW. Przedstawiam kilka narzędzi, które mogą się okazać pomocne.
yUML
- strona: http://www.yuml.me/
- przykłady:
- http://www.yuml.me/diagram/scruffy/class/draw
- http://www.yuml.me/diagram/scruffy/activity/draw
- http://www.yuml.me/diagram/scruffy/usecase/draw
- diagramy: klas, aktywności, przypadków użycia
- integracja: osadzanie IMG SRC
"Cool diagrams", do osadzania w wiki (istnieją wtyczki do popularnych implementacji), forach itp. Rysowany diagram kodujemy w postaci URL-a i osadzamy bezpośrednio na stronie lub zapisujemy wygenerowany obrazek. Bardzo proste i przyjemne.
websequencediagrams
- strona: http://www.websequencediagrams.com/
- przykłady: http://www.websequencediagrams.com/examples.html
- diagramy: sekwencji
- integracja: osadzanie Javascript, HTTP POST (np. z aplikacji Java, Python, Ruby) - http://www.websequencediagrams.com/embedding.html
Diagram sekwencji można stworzyć na stronie korzystając z palety elementów lub poprzez API. Dostępne są różne wizualne style diagramów.
UML Graph
- strona: http://www.umlgraph.org/
- przykłady:
- diagramy: klas, sekwencji
- integracja: http://www.umlgraph.org/doc/deriv.html
MetaUML
- strona: http://metauml.sourceforge.net/old/index.html
- przykłady:
- http://metauml.sourceforge.net/old/statemachine-diagram.html
- http://metauml.sourceforge.net/old/activity-diagram.html
- diagramy: klas, aktywności, przypadków użycia, stanów, pakietów
- integracja: LaTeX
yED i Graphity
- strony:
- http://www.yworks.com/en/products_yed_about.html
- http://www.yworks.com/en/products_graphity_about.html
- http://en.wikipedia.org/wiki/YEd
- przykłady: http://www.yworks.com/en/products_yed_gallery.html
- diagramy: podstawowe kształty i krawędzie, elementy diagramów procesowych — BPMN, flowchart, przypadki użycia, diagramy z wykorzystaniem ikon użytkownika
Violet UML Editor
- strona: http://alexdp.free.fr/violetumleditor/page.php
- przykłady: http://alexdp.free.fr/violetumleditor/page.php?id=en:tour
- diagramy: przypadków użycia, klas, obiektów, stanów, aktywności, sekwencji
- integracja: Eclipse
UMLet
- strona: http://www.umlet.com/
- przykłady: http://www.umlet.com/screenshots.htm
- diagramy: klas, przypadków użycia, stanów, aktywności, pakietów i inne, ponadto własne programowalne elementy graficzne
- integracja: Eclipse
Aplikacja Java. Eksport: grafika bitmapowa i wektorowa. Całkiem rozbudowana.
Graphviz
- strona:
- przykłady: http://graphviz.org/Gallery.php
- diagramy: grafy
Deklaratywne programowanie grafów w języku DOT. Dojrzałe narzędzie, dostępne różne nakładki, wykorzystywane także w roli silnika w różnych aplikacjach.
Dia
- strona:
- przykłady: http://live.gnome.org/Dia/Examples
- diagramy: elementy UML, BPMN, flowchart, inne
Kolejny klasyk. Prosta alternatywa dla Visio, wielką zaletą jest szereg gotowych bibliotek z ikonami do rysowania np. schematów sieci Cisco, schematów obwodów elektrycznych itp.
środa, 1 grudnia 2010
Zapytanie ofertowe o żółty, zakrzywiony, jadalny produkt
Wessał mnie korpowir i nie miałem ostatnio czasu na aktualizowanie blogaska. Mam w zanadrzu kilka wpisów, ale wymagają dopracowania.
Tymczasem zaserwuję cudzy zestaw złotych myśli nt. RFP, zwanego także Zapytaniem Ofertowym wraz z SIWZ-em. ;)
Tymczasem zaserwuję cudzy zestaw złotych myśli nt. RFP, zwanego także Zapytaniem Ofertowym wraz z SIWZ-em. ;)
- A few notes on procurement — na przykładzie banana
- What Does Your Storage RFP Say About You? — nieco bardziej poważnie
They later informed us that despite the fact that this "required" operating system didn't actually exist, none of the other vendors had asked about it, and none had taken any exception to fully supporting it in their RFP responses.Next up, how about a full year? No says the farmer, no way. Ah, but the legal eagle of the bidding team has discovered that the matrix does not provide for who the 'product' should be edible! Would a rat eat a one year old banana? Definitely! COMPLIANT!
poniedziałek, 1 listopada 2010
Czy OpenFlow zdemontuje Układ?
W notatce z PLNOG5 wspomniałem o OpenFlow. Pomysł wydał mi się ciekawy, ale producenci jakoś niespiesznie go implementują. Ostatni wpis Jamesa Hamiltona Datacenter Networks are in my Way rzuca nieco światła na potrzeby dużych Data Center w tej materii. Sprzęt sieciowy to wielkie, prądożerne kloce, a ich konstrukcja utrudnia budowę tanich, rozproszonych i skalowalnych sieci. James porównuje je nawet do mainframe'ów oraz SUV-ów. Podobnież czyni CEO Vyatty. ;)
To, czego potrzebujemy, to demontaż układu. We wpisie o Route Bricks (rozpraszanie routerów na platformy PC) wspomniałem, że open source skutecznie zaatakował niektóre obszary, ale rozwiązania sieciowe i poważne bazy danych wciąż opierają się na komercyjnych produktach. Nawet telefonia została skutecznie zaatakowana VoIP-em. Potrzebny jest zestandaryzowany sprzęt o otwartej specyfikacji i darmowe biblioteki do zarządzania: Software Defined Network (SDN).
Zobacz także:
A fully configured Cisco Nexus 7000 requires 8 circuits of 5kw each. Admittedly some of that power is for redundancy but how can 120 ports possibly require as much power provisioned as 4 average sized full racks of servers? Net gear is the SUV of the datacenter. The network equipment business model is broken. We love the server business model where we have competition at the CPU level, more competition at the server level, and an open source solution for control software. In the networking world, it’s a vertically integrated stack and this slows innovation and artificially holds margins high. It’s a mainframe business model.Produkcję "poważnego" sprzętu sieciowego zdominował swoisty układ. ;-) Marże są wysokie. Rozwiązania profesjonalne, a więc i drogie. Ścieżki szkoleniowe do najwyższych stopni wtajemniczenia kręte, a niektórzy ich posiadacze wydają się lewitować - są tak boscy. Sam wygląd dużego routera budzi respekt i szacunek. Prawie jak centrala telefoniczna czy superkomputer Cray. ;)
To, czego potrzebujemy, to demontaż układu. We wpisie o Route Bricks (rozpraszanie routerów na platformy PC) wspomniałem, że open source skutecznie zaatakował niektóre obszary, ale rozwiązania sieciowe i poważne bazy danych wciąż opierają się na komercyjnych produktach. Nawet telefonia została skutecznie zaatakowana VoIP-em. Potrzebny jest zestandaryzowany sprzęt o otwartej specyfikacji i darmowe biblioteki do zarządzania: Software Defined Network (SDN).
Zobacz także:
Wydano OpenBSD 4.8
Wydano OpenBSD 4.8. W stosunku do poprzedniej wersji conieco się zmieniło. Wybrane dość dowolnie ;) zmiany:
- IPsec - wsparcie dla IKEv2: iked
- lekki serwer LDAP: ldapd
- OpenSSH 5.6
- prosty mechanizm keepalive dla GRE
- wsparcie dla zagnieżdżonych VLAN-ów QinQ: svlan(4)
- dużo różnych usprawnień ukierunkowanych na MPLS
środa, 27 października 2010
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:
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
poniedziałek, 25 października 2010
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.
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.
niedziela, 17 października 2010
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.:
Ładnie to wygląda, ale co to oznacza w praktyce? W realnym świecie mamy np.:
- Podział na biednych i bogatych. Jeden dział ma lepsze "przełożenie" i konsumuje pieniądze potrzebne innym działom.
- Strefy skażenia. Nikt nie chce ich nawet dotykać (syndrom "to nie moje").
- Wojenki. Jeden lokalny kacyk robi na złość drugiemu za nie swoje pieniądze i trzeba go jakoś obchodzić, żeby dopiąć celu.
- Każdy sobie rzepkę skrobie. Brak zdolności współpracy w obliczu nadciągającej katastrofy.
sobota, 16 października 2010
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:
- Za pewną granicą pieniądze już nie motywują.
- Praca powinna dostarczać przyjemności i być wykonywana z pasją.
- Ważne jest poczucie realnego wpływu na projekt od momentu jego powstania.
- Projekt powinien budować wrażenie, że robimy coś sensownego.
- Szkolenia powinny być zgodne z oczekiwaniami pracownika, a nie tylko doraźnymi potrzebami pracodawcy.
- Dostarczone narzędzia pracy powinny być dobrej jakości i pomagać, a nie przeszkadzać.
- Miejsce pracy powinno zapewniać wygodę i możliwość skupienia się.
wtorek, 12 października 2010
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:
- ADHD. Nie skupiamy się na celu, rozpraszają nas technologiczne błyskotki.
- Amnezja wsteczna. Powtarzamy te same błędy.
- Zaburzenia obsesyjno-kompulsyjne. Powtarzamy bezmyślnie nic nie wnoszące rytuały.
niedziela, 10 października 2010
Serwery lubią prad
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?
piątek, 8 października 2010
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ć. ;)
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ł.
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ł.
sobota, 2 października 2010
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. :)
wtorek, 28 września 2010
RIPE Labs: rozproszony, aktywny monitoring
W każdej chwili w Internecie gdzieś jest jakaś awaria.
Część tych awarii ma punktowych charakter i nie oddziaływuje na ruch na całym świecie. Czasem jednak, np. w wyniku zabaw z Bardzo Groźnym Protokołem, może pojawić się spore zamieszanie.
Jak już jesteśmy przy RIPE, warto w tym miejscu wspomnieć o jednym z ostatnich projektów RIPE Labs: Active Measurements. Pomysłodawcy wyszli z założenia, że nic tak dobrze nie będzie monitorować osiągalności kluczowych elementów sieci jak... rozproszona baza użytkowników końcowych.
Jest to zresztą naturalne rozwinięcie koncepcji innego projektu: DNSMON. O ile DNSMON używa sieci dedykowanych serwerów testowych (Test Traffic Measurements boxes), to aktywny monitoring zmierza w kierunku wykorzystania zminiaturyzowanych sond, które można tanio i łatwo instalować nawet u końcowego użytkownika. Poza rozmiarem, siłą tych sond jest ich docelowa liczebność - dziesiątki tysięcy lub więcej. Dzięki temu chwilowe problemy w pracy niektórych z sond będą tylko anomalią statystyczną.
Przy tak dużej liczbie, w każdej chwili gdzieś w Internecie będzie pracować jakaś sonda. ;)
Więcej informacji o projekcie:
Część tych awarii ma punktowych charakter i nie oddziaływuje na ruch na całym świecie. Czasem jednak, np. w wyniku zabaw z Bardzo Groźnym Protokołem, może pojawić się spore zamieszanie.
Jak już jesteśmy przy RIPE, warto w tym miejscu wspomnieć o jednym z ostatnich projektów RIPE Labs: Active Measurements. Pomysłodawcy wyszli z założenia, że nic tak dobrze nie będzie monitorować osiągalności kluczowych elementów sieci jak... rozproszona baza użytkowników końcowych.
Jest to zresztą naturalne rozwinięcie koncepcji innego projektu: DNSMON. O ile DNSMON używa sieci dedykowanych serwerów testowych (Test Traffic Measurements boxes), to aktywny monitoring zmierza w kierunku wykorzystania zminiaturyzowanych sond, które można tanio i łatwo instalować nawet u końcowego użytkownika. Poza rozmiarem, siłą tych sond jest ich docelowa liczebność - dziesiątki tysięcy lub więcej. Dzięki temu chwilowe problemy w pracy niektórych z sond będą tylko anomalią statystyczną.
Przy tak dużej liczbie, w każdej chwili gdzieś w Internecie będzie pracować jakaś sonda. ;)
Więcej informacji o projekcie:
poniedziałek, 27 września 2010
Wzorce skalowania
Trafiłem niedawno na interesującego posta Scalability patterns and an interesting story... Autor wyróżnił pewne uniwersalne wzorce spotykane przy skalowaniu (rozumianym jako scale out, nie up) oprogramowania. Lubię porządek więc przytoczę. ;)
- dystrybucja obciążenia
- równoważenie obciążenia
- partycjonowanie
- poziome
- pionowe
- zrównoleglanie
- luźne wiązanie
- kolejkowanie i paczkowanie
sobota, 25 września 2010
Postępy DTrace we FreeBSD
Jak informuje blog Fundacji FreeBSD, zakończono projekt implementacji DTrace we FreeBSD. Ostatnim krokiem było wsparcie dla instrumentacji aplikacji.
Ciekawe, czy w przyszłości wyrocznia będzie równie łaskawa dla tego typu dzielenia się dobrymi rzeczami, co słoneczko.
Since DTrace on FreeBSD now has the ability to instrument both the kernel and the userland program, you can get very meaningful data on how your program is behaving and why.DTrace to drugi po ZFS killer-feature Solarisa zaimplementowany pod FreeBSD.
Ciekawe, czy w przyszłości wyrocznia będzie równie łaskawa dla tego typu dzielenia się dobrymi rzeczami, co słoneczko.
czwartek, 23 września 2010
RouteBricks
Rok po roku opensource podgryza kolejne przyczółki branży IT, okupowane dotąd przez rozwiązania komercyjne.
Są takie miejsca, w których ekspansja jest łatwa - dziś już chyba nikt nie wyobraża sobie płacenia za program do przeglądania zdjęć? Choć wiem, że niektórzy płacą np. za edytory tekstu ze wsparciem dla programowania ;) W innych przypadkach idzie nieco trudniej - choćby "ekspansja" Linuksa na desktopach... Są i takie, w których wejście na lukratywny rynek jest bardzo trudne - we wpisie z Open Source Day 2010 przytoczyłem przykład profesjonalnych baz danych.
Innym tego typu obszarem są urządzenia sieciowe. Widać postęp - od lat wiele urządzeń w segmencie SOHO (np. routery bezprzewodowe) to po prostu małe komputerki oparte np. o MIPS-a, z Linuksem w środku. Otwartość oprogramowania to tylko jeden z czynników, krytyczny jest jednak wzrost możliwości obliczeniowych architektury PC. Co by nie mówić o tym wzroście, przy wysokowydajnym przełączaniu pakietów IP, PC nie jest w stanie konkurować ze specjalizowanymi układami. Ale i tak kawałek tortu jest podgryzany, obsługa dziesiątek czy setek megabitów ruchu IP na pececie nie jest wielkim problemem. We wpisie z meetBSD 2010 pisałem o ekstremalnym rozwiązaniu pewnego bułgarskiego ISP, opartym o FreeBSD. ;) Elastyczność platformy PC w roli routera nie zawsze jest atutem, toteż powstają takie produkty jak Vyatta. Jest jednak poziom, z którym trudno się równać.
Trafiłem jednak w sieci na dający nadzieję artykuł: Software Router Smashes Speed Records. Ostateczne, jeśli procesor PC wciąż jest za słaby, można poszukać mocy w karcie graficznej. Można też zainstalować karty z układami FPGA. Oczywiście, wciąż ogranica nas magistrala. Istnieje równiez inicjatywa RouteBricks korzystająca z Clicka, gdzie wydajność routowania skaluje się... zrównoleglaniem, czyli zwiększając liczbę pecetów. Niestety, prototyp rozwiązania wciąż nie jest komercyjnie dostępny.
Są takie miejsca, w których ekspansja jest łatwa - dziś już chyba nikt nie wyobraża sobie płacenia za program do przeglądania zdjęć? Choć wiem, że niektórzy płacą np. za edytory tekstu ze wsparciem dla programowania ;) W innych przypadkach idzie nieco trudniej - choćby "ekspansja" Linuksa na desktopach... Są i takie, w których wejście na lukratywny rynek jest bardzo trudne - we wpisie z Open Source Day 2010 przytoczyłem przykład profesjonalnych baz danych.
Innym tego typu obszarem są urządzenia sieciowe. Widać postęp - od lat wiele urządzeń w segmencie SOHO (np. routery bezprzewodowe) to po prostu małe komputerki oparte np. o MIPS-a, z Linuksem w środku. Otwartość oprogramowania to tylko jeden z czynników, krytyczny jest jednak wzrost możliwości obliczeniowych architektury PC. Co by nie mówić o tym wzroście, przy wysokowydajnym przełączaniu pakietów IP, PC nie jest w stanie konkurować ze specjalizowanymi układami. Ale i tak kawałek tortu jest podgryzany, obsługa dziesiątek czy setek megabitów ruchu IP na pececie nie jest wielkim problemem. We wpisie z meetBSD 2010 pisałem o ekstremalnym rozwiązaniu pewnego bułgarskiego ISP, opartym o FreeBSD. ;) Elastyczność platformy PC w roli routera nie zawsze jest atutem, toteż powstają takie produkty jak Vyatta. Jest jednak poziom, z którym trudno się równać.
Trafiłem jednak w sieci na dający nadzieję artykuł: Software Router Smashes Speed Records. Ostateczne, jeśli procesor PC wciąż jest za słaby, można poszukać mocy w karcie graficznej. Można też zainstalować karty z układami FPGA. Oczywiście, wciąż ogranica nas magistrala. Istnieje równiez inicjatywa RouteBricks korzystająca z Clicka, gdzie wydajność routowania skaluje się... zrównoleglaniem, czyli zwiększając liczbę pecetów. Niestety, prototyp rozwiązania wciąż nie jest komercyjnie dostępny.
niedziela, 19 września 2010
e-Bawidełko
Mianem e-bawidełka określił "komputery dla dziecka do nauki" jeden z komentujących posta Darmowe komputery przeszkadzają w nauce. Według mnie bardzo trafnie. Komputer jako narzędzie niesie pewne szanse, ale i ryzyka.
Niewątpliwą szansą jest możliwość dostępu do potężnej bazy wiedzy i (z czasem) nabrania biegłości w odrzucaniu rzeczy nieistotnych.
Ryzykiem jest upośledzenie rozwoju psychoruchowego, utrata koncentracji i tracenie czasu na bzdety. Jest wiele fascynujących serwisów Web 2.0, społecznościowych i znajomych w komunikatorze. Można tym wszystkim spokojnie wypełnić dobę, nawet kosztem snu.
Kluczowa jest więc umiejętność odmówienia sobie rozrywki. Które dziecko potrafi coś takiego? ;)
Zabrzmi to niewiarygodnie, ale największy rozwój moich kompetencji IT przypadł na czas, w którym nie miałem komputera. Czytałem wtedy książki lub czasopisma. ;) Dostęp do komputera i Internetu miałem w szkole i tam - w ograniczonych ramach czasowych - zajmowałem się dokłanie tym, co mnie interesowało.
Jeśli ktoś chce wydawać cudze pieniądze na sponsorowanie komputerów dla dzieci, to pewnie ma jakieś dowody na dobroczynny wpływ komputerów na intelekt dziecka? ;) Cytacik z Computers at Home: Educational Hope vs. Teenage Reality:
Niewątpliwą szansą jest możliwość dostępu do potężnej bazy wiedzy i (z czasem) nabrania biegłości w odrzucaniu rzeczy nieistotnych.
Ryzykiem jest upośledzenie rozwoju psychoruchowego, utrata koncentracji i tracenie czasu na bzdety. Jest wiele fascynujących serwisów Web 2.0, społecznościowych i znajomych w komunikatorze. Można tym wszystkim spokojnie wypełnić dobę, nawet kosztem snu.
Kluczowa jest więc umiejętność odmówienia sobie rozrywki. Które dziecko potrafi coś takiego? ;)
Zabrzmi to niewiarygodnie, ale największy rozwój moich kompetencji IT przypadł na czas, w którym nie miałem komputera. Czytałem wtedy książki lub czasopisma. ;) Dostęp do komputera i Internetu miałem w szkole i tam - w ograniczonych ramach czasowych - zajmowałem się dokłanie tym, co mnie interesowało.
Jeśli ktoś chce wydawać cudze pieniądze na sponsorowanie komputerów dla dzieci, to pewnie ma jakieś dowody na dobroczynny wpływ komputerów na intelekt dziecka? ;) Cytacik z Computers at Home: Educational Hope vs. Teenage Reality:
Students posted significantly lower math test scores after the first broadband service provider showed up in their neighborhood, and significantly lower reading scores as well when the number of broadband providers passed four.
piątek, 17 września 2010
Slajdologia
Podejmujesz dużo ważnych decyzji i nie masz czasu wnikać w ich materię? Nic trudnego, wystarczy poprosić interesariuszy o prezentacje w postaci slajdów.
Slajdy są jak papier - zniosą wszystko. Ba, są nawet lepsze, jeśli plik źródłowy nie zostanie rozpowszechniony - nie zostawiają śladów. Dobre slajdy mogą uzasadnić niejeden pokrętny Business Case. Slajdy są proste więc nawet dziecku łatwo je zrozumieć. Na slajdach można się też uprawiać korpoślizg - prezentujący sprzedaje się szerokiemu i ważnemu gremium jako kumaty gość, podczas gdy wsad do slajdów powstaje w mało widowiskowej, żmudnej pracy wielu szarych ludzi.
Oczywiście, nie chodzi o slajdy same w sobie (one są bardzo przydatnym narzędziem), lecz o to, jak wpływają na kulturę podejmowania decyzji.
Natknąłem się ostatnio w sieci na kilka niepochlebnych opinii nt. stosowania PowerPointa. Co prawda pochodzą one ze środowisk wojskowych, ale procesy decyzyjne zachodzą również w organizacjach cywilnych - zatem pozwolę sobie zacytować i polecić lekturę. ;)
We Have Met the Enemy and He Is PowerPoint
Dumb-dumb bullets
Slajdy są jak papier - zniosą wszystko. Ba, są nawet lepsze, jeśli plik źródłowy nie zostanie rozpowszechniony - nie zostawiają śladów. Dobre slajdy mogą uzasadnić niejeden pokrętny Business Case. Slajdy są proste więc nawet dziecku łatwo je zrozumieć. Na slajdach można się też uprawiać korpoślizg - prezentujący sprzedaje się szerokiemu i ważnemu gremium jako kumaty gość, podczas gdy wsad do slajdów powstaje w mało widowiskowej, żmudnej pracy wielu szarych ludzi.
Oczywiście, nie chodzi o slajdy same w sobie (one są bardzo przydatnym narzędziem), lecz o to, jak wpływają na kulturę podejmowania decyzji.
Natknąłem się ostatnio w sieci na kilka niepochlebnych opinii nt. stosowania PowerPointa. Co prawda pochodzą one ze środowisk wojskowych, ale procesy decyzyjne zachodzą również w organizacjach cywilnych - zatem pozwolę sobie zacytować i polecić lekturę. ;)
We Have Met the Enemy and He Is PowerPoint
- PowerPoint makes us stupid
- It's dangerous because it can create the illusion of understanding and the illusion of control
Dumb-dumb bullets
Unfortunately, as soon as they graduate, our people return to a world driven by a tool that is the antithesis of thinking: PowerPoint. Make no mistake, PowerPoint is not a neutral tool - it is actively hostile to thoughtful decision-making. It has fundamentally changed our culture by altering the expectations of who makes decisions, what decisions they make and how they make them.
środa, 15 września 2010
NetBSD Packet FIlter - YAPF?
Jak informuje osnews.com, w NetBSD pojawi się NetBSD Packet Filter.
Czyżby Yet Another Packet Filter? Tak, na dodatek design NPF-a zapowiada się interesująco. Jednym z elementów ma być zdolny do pracy wieloprocesorowej, zainspirowany BPF-em, rozszerzalny silnik dopasowujący pakiety o nazwie N-Code.
No cóż, niech piszą... z OpenBSD-owego pf-a też się kiedyś śmiali, że bezsensowna robota skoro jest ipf. A jednak pf jest naprawdę świetny. Może npf będzie jeszcze lepszy? ;)
Czyżby Yet Another Packet Filter? Tak, na dodatek design NPF-a zapowiada się interesująco. Jednym z elementów ma być zdolny do pracy wieloprocesorowej, zainspirowany BPF-em, rozszerzalny silnik dopasowujący pakiety o nazwie N-Code.
No cóż, niech piszą... z OpenBSD-owego pf-a też się kiedyś śmiali, że bezsensowna robota skoro jest ipf. A jednak pf jest naprawdę świetny. Może npf będzie jeszcze lepszy? ;)
poniedziałek, 13 września 2010
DNSSEC u bram
Trafiłem niedawno na całkiem przyjemne wprowadzenie do DNSSEC (artykuł w serwisie Heise Online). Warto rzucić okiem.
Już widzę te problemy obsługi klienta z debugowaniem nowej klasy problemów w działaniu Internetu. ;) A tak serio, lepiej mieć te rozszerzenia późno niż wcale - klasyczny DNS, podobnie jak np. SMTP, ma trochę naiwne podejście do spraw bezpieczeństwa w sieci.
Już widzę te problemy obsługi klienta z debugowaniem nowej klasy problemów w działaniu Internetu. ;) A tak serio, lepiej mieć te rozszerzenia późno niż wcale - klasyczny DNS, podobnie jak np. SMTP, ma trochę naiwne podejście do spraw bezpieczeństwa w sieci.
środa, 8 września 2010
DevOps - utopia czy źródło przewagi konkurencyjnej?
Czy deweloperzy powinni mieć dostęp do systemów produkcyjnych?
Odpowiedź na to pytanie wydaje się prosta. Oczywiście, że tak/nie! (zależnie, kto odpowiada). ;-)
W dużych firmach o strukturze silosowej zwykle podział ten jest "naturalny". Z kolei w małych firmach, gdzie wszyscy zajmują się wszystkim, podziału takiego nie ma. Rozdzielenie rozwoju systemów od ich utrzymania ma niewątpliwie pewne zalety, ale wydaje się, że zyskuje ostatnio na popularności trend odwrotny - nazwany DevOps.
Aby dobrać właściwy model, należy przeanalizować potrzeby i ograniczenia konkretnej organizacji. Osobiście skupiłbym się przede wszystkim na następujących czynnikach:
Niektórzy idą dalej i łączą obie funkcje: rozwój i eksploatację (we code and run). Wydaje mi się, że to nie zawsze ma sens, np. w przypadku aplikacji biznesowych, gdzie duży wysiłek dewelopmentu to prace analityczne. Ale w przypadku aplikacji webowych, tolerujących krótkotrwałe przestoje i zdolnych testować nowe funkcjonalności na końcowych użytkownikach - jak najbardziej.
Sporo ciekawych uwag na ten temat można przeczytać we wpisie Should Developers have Access to Production? oraz jego komentarzach.
Tematyka zaszczepiania DevOps nie tylko przy utrzymaniu środowisk web, ale w organizacjach typowo biznesowych (w tym przekonywania menedżerów do tego podejścia), jest także tematem niniejszych paneli InfoQ:
Uczestnicy zwracają w nich uwagę m.in. na:
Brzmi jak utopia? ;-)
Odpowiedź na to pytanie wydaje się prosta. Oczywiście, że tak/nie! (zależnie, kto odpowiada). ;-)
W dużych firmach o strukturze silosowej zwykle podział ten jest "naturalny". Z kolei w małych firmach, gdzie wszyscy zajmują się wszystkim, podziału takiego nie ma. Rozdzielenie rozwoju systemów od ich utrzymania ma niewątpliwie pewne zalety, ale wydaje się, że zyskuje ostatnio na popularności trend odwrotny - nazwany DevOps.
Aby dobrać właściwy model, należy przeanalizować potrzeby i ograniczenia konkretnej organizacji. Osobiście skupiłbym się przede wszystkim na następujących czynnikach:
- niezawodność/dostępność - deweloperzy bez doświadczenia utrzymaniowego mogą zwyczajnie zagrozić stabilności środowiska produkcyjnego
- integralność - deweloper majstrując przy wnętrzu aplikacji na produkcji może np. rozspójnić dane
- poufność - deweloper z dostępem do produkcji to dodatkowe potencjalne źródło wycieku danych
- wymogi formalne - przepisy prawa mogą wymuszać na danej organizacji wyraźne odseparowanie rozwoju systemów od środowiska produkcyjnego
- generyczność aplikacji - system może być rozwijany pod to jedno, konkretne wdrożenie i wymaga głębokiej wiedzy o zachowaniu systemu na produkcji
- zmienność - systemy bywają modyfikowane bardzo często lub np. raz na kilka lat
- skuteczność - rozwiązywanie problemów bez dostępu do produkcji może być trudne, długotrwałe, a przez to kosztowne
- procedury i struktura firmy - procedury bywają stosowane bezmyślnie, dodatkowo rozdział rozwoju od utrzymania generuje więcej stanowisk dla menedżerów, którzy mogą mieć słabą komunikację lub wręcz konkurować
Niektórzy idą dalej i łączą obie funkcje: rozwój i eksploatację (we code and run). Wydaje mi się, że to nie zawsze ma sens, np. w przypadku aplikacji biznesowych, gdzie duży wysiłek dewelopmentu to prace analityczne. Ale w przypadku aplikacji webowych, tolerujących krótkotrwałe przestoje i zdolnych testować nowe funkcjonalności na końcowych użytkownikach - jak najbardziej.
Sporo ciekawych uwag na ten temat można przeczytać we wpisie Should Developers have Access to Production? oraz jego komentarzach.
Uczestnicy zwracają w nich uwagę m.in. na:
- model DevOps to nie zwykła zmiana organizacyjna lecz zmiana kultury (rozbijanie silosów) i nie należy jej wprowadzać odgórnie, raczej przez dobry przykład
- można pokazać DevOps jako podejście ułatwiające osiągnięcie celów biznesowych organizacji
- istotne jest wcześniejsze ustalenie dobrych metryk (KPI) - bez tego nie da się menedżerom pokazać, czy zmiana cokolwiek poprawiła (np. skrócony TTM)
- metryki należy monitorować i stopniowo doskonalić organizację
- dla menedżerów wyższego szczebla często nie liczą się już liczby, lecz zaszczepienie wizji
Podsumuję cytatem z posta What Is This Devops Thing, Anyway?
Devop requires a certain state of mind. It's an attitude which says: I'm going to make a difference, I'm going to cooperate and communicate, and I'm going to understand that in the business of delivering great software, we're all in it together. If you're a sysadmin, this means spending time with the developers. (...) If you're a developer, go and make friends with your sysadmins. Don't view them as lower life forms, or as people to lob problems to. Go and join in - pair with them.
Brzmi jak utopia? ;-)
środa, 1 września 2010
Rola szkoły
Nastał wrzesień. Czas wspominek o II Wojnie Światowej, rocznic solidarnościowych, jęk szklany deszczu i szkolnych dzwonków.
Z okazji rozpoczęcia roku szkolnego postanowiłem nawiązać do roli edukacji szkolnej w dzisiejszym społeczeństwie i polecić leciwy już nieco esej Paula Grahama: "Why Nerds are Unpopular".
Autor analizuje w nim przyczyny niskiej popularności społecznej tzw. nerdów. Przyrównuje także szkołę do organizacji typu więziennego, gdzie dorośli celowo skoszarowują swoje dzieci, które są w dzisiejszym społeczeństwie nieużyteczne (wydłużony czas edukacji potrzebnej do podjęcia jakiejkolwiek pracy, zakaz zatrudniania dzieci), może nie licząc tradycyjnej pracy na wsi przy żniwach. Po prostu nie ma co z nimi zrobić, nie ma ich kto pilnować - więc zbierzmy ich w jedno miejsce, postawmy kilku dorosłych do pilnowania i dajmy do wkucia pełno niepotrzebnych rzeczy. Lepsze to, niż żeby łazili w samopas po mieście i psuli nasze mienie. :-)
Moim zdaniem jedną z najważniejszych rzeczy, które mogą w tej sytuacji zrobić rodzice, to zaszczepiać dziecku zdolność samodzielnego myślenia, żeby nie zatonęło w szkolnej masie postępującego zidiocenia i jednomyślności.
Na zachętę cytacik:
Z okazji rozpoczęcia roku szkolnego postanowiłem nawiązać do roli edukacji szkolnej w dzisiejszym społeczeństwie i polecić leciwy już nieco esej Paula Grahama: "Why Nerds are Unpopular".
Autor analizuje w nim przyczyny niskiej popularności społecznej tzw. nerdów. Przyrównuje także szkołę do organizacji typu więziennego, gdzie dorośli celowo skoszarowują swoje dzieci, które są w dzisiejszym społeczeństwie nieużyteczne (wydłużony czas edukacji potrzebnej do podjęcia jakiejkolwiek pracy, zakaz zatrudniania dzieci), może nie licząc tradycyjnej pracy na wsi przy żniwach. Po prostu nie ma co z nimi zrobić, nie ma ich kto pilnować - więc zbierzmy ich w jedno miejsce, postawmy kilku dorosłych do pilnowania i dajmy do wkucia pełno niepotrzebnych rzeczy. Lepsze to, niż żeby łazili w samopas po mieście i psuli nasze mienie. :-)
Moim zdaniem jedną z najważniejszych rzeczy, które mogą w tej sytuacji zrobić rodzice, to zaszczepiać dziecku zdolność samodzielnego myślenia, żeby nie zatonęło w szkolnej masie postępującego zidiocenia i jednomyślności.
Na zachętę cytacik:
Public school teachers are in much the same position as prison wardens. Wardens' main concern is to keep the prisoners on the premises. They also need to keep them fed, and as far as possible prevent them from killing one another. Beyond that, they want to have as little to do with the prisoners as possible, so they leave them to create whatever social organization they want. (...) What bothers me is not that the kids are kept in prisons, but that (a) they aren't told about it, and (b) the prisons are run mostly by the inmates. Kids are sent off to spend six years memorizing meaningless facts in a world ruled by a caste of giants who run after an oblong brown ball, as if this were the most natural thing in the world. (...) Now adults have no immediate use for teenagers. They would be in the way in an office. So they drop them off at school on their way to work, much as they might drop the dog off at a kennel if they were going away for the weekend. (...) Someone has to watch over them, and the most efficient way to do this is to collect them together in one place. Then a few adults can watch all of them. (...) This is the sort of society that gets created in American secondary schools. And it happens because these schools have no real purpose beyond keeping the kids all in one place for a certain number of hours each day. (...) If life seems awful to kids, it's neither because hormones are turning you all into monsters (as your parents believe), nor because life actually is awful (as you believe). It's because the adults, who no longer have any economic use for you, have abandoned you to spend years cooped up together with nothing real to do. Any society of that type is awful to live in. You don't have to look any further to explain why teenage kids are unhappy.
wtorek, 24 sierpnia 2010
Narzut protokołów na łączu ADSL
Technologia ATM wydaje się dziś nieco skostniała, ale tu i ówdzie trzyma się nieźle. :) Dlatego warto czasem wiedzieć co jest na rzeczy, np. gdy klient nie może wysycić swojego wypasionego łącza ADSL-owego ruchem IP.
Narzut wprowadzany przez łącze ADSL jest dwojaki i wynika z:
Jak wielki jest to narzut, ładnie uświadamia fachowiec we wpisie: ADSL Overhead. Pod wpisem wywiązała się także interesująca dyskusja nt. doboru optymalnego MTU dla łączy ADSL z enkapsulacją PPPoE i PPPoA.
Popularność i żywotność tego jakże pokręconego rozwiązania daje się łatwo wyjaśnić: dostarcza łatwość zarządzania tak podłączoną bazą klientów nawet przy bardzo dużych rozmiarach sieci. Istnieją sieci czysto Ethernetowe, które - choć nie musiałyby - wdrażają PPPoE tylko po to, żeby sobie to zarządzanie ułatwić.
Narzut wprowadzany przez łącze ADSL jest dwojaki i wynika z:
- enkapsulacji np. PPPoE
- warstwy adaptacji np. AAL5, która wprowadza szczególnie wielki narzut dla małych pakietów (np. TCP ACK)
Jak wielki jest to narzut, ładnie uświadamia fachowiec we wpisie: ADSL Overhead. Pod wpisem wywiązała się także interesująca dyskusja nt. doboru optymalnego MTU dla łączy ADSL z enkapsulacją PPPoE i PPPoA.
Popularność i żywotność tego jakże pokręconego rozwiązania daje się łatwo wyjaśnić: dostarcza łatwość zarządzania tak podłączoną bazą klientów nawet przy bardzo dużych rozmiarach sieci. Istnieją sieci czysto Ethernetowe, które - choć nie musiałyby - wdrażają PPPoE tylko po to, żeby sobie to zarządzanie ułatwić.
niedziela, 22 sierpnia 2010
Jak hartowało się IPv6
Uwaga nadchodzi IPv6 - krzyczy okładka magazynu NetWorld. Z którego roku? 2010? 2009? Nie, przestałem prenumerować to pismo chyba jeszcze w ubiegłym wieku. ;) To numer 5/97 (29) - znów pochyliłem się nad szafką ze starociami.
Artykuł ze strony 42. informuje:
Minęło kilkanaście lat i co? Jeśli chodzi o wdrażanie IPv6 w Internecie, nadal jesteśmy w ciemnej... leśnej gęstwinie.
Nadchodzi czas IPv6 - informuje inne pismo IDG, PC World. Tym razem z 2008 roku. ;)
Na koniec smakołyki z wspomnianego numeru NetWorld z 1997, aby oddać ducha epoki... i pochichotać.
W Ameryce Północnej, Europie i Japonii rozpoczęto szeroko zakrojone prace nad stworzeniem próbnych sieci IPv6. Udział w nich biorą producenci sprzętu i administratorzy sieci. Większość producentów oczekuje, że protokół IPv6 przyjmie w połowie tego roku postać, która pozwoli na pełne wykorzystanie w przyszłym roku jego zalet w rzeczywistych sieciach.
Minęło kilkanaście lat i co? Jeśli chodzi o wdrażanie IPv6 w Internecie, nadal jesteśmy w ciemnej... leśnej gęstwinie.
Nadchodzi czas IPv6 - informuje inne pismo IDG, PC World. Tym razem z 2008 roku. ;)
Kiedy więc można spodziewać się przejścia na IPv6? Powinno to nastąpić wkrótce, gdyż przewiduje się, że pula adresów IPv4 zostanie wykorzystana do 2012 roku.
To jak to w końcu jest, skończą się te adresy IPv4 czy nie?
Prawdę mówiąc, świat tak dobrze czuje się z IPv4, że chyba jedynym motywatorem do migracji do IPv6 jest faktyczne wyczerpywanie się 32-bitowej przestrzeni adresowej.
Poza tym, adresy IPv6 są paskudne i trudne do zapamiętania. Zapamiętywanie adresów IPv4 jest łatwe i podobne do zapamiętywania numerów telefonów - nasze społeczeństwo jest do tego ewolucyjnie przystosowane. ;-)
O tym, że adresy IPv4 się wyczerpują, słyszymy od wielu lat. Tak wielu, że już się człowiek do tego przyzwyczaił. Wypracowano różne rozwiązania przedłużające życie IPv4. NAT pozwala podłączyć do sieci więcej komputerów niż mamy faktycznie adresów. SNI pozwala hostować wirtualki HTTPS na jednym adresie IP. Regionalni rejestratorzy wywierają presję ekonomiczną na organizacje, którym przypisano fragmenty przestrzeni adresowej, w tym posiadaczy klas PI. Trwa odzyskiwanie bloków adresowych, które przydzielano zbyt lekką ręką. Rozdawane są adresy z bloków zaznaczonych uprzednio jako zarezerwowane (sławetna sprawa alokacji 83.0.0.0/11 dla TP, która była firewallowana z wielu miejsc na świecie przez nadgorliwych administratorów; dziś prowadzi się debogonizację adresów).
Nieuchronnie jednak zbliżamy się do ściany. Spójrzmy do rejestru IANA. Nawet gdyby uwolnić bloki tzw. klasy E, a zrodzi na pewno wiele problemów z różnych urządzeń sieciowych, to wciąż tylko kilka dodatkowych lat.
Czy IPv6 oferuje coś więcej poza większą przestrzenią adresową? No cóż, na pewno wiele nowych problemów i dalszą komplikację sieci, szczególnie w czasie koegzystencji sieci IPv4 i IPv6 w Internecie. Z tematem rozprawia się Ivan Pepelnjak w poście IPv6 myths.
- Modnym tematem były NC
- "Plan rozszerzenia nazw domen internetowych o siedem nowych (.firm, .store, .web, .arts, .rec, .info i .nom) zyskuje coraz szersze poparcie"
- Na reklamach szacownych 3Coma, SMC czy HP widzimy, zarządzalne, stackowalne huby
- NT kontra Unix
- Przenoszenie użytkowników NT do schematu NDS
- Test wypasionego serwera HP LX Pro 6/166 SMP z 4 procesorami Pentium Pro 166MHz. Cena - skromne 30 tys. USD.
- HTML i okolice. Nowe możliwości WWW (I), a na screenshocie strona HotWired, layout przyprawiłby o zawał dzisiejszych specjalistów ;)
- Narzędzia projektowe Javy: "Istnieje już tak wiele produktów określanych mianem narzędzi projektowych Javy, że wybór między nimi staje się niemal tak kłopotliwy, jak wybór marki samochodu". (Biedacy, nie wiedzieli jeszcze o szykującej się mnogości frameworków).
sobota, 14 sierpnia 2010
Kaszmirowy sweterek informatyka
Kiedy na spotkaniu projektowym nie jesteś w stanie rozróżnić po ubiorze szeregowych przedstawicieli IT od eleganckich Kierownika Produktu i Kierownika Projektu, to może być sygnał, że z firmą coś jest nie tak. Kiedy firma ma za dużo pieniędzy, manifestuje się to nie tylko rozdętymi systemami, ale także przesiąkaniem świata menedżerów do świata informatyków.
Idziesz do kuchni i nie słyszysz rozmowy o optymalizacji wydajności albo użytecznych bibliotekach, tylko np. o quick winach, challengowaniu, celach premiowych i wdrażaniu inicjatyw polepszających komunikację. Na spotkaniu projektowym grupa średnio zorientowanych osób debatuje nad niezbyt złożonym technologicznie problemem. Grupa nie dochodzi do konsensusu więc zaprasza się jeszcze więcej osób i dyrektorów.
Paul Graham, znany popularyzator idei start-upów, w felietonie "What Happened to Yahoo" opisuje wynaturzenia, jakie zrodziły dla tej spółki łatwe pieniądze. Zwraca szczególną uwagę na odpływ kompetencji technicznych i zestawia to z przykładami firm takich jak Google czy Facebook, które potrafią kultywować "kulturę hakerską". Ostatecznie Yahoo oddał walkowerem rynek reklam w wynikach wyszukiwania Googlowi.
Idziesz do kuchni i nie słyszysz rozmowy o optymalizacji wydajności albo użytecznych bibliotekach, tylko np. o quick winach, challengowaniu, celach premiowych i wdrażaniu inicjatyw polepszających komunikację. Na spotkaniu projektowym grupa średnio zorientowanych osób debatuje nad niezbyt złożonym technologicznie problemem. Grupa nie dochodzi do konsensusu więc zaprasza się jeszcze więcej osób i dyrektorów.
Paul Graham, znany popularyzator idei start-upów, w felietonie "What Happened to Yahoo" opisuje wynaturzenia, jakie zrodziły dla tej spółki łatwe pieniądze. Zwraca szczególną uwagę na odpływ kompetencji technicznych i zestawia to z przykładami firm takich jak Google czy Facebook, które potrafią kultywować "kulturę hakerską". Ostatecznie Yahoo oddał walkowerem rynek reklam w wynikach wyszukiwania Googlowi.
Pozwolę sobie podprowadzić fragment felietonu na zachętę:
In technology, once you have bad programmers, you're doomed. (...) Most technology companies eventually get taken over by suits and middle managers. At Yahoo it felt as if they'd deliberately accelerated this process. They didn't want to be a bunch of hackers. They wanted to be suits. (...) Why would great programmers want to work for a company that didn't have a hacker-centric culture, as long as there were others that did? I can imagine two reasons: if they were paid a huge amount, or if the domain was interesting and none of the companies in it were hacker-centric. Otherwise you can't attract good programmers to work in a suit-centric culture. And without good programmers you won't get good software, no matter how many people you put on a task, or how many procedures you establish to ensure "quality".
piątek, 13 sierpnia 2010
BSNMP
Pakiet Net-SNMP (dawniej UCD-SNMP) to bardzo popularna implementacja agenta SNMP. Dostarcza oprogramowanie użytkowe (sam agent jak i narzędzia) oraz biblioteki udostępniające API dla innych programów i języków programowania.
Każdy kto pracował chwilę z Net-SNMP wie, że prostota nie jest atutem tego pakietu... podobnie jak i samego protokołu (Simple Network Management Protocol), prostotę mającego chyba tylko w nazwie.
Harti Brandt, jeden z deweloperów FreeBSD, stworzył swego czasu uproszczoną implementację agenta, zwaną BSNMP: "It is intended to serve only the absolute basic MIBs and implement all other MIBs through loadable modules".
Wydaje się, że nie jest on jakoś powszechnie stosowany - ociężałego Net-SNMP ciężko się pozbyć. ;) Warto więc zauważyć, że BSNMP jest rozwijane i Shteryana Shopova otrzymała tegoroczny grant (o GSoC więcej pisałem tutaj) na implementację obsługi SNMPv3 i lepszą integrację ze statystykami sieci bezprzewodowych. Do wielu zastosowań, sprowadzających się do monitorowania wydajności narzędziami opartymi o RRDtool, BSNMP jest wystarczający.
Poza tym, w portach dostępne są dodatki: bsnmp-jails, bsnmp-regex, bsnmp-ucd, bsnmptools.
Każdy kto pracował chwilę z Net-SNMP wie, że prostota nie jest atutem tego pakietu... podobnie jak i samego protokołu (Simple Network Management Protocol), prostotę mającego chyba tylko w nazwie.
Harti Brandt, jeden z deweloperów FreeBSD, stworzył swego czasu uproszczoną implementację agenta, zwaną BSNMP: "It is intended to serve only the absolute basic MIBs and implement all other MIBs through loadable modules".
Wydaje się, że nie jest on jakoś powszechnie stosowany - ociężałego Net-SNMP ciężko się pozbyć. ;) Warto więc zauważyć, że BSNMP jest rozwijane i Shteryana Shopova otrzymała tegoroczny grant (o GSoC więcej pisałem tutaj) na implementację obsługi SNMPv3 i lepszą integrację ze statystykami sieci bezprzewodowych. Do wielu zastosowań, sprowadzających się do monitorowania wydajności narzędziami opartymi o RRDtool, BSNMP jest wystarczający.
Poza tym, w portach dostępne są dodatki: bsnmp-jails, bsnmp-regex, bsnmp-ucd, bsnmptools.
czwartek, 12 sierpnia 2010
Aplikacje jak krzyże
Nowe aplikacje w organizacji są jak krzyże - łatwo się je stawia, a trudno usuwa.
W gruncie rzeczy to zrozumiałe i zasadne. Komplikacja świata rośnie i znajduje odbicie w komplikacji i mnogości systemów w danej organizacji. Ale czy to jedyny powód mnożenia systemów? Wydaje mi się, że nie.
Czasem nowa aplikacja pojawia się, bo ktoś dał się przekonać slajdom na prezentacji Bardzo Drogiego Produktu, że taki produkt jest naprawdę dobry i profesjonalny. Umożliwi naszej firmie podążanie w kierunku, w którym podążają już inni. Rzeczywiście, znajomy prezes innej firmy podczas gry w golfa wspomniał, że właśnie go wdrażają. Nie możemy być gorsi - wdrażamy i my. (Charakterystyczne dla firm, które mają za dużo pieniędzy).
Kiedy indziej okazuje się, że pewien obszar działalności organizacji powinien zostać wsparty systemami IT, ale niestety kilka dotychczas wdrożonych systemów jakimś cudem nie nadaje się do tego celu. Kupujemy więc kolejny i spokój. Albo lepiej, dewelopujemy jakieś własne rozwiązanie, które ukrywa braki produktów komercyjnych.
Z czasem może się okazać, że takie własne rozwiązanie nieco się rozrosło i bez niego firma nie może funkcjonować. Co by nie mówić, rozwój własnych aplikacji daje niemal nieograniczoną elastyczność w reagowaniu na zmiany potrzeb biznesowych. Nie ma jednak wsparcia producenta - na kogo dyrekcja zwali ewentualne problemy? (Jakie problemy? - zastawia się deweloper aplikacji znający ją na wskroś i usuwający błędy "od ręki"). Doskonały powód, by wymienić je na jakieś nowe, komercyjne rozwiązanie ze wsparciem. Drogim wsparciem. W praktyce może się okazać, że co prawda wdrożono nowe, ale z jakiegoś powodu wciąż nie można wyłączyć tego starego...
Mamy więc systemy, które nie były przeznaczone do likwidacji, takie, które chciano zlikwidować, ale się nie udało, i oczywiście te nowe, które były mniej lub bardziej potrzebne.
Tych nowych nie będziemy przecież likwidować - tyle pieniędzy na to wydaliśmy... już lepiej wydać drugie tyle, by je "udrożnić" i zacząć stosować.
Tych starych nie będziemy przecież likwidować - są filarem naszej firmy, za duża rewolucja. Czasem nawet upgrade jest zbyt ryzykowny - a że utracimy wsparcie? Cóż, korzystamy z tego X lat i ile tych zgłoszeń do supportu poszło? Trzy? I rozwiązywali je ile? Dwa... tygodnie? To o całe 13 dni dłużej niż robili to nasi administratorzy.
Można spróbować zlikwidować te już raz przeznaczone do likwidacji, a co się dotąd nie udało. Pozostaje życzyć powodzenia. :-)
W gruncie rzeczy to zrozumiałe i zasadne. Komplikacja świata rośnie i znajduje odbicie w komplikacji i mnogości systemów w danej organizacji. Ale czy to jedyny powód mnożenia systemów? Wydaje mi się, że nie.
Czasem nowa aplikacja pojawia się, bo ktoś dał się przekonać slajdom na prezentacji Bardzo Drogiego Produktu, że taki produkt jest naprawdę dobry i profesjonalny. Umożliwi naszej firmie podążanie w kierunku, w którym podążają już inni. Rzeczywiście, znajomy prezes innej firmy podczas gry w golfa wspomniał, że właśnie go wdrażają. Nie możemy być gorsi - wdrażamy i my. (Charakterystyczne dla firm, które mają za dużo pieniędzy).
Kiedy indziej okazuje się, że pewien obszar działalności organizacji powinien zostać wsparty systemami IT, ale niestety kilka dotychczas wdrożonych systemów jakimś cudem nie nadaje się do tego celu. Kupujemy więc kolejny i spokój. Albo lepiej, dewelopujemy jakieś własne rozwiązanie, które ukrywa braki produktów komercyjnych.
Z czasem może się okazać, że takie własne rozwiązanie nieco się rozrosło i bez niego firma nie może funkcjonować. Co by nie mówić, rozwój własnych aplikacji daje niemal nieograniczoną elastyczność w reagowaniu na zmiany potrzeb biznesowych. Nie ma jednak wsparcia producenta - na kogo dyrekcja zwali ewentualne problemy? (Jakie problemy? - zastawia się deweloper aplikacji znający ją na wskroś i usuwający błędy "od ręki"). Doskonały powód, by wymienić je na jakieś nowe, komercyjne rozwiązanie ze wsparciem. Drogim wsparciem. W praktyce może się okazać, że co prawda wdrożono nowe, ale z jakiegoś powodu wciąż nie można wyłączyć tego starego...
Mamy więc systemy, które nie były przeznaczone do likwidacji, takie, które chciano zlikwidować, ale się nie udało, i oczywiście te nowe, które były mniej lub bardziej potrzebne.
Tych nowych nie będziemy przecież likwidować - tyle pieniędzy na to wydaliśmy... już lepiej wydać drugie tyle, by je "udrożnić" i zacząć stosować.
Tych starych nie będziemy przecież likwidować - są filarem naszej firmy, za duża rewolucja. Czasem nawet upgrade jest zbyt ryzykowny - a że utracimy wsparcie? Cóż, korzystamy z tego X lat i ile tych zgłoszeń do supportu poszło? Trzy? I rozwiązywali je ile? Dwa... tygodnie? To o całe 13 dni dłużej niż robili to nasi administratorzy.
Można spróbować zlikwidować te już raz przeznaczone do likwidacji, a co się dotąd nie udało. Pozostaje życzyć powodzenia. :-)
środa, 11 sierpnia 2010
FreeBSD 8.1 - zmiany zwracające uwagę
W lipcu wydano FreeBSD 8.1. Wpis - suchar? Trochę tak. ;) Na liście zmian tej wersji systemu znalazłem kilka interesujących rzeczy.
Rozbudowane IPFW ("ipfw3"), czyli natywny firewall FreeBSD (pf jest importowany z OpenBSD). Pojawiła się w końcu możliwość eksportu do pseudourządzenia ipfw0 (analog do pflog0). Śledzenie pracy firewalla narzędziami typu tcpdump jest naprawdę przyjemniejsze niż syslog. Wiele algorytmów wyszukiwania zmieniło złożoność czasową na niższą. Mocno przepisany został dummynet.
Widać też postępujący proces migracji sterowników ATA pod interfejs CAM, który obejmował dotąd SCSI. Dzięki temu można będzie stosować wspólne API przy dostępie do obu rodzin urządzeń dyskowych.
Zmiany od Polaków: pojawił się HAST, ale o tym wspominałem wcześniej. Jest także wsparcie dla NFSv4 ACLs (więcej).
Enterprajsowo, pojawiła się komenda service sterująca usługami. ;)
Wreszcie pojawiło się wsparcie w skryptach startowych do hurtowego tworzenia puli VLAN-ów na danym interfejsie fizycznym, ponazywanych według konwencji znanej z ruterów, np. em0.X (VLAN X na pseudointerfejsie em0).
Rozbudowane IPFW ("ipfw3"), czyli natywny firewall FreeBSD (pf jest importowany z OpenBSD). Pojawiła się w końcu możliwość eksportu do pseudourządzenia ipfw0 (analog do pflog0). Śledzenie pracy firewalla narzędziami typu tcpdump jest naprawdę przyjemniejsze niż syslog. Wiele algorytmów wyszukiwania zmieniło złożoność czasową na niższą. Mocno przepisany został dummynet.
Widać też postępujący proces migracji sterowników ATA pod interfejs CAM, który obejmował dotąd SCSI. Dzięki temu można będzie stosować wspólne API przy dostępie do obu rodzin urządzeń dyskowych.
Zmiany od Polaków: pojawił się HAST, ale o tym wspominałem wcześniej. Jest także wsparcie dla NFSv4 ACLs (więcej).
Enterprajsowo, pojawiła się komenda service sterująca usługami. ;)
Wreszcie pojawiło się wsparcie w skryptach startowych do hurtowego tworzenia puli VLAN-ów na danym interfejsie fizycznym, ponazywanych według konwencji znanej z ruterów, np. em0.X (VLAN X na pseudointerfejsie em0).
wtorek, 10 sierpnia 2010
Migracja zawodowa w IT
Zdarzyło mi się zmienić miejsce zamieszkania celem uzyskania dostępu do lepszego rynku pracy IT (czytaj: przeprowadziłem się do Warszawy). Nigdy jednak nie rozważałem serio wyjazdu z Polski. Powodów jest kilka:
Wracając jednak do migracji zawodowej - do podjęcia rozważań i umieszczenia tego posta zainspirowali mnie rekruterzy firm zagranicznych, którzy zechcieli do mnie zagadnąć. Oczywiście, zagadują oni pewnie wiele osób, a tylko niektórym faktycznie udaje się przejść rekrutację (po czym jeszcze mniej z nich faktycznie decyduje się na przeprowadzkę). Konkretnie, poproszono mnie o wysłanie CV w następujących kierunkach:
Przyznam, że nigdy nie byłem w tych krajach i nie wiem o nich wiele. Szybkie skojarzenia miałem następujące:
Irlandia
Szwajcaria
Oczywiście, wyboru nie podejmuje się na podstawie danych tak marnej jakości. ;) Zacząłem się więc zastanawiać, jakimi kryteriami posłużyć się przy bardziej szczegółowej analizie - o ile zdarzyło by się, że faktycznie stanę przed takim dylematem.
Wymyśliłem na razie następujące:
- w Polsce są rodzina, znajomi i przyjaciele
- odwiedziny kogoś w innym mieście zwykle są w zasięgu kilkugodzinnej podróży
- w Warszawie można uzyskiwać bardzo dobre dochody
- pomijając niektóre sklepy, koszty życia w Polsce są stosunkowo niskie
- bariera językowa - angielskiego używam głównie do czytania dokumentacji technicznej
- majstrowanie rządu przy VAT i OFE
- oszołomstwo obrońców krzyża i innych
- tor przeszkód między żebrakami, wszelkiej maści cwaniaczkami i agresywnymi pijanymi wyrostkami, jaki trzeba czasem zaliczyc idąc przez Centrum
- śmieci na trawnikach, palenie papierosów na przystankach i inne przejawy buraczanej mentalności
- irracjonalnie wysokie wyceny nieruchomości w Warszawie
- fatalne perspektywy demograficzne i praktycznie pewne załamanie systemu emerytalnego
- brak klasy rządzącej z prawdziwego zdarzenia i długofalowej strategii rozwoju Państwa
- podtrzymywanie iluzji dobrobytu poprzez bieżące przejadanie majątku narodowego
- mentalność "Państwo powinno mnie wspomóc" i silne poparcie polityków, którzy obiecują rozdawnictwo
- potencjalnie groźnych sąsiadów
Wracając jednak do migracji zawodowej - do podjęcia rozważań i umieszczenia tego posta zainspirowali mnie rekruterzy firm zagranicznych, którzy zechcieli do mnie zagadnąć. Oczywiście, zagadują oni pewnie wiele osób, a tylko niektórym faktycznie udaje się przejść rekrutację (po czym jeszcze mniej z nich faktycznie decyduje się na przeprowadzkę). Konkretnie, poproszono mnie o wysłanie CV w następujących kierunkach:
Przyznam, że nigdy nie byłem w tych krajach i nie wiem o nich wiele. Szybkie skojarzenia miałem następujące:
Irlandia
- w niedalekiej przeszłości przepychanki z Wielką Brytanią i bieda
- wielka migracja Polaków w tym kierunku
- załamanie na rynku nieruchomości i ogólnie kryzys
- zdolność do szybkiego powstawania z kryzysów i rozwoju (ich kiełbasa łatwo przegoni naszą)
- niskie podatki, którymi narażali się UE
- są za wodą i jeżdżą po złej stronie ulicy
Szwajcaria
- neutralność i bezpieczeństwo, broń pod łóżkiem a za oknem góry
- jedno z centrów finansowych świata
- obywatelskie społeczeństwo
- autonomia - własna waluta, "nie" dla meczetów i UE
- bardziej przyda się tam niemiecki (którego nie znam) niż angielski
Oczywiście, wyboru nie podejmuje się na podstawie danych tak marnej jakości. ;) Zacząłem się więc zastanawiać, jakimi kryteriami posłużyć się przy bardziej szczegółowej analizie - o ile zdarzyło by się, że faktycznie stanę przed takim dylematem.
Wymyśliłem na razie następujące:
- obecny stan i prognozowany rozwój (demografia, gospodarka)
- bezpieczeństwo geopolityczne
- bezpieczeństwo fizyczne
- system podatkowy
- czystość środowiska
- zamożność społeczeństwa, liczność i realny wpływ warstw domagających się tzw. socjału
- zarobki minimalne, średnie i średnie zarobki w IT
- realne koszty pobytu i życia (żywność, komunikacja, rozrywki)
- ceny nieruchomości i ceny najmu, dostępność
- kultura społeczeństwa
- łatwość i koszt podróżowania między Polską a danym krajem
niedziela, 8 sierpnia 2010
Drżyj - nadciąga TRILL
Ivan Pepelnjak, posiadacz najwyższych stopni wtajemniczenia w sekcie siskoitów ;) silnie skupił się na krytyce promowanego ostatnimi czasy TRILL-a.
Czym jest TRILL? Bardzo upraszczając, to takie przełączanie ramek, gdzie poszczególne przełączniki wymieniają informacje o trasach podobnie jak rutery, czyli z użyciem protokołu rutingu. (Klasyczne przełączniki uczą się po prostu, na którym porcie jaki MAC jest osiągalny, a jak nie wiedzą, to ślą ramkę do wszystkich). Teoretycznie ma uprościć życie i np. pozwolić budować wielkie (tysiące hostów) domeny rozgłoszeniowe w środowisku datacenter. Bardzo modne w czasach wirtualizacji i chmur.
Dlaczego należy drżeć przed TRILL-em? Ivan zastanawia się nad tym w serii postów. W szczególności polecam:
Czym jest TRILL? Bardzo upraszczając, to takie przełączanie ramek, gdzie poszczególne przełączniki wymieniają informacje o trasach podobnie jak rutery, czyli z użyciem protokołu rutingu. (Klasyczne przełączniki uczą się po prostu, na którym porcie jaki MAC jest osiągalny, a jak nie wiedzą, to ślą ramkę do wszystkich). Teoretycznie ma uprościć życie i np. pozwolić budować wielkie (tysiące hostów) domeny rozgłoszeniowe w środowisku datacenter. Bardzo modne w czasach wirtualizacji i chmur.
Dlaczego należy drżeć przed TRILL-em? Ivan zastanawia się nad tym w serii postów. W szczególności polecam:
- Dlaczego bridge w ogóle nie powinny zaistnieć? - Bridges: a kludge that shouldn't exist
- Jaka jest różnica między przełączaniem a rutowaniem? - Bridging and Routing: is there a difference? oraz Bridging and Routing, Part II
- O wysypie standardów - How many large-scale bridging standards do we need?
- brak licznika hopów
- brak wsparcia dla fragmentacji
- brak sygnalizacji problemu do nadawcy
- powielanie ramek
- mobilność adresu
sobota, 7 sierpnia 2010
Dyktat Business Case
Przeczytałem niedawno artykuł Zasada skautów. Nie jestem programistą, ale obserwuję takowych oraz całą otoczkę związaną z wprowadzaniem zmian w systemach. Artykuł proponuje, aby programiści stosowali zasadę zawsze zostawiaj kod czystszym niż go zastałeś. Udoskonalenia mogą być drobne, ale tak jak skumulowane przez lata drobne niedoskonałości doprowadzają do erozji kodu, tak skumulowane przez lata drobne usprawnienia mogą wydźwignąć kod z bagna.
Do umieszczenia tego wpisu zainspirowały mnie komentarze pod artykułem, że tego typu podejście w realnym świecie bywa niemożliwe do zastosowania. Zupełnie się z tym zgadzam albowiem obserwuję zjawisko, które nazwałem roboczo dyktatem business case'u (BC).
W firmach skupionych na działalności biznesowej, dla których IT pełni rolę służebną, nie dewelopuje się dla przyjemności, tylko do zaspokojenia określonych potrzeb biznesowych organizacji. Decyzja o wykonaniu lub nie określonej zmiany podejmowana jest po analizie BC przez zarządzających, bywa że najwyższego szczebla (zależnie od budżetu). Na tym poziomie nikt nie wnika, czy kod jest ładny. Na słupku w arkuszu kalkulacyjnym widzimy, że wydamy kwotę X i uzyskamy z tego tytułu przychody albo oszczędności na kwotę Y w horyzoncie k-letnim - to jest coś, co przemawia.
Problem jest taki, że istnieją rzeczy, które inżynier uważa za stosowne by je wykonać, ale bardzo trudno biznesowo uzasadnić związane z tym koszty. Dokumentacja, refaktoryzacja pewnych części, przeprojektowanie API, lepsze walidacje, większa uniwersalność, lepsza integracja z systemem operacyjnym, czytelniejsze logi, itd. - z punktu widzenia użytkownika biznesowego to mogą być rzeczy "mało ważne", "ryzykowne dla harmonogramu", "możliwe do realizacji w terminie późniejszym", "na inny projekt".
I rzeczywiście jest tak, że nie powstają rozwiązania dobre, tylko wystarczająco dobre. Nie obsługują niektórych specyficznych przypadków i trzeba dane poprawiać ręcznie (tańsze to niż poprawka aplikacji). Wymagają restartu co noc (akceptowalne, w nocy nie pracujemy). Mają SQL injection (ale używają ją tylko zaufani pracownicy, którzy prawdopodobnie tego nigdy nie odkryją). Działa przy zbyt dużych uprawnieniach (ale działa, a mogłaby nie działać). Ma bardzo niestandardowe skrypty uruchamiające (uczulimy administratorów). Loguje pełno śmieci i rzuca wyjątkami na lewo i prawo (dyski są tanie). Konsumuje duże zasoby (RAM jest tani). Ale za to było połowę tańsze, dzięki czemu BC w ogóle się spiął. Z punktu widzenia klienta biznesowego to może być wręcz pełny sukces.
Te drobiazgi kumulują się w czasie, a niesmak z pracy z kodem rośnie. Rośnie również kulka hacków i workaroundów, ale póki to jakoś istotnie finansowo nie uderzy w organizację (system stanie się krwiobiegiem organizacji i zacznie być blokerem jej rozwoju ze względu na trudność wprowadzania zmian), wszyscy będą z tym żyli pchając całość do przodu. Może to trwać wiele, wiele lat...
Do umieszczenia tego wpisu zainspirowały mnie komentarze pod artykułem, że tego typu podejście w realnym świecie bywa niemożliwe do zastosowania. Zupełnie się z tym zgadzam albowiem obserwuję zjawisko, które nazwałem roboczo dyktatem business case'u (BC).
W firmach skupionych na działalności biznesowej, dla których IT pełni rolę służebną, nie dewelopuje się dla przyjemności, tylko do zaspokojenia określonych potrzeb biznesowych organizacji. Decyzja o wykonaniu lub nie określonej zmiany podejmowana jest po analizie BC przez zarządzających, bywa że najwyższego szczebla (zależnie od budżetu). Na tym poziomie nikt nie wnika, czy kod jest ładny. Na słupku w arkuszu kalkulacyjnym widzimy, że wydamy kwotę X i uzyskamy z tego tytułu przychody albo oszczędności na kwotę Y w horyzoncie k-letnim - to jest coś, co przemawia.
Problem jest taki, że istnieją rzeczy, które inżynier uważa za stosowne by je wykonać, ale bardzo trudno biznesowo uzasadnić związane z tym koszty. Dokumentacja, refaktoryzacja pewnych części, przeprojektowanie API, lepsze walidacje, większa uniwersalność, lepsza integracja z systemem operacyjnym, czytelniejsze logi, itd. - z punktu widzenia użytkownika biznesowego to mogą być rzeczy "mało ważne", "ryzykowne dla harmonogramu", "możliwe do realizacji w terminie późniejszym", "na inny projekt".
I rzeczywiście jest tak, że nie powstają rozwiązania dobre, tylko wystarczająco dobre. Nie obsługują niektórych specyficznych przypadków i trzeba dane poprawiać ręcznie (tańsze to niż poprawka aplikacji). Wymagają restartu co noc (akceptowalne, w nocy nie pracujemy). Mają SQL injection (ale używają ją tylko zaufani pracownicy, którzy prawdopodobnie tego nigdy nie odkryją). Działa przy zbyt dużych uprawnieniach (ale działa, a mogłaby nie działać). Ma bardzo niestandardowe skrypty uruchamiające (uczulimy administratorów). Loguje pełno śmieci i rzuca wyjątkami na lewo i prawo (dyski są tanie). Konsumuje duże zasoby (RAM jest tani). Ale za to było połowę tańsze, dzięki czemu BC w ogóle się spiął. Z punktu widzenia klienta biznesowego to może być wręcz pełny sukces.
Te drobiazgi kumulują się w czasie, a niesmak z pracy z kodem rośnie. Rośnie również kulka hacków i workaroundów, ale póki to jakoś istotnie finansowo nie uderzy w organizację (system stanie się krwiobiegiem organizacji i zacznie być blokerem jej rozwoju ze względu na trudność wprowadzania zmian), wszyscy będą z tym żyli pchając całość do przodu. Może to trwać wiele, wiele lat...
Update - w pewien sposób ilustracja tego o czym piszę ;) Brytyjski rząd: Internet Explorer 6 jest wystarczająco bezpieczny.
niedziela, 25 lipca 2010
Ile może kosztować prosty skrypt powłoki?
Wyobraźmy sobie, że mamy sieć rozległą, złożoną z wielu elementów aktywnych IP. Elementy oraz łącza podkładowe ulegają czasem awarii. Postanawiamy stworzyć proste narzędzie monitorujące - skrypt powłoki:
Sprytna odpowiedź brzmi: to zależy. ;)
Zwinny administrator, posługujący się biegle powłoką i językami skryptowymi, popełni w tzw. międzyczasie jednolinijkowca. Jest to bezkosztowe lub bardzo tanie - powiedzmy 0,1 tys. PLN.
Jeśli zrobi to pracownik zewnętrzny, dojdzie jeszcze prowizja handlowca, krótka dokumentacja dla klienta, prezentacja "jak to działa" - powiedzmy że do 2 tys. PLN.
Co jednak, gdy rzecz dzieje się w środowisku objętym zarządzaniem zmianami? Warsztaty wymagań z użytkownikami, dokument analizy, kodowanie, dokumentacja i testy odbiorcze. Całkowity koszt może wynieść bez problemu 10 tys. PLN.
A gdyby to nie było w kraju PLN-ów lecz w którymś zamożnych krajów Europy Zachodniej... ;-)
Do czego zmierzam? Czy zarządzanie zmianami to źródło zła? Odpowiem: to zależy! ;)
Można wysnuć z tego różne wnioski:
- pobierający z bazy danych wykaz urządzeń,
- testujący pingiem ich dostępność,
- wysyłający e-mail do administratorów w przypadku, gdy któreś urządzenie jest nieosiągalne.
Sprytna odpowiedź brzmi: to zależy. ;)
Zwinny administrator, posługujący się biegle powłoką i językami skryptowymi, popełni w tzw. międzyczasie jednolinijkowca. Jest to bezkosztowe lub bardzo tanie - powiedzmy 0,1 tys. PLN.
Jeśli zrobi to pracownik zewnętrzny, dojdzie jeszcze prowizja handlowca, krótka dokumentacja dla klienta, prezentacja "jak to działa" - powiedzmy że do 2 tys. PLN.
Co jednak, gdy rzecz dzieje się w środowisku objętym zarządzaniem zmianami? Warsztaty wymagań z użytkownikami, dokument analizy, kodowanie, dokumentacja i testy odbiorcze. Całkowity koszt może wynieść bez problemu 10 tys. PLN.
A gdyby to nie było w kraju PLN-ów lecz w którymś zamożnych krajów Europy Zachodniej... ;-)
Do czego zmierzam? Czy zarządzanie zmianami to źródło zła? Odpowiem: to zależy! ;)
Można wysnuć z tego różne wnioski:
- Rzeczy, które są proste i tanie w realiach małej firmy, niekoniecznie są takie w realiach dużej firmy.
- Uwzględniając powyższe, w realiach dużej firmy zakup bardzo drogiego, ale gotowego oprogramowania może być i tak tańszy, niż wdrażanie i wsparcie (TCO) dla oprogramowania darmowego.
- Narzut wprowadzany przez różne standardy i metodyki może podnieść koszty rozwiązania np. o 2 rzędy wielkości, nie zawsze poprawiając jakość rozwiązania.
- W realiach dużej firmy te podwyższone koszty mogą być wciąż zaniedbywalne, a bardziej zwinne firmy zyskują dzięki temu szansę zarobkowania (brutalnie rzecz umując, pasożytują na bezwładnej korporacji sprzedając jej prosty software za wielkie pieniądze).
- Mnóstwo pieniędzy może zostać zmarnotrawionych na wszelkie formy zarządzania i pośrednictwa, a nie na samo rozwiązanie - jest to więc dobre miejsce na szukanie oszczędności.
niedziela, 18 lipca 2010
VPN z OpenSSH
Kiedy potrzebujemy zestawić między dwoma sieciami VPN na publicznej sieci IP, wybór pada zwykle na jedno z dwóch rozwiązań:
W przypadku IPseca mamy implementację na poziomie jądra systemu operacyjnego i opcjonalnego demona do wymiany kluczy, np. racoon, isakmpd lub inny.
Konfiguracja IPseca jest zwykle dość zagmatwana i można spotkać problemy ze współpracą różnych implementacji ;) toteż administratorzy lubią SSL VPN-y, które "po prostu działają".
Implementacja SSL VPN działa w całości w przestrzeni użytkownika, posiłkując się sterownikiem jądra dostarczającym pseudointerfejsu tunelującego (np. tun). Jedną z najpopularniejszych implementacji SSL VPN-a jest OpenVPN.
W tym wpisie chciałbym jednak pokazać inny wariant SSL VPN-a, nieco mniej znany, ale za to oprogramowanie mamy już w systemie więc zwykle da się to odpalić "od ręki" - mowa o OpenSSH. Nie, nie chodzi o przekierowywanie portów. Od wersji 4.3 (2006 rok) mamy dostępną opcję -w, która umożliwia zestawienie VPN-a z użyciem pseudointerfejsu tun/tap.
Aby to działało, musimy włączyć w serwerze SSH następujące opcje: PermitTunnel i PermitRootLogin.
W celu zilustrowania uruchomię sobie 2 maszyny wirtualne: jedną z Linuksem (serwer) i jedną z OpenBSD (klient). Maszyny mają ze sobą bezpośrednią łączność po IP.
debian:~# grep -i permittunnel /etc/ssh/sshd_config
PermitTunnel yes
debian:~# /etc/init.d/ssh restart
Restarting OpenBSD Secure Shell server: sshd.
Następnie łączę się z OpenBSD do Linuksa:
open# ssh -NTf -w any:any 192.168.1.182
root@192.168.1.182's password:
W wyniku mamy po obu stronach pseudointerfejsy tun i możemy je zaadresować:
open# ifconfig tun
tun3: flags=51 mtu 1500
priority: 0
groups: tun
debian:~# ip a sh dev tun0
5: tun0:mtu 1500 qdisc noop state DOWN qlen 500
link/[65534]
debian:~# ip a add 172.16.1.2 dev tun0 peer 172.16.1.1
debian:~# ip link set tun0 up
open# ifconfig tun3 172.16.1.1/32 172.16.1.2
Testujemy... działa:
open# ping -c 2 172.16.1.2
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=64 time=1.785 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=7.274 ms
--- 172.16.1.2 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.785/4.529/7.274/2.745 ms
Pozostaje ustawić ruting do sieci zdalnej (i opcjonalny NAT). Można także wymusić (klient, opcja Tunnel) użycie pseudointerfejsu tap, czyli emulację łącza Ethernet.
Obecne w OpenSSH wsparcie dla tworzenia szyfrowanych tuneli może być w niektórych sytuacjach znacznie lepszym rozwiązaniem niż przekierowywanie portów. Mamy możliwość transportowania innych protokołów niż TCP, a nawet ramek Ethernet (bridge poprzez VPN). Jeśli potrzebujemy uzyskać dostęp do wielu systemów w zdalnej sieci, może to być prostsze rozwiązanie niż przekierowywanie długiej listy portów. Przekierowanie portów może też utrudnić korzystanie z wirtualnych serwerów WWW (name-based) - tutaj nie mamy tego problemu. Jednak aby się tym pobawić, musimy mieć prawa roota zarówno po stronie serwera, jak i klienta.
W przypadku IPseca mamy implementację na poziomie jądra systemu operacyjnego i opcjonalnego demona do wymiany kluczy, np. racoon, isakmpd lub inny.
Konfiguracja IPseca jest zwykle dość zagmatwana i można spotkać problemy ze współpracą różnych implementacji ;) toteż administratorzy lubią SSL VPN-y, które "po prostu działają".
Implementacja SSL VPN działa w całości w przestrzeni użytkownika, posiłkując się sterownikiem jądra dostarczającym pseudointerfejsu tunelującego (np. tun). Jedną z najpopularniejszych implementacji SSL VPN-a jest OpenVPN.
W tym wpisie chciałbym jednak pokazać inny wariant SSL VPN-a, nieco mniej znany, ale za to oprogramowanie mamy już w systemie więc zwykle da się to odpalić "od ręki" - mowa o OpenSSH. Nie, nie chodzi o przekierowywanie portów. Od wersji 4.3 (2006 rok) mamy dostępną opcję -w, która umożliwia zestawienie VPN-a z użyciem pseudointerfejsu tun/tap.
Aby to działało, musimy włączyć w serwerze SSH następujące opcje: PermitTunnel i PermitRootLogin.
W celu zilustrowania uruchomię sobie 2 maszyny wirtualne: jedną z Linuksem (serwer) i jedną z OpenBSD (klient). Maszyny mają ze sobą bezpośrednią łączność po IP.
debian:~# grep -i permittunnel /etc/ssh/sshd_config
PermitTunnel yes
debian:~# /etc/init.d/ssh restart
Restarting OpenBSD Secure Shell server: sshd.
Następnie łączę się z OpenBSD do Linuksa:
open# ssh -NTf -w any:any 192.168.1.182
root@192.168.1.182's password:
W wyniku mamy po obu stronach pseudointerfejsy tun i możemy je zaadresować:
open# ifconfig tun
tun3: flags=51
priority: 0
groups: tun
debian:~# ip a sh dev tun0
5: tun0:
link/[65534]
debian:~# ip a add 172.16.1.2 dev tun0 peer 172.16.1.1
debian:~# ip link set tun0 up
open# ifconfig tun3 172.16.1.1/32 172.16.1.2
Testujemy... działa:
open# ping -c 2 172.16.1.2
PING 172.16.1.2 (172.16.1.2): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=64 time=1.785 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=7.274 ms
--- 172.16.1.2 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.785/4.529/7.274/2.745 ms
Pozostaje ustawić ruting do sieci zdalnej (i opcjonalny NAT). Można także wymusić (klient, opcja Tunnel) użycie pseudointerfejsu tap, czyli emulację łącza Ethernet.
Obecne w OpenSSH wsparcie dla tworzenia szyfrowanych tuneli może być w niektórych sytuacjach znacznie lepszym rozwiązaniem niż przekierowywanie portów. Mamy możliwość transportowania innych protokołów niż TCP, a nawet ramek Ethernet (bridge poprzez VPN). Jeśli potrzebujemy uzyskać dostęp do wielu systemów w zdalnej sieci, może to być prostsze rozwiązanie niż przekierowywanie długiej listy portów. Przekierowanie portów może też utrudnić korzystanie z wirtualnych serwerów WWW (name-based) - tutaj nie mamy tego problemu. Jednak aby się tym pobawić, musimy mieć prawa roota zarówno po stronie serwera, jak i klienta.
sobota, 17 lipca 2010
Gorzej, ale czasem szybciej
Natknąłem się niedawno na ciekawy, a do tego świeży (czerwiec 2010) artykuł "You're Doing It Wrong", który popełnił znany z asertywnych wypowiedzi deweloper FreeBSD i Varnisha, Poul-Henning Kamp.
Autor daje do pieca tekstami w rodzaju: my mind wandered, and it struck me that Knuth might be terribly misleading on the performance of the binary heap, possibly even by an order of magnitude.
Trąci "Faktem", niemniej PHK ilustruje istotny problem: programiści czasem zapominają, że algorytmy o niższej złożoności obliczeniowej mogą się zachowywać gorzej niż algorytmy o wyższej złożoności obliczeniowej, dlatego projektując rozwiązanie należy uwzględnić specyfikę architektury sprzętowej i rozmiar danych wejściowych. Teoretycznie gorszy algorytm może działać szybciej dla danych wejściowych o bardzo dużym rozmiarze (wystarczającym w projektowanym zastosowaniu) ze względu na unikanie np. kosztowego stronicowania.
Jako że mamy sezon ogórkowy, podlinkuję: - You are doing it wrong! - Says who? ;)
Autor daje do pieca tekstami w rodzaju: my mind wandered, and it struck me that Knuth might be terribly misleading on the performance of the binary heap, possibly even by an order of magnitude.
Trąci "Faktem", niemniej PHK ilustruje istotny problem: programiści czasem zapominają, że algorytmy o niższej złożoności obliczeniowej mogą się zachowywać gorzej niż algorytmy o wyższej złożoności obliczeniowej, dlatego projektując rozwiązanie należy uwzględnić specyfikę architektury sprzętowej i rozmiar danych wejściowych. Teoretycznie gorszy algorytm może działać szybciej dla danych wejściowych o bardzo dużym rozmiarze (wystarczającym w projektowanym zastosowaniu) ze względu na unikanie np. kosztowego stronicowania.
Jako że mamy sezon ogórkowy, podlinkuję: - You are doing it wrong! - Says who? ;)
sobota, 10 lipca 2010
Jak hartowała się wirtualizacja
Popełniłem ostatnio kilka bardziej technicznych wpisów, a miały być przecież wynurzenia. ;-)
Jednym ze słów-kluczy, które padły we wpisie o meetBSD, jest wirtualizacja. Ta wspaniała wirtualizacja, dzięki której możemy skonsolidować wiele mielących wiatrakami powietrze serwerów w jedną fizyczną maszynę i uratować zasoby planety; dzięki której możemy powoływać i niszczyć środowiska systemowe (np. do testów) kilkoma kliknięciami myszki.
Pamiętam, że dawno dawno był taki numer PCkuriera, w którym po raz pierwszy ujrzałem VMware, jaskółkę zwiastującą ofensywę wirtualizacji. Przeczesałem dziś metry żółtych okładek na półkach i znalazłem: numer 18/99 z 2-go września 1999 r.
Strona 30, w kategorii Oprogramowanie/Emulatory czai się recenzja Artura Wyrzykowskiego "VMware 1.0. Windows pod Linuksem". Znamienne, że produkt był właśnie w wersji dla Linuksa - "dla Windows NT 4.0 i 2000 VMware przygotowało analogiczny emulator (obecnie jeszcze w wersji beta)". Było to de facto obecne Workstation i kosztowało 299 USD. Autor przeprowadził testy SYSmarkiem, środowisko bez wirtualizacji było o 70-100% szybsze. Zastosowania? Bardzo niszowe. :) Dla kogoś, kto z jakiegoś powodu pracuje tylko pod Linuksem, a musi uruchomić jednocześnie np. MS Windows dla jakiejś specyficznej aplikacji np. Płatnika...
Dziś do zabawy w wirtualizację na desktopie mamy za darmo choćby VMware Player czy Oracle Virtualbox. Prawdziwy biznes robi się na wirtualizacji datacenter, choć i tam coraz więcej można dostać w gratisie.
Dla oddania kontekstu historycznego, kilka smaczków z tego numeru:
Pamiętam... że dawno dawno dawno temu był tak numer C&A, w którym był test emulatora PC na Amigę... ale nie, ta szafa jest zbyt zakurzona.
Jednym ze słów-kluczy, które padły we wpisie o meetBSD, jest wirtualizacja. Ta wspaniała wirtualizacja, dzięki której możemy skonsolidować wiele mielących wiatrakami powietrze serwerów w jedną fizyczną maszynę i uratować zasoby planety; dzięki której możemy powoływać i niszczyć środowiska systemowe (np. do testów) kilkoma kliknięciami myszki.
Pamiętam, że dawno dawno był taki numer PCkuriera, w którym po raz pierwszy ujrzałem VMware, jaskółkę zwiastującą ofensywę wirtualizacji. Przeczesałem dziś metry żółtych okładek na półkach i znalazłem: numer 18/99 z 2-go września 1999 r.
Strona 30, w kategorii Oprogramowanie/Emulatory czai się recenzja Artura Wyrzykowskiego "VMware 1.0. Windows pod Linuksem". Znamienne, że produkt był właśnie w wersji dla Linuksa - "dla Windows NT 4.0 i 2000 VMware przygotowało analogiczny emulator (obecnie jeszcze w wersji beta)". Było to de facto obecne Workstation i kosztowało 299 USD. Autor przeprowadził testy SYSmarkiem, środowisko bez wirtualizacji było o 70-100% szybsze. Zastosowania? Bardzo niszowe. :) Dla kogoś, kto z jakiegoś powodu pracuje tylko pod Linuksem, a musi uruchomić jednocześnie np. MS Windows dla jakiejś specyficznej aplikacji np. Płatnika...
Dziś do zabawy w wirtualizację na desktopie mamy za darmo choćby VMware Player czy Oracle Virtualbox. Prawdziwy biznes robi się na wirtualizacji datacenter, choć i tam coraz więcej można dostać w gratisie.
Dla oddania kontekstu historycznego, kilka smaczków z tego numeru:
- str. 6 - "koszt rejestracji nazwy w domenie .PL to obecnie 300 zł (...) co roku"
- str. 12 - "Usługi katalogowe dziś i jutro", czyli NDS vs. AD - dziś już chyba nie ma wątpliwości, kto wygrał ;)
- str. 18 - "Linux od Corela", pokaz przedpremierowy ś.p. Corel Linuksa oraz Inprise ;) Delphi 5, do tego "Amerykański Departament Handlu poszukuje technologii szyfrujących, z których wybierze jedną jako oficjalny standard AES"
- str. 37 - "TCH Components wprowadził do sprzedaży (...) dyski o pojemności 18GB"
- str. 38 - "Linia komputerów ZETAN, produkowanych przez grupę ZETO (...) wzbogaciła się o komputer wyposażony w procesor Pentium III 600MHz. Zastosowano w nim płytę główną z chipsetem BX, dysk o pojemności 8,4GB oraz 128MB RAM"
- str. 57 - test monitora LCD IBM T55A o przekątnej 15'', cena? jedyne 5700 zł + VAT
- str. 58-59 - zestawienie cen modemów i faksmodemów, ceny rzędu 300-500 zł, ale pojawiają się winmodemy za 149 zł ;)
- str. 60 - informacja o ICQ99b, "w tej chwili baza użytkowników tego pakietu (...) przekracza 40 mln"
- str. 68 - "Bankructwo Iridium. Kosmiczne długi", "Linux na giełdzie. Cena akcji RedHat (...) wzrosła pierwszego dnia notowań o 370%"
Pamiętam... że dawno dawno dawno temu był tak numer C&A, w którym był test emulatora PC na Amigę... ale nie, ta szafa jest zbyt zakurzona.
Subskrybuj:
Posty (Atom)