에볼루션 호환성과 한메일 버그들

그놈 에볼루션은 비교적 최근에 만들어진 메일 프로그램이라서 그런지 인터넷 메일의 표준에는 맞지만 현실과는 동떨어진 방식으로 동작하기도 한다. 슬프게도 한글과 관련된 부분에서 그런 모습이 많이 보인다.

예를 들어 좀 구버전의 MS-Outlook 혹은 MS-Outlook Express에는 헤더를 RFC2047 인코딩할 때 UTF-8로 인코딩하면 제대로 읽지를 못했다. 멀티바이트 인코딩은 본문 인코딩과 관계없이 대충 UTF-8로 보내는 정책을 사용했기 때문이다. 이렇게 동작하는 게 틀린 건 전혀 아니고, RFC2047을 지원하면서 UTF-8 인코딩이 지원되는 환경이므로 당연히 MS-Outlook의 잘못이고, 이 제목이 제대로 읽히도록 MS가 Outlook을 고쳐야 하는 게 맞다. 하지만 현실적으로 MS-Outlook은 사용자가 많아서 무시하기 힘든데다가 상업용 소프트웨어는 이러한 버그가 수정되려면 너무 오래 걸린다. (최근 버전에 고쳐질 때까지 2-3년은 걸린 듯)  표준을 지키는 다른 방법이 있으면서, 많이 사용하는 프로그램의 버그를 피해가는 방법이 있다면 꼭 에볼루션이 맞다고 고집할 필요는 없지 않을까? 하지만 게으른 개발자의 속성상 자기 잘못도 아닌데 귀찮게 고치기도 힘들 노릇이어서 결국 아직까지도 그렇게 동작한다. 내가 직접 본문이 EUC-KR일 때 제목이 EUC-KR 인코딩되도록 패치까지 만들었지만, 적용될 수는 없었다. (기술적인 이유도 있었다. 에볼루션의 코드의 메일 처리 라이브러리쪽에서 헤더를 독립적으로 UTF-8 인코딩해 버리는 구조였는데, 메일 설정이 넘어가도록 고치려면 상당히 귀찮은 작업이 필요하다.)

오히려 이런 문제는 MS-Outlook같은 데스크탑 프로그램보다는 각종 웹메일들에서 특히 잘 드러난다.  (아무래도 웹메일들이 데스크탑용 프로그램보다는 메일 표준을 구현한 완성도가 비교적 떨어지는 게 사실이다.)  마침 한메일이 개선사항을 모집한다고 하니 에볼루션과 한메일이 메일을 주고받을 때 생기는 버그 및 기타 리눅스 환경에서 생기는 문제를 짚어본다.

(1) Q 인코드된 제목의 디코딩

이 문제는 보고를 했는데 고객센터에서도 전달되었다고 하고, 다른 경로(?)로도 전달되었는데 우선순위가 밀렸는지 아직 버그가 남아 있는 상태이다.

위의 예에서와 같이 에볼루션에서 보내는 메일의 한글 제목은 UTF-8 인코딩하게 되는데, 그것도 Quoted Printable 인코딩이다. 그런데 에볼루션에서 메일을 이렇게 보내면,

한메일에서는 이렇게 공백이 밑줄로 나온다..

그런데 이상하게도 클릭해서 본문을 읽어보면 제대로 나와 있다.

Subject: =?UTF-8?Q?=EC=A0=9C=EB=AA=A9?=
        =?UTF-8?Q?_=ED=85=8C=EC=8A=A4=ED=8A=B8?=

"제목 테스트"라는 제목을 UTF-8 QP 인코딩하면 위와 같이 된다. RFC2047에 따르면 Quoted Printable을 디코딩할 때 밑줄(_)을 공백으로 해석해야 하는데 실수를 한 것 같다. 그런데 대체 왜? 메일 본문을 읽어보면 제대로 나오는 걸까? 메일 목록과 메일 본문의 QP 디코드 코드가 다른 걸까?


(2) 첨부파일 내용 인코딩

에볼루션이 아니라 (이제 거의 모두 UTF-8환경인) 리눅스 환경과의 호환성 문제이지만, 첨부 파일의 Content-Type의 charset 정보를 제대로 인식하지 않는다.

Content-Type의 charset 정보를 무시하고 EUC-KR로 해석하는 듯?
 

--=-ObVHrT1mp3C0HEttZi/U
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; name*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
 
=EC=97=90=EB=B3=BC =EB=A7=8C=EC=84=B8
 
 
--=-ObVHrT1mp3C0HEttZi/U--

(3) EUC-KR 페이지의 한계

다음이 많은 부분에서 UTF-8 페이지로 변환하고 있지만, 아직 한메일은 그렇지 못하다. 그래서 아무래도 해외 메일을 받는 용도로는 한계가 있을 수밖에 없다. 일본어 메일만 해도 많은 한자가 물음표 투성이가 된다.

(4) 보너스#1 - 빈 파일을 첨부하면

이 글을 쓰면서 발견한 건데...  사이즈가 0인 파일을 첨부한 다음에 첨부한 파일을 열려고 하면 오류가 발생한다.

--=-Jc22aP0z5j1kvSIVKmG+
Content-Description: =?UTF-8?Q?=EC=97=90=EB=B3=BC?=
    =?UTF-8?Q?_=EB=A7=8C=EC=84=B8=EC=97=AC?=
Content-Disposition: attachment; filename*=UTF-8''%EC%97%90%EB%B3%BC%20%EB%A7%8C%EC%84%B8.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
 
 
--=-Jc22aP0z5j1kvSIVKmG+--

(5) 보너스#2 - HTML 메일이 싫어요~

또 찾아낸 명백한 버그, 보낼때 하단에 있는 옵션을 어떻게 하든 항상 HTML 메일만 날아온다.

티보이제이션?

최근 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는 시대를 잘못 타고났다?)