Valgrind - pomaga wyszukać wycieki pamięci w programach

Chwilę pomyślałem sobie dzisiaj o problemach jakie mogą mieć urządzenia wbudowane z oprogramowaniem i przyszła mi taka myśl: 

Ciekawe, czy zależnie od języka programowania w standardzie możemy dostawać wycieki pamięci lub nie?

Z punktu widzenia różnych znanych mi systemów w urządzeniach mobilnych zastanawia mnie słabe rozwiązanie tego problemu - tzn. klikanie zwolnij zaalokowaną pamięć telefonu na żądanie. Inny wariant, to dedykowane programy z klasy "odśmiecacze pamięci", czyli dedykowane oprogramowanie, którego celem jest przegląd wszelkich niezwolnionych bloków i za zgodą usera próba zwolnienia. Brzmi znajomo, może Twój telefon z Androidem też przymula po otwarciu kilku aplikacji (nie koniecznie gier) ... i dopiero restart naprawia sprawę. Cóż, może mamy tam do czynienia z tzw. wyciekiem pamięci operacyjnej. Koncept nieskomplikowany do sprawdzenia na prostym przykładzie. 

Wprowadzenie do wycieków pamięci

Wyciek pamięci (ang. memory leak) to zaalokowanie pamięci w systemie operacyjnym przez program, który nie zwalania pamięci po zakończeniu swojego działania. 

Wszystko fajnie, kiedy bawimy się telefonem i po np: tygodniu działania zaczyna zamulać, robimy restart i działa dalej. Inaczej sprawa się ma na rynku np: serwerów, czy sprzętu ratującego życie, medycznego, diagnostycznego, kalibracyjnego. Są branże, gdzie wycieki pamięci to nie jest norma a poważny błąd. Każdy bajt wykradziony z puli w takich systemach wbudowanych, to proszenie się o zawieszenie systemu / programu / procesu, czyli o niestandardową awarię.

Nie jest tylko tak, że wycieki pamięci generują programiści danego softu. Mogą istnieć ukryte wycieki pamięci, które generują zewnętrzne bibioteki lub biblioteki współdzielone lub systemowe. Ta klasa błędów posiada dość szeroki zasięg ze względu na magię używania dwóch podstawowych instrukcji niższego poziomu w jężyka programowania t.j. C dobrze znanych. Są to:

 - alloc / malloc / calloc / tallloc i pochodne - rezerwują pamięć w programie dla zmiennej

- free i pochodne - zwalniają przydzieloną pamięć (po podaniu zmiennej z przydziału pamięci jako argumentu) 

Właściwie to chodzi tutaj o fakt, że nie wywołuje się FREE tam gdzie zachodzi *ALLOC. Niby takie proste w opisie a do osiągnięcia nirvany jest sporo kombinacji i pracy ;-)

Valgrind - ratunek na wycieki pamięci w oprogramowaniu

Na szczęście w fazie tworzenia oprogramowania, debugowania i testowania, jesteśmy w stanie sprawdzić jak zachowuje się oprogramowanie i dokonać rozpoznania wycieków pamięci. Narzędziem najpopularniejszym na rynku otwartego oprogramowania jest Valgrind 

Narzędzie to doczekało się dojrzałej wersji i bardzo bogatego portfolio, jeśli chodzi o wspierane architektury.

Valgrind obejmuje obecnie siedem narzędzi o jakości produkcyjnej: 

- detektor błędów pamięci 

- dwa detektory błędów wątków 

- pamięć podręczną i profiler predykcji rozgałęzień 

- wykres wywołań generujący pamięć podręczną 

- profiler przewidywania rozgałęzień 

- dwa różne profilery sterty. 

Zawiera również eksperymentalny generator podstawowych wektorów blokowych SimPoint. 

Działa na następujących platformach: X86 / Linux, AMD64 / Linux, ARM / Linux, ARM64 / Linux, PPC32 / Linux, PPC64 / Linux, PPC64LE / Linux, S390X / Linux, MIPS32 / Linux, MIPS64 / Linux, X86 / Solaris , AMD64 / Solaris, ARM / Android (2.3.x i nowsze), ARM64 / Android, X86 / Android (4.0 i nowsze), MIPS32 / Android, X86 / Darwin i AMD64 / Darwin (Mac OS X 10.12).

W Ubuntu możemy zainstalować narzędzie valgrind z takiego onelinera:

$ snap install valgrind  --classic

Test dwóch znanych języków programowania - Python i Golang - na wycieki pamięci w najprostszym programie

Wracam tutaj do założenia mojego wpisu. Mamy dwa bardzo popularne dzisiaj języki programowania: Python i Golang, którymi posługuję się biegle na codzień. Pomyślałem, spróbuję napisać jednolinijkowca i zobaczymy, czy valgrind coś wykryje :-) Poniżej zrzut z testu i rezultaty:

Program w Python + valgrind

$ cat memleaks_test.py 

print("a" * 255)

$ python3 memleaks_test.py 

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Ok, odpalmy teraz z badaniem wycieków pamięci i co widzimy:

....

==19177== Invalid read of size 4

==19177==    at 0x5139AE: PyGrammar_RemoveAccelerators (in /usr/bin/python3.8)

==19177==    by 0x67EE59: Py_FinalizeEx (in /usr/bin/python3.8)

==19177==    by 0x6B614C: Py_RunMain (in /usr/bin/python3.8)

==19177==    by 0x6B63BC: Py_BytesMain (in /usr/bin/python3.8)

==19177==    by 0x4C890B2: (below main) (libc-start.c:308)

==19177==  Address 0x51f0020 is 384 bytes inside a block of size 732 free'd

==19177==    at 0x4A39078: free (vg_replace_malloc.c:538)

==19177==    by 0x51ACB8: PyGrammar_AddAccelerators (in /usr/bin/python3.8)

==19177==    by 0x5FD6C4: PyParser_New (in /usr/bin/python3.8)

==19177==    by 0x517293: ??? (in /usr/bin/python3.8)

==19177==    by 0x67BA7A: PyParser_ASTFromStringObject (in /usr/bin/python3.8)

==19177==    by 0x67BEFD: PyRun_StringFlags (in /usr/bin/python3.8)

==19177==    by 0x600581: ??? (in /usr/bin/python3.8)

==19177==    by 0x5C4D7F: ??? (in /usr/bin/python3.8)

==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)

==19177==    by 0x5F7145: _PyFunction_Vectorcall (in /usr/bin/python3.8)

==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)

==19177==    by 0x569559: _PyEval_EvalCodeWithName (in /usr/bin/python3.8)

==19177==  Block was alloc'd at

==19177==    at 0x4A37ECB: malloc (vg_replace_malloc.c:307)

==19177==    by 0x51ACCF: PyGrammar_AddAccelerators (in /usr/bin/python3.8)

==19177==    by 0x5FD6C4: PyParser_New (in /usr/bin/python3.8)

==19177==    by 0x517293: ??? (in /usr/bin/python3.8)

==19177==    by 0x67BA7A: PyParser_ASTFromStringObject (in /usr/bin/python3.8)

==19177==    by 0x67BEFD: PyRun_StringFlags (in /usr/bin/python3.8)

==19177==    by 0x600581: ??? (in /usr/bin/python3.8)

==19177==    by 0x5C4D7F: ??? (in /usr/bin/python3.8)

==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)

==19177==    by 0x5F7145: _PyFunction_Vectorcall (in /usr/bin/python3.8)

==19177==    by 0x56B26D: _PyEval_EvalFrameDefault (in /usr/bin/python3.8)

==19177==    by 0x569559: _PyEval_EvalCodeWithName (in /usr/bin/python3.8)

==19177== 

==19177== 

==19177== HEAP SUMMARY:

==19177==     in use at exit: 301,190 bytes in 135 blocks

==19177==   total heap usage: 2,186 allocs, 2,051 frees, 3,158,779 bytes allocated

==19177== 

==19177== LEAK SUMMARY:

==19177==    definitely lost: 0 bytes in 0 blocks

==19177==    indirectly lost: 0 bytes in 0 blocks

==19177==      possibly lost: 1,632 bytes in 3 blocks

==19177==    still reachable: 299,558 bytes in 132 blocks

==19177==         suppressed: 0 bytes in 0 blocks

==19177== Rerun with --leak-check=full to see details of leaked memory

==19177== 

==19177== Use --track-origins=yes to see where uninitialised values come from

==19177== For lists of detected and suppressed errors, rerun with: -s

==19177== ERROR SUMMARY: 1106 errors from 128 contexts (suppressed: 0 from 0)

Kilkaset bajtów program pożarł ;-) a to nowina dla wszystkich milionów użytkowników języka Pytohn :-) Polecam prztestować bardziej skomplikowane programy oraz serwery aplikacji.

Program w Golang + valgrind

$ cat main.go 

package main

import "fmt"

import "strings"

func main() {

fmt.Println(strings.Repeat("a", 255))

}

$ go build main.go 

$ ./main 

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Program w GOlangu robi dosłownie to samo i badamy go przy pomocy valgrind:

==19372== Conditional jump or move depends on uninitialised value(s)

==19372==    at 0x40C4FD: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1152)

==19372== 

==19372== Conditional jump or move depends on uninitialised value(s)

==19372==    at 0x40C4B1: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1136)

==19372==    by 0x4474A8: runtime.growslice (/snap/go/6633/src/runtime/slice.go:230)

