티보이제이션?

최근 GPLv3와 관련된 글들을 보면 티보이제이션(tivo-isation)이란 말이 등장한다. FSF가 만들어낸 이 말은 프로그램이 오픈소스로 배포된다고 해도, 실제적으로 수정한 걸 적용할 수 없기 때문에 무용지물이 되도록 만드는 조치를 말한다.

티보(TiVo)는 디지털 비디오 레코더 분야에서 한 획을 그은 제품이다. 테이프 VCR을 대체하는 TV를 녹화하는 장비인데, 광고를 건너뛰고 녹화하는 기능이라던지, electronic program guide를 (EPG) 활용해 방송시간 변경같은 것에 유연하게 대처한다든지, 요즘 우리나라 전자회사들이 타임머신이라는 이름으로 고가 TV에 내장하고 있는 타임쉬프트 기능 등을 실제 구현해서 시장에서 성공한 최초의 제품이다.  주체하기 힘들게 다양한 채널과 다양한 컨텐츠로 (그리고 지나치게 많은 광고로) 고민해야 하는 미국 시청자들에게 잘 어필하는 제품이다. 또 한가지 재미있는 점은 리눅스 OS 기반이라는 것. 리눅스 기반 장치가 드문 일은 아니지만 10여년전부터 지금까지 ppc 리눅스를 계속 써 왔다는 건 흥미로운 일이다.

하지만 실제로 최근 버전의 티보 하드웨어에서는 사용자가 직접 소스코드를 수정해서 티보 장치에 적용하는 건 불가능하다. 계속되는 hack에 고민하던 티보측에서는 (리눅스 소스를 감출 수는 없으니) 디지털 사인을 체크하는 장치를 달아서 제 3자가 수정한 소프트웨어는 설치하지 못하는 장치를 부착했다. 이것이 티보이제이션이다. (물론 납땜질을 통한 하드웨어적인 hack들이 나왔지만..)

티보가 이렇게 하는 이유는 보안을 위한 것이다...라고 말하기도 하지만(!), 티보 플랫폼에 대한 컨트롤을 놓지 않으려는 수단이기도 하다. 요즘은 부품 가격이 꽤 내려가서 그럴 필요가 없을 지 모르지만..  티보를 만들 당시에만 해도 CPU, HDD, 비디오 코덱 따위를 부착한 디지털 레코더는 도저히 소비자가 가전제품으로 구입할 수 있을 정도의 원가가 나오지 않았다. 그래서  티보는 질레트 면도기, 잉크젯 프린터, playstation과 비슷하게 수익 모델을 가져갔다. 티보 기계는 원가보다 싸게 팔면서, TV 프로그램 가이드를 제공하는 서비스의 subscription fee 등을 통해 손해를 보전하는 것이다. 요즘은 부품 가격이 떨어져서 사정이 많이 달라졌지만 여전히 subscription fee가 수익의 큰 부분을 차지한다. 그런데 만약 누군가가 티보 소스 코드를 수정해서 티보의 공식 서비스가 없이도 잘 동작하도록 무료 EPG 사이트와 연결시키는 펌웨어를 만든다면 티보측으로서는 낭패일 수밖에 없다. 디지털 사인 기술을 보안 용도만으로 사용하는 게 아닌 건 분명하다.

GPLv3에 반대하는 입장인 리누스 토발즈의 주장은 소프트웨어 라이센스는 소프트웨어에 국한해야 하고 하드웨어를 컨트롤할 수는 없지 않느냐라는 것이고, 어차피 소스코드가 있으면 다른 기계에서 돌릴 수도 있지 않느냐고 한다. 하지만 티보이제이션에 반대하는 사람들 입장은 이렇게 되면 실제로 소스코드 변경이 이루어지기 힘들어서 GPL이 보장한 수정과 재배포를 사실상 무력화시키는 거라고 말한다. 특히 개정되기 전에 표현이 너무 포괄적이었던 GPLv3 draft에서는 무고한 DRM enabled media의 사용자가 GPLv3를 위반하는 모호한 상황이 벌어질 수도 있었는데, 개정을 통해서 "티보"와 같이 코드 수정을 사실상 못하게 하는 의도만을 걸러낼 수 있게 된 것 같다. (너무 포괄적으로 썼다가는 데비안의 "아카이브 키"도 GPLv3에 따르면 위반이 되는 경우가 있다...  데비안은 아카이브 키를 무시하는 방법이 있으니까 수정을 못하게 하지는 않는다.)

리눅스 특허 FUD - LG전자 slashdotted

얼마전에 LG전자와 마이크로소프트의 특허협약을 했다는 상당히 긍정적인 논조의 뉴스가 나왔었는데, slashdot에서 그 협약을 자세히 확인해 주었다.  리눅스가 마이크로소프트의 250여개의 특허를 침해했다는 FUD에 대해 Novell과 Xandros에 이어 걸려든 것이다. LG전자가 이 문제를 심각하게 고려한 것 같지는 않고, 전형적인 기업간의 포괄적 특허 크로스 라이센싱 계약에 덩달아서 MS가 리눅스 특허가 끼어든 것으로 보인다.

