윈도PC에서 애플 매직트랙패드 설치하기

애플은 기본적으로 Mac 머신에서 쓸 수 있는 BootCamp용 드라이버만 제공한다. 때문에 일반 윈도 PC에서는 바로 설치하기가 곤란하다. 그러나, 이 BootCamp용 드라이버를 추출해서 직접 설치할 수 있다.

참고로 매직 마우스나 애플 무선 키보드도 같은 방법으로 설치 가능하다.

개인적으로는 맥북을 쓰고 있지만, 회사에서는 윈도 PC로 작업을 하고 있어 삽질을 하게 되었다.


1. 7zip 설치

애플 드라이버를 추출하기 위해 필요하다. 남들이 추출해둔 걸 다운받을 수도 있지만, 최근 버전의 드라이버 혹은 안전성(악성코드 첨부 위험을 피하기 위해)을 생각하면 추출해서 쓰는 법을 익혀두는 게 좋다.

2. 매직 트랙패드용 BootCamp 업데이트 다운로드: 32bit Windows 64bit Windows
매직 매우스나 무선 키보드는: Windows용 Boot Camp 드라이버 업데이트 2.2

다운로드 받은 다음, 7zip으로 압축을 풀면 BootCampUpdate32.msp 또는 BootCampUpdate64.msp 파일이 나온다. 이 파일을 다시 7zip으로 압축을 푼다.

압축이 풀린 디렉토리들 중 BootCampXXXXXToBootCampXXX (X는 숫자 혹은 영문, 글자수는 임의) 식의 디렉토리들이 보이는데, 이 중에서 다음 파일들을 찾아 확장자를 exe로 바꿔준다.

무선 키보드 : Binary.Keyboard_Bin
매직 마우스 : Binary.MultiTouchMouse_Bin
매직 트랙패드 : Binary.AppleWirelessTrackpad_Bin

이 파일들을 쓰기 편한 곳으로 옮겨둔다.

3. 블루투스 동글 설치

중요한 부분인데, 랩탑의 경우 BT 내장인 경우도 있고, 그 외 동글을 따로 쓰는 경우도 있는데 대부분 BlueSoleil이나 Broadcom 혹은 도시바의 블루투스 스택을 설치하는 경우가 대부분이다. 애플 드라이버들은 MS 윈도의 블루투스 스택용이어서 이들과는 호환이 되지 않는다. 때문에 MS 스택과 드라이버로 설치가 되어야 한다. 그러나 많은 BT 동글들이 MS 스택에서 지원이 되지 않는 문제가 있다. (윈도 비스타나 윈도 7은 좀 다양하게 지원하는 것 같지만...) 자신의 동글이 MS 스택에서 지원이 안된다면(안잡힌다면) 다음 프로그램을 설치해본다.
Bluetooth Driver Installer : http://bluetoothinstaller.com/
설치하기 전에 http://bluetoothinstaller.com/hardware.html 에서 자신의 동글이 지원되는지 확인해야 한다. Chip vendor와 Hardware ID가 일치하면 거의 지원된다.

설치할 때 날짜가 지났다며 설치가 안되면 PC의 날짜를 며칠 정도 뒤로 돌려서 설치해본다. 드라이버 설치 시 오류가 난다면 드라이버를 제거하고 리붓한 다음 다시 시도해본다. 이 과정에서 많은 삽질을 하는 경우도 생긴다. 원래 제공된 드라이버를 설치하고 업데이트에서 Bluetooth Driver Installer의 드라이버로 변경도 해 보고 하는 등 생각보다 험난한 과정이 될 수도 있다. (내가 그랬다. ASUS의 BT 동글 사용중.)

여기서 도저히 설치가 안된다 포기해야겠다라고 생각이 들면 MS 스택이 지원되는 제품으로 다시 구매하거나 해야 한다.

그리고 여기서 살짝 갈등되는 것이, XP의 경우 A2DP를 쓰기에는 MS 스택이 별로 좋지는 않았던 걸로 기억을 한다. Windows 7에서는 아예 A2DP가 빠져있다. 그냥 포기하고 트랙패드만 쓰는 중. T.T

제대로 설치가 되었다면 위에서 추출한 드라이버 설치 파일을 실행한다.

4. 매직 트랙패드 연결

MS 스택에서 연결할 장치(트랙패드던 마우스던 키보드던)를 찾아서 연결한다. Passkey를 요구하는 경우 대부분은 0000 을 넣으면 된다. 연결되면 드라이버가 설치되는데 만일 HID 장치로 잡힌다면 제기능을 쓰기는 어렵다. 애플 드라이버로 설치가 되어야 하며, 혹시라도 그냥 HID 장치로 잡혔다면 드라이버 업데이트를 눌러 애플 장치로 변경해준다.

Mac에서처럼 모든 기능을 다 쓸 수는 없어 좀 아쉽기는 하지만, 스크롤까지는 별 문제 없이 쓸 수 있어서 나름 나쁘지는 않다. :-)

5. 끝