==19372==    by 0x43593E: runtime.allgadd (/snap/go/6633/src/runtime/proc.go:473)

==19372==    by 0x43D1F8: runtime.newproc1 (/snap/go/6633/src/runtime/proc.go:3572)

==19372==    by 0x45DBD2: runtime.newproc.func1 (/snap/go/6633/src/runtime/proc.go:3528)

==19372==    by 0x461605: runtime.systemstack (/snap/go/6633/src/runtime/asm_amd64.s:370)

==19372==    by 0x43745F: ??? (<autogenerated>:1)

==19372== 

==19372== Conditional jump or move depends on uninitialised value(s)

==19372==    at 0x40C4FD: runtime.mallocgc (/snap/go/6633/src/runtime/malloc.go:1152)

==19372==    by 0x4474A8: runtime.growslice (/snap/go/6633/src/runtime/slice.go:230)

==19372==    by 0x43593E: runtime.allgadd (/snap/go/6633/src/runtime/proc.go:473)

==19372==    by 0x43D1F8: runtime.newproc1 (/snap/go/6633/src/runtime/proc.go:3572)

==19372==    by 0x45DBD2: runtime.newproc.func1 (/snap/go/6633/src/runtime/proc.go:3528)

==19372==    by 0x461605: runtime.systemstack (/snap/go/6633/src/runtime/asm_amd64.s:370)

==19372==    by 0x43745F: ??? (<autogenerated>:1)

==19372== 

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

==19372== 

==19372== HEAP SUMMARY:

==19372==     in use at exit: 0 bytes in 0 blocks

==19372==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated

==19372== 

==19372== All heap blocks were freed -- no leaks are possible

==19372== 

==19372== Use --track-origins=yes to see where uninitialised values come from

==19372== For lists of detected and suppressed errors, rerun with: -s

==19372== ERROR SUMMARY: 3447 errors from 761 contexts (suppressed: 0 from 0)

... i ku naszemu zdziwieniu jednak GOlang nie ma wycieków pamięci na takim samym banalnym programie.

Podsumowanie

Bardzo ciekawa obserwacja pomyślałem sobie, jak łatwo przy pomocy valgrind znajdziemy wycieki pamięci. Szczególnie kiedy chciałbym coś napisać na urządzenie wbudowane, którego wielkość pamięci RAM to nie są GB a MB, przemyślę jednak w jakim języku napisać kod. 

Nie chciałbym wpaść w totalne błędne wnioski, że nie można tego robić w Pythonie i tylko w GOlang, gdyż może to być błąd mojej wersji i w kolejnej zostanie naprawiony. Oczywiście, tak błachy błąd dla jednych programistów jest powodem do kolejnych eksperymentów dla innych. 

W związku z tym zapraszam do wypowiedzi, jakie macie doświadczenia z valgrind? Z jakich ciekawych sytuacji wyratował Was ten tool w pracy zawodowej? 

Ponad rok na Kali Linux z punktu widzenia 15 lat pracy na Ubuntu Linux

Kali Linux, jak każda dystrybucja bazująca na Ubuntu Linux, który z kolei bazuje na bazie Debian Linux to sprawa dość nieskomplikowana w codziennym użyciu dla DevOps, developerów i adminów. Linux kernel, jest tam aktualizowany, można używać pełnego zestawu narzędzi wizualnych np: gnome i to się spina bez bólu na desktopie. Nie zauważymy różnicy na desktopie w codziennym użytkowaniu.

 

Nie to jednak jest w Kali Linux fajne i praktyczne, że działa podobnie do Ubuntu Linux. Jak większość z was wie, Kali Linux stał się ulubioną dystrybucją: ludzi z gimnazjum, "hackjerów" ;-), white hackerów, testerów penetracyjnych,  red teamów i wielu innych profesji skoncentrowanych wokół bezpieczeństwa systemów i aplikacji w IT, ale też amatorów różnych rozrób i problematycznych sytuacji. 

To jest temat na odrębny wątek, jak ludzie - w tym dzieci - mogą uszkodzić coś lub wpaść w kłopoty, kiedy "przyhaczą" coś na Kali Linux. 

Musimy zdawać sobie sprawę, że z natury zawód związany z tzw. SECURITY w IT to ludzie często na tyle zaawansowani technicznie, że żarty to nie jest ich główne zajęcie a niesamowite analizy włamań/malware/trojanów/wirusów/skany sieci/diagnozy powłamaniowe/predykcje ryzyk/odkrywanie ukrytych otwartych portów i usług/szybkie i trafne decyzje. Szacunek! 

Natomiast, kiedy czasami czytam i słucham różnych opowieści, jak przysłowiowy Janusz "przyhaczył" dzięki Kali coś grubego ... ja tego nie popieram i tym wpisem nie zachęcam do takich działań. Chiałem to napisać, aby z pełną świadomością oznajmić, że jeśli używasz Kali Linux, to nie jest tak, że jesteś bezpieczny i niewidzialny. Po prostu masz w rękach narzędzia, którymi możesz też zrobić z wirtualnego problemu namacalny realny incydent. Tego nie popieram i ten wpis jest nie jest instrukcją użycia narzędzi a subiektywną opinią, którą przedstawiam w celach edukacyjnych. Bawicie się Kali Linux na własne ryzyko, wszelkie poniesione szkody, komplikacje, inne zdarzenia są wyłącznie Waszą odpowiedzialną decyzją. A za dzieci odpowiadają rodzice w większości cywilizowanych krajów.  

Jak pewnie większość z Was zdaje sobie sprawę, w Kali Linux mamy wielki potencjał do testów bezpieczeństwa. Tzn. są tam fantastycznie skatalogowane zestawy narzędzi do różnych typów działań w obszarze tzw. bezpieczeństwa IT. Oto lista kategorii, w których w Kali Linux możemy dotrzeć do profesjonalnych narzędzi pentesterskich tzn. otwartego oprogramowania, wolnego od licencji, dzięki któremu możemy wyszukiwać różne informacje, dane, błędy, naruszenia i wady systemów operacyjnych, protokołów oraz aplikacji.

Do czego ja używałem Kali Linux - wyłącznie do rozwiązywania na nim zadań w ramach tzw. konkursów CTF, czyli "capture the flag". Są to odbywające się weekendowo wyzwania dla zaawansowanych użytkowników komputerów, w których zagadki zaczynają się od banalnych binarnych trickach, poprzez rekonesans na gotowych wirtualnych maszynach, analizę obrazów i ukrytych w nich szyfrów, zagadnienia sieciowe, XSS, SQL Incection, wady serwerwów www, autorskie dekodowanie kart perforowanych i wiele na prawdę ambitnych zagadek  a kończą na odnajdywaniu przy pomocy dekompilacji kodu asemblera nieznanego procesora jakich instrukcji, które zawieszą kod programu :-)

Tak, około roku zabawy na takich konkursach potrafi wzmocnić umiejętności rozwiązywania "różnych" incydentów w IT. Spokojnie polecam dołączenie do zespołu lub indywidualne startowanie w konkursach CTF - co ciekawe, odkrywając flagę za każdym razem uczymy się czegoś nowego o IT. Tak, to zajęcie uczy tzw. szacunku do problemów zawodowych oraz postrzegania tego, co jest na prawdę ważne, wnikliwości i tego jak szybko jesteśmy w stanie nauczyć się np: nowego języka programowania w kilka godzin, aby móc zdebugować w nim quasi-program. 

Kali Linux to nie tyle system operacyjny do CTFów, ale przede wszystkich zwykły Linuxowy OS do codziennego użytku dla ludzi z branży IT. Chciałem w dalszej części skoncentrować się na jednym ciekawym przypadku, który rozgrzebałem technicznie i stał się na tyle podejrzany dla mnie w dystrybucji Kali Linux w odniesieniu do Ubuntu Linux, że zechciałem o nim wspomnieć.

Jakiś czas temu zrobiłem ciekawy switch i mając Ubuntu 20.04 LTS wykonałem niniejsze polecenia, które zamieniły mojego Ubuntu w Kali - to bardzo fajne tricki możliwe w Linuxowym świecie :-) 

Tak na marginesie: jak wiemy Windows zamieni się niebawem w Lindowsa i możliwe, że też jednym pstryczkiem, ale za tym stoi wielka maszyneria biznesowa, aby nie utrzymywać swojego dość wadliwego jądra. Tak mam na myśli M$, który porzuciłem ~20 lat temu w domu i pracy, co bardzo otworzyło mi oczy i nie to była dość trafiona decyzja. Tak, wiem Azure to już w większości Linux od wielu lat i M$ też wie jak kompilować jądro i dopisują swoje rzeczy do kernela ... ale ta firma nie robi nic bezinteresownie, bo każda firma z założenia zarabia. Nawet wtedy, kiedy musi porzucić swój plan budowy jądra systemu operacyjnego a bierze Linux Kernel z Open Source, pisząc wszem i wobec, że "my też to stworzyliśmy". I mają prawo tak rzec, bo commitują swoje zmiany do kernela LInuxa, ale jak wiemy, w tych czasach marketing może robić z takimi działaniami cuda.

Powracając do myśli przewodniej, jestem zadowolony z Kali Linux jako desktopowego Linuxa i polubiłem ten zestaw narzędzi do CTFów, którego używam czasami do rozwiązywania problem, które zdarzają się przy produkcji oprogramowania. Jedna sprawa mnie zmartwiła w wersji Kali 2020.3:

$ lsb_release -a

