Docker for Mac 베타 사용기

연휴 내내 하루 빼고 일하다가 드디어 짬이 났다. 그래서 한 달 반쯤 전에 공개된 Docker for Mac 을 써보기 시작. 베타용 토큰도 지난 주에 받아서 사실 그 전엔 시간 났어도 못 써봤겠지만.

일단 내 희망 사항인 linux 툴들과 Mac 용 GUI 툴을 같이 쓰는 걸 시도해봤다. 대략 docker volume 으로 로컬 디렉터리를 컨테이너에 마운트해서,

  • MacOSX 환경에서 GUI 툴을 가져다 쓸 수 있을 것: 예를 들어 git mergetoolp4merge 를 쓴다거나
  • linux 몇 가지 distro. — 특히 ubuntu 14.04/16.04, CentOS 6/7 — 에 대해서 빌드 환경을 쉽게 불러내서 사용할 수 있을 것: 예를 들어 ubuntu 14.04 gcc4 에서 빌드 + 테스트해보고 + centos 6 (w/ devtoolset) 에서 빌드 + 테스트해보기 등.

이었다.

VirtualBOX 를 중간에 껴 넣는 대신, xhyve 를 써서 상대적으로 더 빠를 것 + volume 이 제대로 동작할 걸 기대했다. 대략 기대한대로 돌았는데 …

CentOS 7 컨테이너에서 빌드를 시작했더니 끝나질 않아서 activity monitor 를 열어보니 상태가 심각하다:

something-wrong

Docker volume 을 위한 구현체인 com.docker.osxfs 가 CPU 를 다 잡아먹고 있다. Docker volume 아닌 곳에서 빌드해보면 그 차이가 더 뚜렷함. (com.docker.xhyve 가 CPU를 다 쓴다)

something-acceptable

VMware Fusion 도 그러던데, Docker for Mac 도 CPU core 수 최대 값을 4개로 잡는다 — 12″ 맥북에서 무슨 만행을… 이것도 2개로 설정. (기본 값이 2개였는데, 메모리 늘리면서 생각없이 늘려서 Orz)

docker-setting-cpu-cores

설정 자체는 원하는 방향으로 가능해졌지만, docker volume (=osxfs) 관련은 앞으로 더 패치된 후에 성능이 나아지길 기대해야. 아니면 지금처럼 build 디렉터리를 docker volume 외부에 두는 식으로 해야할 것 같다;;;

요약

  • GUI 는 Mac에서, 개발툴은 linux 에서 이용하는 (내가 생각하는) 이상적인 휴대 작업 환경이 가능해 짐
  • boot2docker 등과 달리 정식으로 docker volume 을 지원하고, OSX 에서 직접 hypervisor 를 제어하는건 좋음 (메모리, 디스크, …)
  • osxfs 를 이용한 docker volume 의 성능 문제는 개선되지 않으면 못 쓸 정도

MacBook Air 설정 기록

크리스마스 선물로 마느님께서 MacBook Air를 하사.(…)

여하튼 이제 Lion 부팅하고 1분 정도는 쓰기 괴롭고 + 파워케이블 뽑은 순간 꺼지는 MacBook[1] 는 과거 속으로.