보통 유선 트랙패드가 면적도 좁고 멀티터치도 불안정하거나 지원이 안되는 제품들이 거의 10만원 가까이 가는데, 애플 매직 트랙패드가 9만 5천원(정가)이라는 점은 비싸긴 해도 오히려 경쟁력 있는 가격이다. 감도 좋고, 윈도에서는 2 finger scrolling까지만이지만 그럭저럭 쓸만하고, Mac을 쓴다면 매우 좋은 제품이니... 거기에 무선이다!

WACOM의 터치 뱀부라는 제품이 있지만 가격도 상당하고 무엇보다 사용기를 찾아보기 힘들어서 구매 전 평가가 어려웠다. 이래저래 터치패드 사려고 고민하다 애플이 내놓아 주어 바로 질러버림... 한 동안 매직 마우스도 땡겼으나 실사용시 그립감이 좋지는 않아 그립을 달리해서 잡고 써야 해서 지르지는 못했고.

매직 트랙패드만 쓰고 있어서 매직 마우스나 무선 키보드는 실제로 적용해보지는 못했지만, 검색해본 결과로는 거의 위 과정대로였다. 매직 트랙패드는 아직 정리된 자료가 많지 않았지만, 매직 마우스, 무선 키보드 관련 자료들 보고 따라하다보니 성공한 것이어서 결과적으로 애플 제품들은 거의 다 이 방법이 통하는 듯.

6. 팁

매직 트랙패드가 유리패드이고 감도가 좋기는 하지만, 손에 땀이 차거나 해서 물기가 있는 경우 패드에 짝 달라붙어 터치감이 영 좋지 않은 경우가 종종 생긴다. 이 상태로 계속 쓰면 손가락도 아프다. -_- 해서, SGP에서 나온 아이패드용 지문방지 필름을 사서 잘라서 붙였더니 터치감도 확 좋아졌다.

[Git] rebase, fetch, branch

한참 뭔가 수정하고 커밋했는데 리모트 저장소에 이미 push된 내용이 있다.

이 때, pull 해버리면 깔끔하게 한 줄로 정렬된 히스토리가 만들어지지 않는데다가, 이후 다른 사람들이 pull 혹은 cherry-pick하게 될 때 좀 더 귀찮아지는 경우가 생길 수 있다.

그러면, fetch를 하고 rebase를 해 보자.

$ git fetch
$ git log ..FETCH_HEAD
$ git rebase FETCH_HEAD
$ git log --graph

대충 이렇게......

rebase 도중 conflict가 발생하게되면 물론 수정을 해야 하지만, 동일한 파일의 동일한 위치가 수정된 경우가 아니라면 별 문제 없이 rebase가 된다.

깔끔해진 히스토리에 만족스러워하며 push 해버리자.

개인적으로는 거의 항상 임시로 작업 브랜치를 만들어서 작업하면서 rebase, cherry-pick을 이용해 push하기 전에 정리를 하는 방법을 쓰지만, 간혹 작업 브랜치 만드는 걸 잊고 작업할 때가 있다. 위 방법으로 해결할 수도 있지만, 커밋이 여러 개여서 헷갈린다면...

$ git branch -m temp
$ git checkout -f -b master origin/master
$ git checkout -f temp
$ git rebase master

뭐 이런 식으로 하는 수도...

[VIM] vimrc

주력으로 사용하는 텍스트 편집기는 OS가 뭐든 vim이다.

현재 다음 설정을 $HOME/.vimrc 에 넣어두고 쓰고 있다

set nocompatible
"source $VIMRUNTIME/mswin.vim
"behave mswin

colorscheme torte

function! SetKernelIndent()
    set ts=8
    set sts=8
    set shiftwidth=8
    set noexpandtab
endfunction

function! SetAndroidIndent()
    set ts=4
    set sts=4
    set shiftwidth=4
    set expandtab
endfunction

"map ski :call SetKernelIndent
"map sai :call SetAndroidIndent

set ts=8
set sts=8
set shiftwidth=8
set noexpandtab

let  g:MultipleSearchMaxColors=8

set smarttab
set smartindent
"set expandtab false
set fencs=utf8,cp949
set ruler
set number
set hls
set ic " ignore case
set nowb " disable writebackup
set noacd " noautochdir

noremap  :Tlist
set t_Co=256

map s* :execute ':Search \<'.expand('').'\>'
map s8 :execute ':Search \<'.expand('').'\>'
map sr :SearchReset

noremap  
inoremap         
cnoremap         

filetype on
filetype indent on
filetype plugin on

if filereadable("tags")
        set tags=tags
endif
set tagbsearch  " enable binary search in ctags database

"cscope
set csto=0
set cst
set nocsverb

set cscopeverbose

" Ctrl+[ 는 ESC와 동일하므로, Ctrl+P로 변경
nmap c :cs find c =expand("") " Find functions calling this function
nmap d :cs find d =expand("") " Find functions called by this function
nmap e :cs find e =expand("") " Find this egrep pattern
nmap f :cs find f =expand("") " Find this file
nmap g :cs find g =expand("") " Find Find this definition
nmap i :cs find i ^=expand("")$ " Find files #including this file
nmap s :cs find s =expand("") " Find this C symbol
nmap t :cs find t =expand("") " Find assignments to
nmap h :cs help
nmap k :cs kill
nmap r :cs reset
nmap w :cs show