No LSB modules are available.

Distributor ID: Kali

Description: Kali GNU/Linux Rolling

Release: 2020.3

Codename: kali-rolling

Otóż po jakimś czasie - odtwarzalne na trzech różnych maszynach - pojawiły się nierozwiązywalne metodą "--fix-*" z apt-get konflikty, przy poleceniu standardowym aktualizacji paczek systemowych:

sudo apt-get upgrade

Wygląda to mniej więcej tak:

$ sudo apt-get upgrade 

Czytanie list pakietów... Gotowe

Budowanie drzewa zależności       

Odczyt informacji o stanie... Gotowe

Należy uruchomić "apt --fix-broken install", aby je naprawić.

Następujące pakiety mają niespełnione zależności:

 gnome-control-center : Wymaga: gnome-control-center-data (>= 1:3.36.4-1) ale 1:3.36.4-0ubuntu1 jest zainstalowany

 gnustep-base-runtime : Wymaga: libobjc4 (>= 4.2.1) ale nie jest zainstalowany

 libgnustep-base1.27 : Wymaga: libobjc4 (>= 4.6) ale nie jest zainstalowany

E: Niespełnione zależności. Proszę spróbować wykonać "apt --fix-broken install" bez pakietów (lub podać rozwiązanie).

i co najgorsze zachowuje się bardzo słabo w naprawie i skutki są dość słabe. Po kolei:

- wykonanie w/w apt'a z zalecanym "--fix-broken" powoduje, że nie może wykonać się do końca poprawnie, brakuje mu obrazka

$ sudo apt --fix-broken install

Czytanie list pakietów... Gotowe

Budowanie drzewa zależności       

Odczyt informacji o stanie... Gotowe

Naprawianie zależności... Gotowe

Następujące pakiety zostały zainstalowane automatycznie i nie są już więcej wymagane:

  cryptsetup-nuke-password efibootmgr finalrd fonts-wine gnome-control-center-faces gparted-common

  grub-efi-amd64-bin humanity-icon-theme kpeople-vcard libboost-filesystem1.67.0 libboost-system1.67.0

  libboost-thread1.67.0 libcapi20-3 libdb5.3:i386 libebml4v5 libfaudio0 libfprint-2-tod1

  libgsoap-2.8.91 libgtkmm-2.4-1v5 libgtkspell0 libhogweed5 libigdgmm11 libkaccounts1

  libkf5contacts-data libkf5contacts5 libkyotocabinet16v5 liblz1 libmatroska6v5 libmng2 libnettle7

  libnfsidmap2 libnumbertext-1.0-0 libnumbertext-data libopenshot-audio6 libopenshot16 libopenvdb7.0

  libpcre2-8-0:i386 libplacebo7 libpoppler82 libprotobuf-lite22 libprotobuf22 libqrcodegencpp1

  libqxp-0.0-0 libsrt1 libstaroffice-0.0-0 libstb0 libtokyocabinet9 libtsk13 libvkd3d1 libvolume-key1

  libwagon-http-shaded-java libwhisker2-perl libwine libzmf-0.0-0 node-normalize.css

  python-backports.functools-lru-cache python-bs4 python-html5lib python-lxml python-numpy

  python-soupsieve python-webencodings python3-ecdsa python3-entrypoints python3-pycryptodome rpcbind

  shim ssh-import-id ubuntu-mono wine64

Aby je usunąć należy użyć "sudo apt autoremove".

The following additional packages will be installed:

  gnome-control-center-data guile-2.2-libs inkscape libgc1 libgdl-3-5 libgdl-3-common libgsl25

  libgslcblas0 libgtkspell3-3-0 libmailutils7 libmariadb3 libobjc4 mailutils mailutils-common

  mariadb-common

Sugerowane pakiety:

  inkscape-tutorials libsvg-perl libxml-xql-perl pstoedit python3-uniconvertor gsl-ref-psdoc

  | gsl-doc-pdf | gsl-doc-info | gsl-ref-html mailutils-mh mailutils-doc

Polecane pakiety:

  python3-scour

Następujące pakiety zostaną USUNIĘTE:

  libgc1c2 libgsl23 libmailutils6

Zostaną zainstalowane następujące NOWE pakiety:

  libgc1 libgdl-3-5 libgdl-3-common libgsl25 libgtkspell3-3-0 libmailutils7 libmariadb3 libobjc4

  mariadb-common

Następujące pakiety zostaną zaktualizowane:

  gnome-control-center-data guile-2.2-libs inkscape libgslcblas0 mailutils mailutils-common

6 aktualizowanych, 9 nowo instalowanych, 3 usuwanych i 763 nieaktualizowanych.

841 nie w pełni zainstalowanych lub usuniętych.

Konieczne pobranie 0 B/28,4 MB archiwów.

Po tej operacji zostanie dodatkowo użyte 25,4 MB miejsca na dysku.

Kontynuować? [T/n] T

Konfigurowanie pakietu libgcc-s1:amd64 (10.2.0-9) ...

Konfigurowanie pakietu libseccomp2:amd64 (2.4.4-1) ...

(Odczytywanie bazy danych ... 647544 pliki i katalogi obecnie zainstalowane.)

Przygotowywanie do rozpakowania pakietu .../gnome-control-center-data_1%3a3.36.4-1_all.deb ...

Rozpakowywanie pakietu gnome-control-center-data (1:3.36.4-1) nad (1:3.36.4-0ubuntu1) ...

dpkg: błąd przetwarzania archiwum /var/cache/apt/archives/gnome-control-center-data_1%3a3.36.4-1_all.deb 

(--unpack):

 próba nadpisania "/usr/share/pixmaps/faces/bicycle.jpg", który istnieje także w pakiecie gnome-control-center-data

enter-faces 1:3.36.4-0ubuntu1

dpkg-deb: błąd: podproces wklej został zabity sygnałem (Przerwany potok)

- uruchamia się w nieskończoność appport raportujący te błędy, przez co syslog osiąga GB wielkości i zapycha dysk, dalej jest już wiadomo bardzo trudno pracować na systemie z 0 miejsca na partycji systemowej !

- problem jest słabo opisany w sieci i jedyny motyw na odzyskanie miejsca na dysku to usunięcie z /var/crash/ plików !!!

$ ll /var/crash/gnome-control-center-data.0.crash 

-rw------- 1 root whoopsie 386566 paź  9 17:42 /var/crash/gnome-control-center-data.0.crash

$ sudo rm /var/crash/gnome-control-center-data.0.crash 

Uważam, że to jest dość ważny aspekt, aby takie narzędzie jak apt działało poprawnie i tutaj w Kali Linux spotkałem się z mega blokadą, nie pomaga dist-upgrade, nie pomaga szukanie dziury w całym przy pomocy strace, kończy się tym, co kojarzę z RedHat sprzed 20 lat, tzn. chcesz mieć spełnione zależności, to sobie je spełnij sam :-) Rozumiem, że osoba która jest wydawca pakietu mogłaby mnie wspomóc w temacie, o ile to problem z pakietem - nie wydaje mi się, bo próbowałem też dpkg i efekt jest identyczny.

Inny drobny brak w distro Kali Linux - tak mogę to określić - to niedziałająca domyślna obsługa filesystemów takich jak vboxfs (chciałbym sobie na vagrancie i virtualbox zrobić testy), czy LUKS (chciałbym odczytywać szyfrowane wolumeny). Rozumiem, że to sobie mogę doinstalować, ale niespodzianką było dla mnie włożenie pendrive z zaszyfrowanymi danymi przy pomocy LUKS w Kali Linux nie skutkuje automontowaniem i pytaniem o hasło. W Ubuntu Linux takie rozwiązania działają z paczki. Tak, wiem Kali Linux nie do tego celu był stworzony i nie chcę się o to spierać :-) Nadmieniam tylko, że nie zawsze potrzebujemy specjalnej dystrybucji, która rozwiązuje nasze potrzeby. Twierdzę, że czysta (z linii LTS) wersja Ubuntu jest na tyle wytestowana przez userów i naprawiana na bieżąco przez devów, że o wiele prościej rozwiązuje się takie codzienne zagadki jak te z aptem opisane powyżej w Kali Linux.

Reasumując - polecam pomimo opisanych incydentów Kali Linux zaawansowanym użytkownikom i profesjonalistom, zniechęcam amatorów i noobów :-)

Ubuntu Linux po kilkunastu latach trenowania/testowania/używania/pracy/zabawy/odkrywania przedstawił mi się w wersji 20.04 LTS jako system dość dobrze ustabilizowany w codziennym użytkowaniu do pracy i w zastosowaniach  domowych. Polecam Ubuntu Linux, bo jeśli z Windows znane są Wam nadmiarowe programy ochronne, które musicie tam posiadać, bo trojan i wirus czeka, aby się zemścić - to w Ubuntu Linux firewalle, snorty, auditlogi są dość uproszczone i nie wyżerają 30% CPUs a pozwalają na bezpieczną pracę i zabawę również na desktopie.

Kontenerowe systemy operacyjne - porównanie (Container OS)

Pamiętam, jak kiedyś stawiałem FreeBSD na maszynie i486 DX jako bramka do neostrady z 1 CPU. To była niezła przygoda, bo maszynka ta działała kilka lat bezawaryjnie, system na niej również. Tak, to był czysty przypadek :-), bo w serwerowniach normalnie nie zdarzają się takie "cuda" :-) Ponadto instalacja na każdej maszynie oddzielnie to byłaby zwykła robota głupiego. Minęło od opisywanego wyżej dzieła >18 lat i doczekaliśmy się dojrzałej konteneryzacji, całe szczęście dla utrzymania rozwiązań w IT. 