대략 다음과 같은 순서로 설정했다. 나중에 밀고 다시 설치할 일 있으면 참고해야.

  1. AppStore를 통해서 설치했던 프로그램들 재설치 (iA Writer, OmniFocus, OmniGraffle, Caffeine, Caffeinated, Keynote, …); 이 글은 iA Writer에 남겼던 메모를 토대로 썼다.
  2. Google Chrome 설치; 이후부터는 웹 브라우저를 써야 설치할 수 있는 애들이.
  3. Firefox 및 ChatZilla 설치 (…)
  4. iTerm2 설치; solarized theme으로 재설정
  5. /usr/local 밑에 bash-4.2 설치
  6. dot files 복원
  7. NanumGothic-OTF와 NanumGothicCoding-*.ttf 설치
  8. MacVim 설치
  9. 이전에 사용하던 Documents/*, Downloads/*, src/* 이전
  10. Conatcts Google 계정에 연동
  11. 사용 중인 mail 서버 등록 (gmail은 템플릿이 있고, 사용 중인 exchange server는 auto-discovery로 잘 잡히더라)

이걸로 대략 끝.

 

본격적으로(?) 여기서 뭔가 개발하려면 python도 새로 빌드해야할 것 같긴한데, 그건 당장의 일이 아니니 나중에 하는 걸로(…).

  1. Unibody도 아니고 2008년에 초에 나온 모델; OS 버전만 올리면서 잘 썼지만 MountainLion 업데이트는 안되는 모델 []

요즘 일하는 방식

요즘 일하는 방식을 살짝 바꿨다. 이건 반쯤 휴대폰을 바꾸고 생긴 변화이긴 하다. 전에는 노트패드[1] 와 데스크 탑 위젯을 이용해서 일을 기록하고, 하나하나의 일을 어떻게 진행하나 추적했다. 요즘은 그 중 거의 대부분이 휴대폰으로 옮겨 왔다.

우선 거시적인 일정 관리는 구글 달력을 써서 하고, 이걸 쪼갠 세부 태스크(?)는 팀 공용 화이트 보드에 붙여서 처리했었다. 이젠 세부 태스크 관리는 OmniFocus에 맡기고 아침에 일어나서 이걸 한 번 리뷰하고, 퇴근한 뒤 한 번 되돌아 보는 식으로 바꿨음.
올해 목표이기도 한, “한 번에 할 만큼 일정 쪼개서 생각하기”랑 잘 맞는다. 종이보다 편집이 좋고 노트북에서 전체적으로 리뷰 할 수 있는 게 좋음. 다만 종이처럼 ‘쉽게’ 입력할 수 없다는 건 좀 아쉽다.

우선 데스크 탑 화면.[2] 주로 오전에 일어나서 아들 깨기 전까지 이것저것 하는 동안 본다.

omnifocus_on_desktop

밑이 내 iPhone 에서 본 것. > 로 표시된 것들은 “하위 태스크”가 있는 애들이다. 예전 하던 게 지금 보는 화면 수준의 작업 관리였고, 요즘 ‘하려고 하는’ 부분이 > 밑의 하위 태스크로 쪼개기.

app_omnifocus_on_iphone
이 세부 태스크를 예전엔 그냥 묵묵히 하거나 FocusBooster란 위젯을 써서 타이머 도는 동안은 그냥 짐작하는 방식을 썼다. 근데 보조 모니터보다는 유혹을 피한다는 면에서[3] 휴대폰 앱이 더 낫다 싶었다. 그래서 뽀모도로 타이머 비슷한 걸 구해서 쓰고 있다. 생략의 미학 덕인지, 데스크 탑보다 오히려 인터페이스가 편하단 점이 좀 무섭지만…


이런 식으로 대략 25분 일하고 5분 쉬고 있음. 이 글은 대략 이 정도 시간 동안 쓴 글임.[4] 회사에서 업무 볼 때는 대략 이걸 3~4번 돌리면 하위 태스크 하나가 끝난다.

여하튼 올해 목표 겸 테마는 내가 ‘한 번에’ 할 수 있는 수준으로 일을 잘 쪼개고, 각각을 야무지게 하자다. 남은 열 한 달도 잘 해보고 내 년 초 회고에 얘기할 수 있으면 좋겠다.

 

ps. 이 글 + 올라갈 사진 수정하는 동안 데스크 탑 2번 리붓. 대체 왜 -_-?

  1. MS Windows의 그것 말고 노란 실물 메모장 []
  2. OmniGroup이 MacOS 류에서만 프로그램을 내놔서 맥북에서 캡쳐. 주로 쓰는 데스크 탑이 아니라 ㅠㅠ []
  3. 넓은 데스크 탑에서 웹 서핑 하는 것보다, 훨씬 더 귀찮기 때문에, 텍스트 읽는 일만 해서 딴 짓을 훨씬 덜 하게 된다 []
  4. 물론 OmniFocus 데스크 탑 버전 스크린 샷과, 몇몇 모자이크 처리는 이 글이 실제로 웹에 올라가기 전에 따로 손 본 부분임 []

멤버 함수 포인터의 크기

C 에서 함수포인터의 크기는 아주 예외적인 경우를 제외하고는 void* 의 크기와 같다. 즉, 모든 포인터의 크기가 CPU word 크기다[1] 하지만 멤버 함수 포인터의 경우는 조금 다른 얘기가 된다.

지지난 주에 우연히 발견하게 된 사실인데 — Visual Studio 2005의 데이터 visualization 버그인듯 함 — 멤버 함수 포인터를 저장하고, 이걸 가지고 모종의 작업을 하는 템플릿 라이브러리를 짰는데 — 2년 전에 작성해놓고 그 동안 잘 쓰던 녀석 — 이 녀석을 쓰는 코드를 디버깅하다가 생각없이 실행 스택을 따라 내려갔는데, 멤버 함수 포인터 배열에 3단위(12  bytes)로 뛰어넘으면서 접근하는게 아닌가!

실제로는 다른 부분의 코드에서도 일관성 있게 접근하고, 이걸 template 없이 짜면 별 이상없이 1 단위로 점프하는걸로 봐선(여기선 그냥 8bytes씩) 그냥 버그인듯.[2] Visual Studio 와 관련해서는 Raymond Chen이  이걸 잘 정리해놨다 — Pointers to member functions are very strange animals. 즉, member function pointer 그 자체와, data 영역에 대한 오프셋이 들어가서 저 모양이란 소리.

GCC 에 대해서도 간단한 코드를 돌려보니 비슷한 결과가 나온다.  Mac OS X(Snow Leopard) 에서 4개의 (일반) 함수포인터를 넣은 배열의 크기 32 bytes, 멤버 함수 포인터를 4개 넣은 경우엔 64 bytes 크기로 나왔다. 즉, 각각 8 bytes 와 16 bytes. 윈도우즈의 예랑 좀 다른건 이 경우엔 64bit 으로 컴파일 했기 때문. 32  bit linux에서 동일한 파일을 컴파일해서 실행해보면 16  bytes / 32 bytes 가 나올 뿐…

 

결론:  Compiler 마다 멤버 함수 포인터 크기는 다를 수 있으며, 이 역시 플랫폼(CPU 워드 크기  /  OS / 컴파일러)에 따라 다르게 된다. 그리고 일반적으로 이 크기는 일반 함수 포인터 보다 크다.[3]

  1. MS Windows 환경에 익숙한 사람들이라면 WORD 타입이랑 헷갈릴지도 모르지만, 이건 OS 관점에서의 형 문제로, 이 글에서 언급하는 word 크기는 해당 플랫폼이 생각하는 CPU 레지스터 크기다 []
  2. 그러니까 IDE에서 데이터를 보여주는 부분의 아주 미묘한/사소한 []
  3. 왜냐하면 다중 상속이나 virtual 상속 때문에… []

프로그래머의 일상: 산학 프로젝트 및 각종 삽질

산학 프로젝트

사실 산학 프로젝트란 거창한 이름이지만 실제로는 학부 프로젝트 1수업에 관한 거임.

원래대로라면 훨씬 전에 통보가 왔어야 하지만,

  • 월~수 동안 프로젝트 수업 조교들이 메일이 학교 외로 발송되지 않던걸 몰랐음[1]
  • 수요일에는 내가 있는 회사 쪽 담당자가 총장 잔디에서 있는 채용설명회에 나가 있었을 뿐이고,
  • 목요일인 9월 10일 오후 5시까지는 실무 담당인 내가 교육을 받고 있었을 뿐이고 -_-

덕분에 저녁도 제대로 못 먹고 10시까지 PPT 작성하고 퇴근했음. 그리고 일부 이미지는 보안 승인이 필요해서,  다가오는 오전에 회사들려서 이미지 다 집어넣고 학교로 가야할듯 Orz

Office for Mac

노트북을 뭘 가지고갈까 하다가 MS Office 2007이 깔린 애가 안 보이길래, 이에 대응하는 맥 오피스가 깔린 맥북이 생각나서, 거기에 시연할 파일을 넣어봤다. 일부 레이아웃이 깨진다 ?!?!?!?!

주의깊게(…) 살펴본 바로는, 탭으로 공백 지정한 일부 글자들의 위치가 이상해졌다. 탭 폭이 다른가? 혹은 계산 방식에 차이가 있는가 -_-;
덤으로, 아무 문자도 없는 줄을 없는 셈치기도 하는듯 하다(수직 배치에 대해서).
그래도 이 컴에서 하게 될 확률이 꽤 되니 내일 프리젠테이션 전엔 확인해야.

아으 그렇지만 맥북, VGA 연결용 어댑터, 그리고 혹시 모르니 파워 어댑터까지 챙겨 가려니 아주 등골이 휠듯하다.

ps. 여튼 그런 연유로 9/11일 오후에는 301/2동에 출몰할 예정입니다[…]  시간 되는 분들은 잠시 봅시다.
9/25일에도 학교 올 수도 있지만, 그건 뱃속의 아기가 바로잡히지 않으면 불가능하니 패스하고(…), 가능하면 볼 수 있는 사람들은 다 봅시다;

  1. 사실 이건 테스트 안 해 봤다는 점에서 담당 교수한테 메일이라도 보내서 좀 제대로 까야할 것 같은데 []

On Snow Leopard

지난 주 금요일에 주문한 Mac OS X Snow Leopard가 도착해서, 집에 오자마자 맥북에 설치했다.

Mac OS X를 설치해보는 건 이번이 처음이라 어찌 돌아가나 했는데, 거의 최근에 나온 linux 배포판 설치하는 것 만큼이나 쉬웠다.
Win32 쪽 경험으로 비교하자면 Windows Server 2003 -> Windows Vista 업그레이드 설치할 때 빼곤 이 정도로 쉽게 된 기억은 없음…

다만 macport 가 안되고 있다 Orz.

일단 가장 눈에 띄는 부분이고, 내가 이걸 바로 사게 만든 기능을 캡쳐. (이미지를 클릭하면 데스크탑 전체 캡쳐를 볼 수 있다)

stack_sl

Mac OS X에서 가장 맘에 들던 부분이 바로 MS Win32의 태스크 바 같은 Dock[1] 에 있는 기능인데, 미리 지정해놓은 디렉토리[2] 를 태스크 바(여기서는 Dock 이라 부름)에서 바로 접근하게 해준다.

Windows에서 바탕화면에 내 문서 폴더가 있는거랑 살짝 비슷하지만, 이 경우에는 커서를 가져가면 저렇게 팝되면서 보이는 “스택”이란 기능이 참 좋음. Leopard에선 여기있는 디렉토리를 접근하는 경우에는 파인더가 떠 버려서 김새는 느낌이었지만, Snow Leopard에선,

stack_sl_subdir

처럼 내부로 들어가게 된다. 그래서 훨씬 더 편안하게 스택을 쓰게 되었음…

$29가 4.5만이 되어버린건 좀 가슴아프지만(?), 스택이 좀 더 편해진 것만으로도 충분히 맘에 든다.

  1. Windows 7에서 상당히 편해진 태스크 바도 이 dock을 상당 부분 따라한 거라고 생각한다 []
  2. 기본적으로는 문서 디렉토리와 다운로드 디렉토리가 지정되어 있음 []

잡담: 2008년 5월 1일

5월 첫 포스팅은 잡담으로.

Blogging on Mac

맥용 오프라인 블로깅 툴인 bleezer를 받았다. (UTF-8 인코딩된) 한글을 인식 못한다. 버려 -_-

결국 그냥 FF로 WP 내장 에디터(지금까지는 그래왔음). 맥북에서 제일 그리운 윈도우즈 응용 프로그램이 Windows Live Writer라는건 흠좀무. 그런 의미에서 하는 얘기지만, MS가 정말 강점을 갖는 시장은 데스크탑 응용이 아닐까. OS 가 이 시장 자체의 기반이 되긴하지만[1] 데스크탑 응용을 웹과 연동해서 쓰게될때 MS 프로그램이 주는 메리트는 정말 상당한듯. 물론 맥 프로그램들이 다른 형태의 인터페이스로 편의를 제공해줘서 잘 쓰곤 있지만(예를들어 키노트), WLW는 정말 그리움.

아무리 AJAX가 쓸만하다고 해도 JavaScript자체가 모든 브라우져에서 동등하게 구현된게 아니고[2] 같은 기능에 필요한 computation power차이도 좀 무섭다.

비슷한 의미로 Adobe Air도 별로 관심이 안가…

자전거 

햇수로 따지면 10년 정도만에 자전거를 다시 산건데, 의외로 적응은 빨리 되는구나. 오늘 정오 앞뒤로해서 한 2시간쯤 집 주변을 돌아다녀봤는데, 평지라 그런지 확실히 타긴 편하다.[3]

메모리 할당자

GPG 포럼에 할당자를 왜 쓰냐는 식의 글이 올라왔었다. (몇일 전이고 링크 못찾겠음) 

할당자가 어려운 개념도 아니고[4] , 적용했을 때의 꽤나 큰 성능 차이 — 특히나 메모리 할당이 잦은 멀티스레드 코드면 더더욱 — 를 보이게 된다.

근데 할당자를 직접 짜야만하는 것도 아니고 Hoard, RED 같이 링커 레벨에서 malloc, free, new, delete[5] 를 직접 덮어써서 구현해주는데[6] 속도는 꽤나 큰 향상이 있다. 작년 중순에 테스트했던 서버에서 5천 접속 기준으로 CPU 사용량이 40%정도 내려가더라…

  1. 그리고 OS + Office로 매출의 70%를 올리고 있지만 []
  2. 예를 들어 사파리에선 레몬펜이 실행안됨 []
  3. 낙성대 살 때를 생각하면… []
  4. 물론 적당한 경험없이 바로 제대로 짜는건 쉽지 않다. 하지만 그건 non-trivial한 모든 프로그램이 그러할듯. Binary search나 quick-sort도 바로 제대로 짜는걸 구경하긴 쉽지 않다(내 경우엔 그냥 구현하나를 외워서 쓴다) []
  5. new, delete은 내장해서 제공하는 것들 []
  6. 즉 프로그래머가 손댈게 거의 없음 []

새로운 OS에 라이브러리 설치하기

현존하는 C 패러다임에서 라이브러리를 설치한다는 것은 적어도 (최소한) 다음 툴들이 각 라이브러리에 맞게 존재한다는 것

  • C compiler 혹은 C++ compiler : 이건 GCC 등으로 인해 상대적으로 잘 퍼져있고, 표준에 맞게만 짜면 상당히 포터블함[1]
  • Linker (+ loader): 링커는 컴파일러 툴셋의 일부이긴하지만 상대적으로 OS에 의존적인 부분. OS마다 실행 파일 형태가 다르고[2] 그에 따른 링커 동작도 변화한다

여튼 MacOS X에 자주 쓰는 라이브러리들을 몇 가지 설치했다. 그래도 *nix류라서 GCC가 정상적으로 도는 것 같고해서 별 어려움 없이 진행되긴 한듯.[3]

  • Boost — C++ 유저인 rein의 경우 boost는 빛임(…). toolset 만 darwin으로 잡아주면 문제 없이 설치된다.[4]
  • intel TBB — binary 배포판이 존재한다. 일단 그걸로 설치. 나중에 생각나면 빌드를 하던가 말던가(…)
  • UnitTest++ — 라이브러리를 빌드했는데 (.a 파일로 static 빌드됨), 링크가 안된다. 구글에게 물어보니 ranlib을 써서 TOC를 만들어줘야하는군…[5]

여튼 이런 과정을 통해서 라이브러리 설정 종료. 워크샵 준비도 슬금슬금 시작. 인증샷(?)

eclipse_on_leopard

ps. 자주 사용하는 라이브러리가 ANSI/ISO C++ 이고, 대부분의 OS의 경우에 최신 Compiler만 설치되어있어서 별 무리 없이 쓸 수 있다는 것은 참 좋은듯. Python에 비하면 불편하기야 하지만 잃는게 있어야 얻는게 있지…

그리고 boost::thread의 read/write mutex에 존재하던 문제는 1.35로 넘어오면서 해결된듯하다. 새로운 mutex 구현체 쪽으로 read/write mutex와 일부 타입이 typedef 으로 변경된 것을 확인했음

  1. 특히 C의 경우엔 Java보다 더 호환성있게 옮겨지는 경우를 왕왕 본다. 예를 들어 새 모바일 기기가 나올 때마다 포팅되는 Quake라거나…. []
  2. Win32만 해도 COM, PE, linux의 ELF, COFF, … []
  3. 물론 구글에게 물어본게 있지만 []
  4. bjam -j2 –with-python-version=2.5 –toolset=darwin 으로 설치. toolset 없이 하면 GCC가 기본으로 잡혀서 링커 에러를 내더라… []
  5. 근데 내 기억이 맞다면 이거 그냥 index만 헤더에 만들어서 링킹만 조금 빠르게 해주는거 아닌가. 맥은 이거 없으면 링크 실패한다 []