Obie wersje są pod ubuntu. Czy to oznacza, że zadziałają tylko na systemach z rodziny ubuntu, czy w innych dystrybucjach linuxa (np. debian lub slackware) również?
Zasadniczo wszędzie tam, gdzie zadziała Docker, czyli powinien na każdej w miarę współczesnej wersji dowolnej dystrybucji Linuksa. Miałem okazję sprawdzić np. obraz Ubuntu na CentOS-ie i działa - mamy po prostu dwa równoległe systemy na jednej maszynie i można dowolnie mapować porty i podmontowywać katalogi w ramach komunikacji między nimi.
W dodatku jest to repozytorium obrazów, gdzie można korzystać z gotowych obrazów jako bazy dla własnych, czyli jest to modularne i wykorzystuje mechanizmy zależności. Można też na raz odpalać kilka kontenerów, co pozwala wygodnie testować np. z różnymi wersjami bazy albo Mapnika, po prostu odpala się inną wersję np. kontenera bazy (akurat te obrazy, które pokazałem, są zbudowane monolitycznie - wszystko jest zdefiniowane w jednym kontenerze, pobierając najnowsze wersje programów z Gita podczas budowania, ale można to rozbić i instalować w nich konkretne wersje programów). Dlatego tak mi się ten cały pomysł podoba: to bardzo lekki rodzaj wirtualizacji plus klockowy system zarządzania.
Najważniejsze jest jądro - czasem jest zalecana jakaś bardzo świeża jego wersja, co może sprawiać kłopot jak ktoś używa starszej wersji dystrybucji, ale wydaje mi się, że tylko z powodu różnych problemów i błędów (np. podejrzewam, że to było powodem, że vsftpd się ciągle wywalał, ale to mogło być co innego, a z kolei ProFTPD działa tam bez bólu).
Dzięki, to brzmi obiecująco (choć być może zmusi mnie to w końcu do przejścia na 32bitowe jądro).
A nie na 64-bitowe?
Chyba masz na myśli 64-bitowe? 
Warto, ale nie trzeba.
Ja się właśnie przesiadłem (niestety instalacja systemu na nowo, choć na szczęście można go w miarę dokładnie zmigrować), ale to nie jest konieczne, bo Docker wymaga go tylko jeśli uruchamiasz kontenery 64-bitowe, ale możesz sobie sam zbudować obrazy 32-bitowe. Jest to mało znane rozwiązanie i przez to bardziej upierdliwe, bo pewnie większość gotowców jest 64-bitowa i musisz sam zbudować wszystkie obrazy pośrednie, ale jak najbardziej działa - wiem, bo próbowałem. W szczególności jeśli korzystasz z obrazu Ubuntu 14.04 jako bazy, to w Dockerfile wystarczy zmienić w jednym miejscu “ubuntu:14.04” na “32bit/ubuntu:14.04”. Jest nawet inicjatywa obejmująca kilka debianowych wariacji i pewnie z każdej innej dystrybucji też można, może nawet ktoś takie przygotował.
Miałem na myśli 32-bitowe 
zakładając, że takie właśnie są obrazy. Mam już to nieszczęście mieć system z 64-bitowym jądrem i połową programów (reszta jest 32-bitowa, bo nie ma wersji 64-bitowych (np. adobe reader o ile dobrze pamiętam)), więc więcej z tego problemów niż korzyści.
Ale jadra 64-bitowe nie sa zadna przeszkoda w uruchamianiu 32-bitowych aplikacji ani 32-bitowych obrazow. W przypadku obrazow nie muszisz robic nic specjalnego, w przypadku 32-bitowych programow musisz tylko upewnic sie, ze masz multilibs (a jest ono domyslnie w dystrybucjach od zawsze, wiec po prostu go nie wywalaj).
W Gentoo jest to fajnie rozwiązane - kompilując coś tworzone są dwie wersje bilbliotek - 32-bitowa i 64-bitowa. Nie ma wtedy problemu z uruchamianiem starszych aplikacji 32-bitowych, takich jak wspomniany Acrobat Reader, który jest dystrybuowany jako brzydka binarka.
Trzeba tylko sobie ustawić zmienną: ABI_X86=“64 32”
Korzyścią jest możliwość korzystania z więcej niż 4GB pamięci RAM.
W Ubuntu z kolei po migracji doinstalował mi ileś bibliotek o tej samej nazwie co pakiety 64-bitowe, tylko z przyrostkiem “:i386”. Tak czy owak balrog-kun ma rację, w tę stronę to mniejszy problem niż odwrotnie.
Jest nawet narzędzie do wygodnej instalacji i zarządzania Dockerem pod Windows i OS X o nazwie Docker Toolbox (choć oczywiście i tak wiąże się to z wirtualnym odpalaniem Linuksa):
http://docs.docker.com/engine/installation/windows/
http://docs.docker.com/engine/installation/mac/
3 grudnia szykuje się międzynarodowy sprint w mapowaniu obiektów dostępnych (lub nie) dla ludzi na wózkach:
https://lists.openstreetmap.org/pipermail/talk/2015-November/074987.html
Dbając o aktualny stan dróg na mapie OSM warto śledzić jeden z wątków na Forum SCC, tj. zestawienie wszystkich nowo budowanych odcinków dróg w ciągu DK i DW. Kolega Kemo wykonuje naprawdę dobrą robotę: http://www.skyscrapercity.com/showpost.php?p=117967490&postcount=30
5 grudnia nastąpiły poważne problemy z częścią plików na Geofabrik, niestety także w przypadku polskich województw, tu są bardziej szczegółowe informacje:
https://lists.openstreetmap.org/pipermail/dev/2015-December/028961.html
http://forum.openstreetmap.org/viewtopic.php?pid=564747#p564747
Od pewnego czasu gdy edytowałem ten rejon, na niektórych mapach dzieją się dziwne rzeczy:
https://www.openstreetmap.org/#map=18/50.88252/20.58327&layers=C
https://www.openstreetmap.org/#map=18/50.87993/20.58974&layers=C
Tutaj na warstwach osmand jest dokładnie to samo:
http://matthijsmelissen.nl/temp/osmand.html
To jest problem tych map. Na podstawowym stylu jest dobrze.
A co właściwie jest tam dziwnego?
Strzałka kierunkowości.
Kliknij pierwsze dwa linki i zobacz:
- uliczki parkingowe to jakieś dziwne wywijasy
- stare dane mieszają się z nowymi i wygląda to tragicznie
Czy byłoby bardzo źle widziane, gdybym puścił wokół Warszawy arbitralną granicę obszaru, powiedzmy dodając kawałki granic powiatów do jakiejś swojej relacji?
Ewentualnie jak inaczej zdefiniować sobie taki obszar w celu odpytywania Overpassem na potrzeby różnych akcji? Ma nie być prostokątny.
Na razie najlepsze, co wymyśliłem bez wyznaczania własnego obszaru w OSM, to zapisać sobie fragment zapytania sumujący kilka-kilkanaście geocodeArea i to by mi w zasadzie wystaczyło, gdybym umiał sobie wyświetlić taki zsumowany obszar i zobaczyć, czy nie zostawiłem dziur w środku…