Kontenery

Kontenery szybko stały się niezbędną częścią nowoczesnych centrów danych. Kontenery można budować na dowolnej bazie z wielu podstaw systemu operacyjnego. 

W jaki sposób więc wybrać kontener?

W kontekście wdrażania kontenera kierownicy ds. rozwoju systemów muszą wiedzieć, które cechy i funkcje systemu operacyjnego są krytyczne dla wydawanych aplikacji i czy istnieją inne czynniki - takie jak łatwość zarządzania i elastyczność konfiguracji - które skłoniłyby organizację do wybrania jednego systemu operacyjnego zamiast wielu. Oczywiście łatwo utrzymuje się stan wiedzy inżynierów, jak i stack technologiczny jeśli systemy operacyjne w nim są liczone w kilka a nie kilkanaście.

Jak wypada porównanie różnych systemów operacyjnych pod względem funkcji i podstawowych funkcji? Jak te różnice wpływają na sposób, w jaki będą obsługiwać aplikacje? Oto podstawowe pytania, którym przyjrzymy się na reprezentatywnym przykładzie trzech szerokich typów systemów operacyjnych:

• Tradycyjne, w pełni funkcjonalne systemy operacyjne
• Minimalne systemy operacyjne ogólnego przeznaczenia
• Systemy operacyjne zbudowane specjalnie dla kontenerów

W każdej kategorii wybrałem dwa przykłady, które będą reprezentować wszystkie dystrybucje i produkty w grupie.

Po przeczytaniu tego artykułu powinniście mieć znacznie wyraźniejszy obraz różnic między typami systemów operacyjnych. Zakładam, że poprawi się zrozumienie, dlaczego programiści mogą wybrać jeden kontenerowy system operacyjny zamiast innego dla aplikacji kontenerowych i dlaczego mogą wspierać te wybory lub kwestionować je.

W pełni funkcjonalne systemy operacyjne

Co oznacza „w pełni funkcjonalny system operacyjny”? I dlaczego w kontekście wdrożenia kontenera wszystkie funkcje miałyby znaczenie? W tej sekcji przyjrzymy się, dlaczego ten sam system operacyjny, który może być używany w tradycyjnym wdrożeniu serwera, może być najlepszą odpowiedzią na platformę kontenerową.

Przede wszystkim trzeba wiedzieć, że te systemy operacyjne potrafią to wszystko. Jeśli aplikacja potrzebuje funkcji, istnieje prawdopodobieństwo, że któryś z nich ją będzie miała. Elastyczność ma jednak swoją cenę: te systemy operacyjne wymagają od systemu najwięcej, jeśli chodzi o pamięć masową, pamięć RAM i zasoby procesora. Funkcje te zwiększają również powierzchnię ataku systemu operacyjnego, zapewniając potencjalnym napastnikom znacznie więcej zakamarków, w których mogą wykonywać swoją pracę. Są to koszty, które należy ponieść, jeśli te funkcje są potrzebne aplikacjom. Czasami cena staje się bardzo wysoka, jeśli wymagana jest tylko niewielka liczba funkcji.

Te w pełni funkcjonalne systemy operacyjne mogą być najbardziej odpowiednie w środowisku, w którym wiele różnych aplikacji jest wdrażanych w kontenerach na jednej instancji systemu operacyjnego. W takich przypadkach szeroki zakres funkcji może być najbardziej ekonomicznym sposobem obsługi floty aplikacji.

Ubuntu

Ubuntu stał się domyślnym systemem operacyjnym na serwerze, w chmurze, a nawet na komputerze stacjonarnym dla wielu organizacji. Dobrze wspierany przez firmę Canonical, Ubuntu jest dostępny w wielu różnych formatach do pobrania z pakietami narzędzi, powłokami, funkcjami i zestawami funkcji niezbędnymi do wdrożeń obsługujących IoT, kontenery, serwery lub chmury.

Ubuntu przeniosło się w przestrzeń zajmowaną niegdyś wyłącznie przez Red Hat Linux: jest to bezpieczny wybór dla wdrożeń w przedsiębiorstwach, z obsługą i reputacją, które sprawiają, że wybór jest uznawany przez większość komitetów wykonawczych za „rozsądny”. Należy jednak pamiętać, że rozsądek nie przekłada się na najlepszy w każdych okolicznościach - to wciąż duży, pełny system operacyjny z wieloma zbędnymi preinstalowalnymi pakietami.

CentOS

Tam, gdzie Ubuntu stał się najbardziej zaawansowanym wyborem dla przedsiębiorstw spośród w pełni funkcjonalnych systemów operacyjnych, CentOS jest otwartą, kierowaną przez społeczność wersją innego „bezpiecznego” wyboru - Red Hata. CentOS kładzie nacisk na wsparcie społeczności i wkład w rozszerzający się zestaw funkcji i funkcji w systemie operacyjnym, jednocześnie budując stabilność swojego fundamentu Red Hat. Nie oznacza to, że CentOS nie jest używany przez duże organizacje - znajdziesz go na serwerach w laboratoriach krajowych i u głównych dostawców chmury. Ale Ubuntu ma tendencję do oferowania szybszych aktualizacji niż CentOS, który zawiera pakiety, które wydają się być starsze, ale bardzo dobrze przetestowane.

Minimalne systemy operacyjne

Kontenery powstały jako zbiory minimalnych funkcji zebranych razem w kompletną aplikację. Jakich funkcji w „pełnych” dystrybucjach Linuksa brakuje w tych minimalnych systemach operacyjnych - i czy ma to znaczenie dla Twojej aplikacji? Z drugiej strony, jakie są zalety opierania aplikacji na pakietach zredukowanych do absolutnego minimum?

Najlepsze odpowiedzi znajdują się na przecięciu wymagań aplikacji i funkcjonalności systemu operacyjnego. Bez przemyślanego przygotowania można utracić korzyści związane z rozmiarem i złożonością, których oczekuje się od minimalnych systemów operacyjnych, poprzez dodanie indywidualnych narzędzi, funkcji i apletów wymaganych dla określonych aplikacji.

W tej sekcji omówiono dwie dystrybucje, BusyBox i Alpine Linux, oraz korzyści, jakie mogą one przynieść w odpowiednich okolicznościach. Te dwa systemy operacyjne są ze sobą powiązane - Alpine jest oparty na BusyBox - ale istnieją kluczowe różnice, które mogą skłonić zespół do wybrania jednego z nich dla poszczególnych wdrożeń. Różnice te dotyczą nie tylko określonych zdolności, ale także społeczności wsparcia i ekosystemu każdego z nich.

BusyBox

BusyBox jest stosowany powszechnie we wdrożeniach kontenerów, ponieważ nie został zaprojektowany z myślą o kontenerach. Nazwany przez twórców jako „szwajcarski scyzoryk wbudowanego systemu Linux”, BusyBox miał być pojedynczym plikiem wykonywalnym o niewielkich rozmiarach, który zawierał wszystkie funkcje wymagane przez większość wbudowanych aplikacji. To zmusiło go do przyjęcia podejścia zbliżonego do kontenera do wdrożenia, zanim kontenery powstały.

BusyBox można wdrożyć przy użyciu Linuksa lub innych systemów operacyjnych POSIX jako podstawy. Łączy się z wieloma popularnymi narzędziami Linuksa w uproszczonej formie. Rezultatem jest kompaktowy, jednoplikowy plik wykonywalny, który zawiera wiele funkcji „pełnej” dystrybucji Linuksa, chociaż wiele opcji funkcjonalnych dostępnych w tych pełnych wersjach zostało pominiętych w BusyBox w imię zaoszczędzonego miejsca.

Alpine Linux

Jak wspomniano, Alpine Linux jest oparty na BusyBox, ale opiera się na wcześniejszej dystrybucji zarówno pod względem celu, jak i szczegółów. Tam, gdzie BusyBox jest zaprojektowany z niewielkimi rozmiarami, jako jedyny cel, Alpine Linux używa wzmocnionego jądra, aby dodać bezpieczeństwo do kompaktowych, prostych celów swojego poprzednika.

Alpine Linux ułatwia również programistom dodawanie funkcji. Opierając swoją dystrybucję na BusyBox i bibliotece musl, Alpine Linux daje programistom przewagę nad dodawaniem funkcji i budowaniem kompaktowych pakietów dystrybucyjnych. Jest to minimalny system operacyjny zdolny do tworzenia bardzo małych obrazów kontenerów do wdrożenia, a wzmocnione jądro sprawia, że ​​nadaje się on do zastosowań produkcyjnych, a także programistycznych.

Kontenerowe systemy operacyjne

System operacyjny kontenera jest dostarczany po wyjęciu z pudełka z wbudowaną automatyzacją i orkiestracją kontenerów. Są one zaprojektowane i zbudowane jako systemy operacyjne „hosta” - system operacyjny, na którym są hostowane systemy operacyjne kontenerów, takie jak Alpine i BusyBox. Dlaczego więc nie są one automatycznym wyborem dla każdego wdrożenia kontenera?