아무리 리눅스 관련자들이 "Sue me first, microsoft" 리스트에 자기 이름을 올려 놓아도 MS는 명백히 "특허 침해자"라고 할 수 있는 이 사람들과 상대할 생각이 없어 보인다. 왜냐하면 FUD의 목적은 FUD가 널리 퍼져서 사람들의 인식에 관념을 심어주는 것이지, 그 FUD가 진실인지 여부가 밝혀지는 건 중요하지 않기 때문이다. 게다가 이러한 기업간의 특허 협박, 특허 방어, 특허 라이센스 상호 계약이야말로 오늘날 기업화된 (특히 미국의) 특허제도를 가장 효율적으로 활용하는 방법이니까.

어쨌든 거대기업이 이러한 FUD에 걸려드는 일은 그 FUD를 크게 강화시키는 것이다. 아마도 또 다른 기업을 상대할 때 레퍼런스가 될 것이다. "LG전자도 우리 특허를 인정했다"라고 또 다른 기업을 협박할 것이다. 과연 지금의 FUD가 얼마나 성공할 지, 250여개라는 특허가 정말 뭔지 밝혀질지 여부는 모르겠지만, LG전자는 MS의 작전에 크게 기여했다.

(현재 Novell은 직접적인 언급을 회피하고 있고, Xandros는 크로스라이센싱을 했지만 리눅스는 특허 침해 대상으로 생각하지 않는다고 밝혔다.)

(업데이트) 삼성전자도 이미 걸려들었었다.

SVN branching/tagging

왜 CVS에서 한 개의 이름으로 표현되었던 branch와 tag가 SVN에서는 repository의 directory copy로 바뀐 걸까?  branch/tag/merge가 난무하는 프로젝트에서는 이렇게 branch와 tag에 사용자가 정의한 policy가 동원되어야 하는 점은 큰 불편으로 다가온다.  예를 들어 SVN 매뉴얼의 가이드라인을 따라서 branch를 /branches, tag를 /tags에 copy한다고 할 때, 무슨 branch가 있는 지 살펴본 다음 어떤 branch와 trunk 사이의 diff를 뽑아내고 싶다라면

svn info (URL이 뭐더라?)
svn ls svn+ssh://server.name/project/branches/ (무슨 branch가 있더라?)
svn diff svn+ssh://server.name/project/branches/branch-stable svn+ssh://server.name/project/trunk

문제는 branch/tag/merge와 관련된 작업을 하기 위한 모든 명령에 URI를 입력해야 한다는 점이다. 그리고 매번 이 project가 branch/tag에 어떤 copy policy를 쓰고 있는지 상기해야 한다.

svn merge svn+ssh://server.name/project/tags/branch-stable-merged-YYYYMMDD \
        svn+ssh://server.name/project/branches/branch-stable

merge할 때도 역시 repository의 위치와 project의 tag/branch policy를 머리속에 떠올리면서 절대 URI를 입력해야 한다. merge한 포인트가 어디인지 기록이 남지 않는다는 (그래서 별도 tag로 남기기도 하는) 점은 CVS랑 똑같으니까 어쩔 수 없다고 해도, 더 명령을 입력하기 불편해졌다.


애초부터 tag와 branch가 directory와 copy라는 단일한 기능으로 커버한다는 게 어색한 이야기이다. CVS에서는 분명한 branch와 tag 기능들을 (CVS의 branch가 딱히 쓰기 좋은 것도 아니지만) SVN에서는 directory 구조와 copy로 일반화하면서 구분이 없어지고 사용자의 재량에 맡겨 버리고 말았다. 왜 사용자가 tag되어 있는 파일들을 checkout받아서 고쳐서 커밋할 수 있는 걸까?  왜 branch 아래에 있는 디렉토리를 다른 branch로 mv할 수 있는 걸까?  물론 이렇게 쓰면 안 되지만, 이렇게 쓰면 안 된다는 정책을 소프트웨어에서 제공하는 게 아니라 사용자의 정책에 맡겨 놓는 바람에 사용하기가 복잡해졌다.

X 스펙과 실제

debconf6 동영상에서 keith packard가 말한 xorg 관련 비디오를 보다가 (대충 기억나는 대로 재구성 번역):

