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).
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.
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:
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…