Kontenerowe systemy operacyjne wyróżniają się tym, że nie są po prostu oprogramowaniem obsługującym kontenery, ale oprogramowaniem wdrażanym przy użyciu kontenerów. Architektura oparta na „kontenerach do samego końca” może zapewnić poziom dostosowania do wdrożenia, który jest znacznie bardziej złożony niż tradycyjne wdrożenie systemu operacyjnego. Z drugiej strony, dla organizacji na wczesnym etapie przechodzenia na kontenery lub we wdrożeniach aplikacji, które przekraczają granice architektur kontenerów, architektura „całkowicie kontenerowa” może być pomostem za daleko, jeśli chodzi o komfort zarządzania.

Rancher OS i Container Linux to dwie główne opcje dla osób poszukujących kontenerowych systemów operacyjnych. Zrozumienie, co każdy system wnosi pozytywnego, pomoże programistom zrozumieć zalety, które posiadają, oraz sytuacje, w których są jedynym logicznym wyborem.

RancherOS

Każdy proces w RancherOS jest uruchamiany w oddzielnym kontenerze zarządzanym przez Docker. Optymalizacja i zależność od Dockera pozwala RancherOS być bardzo małym z bardzo krótkim czasem rozruchu. Oprócz podstawowych korzyści związanych z wydajnością istnieją jednak czynniki związane z wdrażaniem, które mogą przemawiać na korzyść RancherOS.

Usługi systemowe RancherOS są definiowane i konfigurowane przez Docker Compose. Ta zależność oznacza, że ​​tylko usługi potrzebne dla aplikacji są ładowane i wdrażane, co dodatkowo przyspiesza i upraszcza wdrażanie. Wdrażanie jest ponownie uproszczone dzięki integracji z cloud-init, która umożliwia zautomatyzowaną konfigurację i wdrażanie na szeroką skalę i z dużą szybkością.

CoreOS Container Linux

CoreOS Container Linux jest przeznaczony do wdrażania kontenerów w skali chmurowej. Teraz, jako część Red Hat, Container Linux jest zoptymalizowany pod kątem wdrożeń klastrów w publicznych lub prywatnych infrastrukturach chmurowych.

Container Linux jest wdrażany z jądrem i niezbędnymi narzędziami w jednym pliku wykonywalnym, a wszystkie inne narzędzia i funkcje są wdrażane w kontenerach.

Container Linux jest od dawna w powszechnym użyciu, a wsparcie jest dostępne do wdrażania w większości chmur publicznych. Przejęcie go przez firmę Red Hat nie spowolniło jego wdrażania i sprawiło, że niektóre organizacje są bardziej zadowolone z pomysłu wdrożenia na platformie. Container Linux jest rozpowszechniany z licencją typu open source i ma aktywną społeczność programistów.

Podsumowanie

Biorąc pod uwagę trzy szerokie typy systemów operacyjnych dostępnych do wdrażania kontenerów, który system operacyjny kontenera powinien wybrać zespół programistów? Jeśli jedynym celem konkretnego serwera jest hosting kontenerów, to systemy operacyjne kontenerów, takie jak RancherOS i Container Linux, mają wiele do polecania. Ich automatyzacja, szybkość wdrażania i spójna architektura kontenerów sprawiają, że są one logicznym wyborem dla tych, którzy chcą zoptymalizować środowisko hostingu kontenerów. Po przejściu o jeden poziom w górę do systemów operacyjnych dla samych kontenerów, wybory stają się bardziej zniuansowane.

Kiedy bierzemy pod uwagę zarówno aplikacje kontenerowe, jak i inne niż kontenerowe, nie ma wątpliwości, że tradycyjne wdrożenia Linuksa, takie jak Ubuntu i CentOS, mogą być używane jako platforma kontenerowa. Ich architektura oraz lista narzędzi i funkcji spowodują, że będą wolniej uruchamiać się i będą wymagały więcej zasobów systemowych, ale mogą wykonać zadanie, jeśli szybkość rozruchu i minimalne zużycie zasobów nie są kluczowymi kwestiami.

Pośrodku znajdują się minimalne systemy operacyjne, takie jak BusyBox i Alpine Linux. Mogą to być same w sobie solidne opcje kontenerów, ale naprawdę mogą się przydać, jeśli istnieją ograniczone zasoby aplikacje niebędące kontenerami, takie jak te dla IoT, które również należy uznać za część całego środowiska aplikacji.

Zrozumienie różnicy między możliwościami i ograniczeniami różnych typów systemów operacyjnych ma kluczowe znaczenie dla każdej produktywnej dyskusji na temat platformy systemu operacyjnego. W przypadku nowoczesnych systemów operacyjnych prawdziwa rozmowa nie powinna wtedy dotyczyć tego, który system operacyjny będzie działał, ale który będzie wykonywał pracę najbardziej wydajnie i efektywnie.

Internet of Things, Hardware & Robotics - Poznań #1 - moja inicjatywa meetupu

Od wielu miesięcy się zastanawiałem, jak mógłbym wesprzeć świat Internetu Rzeczy w rzeczy samej, w naszej Rzeczypospolitej. Każda myśl, prezentacja i wystąpienie zostały skrupulatnie przemyślane i wdrożona w życie w ciągu całego 2018 roku. Na postawie tej sprawnej edukacji odważyłem się w ostatnim kwatale 2018 roku otworzyć meetup dla sympatyków Internet of Things, Hardware & Robotics. Ten wpis jest poświęcony pierwszemu wydarzeniu, które miało miejsce w Poznaniu w siedzibie Allegro i było inauguracją wydarzenia mojego pomysłu.

Każdy z Was pewnie kiedyś chciał zrobić coś dla ludzi, otóż i ja również pomyślałem, że coś takiego będzie świetnym uwieńczeniem ok. 20-letniej kariery zawodowej wokół różnych poznanych przeze mnie branż: automatyki przemysłowej, grafiki komputerowe, projektowania układów elektronicznych i systemów wbudowanych, systemów rozproszonych, zarządzania projektami i tworzeniem niebanalnego programowania, wspierania e-commerce w PL, zwinności i pewnie paru innych.

Wymyśliłem, że skupienie się na jednej dziedzinie może nie być sprawiedliwe, bo ludzie interesujący się IoT interesują się tak jak ja programowaniem, SBC - systemami wbudowanymi, automatyką, architekturami, protokołami. Spojrzałem przez ten pryzmat i wyszło, że meetup, który chcę założyć powien posiadać szerszy kontekst tzn.

Internet of Things, Hardware & Robotics

Naturalnie wypadło na meetup.com jako stronę hostującą wydarzenia i co ciekawe po 14 dniach było już 130 osób zapisanych i lubiących tą inicjatywę. Oczywiście liczby stały się motywatorem, aby tą sporą jak dla mnie społeczność spytać w ankiecie, czego oczekują na początek. Wyniki ankiety jednoznacznie wskazały, że nie należy rozdzielać tematu hardware, software oraz IoT.

Jakby z automatu zaczęli do mnie pisać ludzie z różnych branż z kraju i nie tylko, chcąc zaoferować swoje wystąpienie na meetupie. To spowodowało kolejną falę pozytywnego wydźwięku. Kiedy powiedziałem o tym pomyśle kilku znajomym (prelegenci) z branży oraz wspierającej mnie od strony technicznej (salka, rezerwacja, pizza, pokrycie kosztów) koleżance Oli z Allegro, wówczas wszystko się zaczęło urzeczywistniać i pojawił się na horyzoncie termin pierwszego spotkania :-)

Poprosiłem kolegów o pomoc w przygotowaniu swoich prelekcji w ulubionych tematach i taki oto kształt przybrała wersja pierwsza meetupu, który był oklaskany nieraz podczas tego dnia sukcesem.

Tematy jakie poruszyliśmy i mój krótki komentarz do nich (kolejność zgodna z agendą):

Souly – Smart Building – system IoT w praktyce

Marcin Dryjański wprowadził nas w praktyczny system Internetu Rzeczy o nazwie Souly, który tworzony jest w firmie Grandmetric w Poznaniu. Co ciekawego, chłopaki pokazali swoje rozwiązania techniczne, podzielili się wnioskami oraz dość szczegółowymi aspektami projektowymi. Nie zabrakło też wielu porad, jakie problemy są przy tej skali instalacji oraz implementacji (ok. 500 punktów/bramek IoT). Szanuję bardzo pracę chłopaków, gdyż zaskoczyli mnie już na współtworzonym razem meetupie Network & Wireless Meetup, kiedy mówili o poprzedniej wersji swojego produktu. W tej prezentacji zauważyłem naniesione poprawki, które zdążyli zwinnie wdrożyć do systemu na produkcje. Klienci zapewne są z nich dumni i dzięki wielkie za pokazanie, że w Pyrlandii (dla niewtajemniczonych: miasta Poznania) robi się na wysokim poziomie - pierwsze na skalę kraju - produkty Internet of Things.

Oto z jaką uwagą uczestnicy patrzyli na slajdy Marcina:

FreeRTOS - podstawy

Tymoteusz Sielach wprowadził nas w podstawy systemu czasu rzeczywistego FreeRTOS. Uwagi i trafne spostrzeżenia, jakie zostały poruszone wielu osobom zwróciły uwagę, że można coś zrobić sprawniej w systemach wbudowanych zamiast klepać w Arduino. Zdecydowanie kolega podkreślił, że można zyskać wchodząć w FreeRTOS oraz napisać solidny modularny kod aplikacji.

Dla osób lubujących się w Arduino na pewno była to doza spjrzenia w tą bardziej uprzemysłowioną stronę. Tak wyglądał ten temat prezentowany przez Tymka:

Kochanie, po co nam w domu szafa serwerowa (v1.1)

Julian Szulc zaprosił nas do wnętrza swojej szafy serwerowej oraz autorskich adaptacji rozwiązań IoT w domu. Bardzo fajny projekt, w którym Julian buduje serwerownie od podstaw w zakątku domowym. Nie tyle buduje, co zaprojektował dom pod taką okoliczność, aby szafka serwerowa miała swoją wnękę, nadmiar ciepła z grzejących się urządzeń był odpowiednio odprowadzany i rynny na kabelki stanowiły miejsce zabaw dla domowych kotów :-)

Super przekaz i wartościowa porcja wiedzy, jak można się bawić Internetem Rzeczy, przy okazji również używać go w potrzebach domowych t.j. automatyczne podgrzewanie mleka dla dziecka, lokalizowania partnerki, prywatny magazyn dla wszystkich danych, wizualne statystki i metryki.

Wow, jest sporo technicznego mięsa w opowieści Juliana. Z rozmów po meetupie wiem, że wielkim zainteresowaniem ludzi cieszyły się gotowe receptury Juliana na postawienie całego swojego domowego stacka automatyzacji ioT w Dockerach. Oto wizerunek kolegi Juliana:

Przezroczysty telefon komórkowy

Mateusz Piasecki to kolega, którego poznałem na sobotnim warsztacie z Blockchain i po kilku chwilach dyskusji o naszych zainteresowaniach wyraziłem brak meetupu w naszej dziedzinie IoT w Poznaniu. Mateusz przekonał mnie, że na pewno znajdą się chętni, więc po prostu założyłem meetup i tak się formalnie historia zaczęła.

Wracając do ciekawej prezentacji, była ona ukazaniem w tajemniczy i pomysłowy sposób możliwości jakie dają nam przezroczyste wyświetlacze. Mateusz przedstawił tą gałąź przemysłu jako coś, co niebawem ziści wszelkie nadzieje fanatyków sci-fi i będziemy mogli nosić w kieszeni, albo na ręce coś co jest niby bransoletką a niby telefonem, bo tego nie widać :-)

Super, że udało się wypożyczyć jeden prawdziwy egzemplarz takiego wyświetlacza i pokazać nam jak to działa dzisiaj. Proszę zobaczcie, jakie tłumy przyciągnął ten prelegent do urządzenia:

Zbudujmy robota z ROS - RoboTICK.

Marcin Bielak - tak, to moja prywatna inicjatywa o nazwie RoboTICK, do której zapraszam żądnych wiedzy z dziedzin: IoT, hardware, software, cloud, Machine Learning i protokołów sieciowych. Co mam na myśli: otóż zaprezentowałem szkielet prototypu oraz wizualizację robota mobilnego, trójkołowego i chcę wspólnie z poznanymi na meetupie ludźmi go wykonać. Tak wygląda wizualizacja mojego autorstwa (wykonana w programie Open Source Blender): 

Nic nadzwyczajnego pewnie pomyślicie, ale przy moich założeniach zduplikowanego komputera pokładowego, autonomiczności i wielu torów zasilania  - jak w serwerowniach :-) - to będzie nie lada wyzwanie. Zaprezentowałem te koncepty podczas prezentacji, pokazałem przy tym inne kierunki typu: IoT Blockchain, Swarm Robots, Reinforcement Learning (Machine Learning) w których będę rozwijał ten projekt.

Zachęcam Was do udziału w projekcie i gwarantuję wspólną naukę, zabawę oraz poznawanie nowości z lubianej tematyki IoT, Hardware & Robotics. Oto moja skromna osoba przed widownią:

Prezentacja w całości: 

Let's build a robot with ROS - Internet of Things, Hardware & Robotics meetup #1 Poznań from Marcin Bielak

Link do repozytorium projektu (hardware, software, prototypes):

https://github.com/bieli/RoboTICK

Ogólnie chciałem tym wystąpieniem poznać:

• ludzi, którzy są chętni do niezobowiązującej pracy nad różnymi ideami wokół IoT
• opinie ludzi o tym co chcę zrobić
• możliwości tworzenia tej skali projektów, które jak się okazało otworzyły się szerzej tzn. otrzymałem propozycję wystąpienia na uczelni przed setkami studentów chętnymi do realizacji takich pomysłów oraz opcję współpracy we współtworzeniu łazików marsjańskich na konkursy ERC
• alternatywne ścieżki realizacji projektu

Bardzo pozytywny feedback otrzymałem, przez co nadal rozważam, jak pogodzić czas prywatny, życie zawodowe i projekty, aby sprostać nowym wyzwaniom. Coś pewnie się z tego "urodzi", ale zawsze daję sobie czas na zracjonalizowanie możliwości, bo jak wiemy jest ich tak dużo w tych czasach, że warto skupić się na najważniejszych dla siebie.

Naturalnie czas na networking nadszedł dość szybko i wszyscy dzięki wsparciu finansowemu mojego pracodawcy Allegro.pl - któremu dziękuję - otrzymaliśmy na zakończenie megabajty kalorii w postaci ciepłej pizzy. A było w co zęby wbijać zapewniam Was.

Ilość pytań po każdym wykładzie była piękna, musiałem nawet użyć mechanizmu "tykadła" tzn. z powodów czasowych poprosić o przeniesienie dyskusji na później. Oczywiście nie obraźcie się, inni też chcieli coś od siebie przedstawić - mam dzięki temu pewien pomysł na różne dyskusję w kolejnych edycjach meetupów. Niewiarygodnie wiele tematów, które zostały poruszone w trakcie dyskusji przybliża mnie do myśli, że jest potrzeba na takie miejsce jak mój meetup wiele pytań siedzi gdzieś tam w ludziach z branży IT a takie spotkania pozwalają się im uwolnić. Naturalnie nie zawsze dostajemy poprawną odpowiedź, ale mamy gdzie zapytać, skomentować swoje wątpliwości i to się tutaj znacząco liczy. Cenimy sobie podczas meetupu szczere chęci dzielenia się wiedzą, bo to są zasady otwartego na wiedzę społeczeństwa, które wspieramy.

Dziękuję bardzo wszystkim zaangażowanym:

• prelegentom
• uczestnikom
• Aleksandrze Dondziak, za wsparcie mentorskie i organizację techniczną wydarzenia (w profesjonalnej sali w budynku Allegro i za pizze).

Do zobaczenia na kolejnym meetupie, który jak już wiem pojawi się niebawem tutaj.

Everything as Code - kodem opisujemy programy i systemy IT

"Everything as Code" to koncept, który przywołuje bazę programowania, czyli kod. Oczywiście większości z nas kod kojarzy się z pisaniem programów. Jednakże każdy system jesteśmy opisać również dedykowanym kodem i w ten sposób mamy zapewnionie analogicznie jak w przypadku programów sprawniejsze rozwijanie i utrzymanie systemów informatycznych.

Zgodnie z trendami w IT doszło do takiej sytuacji, że frazes "as code" został wykorzystany do wielu produktów, które pokrótcec w tym wpisie chciałbym przedstawić. Oto najpopularniejsze pojęcia, które bardzo silnie wpływają na propagowanie omawianej filozofi "... as code" w IT.

Configuration as Code

Configuration as Code ( CaC ) - Konfiguracja jako kod jest praktyką traktowania wszystkich części systemu jako kodu. Oznacza to przechowywanie konfiguracji wraz z kodem źródłowym w repozytorium, takim jak git lub svn. Przechowywanie konfiguracji kompilacji, właściwości aplikacji i konfiguracji wdrażania jako kodu oznacza, że ​​są one śledzone i można je odtworzyć jednym kliknięciem. Oczywiście w sytuacji ingerencji osoby z zewnątrz do systemu łatwo przywrócić stan konfiguracji automatycznie.

Centralne zarządzanie nawet bardzo rozproszoną konfiguracją to klucz do bezpiecznego i stabilnego systemu, w którym wiemy dlaczego coś działa zgodnie z ustawieniami.

Infrastructure as code

Infrastructure as code - ( IaC ) - Infrastruktura jako kod obejmuje projekt systemu, również zapisany jako kod. W starym świecie IT infrastruktura wymagała specjalistycznych umiejętności oraz fizycznego sprzętu i kabli do zainstalowania. Systemy były cenne lub nie były często dotykane / aktualizowane, ponieważ ludzie, którzy je stworzyli, nie działają już dla firmy. Początek przetwarzania w chmurze i aplikacji natywnych w chmurze sprawił, że jest to tania i łatwa w rozlokowaniu infrastruktura wirtualna. Przechowując konfigurację środowisk wirtualnych jako kodu, można je cyklicznie przetwarzać i odtwarzać w razie potrzeby.

Automatyzacja wdrożeń to klucz do bezpiecznego i stabilnego systemu, w którym poszczególne bloki / usługi / mikroserwisy mają swoją znaną z góry rolę.

Dlaczego infrastruktura jako kod?