X 스펙은 렌더링 방법을 픽셀 단위로 정확하게 기술하고 있습니다. 이게 좋다고 생각하는 분?  한 분인가요?  틀렸습니다.  사람들은 모두 그 의견에 반대합니다.  정확한 픽셀 렌더링을 규정하면 구현하기도 쉽고 테스트할 때는 특히 좋습니다. 정확히 어떤 픽셀에 렌더링됐는지 검사하면 되니까요.  하지만 사용자는 더 빠른 걸 원하고 정확한 픽셀에는 신경쓰지 않습니다.
...
일례로 대부분의 그래픽 하드웨어는 선을 그릴때 정확한 Bresenham 알고리즘을 사용하지 않고 feedback이 필요없기 때문에 더 빠른 DDA 알고리즘을 사용하지만 X spec에는 Bresenham을 사용한다고 정해져 있습니다.
...
결과적으로, X implementation이 선과 폴리곤을 그릴때 느려 터졌었습니다. spec에 있는 그대로 구현해야 했거든요.

(X는 시대를 잘못 타고났다?)

lifepod API 인증 C (libsoup) 예제

며칠에 걸쳐서 잠깐 잠깐씩, 재미가 없으면 내버려뒀다가 다시 생각나면 좀 만져보고 하는 일을 반복한 끝에...

lifepod openAPI의 인증 부분을 짰습니다.  며칠에 걸쳐서 lifepod API 서버의 버그로 잠깐 헤매다가, open ID에 http://를 넣었다가 뺐다가, 해시 부분을 소문자로 써야 하는 API의 숨겨진 사실을 깨닫기도 하다가, gnutls_fingerprint() 함수의 버그성 동작에 헷갈리다가 하면서 인증 부분만 완료.

• 상단의 openid, userkey, appid, appkey는 자기에 맞게 바꾸세요.
  
• 컴파일은 gcc -o example-lifepod `pkg-config --cflags libsoup-2.2` example-lifepod.c `pkg-config --libs libsoup-2.2`
• 스프(libsoup)는 GObject를 이용해서 만든 것이라서, synchronous하게 쓰려면 상관없지만 asynchronous하게 사용하려면 glib main loop가 필요합니다.

example-lifepod.c

사실 인증보다 더 어려운 건 response로 날아온 XML을 파싱하는 거지만 그건 다른 종류의 내공이니까요. evolution frontend를 만드려고 했지만, evolution이 내부 데이터로 ical을 쓰고 있기 때문에 이건 lifepod xml to/from ical 변환 프로그램 만드는 꼴이 될 듯 합니다. 또 잠시 접어뒀다가 생각나면 조금씩 해 봐야죠.

그놈 패널 배경 그림..

"Just works"의 UI 철학에 따라(?) 패널에 배경 이미지를 씌울 수 있는 기능이 왜 있는지 잘 이해가 되지 않았다.  마침 그놈 사용자 안내서를 읽다가 드래그로 그놈 패널의 배경을 설정할 수 있다는 걸 발견, 노틸러스에서 "바탕색 및 꼬리표" 대화 창을 띄웠다.

얼마전 예비군 훈련을 갔다와서 빨아 놓은 군복을 정리하지 않은 지금...  "위장" 색을 패널에 끌어 놓아 보기로 했다.  (예비군 군복보다는 자이툰 부대 군복이랑 비슷한 것 같지만..)

앗!  정말 "위장" 효과가 있다.  패널이 눈에 잘 안 들어온다.

이렇게 하면 오히려 시야가 애플리케이션 창에 집중되서 패널에서 아무리 CPU 로드 그래프를 그려대고 깜박이는 거에 상관없이 집중할 수 있다. 

단, 패널을 볼 때도 패널이 눈에 잘 안 들어온다...

pootle의 가장 큰 문제는

온라인 번역 시스템으로 pootle을 심각하게 고려해 보았으나 결론은...

못 쓰겠다 (적어도 지금은)

그리 나쁘다라는 게 아니다. pootle은 매우 간결하고, PO 파일을 백엔드로 사용해서 그런지 PO 파일 번역에 좋고 훌륭하게 처리한다. 사용자별로 권한레벨을 분리해 놓았고, translation-toolkit에 잘 구성되어 있는 파이썬 모듈을 이용해 메세지별로 온갖 체크를 온라인에서 할 수 있다.  (여기에 KPC를 붙이면 금상첨화)  이정도만 되도 일단 시작하는 데 문제가 될 일이 없다. launchpad가 우분투 스케줄대로 움직이고 closed source이기 때문에 직접 컨트롤할 수 있는 웹 번역 시스템은 pootle이 유일하다. 하지만, 결정적인 문제는,

기록이 안 남는다

아무리 후지고 완성도가 시스템이라고 해도 개선의 여지가 있으면 그래도 일단 돌리고 볼 텐데, 당장 반달리즘으로 작업물이 날아갈 수 있다는 점은 참 어려운 이야기이다. 백엔드가 PO 파일이기 때문에 PO 파일을 그냥 고쳐버린다. RDBMS를 쓸 필요까지야 없겠지만 백엔드의 한계때문에 변경 사항의 기록을 남기도록 고치는 것도 매우 힘들다.