" resize window using vi navigation keys
nmap k -
nmap j +
nmap h :vertical resize -2
nmap l :vertical resize +2

ctags, cscope

vim에서 cscope.files 열어서 프로젝트 파일 리스트로 쓰고, 편집할 파일이름이 있는 라인에서 Ctrl+wgf 를 입력해 탭으로 열어서 편집하면 나름 쓸만한 듯. cscope, ctags DB를 빌드하니, 편하게 뒤적일 수 있다.

$ cat /usr/local/bin/mktags
#!/bin/bash
find . \( -name '*.cpp' -o -name '*.cc' -o -name '*.c' -o -name '*.h' -o -name '*.uh' \
        -o -name '*.hpp' -o -name '*.s' -o -name '*.S' -o -name '*.m' \) -a \
        ! \( -ipath "*doc*/*" -o -ipath "*/doc*/*" -ipath "*out/*" \) \
        -print | sort > cscope.files
cscope -b -q -v -k
ctags --verbose=yes --sort=yes -L cscope.files

vim의 플러그인들 중에 프로젝트 관리용 플러그인들도 있는데, 아직 사용해 본 건 없어서 우선 이렇게 쓰고 있는데, 이게 벌 써 몇 년...... Emacs를 써 보려고도 했으나 영 적응이 안된다.

[Gerrit] Code Review System

코드 리뷰, 하면 좋다는 건 대부분 동의할 것 같다. 그런데, 어떤 시스템을 써야 할지, 코드 리뷰에서 오버헤드가 많아지지는 않을지 걱정도 있다. 더욱이, 게시판이나 이메일, 혹은 비효율적인 시스템을 이용해서 리뷰를 해 본 적이 있다면, 리뷰 과정의 오버헤드때문에 괴로워 하기도 했을 것 같다.

만일, Git을 버전 관리 시스템으로 쓰고 있다면?

Gerrit이라는 코드 리뷰 시스템이 있다. 구글의 안드로이드 코드 리뷰도 이 Gerrit으로 진행하고 있고, 현재 일하는 회사에서도 리뷰 시스템으로 Gerrit을 쓰고 있다.


http://code.google.com/p/gerrit/


리뷰어(reviewer), 서미터(submitter)를 등록하고 리뷰를 통해 +, - 점수를 매기고 코멘트를 주고 받으면서 리뷰를 진행한다. 리뷰 과정에서 코드 수정을 자유롭게 할 수 있다. 리뷰가 완료되고 서미터에 의해 approve가 되면 해당 브랜치로 merge를 하게 된다.

이런 과정에 대해 http://source.android.com/source/life-of-a-patch.html 에서 좀 더 자세히 설명하고 있다.


Gerrit은 리뷰로 인한 오버헤드가 매우 적고, Git과도 매우 잘 통합되어 있어 Git을 쓰는 경우에는 최적의 리뷰 시스템이 아닐까 생각한다.

[Git] bundle 사용하기

git 사용 중에 push/pull 하기는 좀 어렵고 patch는 patch대로 또 좀 귀찮은 면이 있어서, push/pull 처럼 쓸 수 있는 다른 방법을 알아보니 (역시나) bundle이란 게 있다. hg 쓸때 종종 쓰던건데, 간단히 설명하자고 하면 특정 커밋(들)만 파일로 뽑아내서 저장소처럼 쓰는 방법이다.

사용법은 git bundle --help

참고자료 http://progit.org/2010/03/10/bundles.html

간단히 사용법을 정리하면,

mybranch의 커밋들 중 master에 없는 것들을 ~/mybundle 파일로 저장.

$ git bundle create ~/mybundle master..mybranch

다른 저장소에서 저걸 가져오려면, 예의상 먼저

$ git bundle verify ~/mybundle

로 검사부터 해 주고.

가져오는 방법은 다양하게 할 수 있다.

이렇게 바로 git pull 할 수도 있지만...

$ git pull ~/mybundle

이렇게 fetch + cherry-pick 할 수도 있고...

 $ git fetch ~/mybundle

$ git cherry-pick FETCH_HEAD

아니면 이렇게 fetch + rebase도 된다. (커밋이 여러개이고, 가져오는 저장소의 히스토리와 일렬로 늘어놓고 싶다면)

$ git fetch ~/mybundle

$ git rebase HEAD FETCH_HEAD

fetch 할때 브랜치 이름을 지정할 수도 있다.

$ git fetch ~/mybundle mybranch:mybranch_from_bundle

원격 저장소를 공유하지 않는 상태에서 이렇게 번들 파일을 주고 받으면서 공유할 수도 있고, 원격 저장소로의 push가 엄격히 제한이 되어 있어 push 하기는 곤란한 경우 다른 로컬 저장소에 적용해서 테스트 해 보려면 이렇게 번들을 쓰면 편하다. rebase, cherry-pick도 사용가능하니 여러 커밋들을 선택적으로 추출하거나 base가 달라 rebase를 해야 하는 경우 등에서도 patch file에 비해 훨씬 편하다.