Wirtualizacja, chmura, kontenery, automatyzacja serwerów i sieci zdefiniowane przez oprogramowanie powinny uprościć pracę działu IT. Zapewnienie, skonfigurowanie, zaktualizowanie i utrzymanie usług wymaga mniej czasu i wysiłku. Problemy powinny być szybko wykrywane i rozwiązywane, a systemy powinny być konsekwentnie konfigurowane i aktualne.
Pracownicy IT powinni spędzać mniej czasu na rutynowych pracach, mając czas na szybkie wprowadzanie zmian i ulepszeń, aby pomóc ich organizacjom w zaspokajaniu ciągle zmieniających się potrzeb współczesnego świata. Ale nawet z najnowszymi i najlepszymi nowymi narzędziami i platformami zespoły ds. Obsługi IT wciąż uważają, że nie nadążają za codziennym obciążeniem pracą. Nie mają czasu na rozwiązywanie długotrwałych problemów z ich systemami, a tym bardziej ich modernizację, aby jak najlepiej wykorzystać nowe narzędzia.
W rzeczywistości chmura i automatyzacja często pogarszają sytuację. Łatwość dostarczania nowej infrastruktury prowadzi do ciągle rosnącego portfolio systemów i potrzeba coraz więcej czasu, aby wszystko się nie zawaliło. Przyjęcie narzędzi chmurowych i automatyzacyjnych natychmiast obniża bariery dla wprowadzania zmian w infrastrukturze. Jednak zarządzanie zmianami w sposób poprawiający spójność i niezawodność nie wychodzi z pudełka z oprogramowaniem. Potrzeba ludzi, aby zastanowili się, w jaki sposób wykorzystają narzędzia i wprowadzą systemy, procesy i nawyki, aby skutecznie z nich korzystać.

Wartościowy cytat z wartościowej książki o IaC odpowiadający na postawione pytanie. Przy okazji polecam tą książkę jako lekturę podstawową w tym temacie. Oto jak prezentuje się okładka:

Potężne narzędzia operacyjne DevOps we współczesnych systemach IT

Od wielu lat poskramiamy rozwiązania w chmurach prywatnych, publicznych i hybrydowych. Zdecydowanie więcej Dev niżeli Ops jest obecnie w codziennej pracy w nowowczesnym dziale IT.

Koncept DevOps to stałe poszukiwanie możliwości automatyzacji powtarzalnych admińskich działań poprzez rozwój warsztatu developerskiego. Automatyzacja infrastruktury poprzez kod uwypukla ten koncept.

Najczęściej kod opisujący infrastrukturę to specjalny język domenowy DSL (ang. Domain Specific Language), czyli rozwiązujący problemy określonej dziedziny. W tym przypadku problem to opis konfiguracji i kolejności instalacji poporzez skrypty automatyczne naszych maszyn, systemów i  oprogramowania na nich.
Najczęściej plików definicji nie piszemy od zera, gdyż analogicznie do języków programowania istnieją biblioteki, które ułatwiają nam wiele typowych czynności t.j. ustawienie strefy czasowej, automatyzacja aktualizacji, czyszczenie starych kerneli z listy, postawienie serwera www, itp.



Przedstawiam poniżej kilka gotowych do użycia ideii oraz narzędzi automatyzacji i wsparcia operacyjnego dla świeta DevOps (pod linkiem mój odrębny artykuł p.t. "Fenomen DEVOPS na ratunek dla skostniałych i niezbyt wydajnych zespołów w IT (programista i administrator w jednym)").


Puppet - bazując na dialekcie języka Ruby powstał pakiet pierwotnie pod banderą 'Puppet Labs' do zarządzania farmą maszyn. Obecnie Puppet doczekał się wersji 5 co potwierdza jego popularność wśród środowsk produkcyjnych. Działa dość sprawnie i zasadniczo tworzymy plik z rozszerzeniem *.pp a wnim zawieramy recepturę. Oczywiście dotyczyła będzie w praktyce całej farmy/klasy maszyn a nie jednej maszynki. Taka receptura trafia do repozytorium, z którego puppet-agent - zainstalowany na maszynce tuż po postawieniu z kanonicznego obrazu systemu - pobiera sobie przebieg działań i skutecznie je wykonuje.   


Ansible - to narzędzie do provisioningu, któro pozwala na podłączenie się do node/maszyny, wgranie tam modułów. Moduły to zasoby wykorzystywane w opisie deklaratywnym stan systemu. Moduły są następnie wykonywane. Po wykonaniu moduły są kasowane. Słowo klucz tutaj to deklaratywny stan systemu. Czyli coś co nam opisuje jaki jest pożądany końcowy stan – jeżeli coś odbiega od założeń my mamy prawo odpowiednio zareagować, jak? zależy od nas.
Ansible najlepiej nadaje się do środowisk już istniejących, np. kiedy przejmujemy "legacy system" i musimy wesprzeć się automatyzacją, to możemy dodawać nowe zmiany już w sposób kontrolowany, przy pomocy receptur pisanych w Ansible.
Plusem Ansible jest prosta konfiguracja zmiennych i zadań do wykonania na środowisku oraz brak konieczności instalowania na klientach (w puppet musimy zainstalować puppet-agent na mszynkach).

Oczywiście mamy jeszcze do dyspozycji Chef, Salt i wiele innych możliwości.

Oto porównenie kilku narzędzi automatyzacji opisu systemu jako kodu.


Kolejnymi ważnymi pojęciami, które warto kojarzyć w kontekście konfiguracji jako kodu jest:

Platform as a service - PaaS - opis całej platformy w kodzie, który pozwala na postawienie np: całego naszego systemu w innej chmurze publicznej w celu wykonania testów lub sprawnej migracji do modelu hybrydowego.

Function as a service - FaaS - funkcje w chmurze (koncepcja serverless computing), dzięki którym nie musimy budować wielu mikroserwisów. Są to funkcje zazwyczaj dostępne publicznie po protokole HTTP i oferujące ~kilka minut przetwarzania naszych danych wejściowych. W wielu chmurach publicznych umożliwiają łączenie z wieloma usługami wewnętrznymi a nawet zewnętrznumi spotkałem się z takim ciekawym przypakiem w Azure, że można np: wpisywać do Google Docs rezultaty przetwarzania danych z FaaS.


Oto ciekawe porównanie, IaaS, PaaS i FaaS:

Pamiętaj, kiedy potrzebujesz potężnych narzędzi operacyjnych. Musisz napisać kod.

UbuntuBSD - bezpieczny kernel z FreeBSD + popularna dystrybucja Linuxa Ubuntu + system plików ZFS

Przypomniałem sobie ostatnio 2001 rok, kiedy to po raz pierwszy zainstalowałem system FreeBSD i był to nie lada wyczynem. Podłączenie do łącza/internetu poprzez dialup/SDI również wyamgał czasu. Pomogła mi na pewno "salka internetowa", czyli taka mała kańcapa którą mieliśmy w Technikum Łączności nr. 2 w Lublinie i faktycznie tam terminal tekstowy na FreeBSD to była codzienność :-) Po kilku latach stabilnego działania serwerka/bramy do internetu postawionego na FreeBSD, nastał na czas na PLD, wiele Live CD distros, RedHat Linux a następnie w ok. 2008 roku na Ubuntu Linux.

Jestem użytkownikiem Ubuntu Linux ~9 lat i doceniam korzenie odziedziczone z Debian Linux w tym systemie. Jednak ciekawostki z DistroWatch są dla mnie codzinnością i w związku z pewnym kontrowersyjnym newsem czynię ten wpis.

Objawił się moim oczom pewnego dnia UbuntuBSD i pomyślałem, że diabełek z widłami oraz koło wsparcia dla wszystkich to moze być ciekwe połączenie :-)

Oczywiście jak każdy ciekawski dystrybucji Linuxa pobrałem ISO i zainstalowałem na dostępnym storagu. I tutaj niespodzianka, bo od razu moim oczom rzuciło się pomieszanie komend z dwóch systemów ... co spowodowało u mnie na początku zdziwienie. W sumie czegoś takiego mogłem się spodziewać, ale kiedy człowiek nie poczuje mixów w praktyce, nie zdaje sobie sprawy, jak artyści-programiści mieszają różne koncepty ;-) 

Z jednej strony jądro FreeBSD a z drugiej shell/środowisko/komendy używane na codzień w Ubuntu.

Najważniejsze funkcje i właściwości oferowane przez UbuntuBSD:
– wsparcie dla technologi jail (wirtualizacja i zabezpieczenie dla jądra systemu)
– OSS jako domyślny system dźwięku
– OpenBSD Packet Filter (pf)
– wsparcie dla systemu plików ZFS (to jest mega wyczyn i moim zdaniem wielki plus)
– GNU userland
– nie zawiera żadnych pakietów własnościowych (non-free)
– używa pakietów Debuana "deb" do instalowania oprogramowania
– pakiety mogą być obsługiwane za pośrednictwem menadżera pkietów APT
– wsparcie dla maszyn wirtualnych, takich jak VMware oraz VirtualBox

Platforma programistyczna do tworzenia robotów ROS (Robot Operating System) pomaga inżynierom już 8 lat

Jak większość ludzi z branży IT w tym również ja, nie przechodzę obojętnie obok robotów i tematów związanych z robotyką. Tym razem warto spojrzeć na platformę do oprogramowania robotów ROS.

Tak wiele jest przeróżnych amatorskich rozwiązań do zbudowania robotów w oparciu o OpenSource + Arduino + gotowe moduły, że każdy z Nas, po zbudowaniu kilku robotów i skopiowaniu/zmodyfikowaniu poprzedniej wersji kodu (udoskonaleniu lub zmianie algorytmów) przychodzi w stan refleksyjny z serii "co dalej...". Jak to była w inżynierii warto zastanowić się, jak daleko chcemy zajść w konstrukcjach robotycznych. Każda sklejanka bibliotek różnej maści, która działa i cieszy amatora konstruktora jest czymś pozytywnym i jak najbardziej odkrywczym. Jednak kiedy mamy plany dalekosiężne w budowanie robotów i chcemy odkrywać więcej ciekawych możliwości - i rozwijać się w oprogramowaniu ciekawszych - robotów przychodzi nam na myśl słowo framework. Najbardzej marzy się nam platforma do konstruowania robotów. Właściwą odpowiedzią an takie potrzeby będzie ROS (Robot Operating System), czyli projekt OpenSource, który doczekał się wersji produkcyjnej i w zagościł w laboratoriach wielu dużych graczy na rynku w konstrukowaniu nowoczesnych robotów.

Na wstępnie filmik pokazujący możliwości jakie na dzień dzisisejszy posiada ROS - miłego oglądania.

Spróbuję wyjaśnić pokrótce, dlaczego platformę ROS uważam za profesjonalny produkt OpenSource.
Na wielu forach internetowych i w dyskusjach z ludźmi spotykam się z opiniami, że programiści oprogramowania robotów nie mają czasu poznać ROS, chociaż bardzo by chcieli. Jawi się im to jako zbyt duży system i niezbyt pasujący do ich np: samojezdnych robotów. Z drugiej strony wszelkie nowoczesne funkcjojnalności t.j. rozpoznawanie otoczenia przez robota, unikanie przeszkód, komunikacja intersystemowa, wizualizacja trasy w 3D, itp. chętnie by uruchomili na swoim robocie. Czas najwyraźniej zmienić sposóśb patrzenia na budowanego robota z zabawki na produkt. Jest wówczas spora szansa na uzyskanie wymienonych wyżej funkcjonalności niejako z paczki :-) Tak, dokładnie chodzi mi o "nie wymyślanie koła od nowo" i to daje programistom robotów platforma ROS.

Chciałbym przedstawić, co można zrobić w takiej platformie oprogramowania robotów Open Source jaką jest ROS. Przede wszystkim ROS to ekosystem, który składa się z:

• niezależne od języka i systemu operacyjnego narzędzia do budowania rozproszonych robotów w oparciu o ROS
• klientów napisanych dla języków: C/C++, Python, JavaScript i LISP
• pakiety komunikujące się z ROS realizujące niezależne funkcjonalności w ramach platformy
• koncepcja wymiany danych i komunikatów oraz sterownaia robotami lub całym złożonym systemem poprzez kolejki, topicki i subskrypcję - Pub Sub. Jest to niezbędne do separacji modułów ROS od komponentów robota. Nie jest konieczne, aby komputer robota był supermaszyną obliczeniową, wystarczy, że przez odpowiedni topic będzie komunikował się z chmurą i otrzymywał szybko wymagane wyniki obliczeń a sam wykonywał rozkazy. TO możęmy osiągnąć dzięki wzorcowi publish-subscribe w platformie ROS.
• wsparcie dla robotóœ budowanych jako Open Hardware
• gotowość do współpracy z Robotics middelware
• gotowe obrazy systemów operacyjnych Linux pod Virtual Box, VMWare, z preinstalowanymi systemami, dla programistów a nie DevOpsów, aby w szybciej uruchomić sówj eksperyment

Na poniższym filmie widać, że ROS to nie tylko soft do robotów, ale również do prototypowania interfejsów bazujących na szkieletowych/szablonowych ruchach człowieka używanych do sterowania (w tym przypadku żółwiem)

Poniżej zamieszczam przykład użycia platformy ROS do eksperymentu z robotem, który porusza się w środowiksu i poznaje je, dzięki czemu prędkość robota zależy od wiedzy o otoczeniu a nie jest blokowana przez kolizję z otoczeniem. Bardzo kompleksowy eksperyment, który naświetla też, jak wybgląda zestaw narzędziowy ROS i jak elastycznie można się nim posługiwać.

Kolejny przykład to połączenie ROS i OpenCV, czyli biblioteki do rozpoznawania/przetwarzania obrazów. Jest to bardzo silny trend w kierunku AI w robotach, aby używając kamery rozpoznawać kształy, kolory, śledzić cele.

Symulacja i możliwości uruchomienia robota "na sucho" stanowi założenie platformy ROS, więc jeśli chcesz stworzyć coś ciekawego i używać ROS możesz rozpocząć od serii dostępnych tutoriali. Polecam, jest to dość przemyślana platforma robotyczna i dzięku dodatkom rozwiążemy najczęstsze zagadki z robotycznego świata sprawniej, bo użyjemy implementacji wartościowych algorytmów w wersji Open Source. Więc nie trać czasu na zastanawianie się, gdzie warto zacząć uczyć się systemu operacyjnego robotów ROS - poniżej załączam szybki start.

Warto wspomnieć tutaj o wbudowanym w platformę ROS symulatorze 3D o nazwie GAZEBO, dzięki któremu można przećwiczyć system operacyjny naszego robota w wirtualnej rzeczywistości. Tak, można poustawiać meble, przeszkody, ściany, labirynty i obejrzeć, co zrobi nasz robot ew. farma robotów. Najważniejsze jest to, że zdarzenia systemowe na kolejkach oraz zmienne wystawione z robota możemy róœeniż podglądać na bierząco, co pozwoli nam wychwycić wcześnie wady naszego oprogramowania i pozwoli zaoszczędzić cenny czas.

Linki:
Wprowadzenie do systemu operacyjnego robotów ROS - przykład kodu w języku Python
Pi Robot - ROS pomaga w nawigacji
Polecane książki n.t. ROS Mastering ROS robotic programming ROS w przykładach
Hardware ROS
KOnferencja ROS 2016 - dostępne są filmy i filmy z każdej prelekcji
Nauka programowania robotów z użyciem języka Python

Puppet - automatyzacja gwarantuje utrzymanie oprogramoania

Zdajecie sobie sprawę z tego ilu adminów musi posiadać firma, aby serwery działały. Czasami warto zresetować myślenie o utrzymaniu infrastruktury i nie mnożyć stada adminów w firmie. Dlaczego ? - o tym właśnie jest ten wpis. Przychodzi nam na ratunek szereg rozwiązań zwanych automatyzacją IT.

W sumie istnieje przetestowane i rekomendowane przeze mnie rozwiązanie do zarządzania farmami serwerów, o którym wspominałem kilka lat temu. Nazywa się Puppet. W skrócie to synonim uproszczonej automatyzacji powtarzalnych czynności i procesów, który kojarzy się z szybkim wdrażaniem systemów i aplikacji w dziale infrastrukturyIT.

Warto wspomnieć, że automatyzacja w IT to nie tylko możliwość zdalnego zainstalowania softu, to również szereg zadań na każdym z etapów cyklu życia systemów:

• wdrażanie (provisioning),
• odkrywanie (discovery),
• zarządzanie systemami i aplikacjami,
• zarządzanie budowaniem i dystrybucją aplikacji,
• zarządzanie wdrażaniem poprawek (patching),
• audytowanie i śledzenie zgodności środowisk (audit)

Chciałbym się podzielić kilkoma cennymi i gotowymi materiałami z sieci, które warto znać, gdy podejmuje się decyzję o ułatwieniu życia działowi IT. Oto wartościowe materiały:

• Linux - praktyczne użycie automatyzacji z Puppet
• Puppet - materiały z konferencji

gource & logstalgia - wizualizacja życia repozytorium kodu oraz aktywności na serwerze www

Pomyślałem sobie, żę warto opublikować ten bajerancki przykład bezgranicznej wyobraźni programistów zwany gource. Z założenia jest to aplikacja napisana w C++ z wykorzystaniem korzyści płynących z poniższych bibliotek:

SDL 1.2 (libsdl1.2-dev)
SDL Image 1.2 (libsdl-image1.2-dev)
PCRE3 (libpcre3-dev)
FTGL 2.1.3~rc5-2 (libftgl-dev)
PNG library (libpng12-dev)
JPEG library (libjpeg62-dev)



Mając dowolne repozytorium GITa pobrane np: z serwisu github możemy obejrzeć niesamowitą animację renderowaną w czasie rzeczywistym z cyklu życia projektu. Osoby zatwierdzające / skłądujące kod w repozytorium uwidocznione są jako ludki strzelające z laserów do dynamicznego drzewa kodu. Bajerancko ukazuje się nam w lini czasu życia naszego kodu jego rzeczywisty rozwój i spojrzenie na kod nabiera zupełnie innego wirtualnego wymiaru. Z resztą sami spójrzcie:





Sposób kompilacji na Ubuntu 9.10:

$ git clone git://github.com/acaudwell/Gource.git
$ cd Gource
$ sudo apt-get install libsdl1.2-dev libsdl-image1.2-dev libpcre3-dev libftgl-dev libpng12-dev libjpeg62-dev
$ ./configure
$ make
$ make install

Uruchomienie na repozytorium Gource:

$ ./gource

Innym pomysłem na wizualizacje wirtualnego życia jest projekt logstalgia.




Efekt wizualizacji przedstawia pinponga z logów dostępu serwera www (access.log). Obserwacja odbijania a la gra typu ping-pong umożliwia uzmysłowienie natężenia ruchu na serwerze www. Oto przykładowy filmik z działania:





Materiały dodatkowe:
Oficjalna strona projektu Gource
Oficjalna strona projektu Logstalgia